На сколько детальные должны быть постановки задач?
Приветствую!
Я разработчик уже с опытом, но теперь работаю в новой роли постановщика задач (задачи внутренние). Мне приходит задача, а я должен расписать её для программистов и оценить ориентировочное время. По большей части это не проекты, а задачи, от 2 до 20 часов на разработку.
И я все время задаюсь вопросом, насколько детальной должна быть постановка?
Вариант 1: это детально расписать, что сделать. Добавить регистр, с таким то набором измерений и ресурсов, на форму документа добавить поля и кнопки, по нажатию кнопок выполнить действия и в таком духе.
Постановка - подарок. По скольку я сам остаюсь разработчиком и мне приходиться выполнять задачи, то по такой постановке просто делаешь и не "греешь" голову.
Минусом этого подхода является то, что, во-первых, сложно описать все нюансы, а во-вторых можно ошибиться с решением. Мы же знаем, что пока не начнешь делать, всех подводных камней не узнаешь.
Тут ещё такой психологический момент у меня возникает, разрабатывая ТЗ я ставлю себя на место разработчика и составляю ТЗ ни как нужно и удобно постановщику, а как легче сделать.
Вариант 2: это описать задачу с точки зрения пользователя. Т.е. просто более расширено и детально, описать какие потребуются проверки, и как функционал будет сопрягаться с другим функционалом и т.д. Программисту самому придется решать, как выполнять задачу. Тут можно абстрагироваться от разработки и составить красное ТЗ (главное чтобы оно на тебя не упало )) ).
Вопрос мой, ни в том, как правильно, а в том, как вы составляете ТЗ или какое ТЗ вам бы хотелось видеть перед собой? Поделитесь опытом.
Я разработчик уже с опытом, но теперь работаю в новой роли постановщика задач (задачи внутренние). Мне приходит задача, а я должен расписать её для программистов и оценить ориентировочное время. По большей части это не проекты, а задачи, от 2 до 20 часов на разработку.
И я все время задаюсь вопросом, насколько детальной должна быть постановка?
Вариант 1: это детально расписать, что сделать. Добавить регистр, с таким то набором измерений и ресурсов, на форму документа добавить поля и кнопки, по нажатию кнопок выполнить действия и в таком духе.
Постановка - подарок. По скольку я сам остаюсь разработчиком и мне приходиться выполнять задачи, то по такой постановке просто делаешь и не "греешь" голову.
Минусом этого подхода является то, что, во-первых, сложно описать все нюансы, а во-вторых можно ошибиться с решением. Мы же знаем, что пока не начнешь делать, всех подводных камней не узнаешь.
Тут ещё такой психологический момент у меня возникает, разрабатывая ТЗ я ставлю себя на место разработчика и составляю ТЗ ни как нужно и удобно постановщику, а как легче сделать.
Вариант 2: это описать задачу с точки зрения пользователя. Т.е. просто более расширено и детально, описать какие потребуются проверки, и как функционал будет сопрягаться с другим функционалом и т.д. Программисту самому придется решать, как выполнять задачу. Тут можно абстрагироваться от разработки и составить красное ТЗ (главное чтобы оно на тебя не упало )) ).
Вопрос мой, ни в том, как правильно, а в том, как вы составляете ТЗ или какое ТЗ вам бы хотелось видеть перед собой? Поделитесь опытом.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) на мой взгляд все упирается в исполнителя; Из своего опыта скажу, - бывало распишешь все подробно (по варианту 1) что надо сделать, как надо сделать ... В итоге программист делает по своему ?! Почему ? Зачем ? Да лучше бы я сам сделал ... А ничего не поделаешь, его квалификация такая. Он тупо дочитать до конца твое тз не может/не хочет.
Поэтому если есть толковый программист, нужно стараться работать по варианту 1.
Если такого программиста нет, придется работать по варианту 2. Расписывать крупноблочно что делать, и что должно получиться на выходе (а вот как делать в деталях описывать не стоит)
Поэтому если есть толковый программист, нужно стараться работать по варианту 1.
Если такого программиста нет, придется работать по варианту 2. Расписывать крупноблочно что делать, и что должно получиться на выходе (а вот как делать в деталях описывать не стоит)
Я делаю так, раз я постановщик, то соответственно я полностью проектирую задачу, сразу указываю где создавать объекты и куда вносить код, например, в расширении или в самой конфигурации. Делаю скриншоты, как должны выглядеть формы. Тут ведь как, чем лучше и понятнее поставишь задачу, тем больше шансов, что на выходе получится именно то, что я хотел увидеть. Единственное, что оставляю на программиста - это сам программный код, описываю только действия, которые должны отрабатывать при том или ином событии, а реализация уже на разработчике, так что создать или нет общий модуль, сделать или нет запрос в цикле - за это уже отвечает программист.
Люди разные идут в программисты. Кому-то нужно полностью задачу "разжевать", вплоть до того какие индексы сделать в регистре сведений или четко указать, что префиксацию номера использовать в новом документе (хотя до этого везде использовали, но человеку лень подумать)
А кто-то, в силу опыта или аналитического склада ума, сам может реализовать задачу, имея на руках некое укрупненное понимание задачи.
Резюмируя:в постановке задач нужна гибкость
А кто-то, в силу опыта или аналитического склада ума, сам может реализовать задачу, имея на руках некое укрупненное понимание задачи.
Резюмируя:в постановке задач нужна гибкость
Для программиста сложно когда задача ставится чисто как функциональная, т.е. только общее описание задачи, известно же что дьявол в мелочах. И сложно когда задача стоит чисто подробная с точки зрения разработчика, когда нет общего понимания задачи и ты не в теме вопроса.
Мне ставят задачи пользователи чисто функциональные, с нечетким описанием задачи. т.е. вообще без алгоритмизации на уровне условий, хочу так и все, без понимания что условия меняются и как быть в таком случае не понятно
Я сейчас на новом месте работаю и пользователи ставят задачи очень нечетко, когда вызвали к руководству с обсуждением то стало понятно что пользователи неверно поняли задачу либо руководство им объясняло им не совсем так, потому что руководство тоже меняет свои мнения))
Мне ставят задачи пользователи чисто функциональные, с нечетким описанием задачи. т.е. вообще без алгоритмизации на уровне условий, хочу так и все, без понимания что условия меняются и как быть в таком случае не понятно
Я сейчас на новом месте работаю и пользователи ставят задачи очень нечетко, когда вызвали к руководству с обсуждением то стало понятно что пользователи неверно поняли задачу либо руководство им объясняло им не совсем так, потому что руководство тоже меняет свои мнения))
п. 1 наверное правильно.
П. 2 - для него не нужен отдельный постановщик задачи, пользователь описал свои желания, программист понял, что нужно и сделал правильно. Должность постановщика задачи становится лишней, он просто ретранслятором работает, получается так. Добавляет испорченности телефону.
П. 2 - для него не нужен отдельный постановщик задачи, пользователь описал свои желания, программист понял, что нужно и сделал правильно. Должность постановщика задачи становится лишней, он просто ретранслятором работает, получается так. Добавляет испорченности телефону.
Свои пять копеек вставлю. Если предполагается интерактивная работа пользователя, то описание, а ещё лучше проект диалогового окна очень важен. Желательно указать архитектуру (на каких видах регистров делать и т.д.) и какие специфические действия на форме. Все остальное это на совести программиста. Если приходится программисту расписывать все детально, то проще самому реализовать.
У меня мысли такие.
Первое, интересно будет, если ты этот вопрос задашь своим программистам:) Наверняка среди них есть люди которые могут работать и так и эдак.
Второе, неплохо бы поговорить с твоим руководителем об этом. Наверняка, не просто так они ввели такие обязанности.
Третье, есть такое понятие как требования к программному обеспечению. Это описание функционала на языке пользователя. Чем детальнее они будут тем лучше. И обязательно они должны быть согласованы. Требования описывают ЧТО нужно сделать, а ТЗ - КАК. И понять чего будет достаточно (требований или ТЗ) в твоем случае можно только пройдя первые 2 пункта...
Первое, интересно будет, если ты этот вопрос задашь своим программистам:) Наверняка среди них есть люди которые могут работать и так и эдак.
Второе, неплохо бы поговорить с твоим руководителем об этом. Наверняка, не просто так они ввели такие обязанности.
Третье, есть такое понятие как требования к программному обеспечению. Это описание функционала на языке пользователя. Чем детальнее они будут тем лучше. И обязательно они должны быть согласованы. Требования описывают ЧТО нужно сделать, а ТЗ - КАК. И понять чего будет достаточно (требований или ТЗ) в твоем случае можно только пройдя первые 2 пункта...
Есть передаст задачи от пользователя к программистам (сделано что бы программисты не общались с пользователями и не отвлекали их от задач), а есть архитектор (все продумывает и учитывает при проектировании в том числе юзабилити) . Вы уж определитесь кто вы.
+ Все зависит от программистов, есть тупни, а есть эстеты.
+ Все зависит от программистов, есть тупни, а есть эстеты.
Все зависит от бюрокартии и политики партии.
Если у вас аутсорсеры - им надо расписывать все по пунктикам, а потом за каждый пунктик драть (ждать от них вовлечения в бизнес-процессы не приходится).
Если у вас внутренний штат - то их надо посвящать в детали процесса и дальше они сами могут разобраться в алгоритмах при наличии квалификации...
Если у вас есть отдел тестировщиков - надо расписывать так, чтобы те тоже поняли - а чего собственно тут надо проверять и как должно работать в ожидаемом результате?
Если у вас вредные заказчики - расписывать надо все до мелочей, чтобы потом не придирались (даже если у вас суперские разработчики, понимающие с полуслова)...
Все зависит от бюрократии и политики партии, да. И от взаимоотношений с заказчиком (внутренним или внешним).
Если у вас аутсорсеры - им надо расписывать все по пунктикам, а потом за каждый пунктик драть (ждать от них вовлечения в бизнес-процессы не приходится).
Если у вас внутренний штат - то их надо посвящать в детали процесса и дальше они сами могут разобраться в алгоритмах при наличии квалификации...
Если у вас есть отдел тестировщиков - надо расписывать так, чтобы те тоже поняли - а чего собственно тут надо проверять и как должно работать в ожидаемом результате?
Если у вас вредные заказчики - расписывать надо все до мелочей, чтобы потом не придирались (даже если у вас суперские разработчики, понимающие с полуслова)...
Все зависит от бюрократии и политики партии, да. И от взаимоотношений с заказчиком (внутренним или внешним).
Из лекций Глеба Стального сделала вывод что тз должно состоять из функциональной модели-прототипа с каким-то набором данных и текстовых уточнений к этой конкретной модели.
Как должно выглядеть ТЗ разработку с нуля какой-то системы вообще непонятно.
Как должно выглядеть ТЗ разработку с нуля какой-то системы вообще непонятно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот