Третья роль документов - это хранение и передача знаний. Когда вы что-то разработали, то важно задокументировать результат, чтобы потом было понятно, как все устроено. С этим в разработке всегда большая беда: подобная описательная документация или вообще не ведется (ибо некому и некогда), или же в ее роли используется тот же документ, который применялся для постановки задачи - то самое ТЗ в моей терминологии.
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы
Это однозначно плохая практика: ТЗ может не включать в себя технические детали, которые не важны на момент постановки задачи, но важны с точки зрения развития продукта (например, описание каких-то хитрых внутренних процессов или базы данных), а еще продукт в процессе разработки может сильно поменяться.
Я всегда ратую за то, чтобы процесс разработки включал в себя составление спецификаций - документа, который описывает уже сделанный продукт. Чаще всего этот документ составляется на основе ТЗ, но пишется уже после разработки и включает в себя больше деталей и актуальных нюансов. Если в дальнейшем происходит доработка продукта, то этот документ обогащается новыми разделами и деталями, но сам он остается единым.
Требования к спецификациям: однозначность, полнота (обратите внимание - не достаточность для конкретного разработчика, а полное описание всех деталей!), системность (описание всех аспектов продукта - от интерфейсов до функциональности) и читабельность.
Четвертая роль документов - это формальная фиксация договоренностей с заказчиком или подрядчиком. Тут возможны многие варианты - к договору может быть приложено как реальное ТЗ, так и формализованная концепция, а то и просто невнятная декларация о намерениях. Когда я работал с госпроектами, в норме вещей было взять нормальное ТЗ для разработчиков, отдать его в специальную контору и получить обратно лютый пакет документов на государственном языке, с которым было безумно тяжело работать, но которое хорошо укладывалось в бюрократические процедуры госзакупок.
Форматов оформления масса, и я бы выделил два главных требования к ним: соответствие ситуации (работаете с госами - подавай документацию по ГОСТу, работаете с лояльным заказчиком - расслабься и описывай общую дорожную карту) и юридически выверенный язык, поскольку этот документ все же важен с точки зрения делопроизводства и несет юридическую силу.
Тут, впрочем, будьте внимательны: как показывает моя жизнь, классное «юридическое» ТЗ является гарантией в суде, но не является гарантией качественной разработки или адекватного поведения заказчика. Да и вообще никакое ТЗ не является гарантией хорошей разработки, потому что отдельные чудилы ничего не читают и читать не собираются. Поэтому помните про Agile-манифест и заморачивайтесь не документами, а людьми.
P.S. А еще документы не обязательно должны быть текстовыми - это могут быть, например, изображения интерфейсов или схемы бизнес-процессов. Более того, одна и та же картинка может выполнять разные роли: макет интерфейса может быть иллюстрацией идеи, постановкой задачи для верстальщика, входить в состав спецификаций и прикладываться к договору. Главное - соблюдать требования, которые я описал выше.
P.P.S. Еще я вам пообещал сказать о том, кто же должен писать ТЗ. Ответ такой: да кто угодно. Главное, чтобы писать умел и свое дело знал.
P.P.P.S. Ладно-ладно, почти шучу. Вопрос про писателей документов настолько нажористый, что я про него еще отдельно расскажу.
#вашидокументы