ТЗ — зло!

В основном мы занимаемся сложными и технологичными сайтами и веб-сервисами. И часто на этапе продажи или заключения контракта наши клиенты с удивлением узнают, что мы не планируем писать ТЗ, и даже возникают диалоги: «давайте мы увеличим бюджет и вы все-таки его напишете, как же без ТЗ проект-то делать».

Или вместе с другими документами от клиента мы получаем: «вот ТЗ на 300 листов, давайте придерживаться его».

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

1. ТЗ — это долго

Просто представьте, что кто-то должен взять, внимательно разобраться со всеми деталями проекта и расписать текстом, картинками и графиками все-все нюансы его работы на те самые 300 страниц. Даже если это кто-то очень опытный и сможет выдавать по 10 качественных страниц ежедневно, создание такого документа займет больше месяца.

При разработке продуктов и сервисов время зачастую играет ключевую роль. Иногда мы слышим: «деньги не важны, но продукт мы должны получить через два месяца, иначе он просто не нужен». В таких условиях выкидывать месяц работы просто на формализацию требований кажется неоправданной роскошью.

2. ТЗ — это не точно

Если мы разрабатываем небольшой лендинг или корпоративный сайт, вполне возможно сходу написать задание, в котором учесть все нюансы его работы.

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

Кроме того, в сложных проектах зачастую на изначальном этапе просто нет возможности уточнить и четко зафиксировать все требования. Например, если речь идет о стартапе, в котором еще нет устоявшихся инструментов или бизнес-процессов, многие сценарии могут устаканиваться в процессе разработки. И в этом случае заказчик оказывается просто не готов подписать ТЗ, потому что не может быть уверен, что всё действительно должно выглядеть и работать именно так.

Также в процессе самой разработки могут появляться неожиданные сложности. Например, в нашей практике, при интеграции проекта со сторонними сервисами и системами часто возникают две проблемы:

  1. На этапе интеграции выясняется, что сервис работает не так, как это требуется нашему проекту, хотя при предварительном общении его разработчики клялись и божились, что всё работает как нужно, а даже если не работает, можно будет быстро/легко/дешево доработать.
  2. На этапе тестирования выявляются проблемы с качеством стороннего сервиса (в первую очередь связанные со стабильностью работы).

В обоих случаях нам приходится придумывать альтернативное решение, а ТЗ возвращается к автору на переработку.

3. ТЗ — это дорого

Совокупность первых двух пунктов приводит нас к выводу, что ТЗ — это дорого. Ведь недостаточно просто выделить человека, который его напишет. Этот человек (аналитик, менеджер, технический писатель) будет вынужден на протяжении всего жизненного цикла продукта поддерживать актуальность этого документа. Нам даже знаком пример, когда в проект пришлось нанять отдельного человека, который только и занимался тем, что целыми днями актуализировал ТЗ по результатам ежедневных митингов команды разработчиков.

4. ТЗ разрушает продуктивность отношений «заказчик — исполнитель»

Конечно, нельзя сказать, что само по себе наличие ТЗ создает рабочей группе какие-то барьеры. Но если отношения внутри группы не очень здоровые, ТЗ может стать козырем в рукаве при дальнейшей эскалации конфликтов. Причем, с обеих сторон.

Разработчики начнут кивать: «А покажите, где это написано в ТЗ. Нету? Значит, не делаем или с вас доп. бюджет». А клиент наоборот, может попытаться заставить реализовать всё, что написано в ТЗ, даже если всем уже очевидно, что функционал должен работать не так, либо его вообще быть не должно. Особенно часто такая ситуация встречается в гос. компаниях, где представители клиента больше беспокоятся о сохранении своих рабочих мест, а не о получении качественного результата.

Как же жить без ТЗ

То что мы не используем ТЗ, вовсе не говорит о том, что мы вообще против проектной документации. Важно не свалиться в другую крайность — хаотичную разработку, когда постоянно меняются приоритеты и требования, и зачастую в мусорку вместо устаревших листов ТЗ приходится выкидывать готовые модули, на разработку которых было потрачено гораздо больше сил и времени.

Для этого в проекте существует целый набор документов, позволяющих в любой момент времени убедиться, что реализация проекта соответствует его целям и задачам.

Паспорт проекта

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

Функциональная спецификация

В этом документе описываются требования к структуре и функционалу проекта. Основная задача этого документа — сверяться, что мы ничего не забыли на этапе аналитики и проектирования.

Главное отличие от классического ТЗ — отсутствие детализации и алгоритмизации функционала. То есть, если проекту нужны, допустим, почтовые рассылки, достаточно об этом просто упомянуть, не детализируя задачу до сценариев, при которых эти рассылки отправляются, и выбора конкретного сервиса, который будет их отправлять.

Роли и процессы

Набор документов, описывающих, кто и как будет пользоваться этим проектом. Документ с ролями содержит описание профилей пользователей и их функционала.

Документ процессов помогает создать у рабочей группы единое понимание алгоритмов работы компании, сервиса, продукта или пользовательских сценариев.

Прототипы

Прототипы превращают алгоритмы в конкретные интерфейсы и служат отправной точкой при технической разработке.

Техническая документация

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

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

Здесь же лежит вся техническая документация по сторонним сервисам (платежным системам, сервисам доставки, специализированному ПО и т.д.). Советуем даже для этой документации использовать версионность и не удалять старые версии. У нас есть один проект, где мы регулярно возвращаемся к версии документа от 2015 года, потому что разработчики этого продукта очень любят что-нибудь терять в функционале новых версий :)

Задачи в проекте

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

Руководства пользователей

Мы стараемся делать так, чтобы люди, работающие с нашими проектами, не испытывали проблем (как все любят писать в требованиях «интуитивно-понятные интерфейсы»).

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

Разумеется, комплект документов подбирается под конкретный проект. Не каждому, к примеру, требуется отдельный файл с описанием ролей. Но в целом чаще всего общий состав документации выглядит так.

Когда ТЗ всё-таки нужно

1. Если ТЗ нужно клиенту, оно нужно и вам

Никогда не забывайте, что вы работаете для своих клиентов.
Иногда клиенты понимают, что смысла в таком документе не много, но внутренние стандарты не позволяют от него отказаться. Чаще всего это касается государственных заказчиков или международных корпораций.

Если клиенту по каким-то причинам нужно ТЗ, это не должно становиться камнем преткновения. Сначала постарайтесь объяснить свою методологию и отсутствие практического смысла в таком документе. Но если клиент настаивает, просто добавьте в смету и сделайте. Только не забудьте, что помимо создания документа необходимо заложить как минимум тот же объем трудозатрат на его поддержку.

2. Работа со сторонними командами

Крутую и опытную команду могут подключить в проект на первоначальные этапы: «Вы нам всё придумайте и опишите, а реализуем мы своими силами». В подобных случаях лучше сразу максимально описать все детали проекта, т.к. вы не знаете уровня и опыта другой команды. И им тоже будет проще, не придется додумывать какие-то истории, достаточно будет следовать четкой инструкции.

3. Слабые разработчики

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

4. Цена ошибки слишком высока

В начале статьи мы рассказывали о стартапах и сервисах, в которых время — деньги (и часто — в буквальном смысле этого слова). Но бывают и обратные ситуации, когда лучше семь раз отмерить и ... подумать еще пару раз — стоит ли резать.

Если цена ошибки слишком высока, например, речь идет о человеческих жизнях, огромных финансовых или репутационных потерях, экологических катастрофах или даже инцидентах, способных спровоцировать кризис в той или иной системе, — в таких проектах, пожалуй, без ТЗ не обойтись.

И дело тут даже не в том, чтобы потом можно было отыскать «крайнего» — того, по чьей вине случайно была запущена ядерная ракета или человеку удалили здоровую почку. Дело в том, что в таких проектах важнейшая задача — минимизация рисков (даже если нужно будет затратить избыточный временной и финансовый ресурс на этапе постановки задачи). А основная задача ТЗ как раз и заключается в том, чтобы свести эти риски к разумному минимуму.

Будем рады, если наш опыт окажется кому-то полезным или мы сами сможем получить от вас обратную связь и улучшить наши процессы и инструменты.

0
14 комментариев
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Sergey Filippov

Привет, Мисато! :)

Тут еще от типажа людей многое зависит. С карантина у нас очередная новая волна стартапов, где нас хотят видеть такими "технологическими партнерами".

И мы недавно как раз поняли, что в большинстве случаев это просто люди другого типа, они не инженеры от слова "совсем". И они в принципе не хотят никакие документы читать.

Сейчас есть довольно сложный с точки зрения внутренних процессов и алгоритмов проект, и там клиент - ну просто топовая женщина, очень крутая. Но при этом она вообще не воспринимает тексты больше пары абзацев, сама признается, что ей лень вчитываться и разбираться.

Ну вот какое ТЗ с ней? :)

Зато прототипы заходят на "ура", на визуальном контенте она прям включается и отлично обсуждения идут.
И такую вот историю мы всё чаще начинаем встречать, когда напрямую с предпринимателями работаем. "Понимаем, к чему идем и хотим, чтобы мы просто пришли".

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Алена Андреева

Про месяц на ТЗ — это просто жиза. 

Ответить
Развернуть ветку
Ivan Grinkevich

И это оптимистичный сценарий, если проект крупный ))

Ответить
Развернуть ветку
Анатолий Полицын

На все ТЗ которые я видел в последние дцать лет у меня похожая реакция: "хватит это терпеть" =)

Ответить
Развернуть ветку
Greatsteve

Очень полезно, спасибо 

Ответить
Развернуть ветку
Дмитрий Королев

Неплохо написано! Самое прекрасное в этой статье, что тут нет крайности: надо или не надо ТЗ...

У себя в компании мы первично пишем упрощенное ТЗ. Называем его «Бизнес-требование». Это тот случай когда заказчик вообще не понимает что хочет и из чего оно должно состоять. Данный документ описывает перечень задач системы без детального описания (аналогичному тому как у вас Паспорт проекта).

Когда документ готов и п нему есть правки мы пишем подробное ТЗ (у нас заказная разработка с нестандартными модулями и всегда есть нюансы). В 90% будет ТЗ, хотя я начинаю приходить к тому, что этим мы избаловали команду. Все таки аналитический склад ума и понимание бизнес логики должно быть и разработчиков.

Ответить
Развернуть ветку
Степан Чельцов

Спасибо за подход!

Я люблю ТЗ, но те, которые мы делаем. Видимо, надо статью-алыверды готовить.

Ответить
Развернуть ветку
SVK

Обязательно напишите, мы с удовольствием почитаем!
В этой парадигме мы живем уже более 8 лет и, разумеется, не хочется "закисать" в процессах.

Просто за период карантина этот вопрос начал в разы чаще звучать. Видимо, люди считают, что с таким документом лучше контролировать итоговые договоренности при удаленной работе. А мы вот не согласны :)

Поэтому и решили пост, наконец, написать: о своем подходе рассказать, других послушать.

Ответить
Развернуть ветку
RussianGeeks

Но как тогда, без ТЗ...😢😢😢😢😢😢😢

Ответить
Развернуть ветку
EVEN Lab

К документации еще можно добавить User Story, это примерно то же, что роли и процессы у вас. 
В идеале для разработчика работать по Time & Material, изначально прикинув приблизительно стоимость проекта. Как вариант, можно оценить количество часов по ТЗ. Затем, при изменениях, заново оценивать количество часов и делать дополнительные соглашения.

Ответить
Развернуть ветку
SVK

T&M, как и ФФФ, во многих случаях действительно являются оптимальными вариантами реализации сложных проектов, выгодными как подрядчику, так и заказчику.

Но здесь вылезает проблема из другой плоскости: большинство российских клиентов не готовы по ним работать, в отличии от европейских и американских заказчиков. У нас, по крайней мере, очень редко получается сходу договориться о T&M с российскими компаниями. Сначала приходится жить с полностью зафиксированными договоренностями, нарабатывать определенный уровень доверия, и тогда уже T&M начинает хорошо работать.

User Story да, пока не добавили в обязательном порядке, но иногда используем, когда в проекте много ролей и сценариев и при последовательном описании получаются нечитаемые "портянки".

Ответить
Развернуть ветку
Ilya Larshin

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

Ответить
Развернуть ветку
11 комментариев
Раскрывать всегда