Так вот, про ТЗ. Как вы заметили по голосованию выше, под ТЗ все подразумевают совершенно разное, и дискуссия «что такое ТЗ» неизбежно вырождается в спор глухого с тупым - очень сложно сойтись в своих оценках, когда ты даже под одними и теми же словами понимаешь разное.
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы
Поэтому во исполнение Федеральной программы по соблюдению здравого смысла (которую я выдумал только что) я хочу призвать вас отвлечься от ТЗ и задуматься - а какую роль вообще выполняют всякие описательные документы в процессе разработки?
Этих ролей не так уж и много - всего четыре штуки.
Роль первая - выражение идеи. Когда вы придумываете продукт (будь вы заказчик или разработчик), то вы рано или поздно должны сформулировать его общую идею и донести ее до окружающих - заказчика, подрядчика, команды, начальства, самого себя, в конце концов. Хорошо, если идея будет сопровождаться еще и описанием решаемой задачи - это облегчает понимание того, нахрена вы все тут собрались. Это полезно делать как с чисто коммуникационной точки зрения, чтобы все были в курсе, так и с точки зрения планирования - сложно составлять какие-либо дорожные карты, когда ваш продукт описывается словами «ХОЧУ КАК ХЕДХАНТЕР ТОЛЬКО С БЛОКЧЕЙНОМ И ГЕОЛОКАЦИЕЙ».
Требования к подобному документу простые: ясность выражения мысли, отсутствие ненужных деталей (дабы не затуманивать идею и не влезать раньше времени в проектирование) и, самое главное, честность - если вам предстоит какая-то рискованная жопа, про это стоит начать говорить как можно раньше.
Я лично называю документы этого типа концепцией, широкие народные массы называют это по-разному - от «брифа» до «ТЗ». И это нормально: по факту, идея может рождаться на стороне заказчика и дозревать потом в руках разработчика, по ходу пьесы принимая формат самых разных документов.
Роль вторая - постановка задачи. Когда вы спроектировали продукт, то вам надо объяснить вашим разработчикам (а иногда - и самому себе), что именно вы хотите получить в итоге. Тут есть важная хитрость - степень подробности описания будет сильно зависеть от степени доверия команде: если крутому, дружественно настроенному тимлиду может быть достаточно описания уровня «вот нарисованные интерфейсы, вот общее описание процессов, давай фигачить и разбираться вместе с мелочами в процессе», то горе-разработчику с фриланс.ру нужно будет нудно расписывать, а что же вы подразумеваете под словами «при нажатии на кнопку покупки происходит добавление товара в корзину».
Схожая тема касается и формальности документа - она будет зависеть от ваших взаимоотношений с командой. Если вы работаете со своей командой, то можно использовать емкие, простые описания, если же у вас куча сменяющих друг друга подрядчиков, то не обойтись без формального, системного документа со всякими «Историями изменений», «Словарем терминов» и прочей бюрократической мутью, единственная цель которой - в случае чего схватить зарвавшегося подрядчика за яйца (об этом, впрочем, не сегодня).
Требования к этой группе документов такие: однозначность и достаточность (у вашего конкретного разработчика, который прочтет документ, не должно остаться к вам важных вопросов), а также читабельность (как правило, описания продуктов большие, и если вы сделаете документ мутным и запутанным - на пользу это никому не пойдет).
Именно эту группу документов чаще всего называют техническим заданием, потому что вся она действительно представляет собой задание на разработку. И я с этой позицией полностью согласен.
Нам осталось поговорить про третью и четвертую роли документации, а также про еще кое-какие мелочи (например, кто все это должен писать). Об этом я расскажу вам завтра, чтобы не травмировать ваш ДЕНЬ РОССИИ огромной простыней из текста.
#вашидокументы