60 дней фильмов и сериалов
по промокоду:
VC60
Забрать
60 дней подписки Яндекс Плюс бесплатно для новых пользователей, ранее не оформлявших подписку Яндекс Плюс либо подписки, её включающие, при условии привязки банковской карты. Далее — автопродление: 199 ₽/месяц. Действует на территории РФ. Активировать до 04.06.2021 г. https://hd.kinopoisk.ru/gift. Условия: clck.ru/FMQND.

ТЗ — зло!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прототипы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{ "author_name": "Студия Валерия Комягина", "author_type": "self", "tags": [], "comments": 14, "likes": 17, "favorites": 14, "is_advertisement": false, "subsite_label": "life", "id": 151103, "is_wide": false, "is_ugc": true, "date": "Thu, 20 Aug 2020 12:04:30 +0300", "is_special": false }
0
14 комментариев
Популярные
По порядку
Написать комментарий...
3

Писал об этом ещё пять-шесть лет назад ;)

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

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

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

Хорошая статья.

Ответить
0

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

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

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

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

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

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

Ответить
0

Привет! Ну со стартапами вообще никакого ТЗ не может быть, стартап - это же проработка бизнес-идеи, тут только быстрые итерации с аджайлом.

Ответить
1

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

Ответить
1

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

Ответить
1

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

Ответить
1

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

Ответить
1

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

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

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

Ответить
0

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

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

Ответить
1

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

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

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

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

Ответить
0

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

Ответить
Читать все 14 комментариев
«Apple упрощает взаимодействие дизайнеров и разработчиков»: чем запомнилась WWDC 2021

В пилотном выпуске подкаста jam_talks дизайнеры и разработчики из Voltmobi, Funcorp, Arrival и red_mad_robot поделились впечатлениями от WWDC и рассказали про самые интересные на их взгляд нововведения. Выжимка подкаста и подборка самых ярких сессий с комментариями внутри статьи.

Обнаружили продавца на Ozon, который торгует домашними соленьями без документов и этикеток

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

Какие клише и штампы есть в анимационных роликах и как их избежать

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

Panasonic продала все свои акции Tesla на $3,6 млрд — они подорожали за год в пять раз Статьи редакции

Компания хочет заработать капитал для покупки разработчика программ с искусственным интеллектом.

Как технологии помогают не забывать школьную программу летом

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

Зачем PR стартапу?

Какие цели решает PR?

Почему Snowpack лучше Webpack, и зачем нужен WebGL? Доклады frontend-митапа
От воронки стартапов до экзита: где учиться венчурному инвестированию

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

Каннабис, премиум-шампанское и агенты для спортсменов: на чем заработал свои $1,4 млрд первый рэпер-миллиардер Jay-Z Статьи редакции

В 2005 году рэпер Jay-Z произнёс ставшую пророческой фразу: «Я не бизнесмен, я бизнес, мэн». В июне 2019 года Forbes назвал его первым рэпером-миллиардером, но своё состояние исполнитель заработал не только благодаря музыке.

Jay-Z Highsnobiety
Руководство по запуску войсчатов в Telegram: зачем банк «Открытие» провёл 6-часовой эфир и что от этого получил

В марте 2021 года, уже после того, как Clubhouse начал стремительно терять аудиторию в России, в мессенджере Павла Дурова появилась возможность проводить голосовые чаты в телеграм-каналах. Мы решили провести эксперимент и, спустя 2 месяца после релиза этой фичи, устроили шестичасовой марафон для предпринимателей, в котором поучаствовали около 3…

Комментарии
null