ТЗ — зло!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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