На сколько детальные должны быть постановки задач?

1. FreeArcher 162 02.12.20 05:15 Сейчас в теме
Приветствую!
Я разработчик уже с опытом, но теперь работаю в новой роли постановщика задач (задачи внутренние). Мне приходит задача, а я должен расписать её для программистов и оценить ориентировочное время. По большей части это не проекты, а задачи, от 2 до 20 часов на разработку.

И я все время задаюсь вопросом, насколько детальной должна быть постановка?

Вариант 1: это детально расписать, что сделать. Добавить регистр, с таким то набором измерений и ресурсов, на форму документа добавить поля и кнопки, по нажатию кнопок выполнить действия и в таком духе.
Постановка - подарок. По скольку я сам остаюсь разработчиком и мне приходиться выполнять задачи, то по такой постановке просто делаешь и не "греешь" голову.
Минусом этого подхода является то, что, во-первых, сложно описать все нюансы, а во-вторых можно ошибиться с решением. Мы же знаем, что пока не начнешь делать, всех подводных камней не узнаешь.
Тут ещё такой психологический момент у меня возникает, разрабатывая ТЗ я ставлю себя на место разработчика и составляю ТЗ ни как нужно и удобно постановщику, а как легче сделать.

Вариант 2: это описать задачу с точки зрения пользователя. Т.е. просто более расширено и детально, описать какие потребуются проверки, и как функционал будет сопрягаться с другим функционалом и т.д. Программисту самому придется решать, как выполнять задачу. Тут можно абстрагироваться от разработки и составить красное ТЗ (главное чтобы оно на тебя не упало )) ).

Вопрос мой, ни в том, как правильно, а в том, как вы составляете ТЗ или какое ТЗ вам бы хотелось видеть перед собой? Поделитесь опытом.
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
10. Vitaly1C8 02.12.20 09:55 Сейчас в теме
(1) на мой взгляд все упирается в исполнителя; Из своего опыта скажу, - бывало распишешь все подробно (по варианту 1) что надо сделать, как надо сделать ... В итоге программист делает по своему ?! Почему ? Зачем ? Да лучше бы я сам сделал ... А ничего не поделаешь, его квалификация такая. Он тупо дочитать до конца твое тз не может/не хочет.
Поэтому если есть толковый программист, нужно стараться работать по варианту 1.
Если такого программиста нет, придется работать по варианту 2. Расписывать крупноблочно что делать, и что должно получиться на выходе (а вот как делать в деталях описывать не стоит)
user623969_dusa; +1 Ответить
2. D_e_X_T_e_R 575 02.12.20 05:59 Сейчас в теме
Я делаю так, раз я постановщик, то соответственно я полностью проектирую задачу, сразу указываю где создавать объекты и куда вносить код, например, в расширении или в самой конфигурации. Делаю скриншоты, как должны выглядеть формы. Тут ведь как, чем лучше и понятнее поставишь задачу, тем больше шансов, что на выходе получится именно то, что я хотел увидеть. Единственное, что оставляю на программиста - это сам программный код, описываю только действия, которые должны отрабатывать при том или ином событии, а реализация уже на разработчике, так что создать или нет общий модуль, сделать или нет запрос в цикле - за это уже отвечает программист.
3. HAMAZ 8 02.12.20 07:28 Сейчас в теме
Люди разные идут в программисты. Кому-то нужно полностью задачу "разжевать", вплоть до того какие индексы сделать в регистре сведений или четко указать, что префиксацию номера использовать в новом документе (хотя до этого везде использовали, но человеку лень подумать)
А кто-то, в силу опыта или аналитического склада ума, сам может реализовать задачу, имея на руках некое укрупненное понимание задачи.
Резюмируя:в постановке задач нужна гибкость
4. Swetlana 27 02.12.20 08:28 Сейчас в теме
Для программиста сложно когда задача ставится чисто как функциональная, т.е. только общее описание задачи, известно же что дьявол в мелочах. И сложно когда задача стоит чисто подробная с точки зрения разработчика, когда нет общего понимания задачи и ты не в теме вопроса.
Мне ставят задачи пользователи чисто функциональные, с нечетким описанием задачи. т.е. вообще без алгоритмизации на уровне условий, хочу так и все, без понимания что условия меняются и как быть в таком случае не понятно
Я сейчас на новом месте работаю и пользователи ставят задачи очень нечетко, когда вызвали к руководству с обсуждением то стало понятно что пользователи неверно поняли задачу либо руководство им объясняло им не совсем так, потому что руководство тоже меняет свои мнения))
5. starjevschik 02.12.20 08:53 Сейчас в теме
п. 1 наверное правильно.
П. 2 - для него не нужен отдельный постановщик задачи, пользователь описал свои желания, программист понял, что нужно и сделал правильно. Должность постановщика задачи становится лишней, он просто ретранслятором работает, получается так. Добавляет испорченности телефону.
7. Swetlana 27 02.12.20 09:10 Сейчас в теме
(5) в данном случае постановщик задач это по сути и консультант и он необходим. Иначе придется программисту бегать и выяснять суть задачи
6. texnic79 43 02.12.20 08:53 Сейчас в теме
Свои пять копеек вставлю. Если предполагается интерактивная работа пользователя, то описание, а ещё лучше проект диалогового окна очень важен. Желательно указать архитектуру (на каких видах регистров делать и т.д.) и какие специфические действия на форме. Все остальное это на совести программиста. Если приходится программисту расписывать все детально, то проще самому реализовать.
8. hiduk 128 02.12.20 09:40 Сейчас в теме
У меня мысли такие.
Первое, интересно будет, если ты этот вопрос задашь своим программистам:) Наверняка среди них есть люди которые могут работать и так и эдак.
Второе, неплохо бы поговорить с твоим руководителем об этом. Наверняка, не просто так они ввели такие обязанности.
Третье, есть такое понятие как требования к программному обеспечению. Это описание функционала на языке пользователя. Чем детальнее они будут тем лучше. И обязательно они должны быть согласованы. Требования описывают ЧТО нужно сделать, а ТЗ - КАК. И понять чего будет достаточно (требований или ТЗ) в твоем случае можно только пройдя первые 2 пункта...
9. homer_ 79 02.12.20 09:42 Сейчас в теме
Есть передаст задачи от пользователя к программистам (сделано что бы программисты не общались с пользователями и не отвлекали их от задач), а есть архитектор (все продумывает и учитывает при проектировании в том числе юзабилити) . Вы уж определитесь кто вы.
+ Все зависит от программистов, есть тупни, а есть эстеты.
11. FatPanzer 02.12.20 10:34 Сейчас в теме
(9)
Все зависит от программистов, есть тупни, а есть эстеты.
Это вы еще просто с эстетствующими тупнями не встречались, видимо...
12. FatPanzer 02.12.20 10:38 Сейчас в теме
Все зависит от бюрокартии и политики партии.

Если у вас аутсорсеры - им надо расписывать все по пунктикам, а потом за каждый пунктик драть (ждать от них вовлечения в бизнес-процессы не приходится).
Если у вас внутренний штат - то их надо посвящать в детали процесса и дальше они сами могут разобраться в алгоритмах при наличии квалификации...
Если у вас есть отдел тестировщиков - надо расписывать так, чтобы те тоже поняли - а чего собственно тут надо проверять и как должно работать в ожидаемом результате?
Если у вас вредные заказчики - расписывать надо все до мелочей, чтобы потом не придирались (даже если у вас суперские разработчики, понимающие с полуслова)...

Все зависит от бюрократии и политики партии, да. И от взаимоотношений с заказчиком (внутренним или внешним).
t278; m_nazar; +2 Ответить
13. user1464234 02.12.20 10:50 Сейчас в теме
Из лекций Глеба Стального сделала вывод что тз должно состоять из функциональной модели-прототипа с каким-то набором данных и текстовых уточнений к этой конкретной модели.
Как должно выглядеть ТЗ разработку с нуля какой-то системы вообще непонятно.
14. FatPanzer 02.12.20 10:52 Сейчас в теме
(13) Это чудо еще в профессии? Чистой воды профанатор.
15. FreeArcher 162 04.12.20 05:39 Сейчас в теме
(13) Не, с таким подходом быстрее самому сделать, чем писать ТЗ.
user1464234; +1 Ответить
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот