Yonote

Привет, я Вова - исполнительный директор +7 pay и бывший СТО проекта “Утконос” 👋

Хочу поделится с вами рецептом того, как грамотно организовать написание документации и четко поставить ТЗ. 

Думаю, многие сталкивались с ситуацией, когда спустя полгода активной разработки и релиза описания продукта оказываются разбросанными по различным тикетам в Jira или отдельным документам в базе знаний. И единственная точка истины — это устаревший набор тестов (тест-сьют) и немногословный разработчик.

Я в какой-то момент устал от таких ситуаций, но в то же время понимал, что дело не в документации, а том, как выстроен процесс ее создания 🤯

Стандартная схема выглядит так:

“Новые требования от бизнеса -> Новое техническое задание -> Доработка в существующего кода -> Обновление тест-сьюта”

Чувствуете где подвох? 🤔
Дело в том, что каждый раз создаётся совершенно новое ТЗ, тогда как разработчики продолжают работу над старым проектом.

💡Почему бы не сделать создание ТЗ частью самого проекта?

Подобно тому как разработчик разбивает проект на классы, аналитики создают документы, описывающие сущности, бизнес-процессы, взаимодействие с внешними системами. 

И тут, самое главное, вместо написания нового ТЗ добавлять изменения прямо в существующие документы.

Какой профит это даёт?

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

📍 Во-вторых, уже упомянутая целостность и есть суть того, что характеризует документацию. 

Окей, мы создали документацию, а как теперь поставить разработчику ТЗ? 🤔

С таким подходом ТЗ появляется  автоматически и формируется путём сравнения двух версий документа. И становится ясно, какие именно доработки необходимы в коде.

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