Comments 13
Словно боженька ниспослал. Сколько раз мы с тобой обсуждали эти вещи) Поздравляю с тем, что ты решилась, наконец-то, написать про это статью! Уверен, инженерное сообщество оценит!
Если заказчик не написал ТЗ - пишите его сами. И требуйте согласовать.
Нет, есть конечно вариант, когда заказчик "согласует" не глядя ваше ТЗ, а потому выяснится, что "он не то имел в виду" - обычно это случается во внутренних проектах внутри организации.
Но даже в этом случае, имея на руках документ - проще доказать необходимость дополнительных часов/людей на выполнение новых "хотелок".
-------------------------------
На самом деле есть команды, которые очень любят отсутствие ТЗ. Это команды, ориентированные на процесс, а не результат. Обычно такая команда берётся за мегапроект с хорошим финансирование, месяцы-годы над проектом работает - а потом сливается в полном составе, например, "все уволились по причине того, что нас тут не ценят".
Далее ищется другой проект ... а по поводу прежнего в резюме перечисляется миллион суперкрутых техник/фреймворков/языков (у нас всё на микросервисах, работаем с бигдатой с помощью ИИ, почти закончили суперсистему для торговли индивидуально сгенерированными ИИ и распечатанными на 3д-принтере чесалками для жопы, но тут заказчик закрыл проект из-за финансовых проблем. А, да, всё это написано на Go, а что не на Go - то на Rust).
Всё именно так.
А по поводу самому писать -- ну по сути это интервьюирование человека, которому лень самому структурировать свои мысли. Я в статье и хочу донести до заказчиков что так не надо делать, тем более когда исполнителя нет, его только хочется найти, то и интервьюировать некому.
Для тех, кто не умеет формулировать сразу то, что он хочет ТЗ - это проклятье. Соглашусь, что с такими нужно писать ТЗ самостоятельно исключительно для того, чтобы самому понимать объем работ и выстраивать разработку в соответствии с этим ТЗ. А все хотелки сверху - через доп ресурсы или извините, этого не было на старте. Гибкость - это хорошо, но вот твердят в аджайл скраме, мол "Сотрудничество с клиентом важнее согласования условий контракта" и "Готовность к изменениям важнее следования плану" и многие это понимают так, что можно тупо положить на план и на условия контракта. Кто-то такую лапшу кушает и потом страдает, но я вот много собак уже на таком скушал.
Картинка с гусём очень смешная — спасибо, поржал! :D
Но в реальности, к сожалению, всё может пойти не так. Краткая выжмимка трустори с последнего проекта.
Ко мне пришли готовым и вроде как согласованными прототипом — как грится, только раскрасить. ТЗ звучало как — «добавить дизайну».
Я раскрасил прототип как хотел клиент и предложил своё видение как это могло бы быть более правильно и визуально и по логике. Плюс предложил переделать айдентику — клиенту понравилось, утвердили и взяли в работу.
Клиенту понравилось моё видение предложенного сайта и решили делать в моей концепции. Я отрисовал весь сайт в новом стиле на декстопе, согласовал дизайн на кликабельном прототипе в фигме и после этого пошёл собирать на тильде.
После того как мы собрали всё тильде и выкатили на прод, клиент говорит — «это супер ужасно, как такое можно было выкатиь на боевой сайт». Я чуть не порвался тогда. Я переделал сайт полностью ещё раз дважды.
Клиент был настолько сложный, что мне было проще дважды переделать полностью дизайн сайта нежели объяснять клиенту, что он сам утвердил мою концепцию и после согласовал финальный дизайн-макет.
И вишенка на торте. Когда встал вопрос денег, я выставил счёт за обновление айдентики, на что получил вопросительно: «Но ты же сам предложил? Мы не просили…». Я спокойно ответил: «Но вам же понравилось и вы взяли в продакшен». В ответ получил скупое «Окей» и мы разошлись, надеюсь, что навсегда.
Вместо вывода — бумажки не спасают от мудаков, но с ними полегче.
Вообще-то бизнес-требования (BRD) и ТЗ (FSD) совершенно разные сущности.
Заказчик пишет BRD - что он хочет получить.
Согласование BRD
Разработка архитектурного решения
Аналитик пишет FSD для разработчика
Разработка
Компонентное тестирование на соответствие результата разработки требованиям FSD
Бизнес-тест на соответствие продукта требованиям BRD.
Внедрение
Как-то так это выглядит.
BRD и FSD одновременно являются документацией по проекту. Если требуются доработки, выпускается новая версия FSD фиксируются все изменения (т.е. всегда можно всю историю отследить).
И, естественно, всегда контролируется соответствие кода и FSD (бывают ситуации, когда аналитик предлагает одно решение, разработчик - другое, более эффективное, в этом случае FSD корректируется)
Получается, что и нет такого понятия, как ТЗ. То что в простонародье называют ТЗ это как раз и есть бизнес-требования?
Для разработчика ТЗ - это FSD.
Бизнес-требования, BRD - это от заказчика. Что он хочет получить. Что на входе будет, что на выходе должно быть, бизнес-логика, граничные условия, оценка нагрузки, типовые сценарии использования... Можно рассматривать как ТЗ для аналитика.
FSD - это уже аналитик пишет для разработчика. Как реализовать то, что хочет заказчик. Это ТЗ для разработчика.
В таком случае будет нужно несколько итераций согласования FSD с BRD и самим заказчиком еще до разработки.
Чтобы не получить сюрпризов во время и после разработки в виде новой ультра супер важной и приоритетной хотелки от заказчика которая ранее нигде не утверждалась и в календарь не заносилась, либо аналитику убедить заказчика что это будет выполнено с учетом готовности апи заказчика (при интеграциях) "в порядке очереди с расширением дедлайнов", иначе, оплатить срочность внедрения соответствующе.
Исполнитель иногда забывает себя защитить от подобного, например при интеграциях разработчик может зависеть от готовности документации и систем заказчика но договор исполнения подписали на фиксированный срок, в итоге система заказчика готова только под конец этого срока а на интеграцию остается слишком мало времени, даже если разработка ведется на моках может неожиданно, не своевременно, выясниться что контракт полностью поменялся и заказчик требует новые фичи не говоря о том что сделанное ранее исполнителю придется частично или полностью переделывать.
И вместо сейва подобного заранее, разработчик может быть вынужден кранчить и тд, потому что бизнес слой разработчиков думал только о быстрой выгоде и подписи договора а не ответственности при нарушении сроков.
В таком случае будет нужно несколько итераций согласования FSD с BRD и самим заказчиком еще до разработки.
Да. Именно для того
Чтобы не получить сюрпризов во время и после разработки в виде новой ультра супер важной и приоритетной хотелки от заказчика которая ранее нигде не утверждалась и в календарь не заносилась
Потому что есть пул проектных задач и по каждой есть сроки И редко когда разработчик или аналитик занимается только одной задачей, обычно в работе одновременно 2-3 - выполнил свой этап по одной - передал ее дальше, делаешь другую. Отдал в тест - берешь другую задачу. Нужны доработки по результатам теста - вернулся, поправил, обратно в тест...
Когда BRD согласовано, любая более-менее значимая доработка со стороны заказчика - новое BRD и "в очередь, сукины дети, в очередь" (с) Иначе сорвем сроки для всех. И при этом еще бывают дефекты промсреды которые имеют наивысший приоритет.
Такой подход, в том числе, дисциплинирует заказчика, заставляет его думать заранее чего он точно хочет сейчас, а что можно отложить на потом. Это с одной стороны. С другой - позволяет команде разработки более устойчиво планировать свою работу - после утверждения BRD можно более точно проводить оценку - сколько займет аналитика, сколько разработка, сколько тестирование.
Достаточно обычная ситуация, когда "Мы думали, что ТЗ - это Точка Зрения. И у нас их уже несколько".
ТЗ — документ-основание для технического проектирования и разработки-тестирования-сдачи.
Появление ТЗ — это результат концептуального, логического и функционального проектирования.
Вы видимо хотите чтобы плохо осязаемую работу по этим видам проектирования заказчик делал сам. Но в общем случае он этого делать не умеет.
В лучшем случае заполнит бриф или сделает вменяемые бизнес-требования (опять же с риском свалиться в фичи).
Пусть хоть что-то напишет. Всё равно как это назвать. Суть в том чтобы другим людям было понятно (хотя бы примерно) что нужно сделать. Никто не говорит о том что нужно сделать идеально, я как раз и подчёркиваю что не надо. Но почему-то для многих выбор именно такой, либо идеально, либо никак. Раз заранее ясно что у них не получится сделать идеально (они ведь не специалисты), то значит не надо делать никак.
Зачем и как писать ТЗ