Что весит больше - 1 кг ТЗ по шаблону или 1 кг ТЗ по гайдлайнам?
Вступление
Привет! Не пугайся, я полностью с тобой согласен, первая реакция на заголовок должна быть, как у Джеки. Сейчас всё расскажу по порядку. И, в конце концов, мы даже действительно взвесим два типа ТЗ.
На связи снова я, Сергей Павлов, тимлид по системному анализу в банке "Открытие". Как я писал ранее, мы разработали некую парадоксально названную "методику строгой гибкости написания ТЗ". Именно об этом я и хочу сегодня рассказать.
Прежде всего хочу отметить одну немаловажную деталь, которая изменилась за год - наша команда системных аналитиков на проекте "Бизнес-портал" увеличилась с 12 до 25 человек (тут должна быть картинка с кроликами, но что-то пошло не так).
Такой рост повлек за собой массу изменений во внутренних процессах, в том числе в процессе написания/подготовки технического задания на разработку.
Проблемы
Итак, что у нас было:
Несколько типов устоявшихся правил ведения документации;
Один шаблон ("рыба") написания ТЗ;
Несколько примеров написанных ТЗ по шаблону.
Что хотелось получить на выходе:
Единый стиль ТЗ;
Интуитивно понятный инструмент для описания заданий на разработку;
Документ должен легко читаться и восприниматься любым конечным пользователем (разработчики, аналитики и т.д.).
Сперва мы попробовали самый простой и банальный метод "сейчас создадим шаблон ТЗ. Просто же! Взял, поправил его, убрал лишнее и готово. Что тут сложного?".
Just do it. © Nike
Решение
ТЗ по шаблону
Давайте пробовать! Пораскинули мозгами, накидали пункты, получилось следующее – написание документа происходит не с чистого листа, а по тому самому шаблону, который, в свою очередь, представляет некую смесь "рыбы" и "инструкций по заполнению".
Шаблон состоял из 14 пунктов, которые по необходимости нужно заполнить (лишние при этом удаляются):
Ссылка на UserStory – прикладываем ссылку на User Story, в рамках которой происходит работа;
Согласование – об этом как раз была речь в прошлой статье, где мы указываем список участников и контролируем понимание задачи всеми исполнителями;
Цель – описываем кратко цель данного ТЗ/ЧТЗ;
Интеграционное взаимодействие – прикладываем ссылки на статьи, где мы описываем какие-либо внутренние и внешние коммуникации;
Доступы – данные для подключения к внешним системам;
Глоссарий – собственно, сам глоссарий, либо ссылка на общие термины;
Дизайн – ссылки, макеты и т.д;
Backend – изменения в БД, изменения в API;
Frontend – сценарии поведения и системного взаимодействия;
Маппинг для шины данных – схема, атрибутный состав интеграции;
Обработка ошибок – описание поведения системы в случае возникновения ошибок;
Тестирование – акцентируем внимание на какие-то сценарии, предусловия и ожидаемый результат. ВАЖНО! Не забыть уточнить, нужно ли будет нагрузочное тестирование;
Ограничения – технические ограничения при реализации, т.е. объяснение причин, по которым что-то не может быть сделано;
Полезная документация – раздел для документов, которые могут быть полезны.
Казалось, это железный и проверенный метод. Стронг дисижн, рил толк и всё такое. Как говорит господин Ургант: "Работаем!".
Немного со скрипом попробовали написать несколько ТЗ и поняли, что надо расширять шаблон дальше. Не всё, что хотелось сказать, вписывалось в рамки вышеперечисленных пунктов. Например, куда вписать краткое решение или где хранить открытые вопросы. Также "без определенного места жительства" остались такие моменты, как схемы потока данных и диаграммы.
СРОЧНОЕ СОБРАНИЕ!
Расширенная версия ТЗ по шаблону
Давайте дополнять тэзэшку! Вернее, наш чудо-шаблон. Нужно добавить несколько пунктов. “Хряк-хряк и в продакшн” - новый шаблон ТЗ готов. В него вошли ещё несколько дополнительных пунктов:
Оглавление – оглавление формируется автоматически, т.к. мы сохраняем стандарт форматирования "Заголовки, подзаголовки и т.д.", просто нужно оставить этот пункт в шаблоне, не трогая его;
Проблема – вынесли отдельно, чтобы не путать с целью. Тут мы также кратко описываем, какую проблему решаем;
Решение – без технических деталей описываем, как мы решаем проблему и за счёт чего достигаем поставленной цели в рамках данной документации, ТЗ, ЧТЗ;
Открытые вопросы – плавающий блок, который становится всё меньше и меньше в процессе проработки документа. Впоследствии он исчезает вовсе;
Backend. Версионирование – нужно не забыть о потенциальном версионировании бизнес-процесса, если им пользуется мобильное приложение;
Frontend. Схема – диаграмма потока данных или взаимодействия, если в сценарии присутствуют сложные ветветвления.
Итого, шаблон растолстел до 20 пунктов.
Вернемся в начало и попробуем ответить на вопрос, сколько весит 1 кг ТЗ? Нетрудно представить, каким тяжелым и неподъемным оказался этот метод. Причем сложность работы, как бы абсурдно это ни звучало, прямо пропорциональна простоте задачи. Чем меньше задача, тем сложнее составить описание документа на разработку (нужно пройтись по всему шаблону, определить, что лишнее, убрать то, что не относится к делу, дополнить пустые пункты необходимой информацией либо позже нужно добавить то, что уже удалили и т.д.). Стало понятно, что в один шаблон более чем 10 команд никак не вписываются.
Простой пример на лапках
Объясню на котиках, как это выглядело со стороны, ведь все любят котиков?
Знакомьтесь – это котик Петрушка и он собирается в гости к Ватрушке.
Они собираются вместе приготовить что-то вкусное. Давайте разберемся, что им понадобится для того, чтобы у них получился кекс. Им необходимы базовые ингредиенты: масло, мука, яйца, сахар – всего четыре компонента.
Ватрушка и Петрушка идут в супермаркет, но в магазине есть только огромные наборы для приготовления любой выпечки. За неимением других вариантов они берут такой набор с мыслью, что на месте разберутся, какие элементы из всего этого им понадобятся – остальное придется убрать.
Но, к сожалению, кекс так и не приготовили, а вместо этого они сидели и пытались разобраться в большом наборе возможных специй и вкусовых добавок. Грустно и котиков жалко.
Тут и родилась мысля: “А что, если котикам выдавать не универсальный набор для приготовления, а только нужные им ингредиенты? Пускай сами выбирают, что им понадобится”.
А теперь вернёмся обратно в мир IT, банков и системный анализ в целом.
КОМАНДА, СНОВА НА ЭКСТРЕННОЕ СОВЕЩАНИЕ!
ТЗ по гайдлайнам
Нужно пересмотреть подход к формированию документов – делаем его максимально простым и удобным.
Основная идея – предоставляем возможность аналитику самому решить, из каких блоков будет состоять документ. Идём от обратного: не удаляем лишние блоки, а собираем ТЗ из готовых мини-кусков, написанных по так называемым гайдлайнам.
В терминологии системного анализа я ещё не встречал понятия "гайдлайн", поэтому попробую сформулировать его своими словами.
Гайдлайны — это правила, которым следуют аналитики при описании отдельного небольшого блока документа. Это список пошаговых действий для того, чтобы полностью сформировать отдельную часть документа. Отдельный гайдлайн сопровождается примерами ("рыбой") для более лёгкого восприятия, а также сохранения единого стиля заполнения и форматирования документа.
Вжух - и готово! Формируется список инструкций декомпозированного шаблона ТЗ. При написании самого ТЗ/ЧТЗ системный аналитик понимает, какие области будут затронуты, и исходя из этого формирует некий набор готовых гайдлайнов для формирования всего документа.
Готовый вариант инструкций выглядит следующим образом:
[*] Блок "Вступление и описание" – оглавление с заголовками, таблица участников локального и кросс-ревью, глоссарий, бизнес-цель, техническое решение (коротко), открытые вопросы, ссылка на User Story;
[*] Блок "Диаграмма бизнес-процесса" – составляем диаграмму UML, BPMN. Блок-схема - тоже допустимый способ (всё зависит от уровня системного аналитика либо бизнес-процесса);
Блок "Схема интеграции" – диаграмма последовательности взаимодействия;
Блок "Доработки BE" – описываем все изменения, касающиеся backend:
а) Блок "Изменения в API" – название конечной точки + метод, логика работы сервиса, перечисление параметров, скоупы и роли, маппинг данных, валидация, указываем коды ответов и т.д.;
b) Блок "Изменения в БД" – кратко описываем, для чего создаем/изменяем таблицу, описываем атрибуты, добавляем ER-диаграмму, если это необходимо;
Блок "Изменения FE" – описываем сценарий поведения системы со стороны frontend, указываем на изменения в дизайне, перечисляем обработку ошибок;
Блок "Взаимодействие с Шиной" – cхема/диаграмма последовательностей взаимодействия, характеристики планируемой интеграции, атрибутный состав интеграции;
Блок "Технические ограничения" – описываем технические ограничения при реализации и причины;
Блок "Тестирование" – дать рекомендацию, по каким критериям выбрать тестового клиента, перечислить вспомогательные действия, акцентировать внимание на негативном сценарии, описать критерии успешности работы, отразить информацию о возможном влиянии на существующий функционал, отразить информацию, требуется ли проведение нагрузочного тестирования;
Блок "Полезная документация" – оставляем любую полезную информацию по задаче.
Итого: мы сократили объем пунктов с 20 до 9! При этом хочу обратить внимание на процесс создания документа – теперь это метод набора, а не метод исключения. Из описаний каждого отдельного блока формируется итоговое готовое ТЗ с сохранением всех условий форматирования, в результате чего структура документа единообразная и интуитивно понятная.
Котик приходит в магазин,
набирает нужные ему ингредиенты,
котик счастлив!
Теперь, независимо от размера и сложности задачи, документ будет наполнен только необходимой информацией и время на ведение ТЗ не будет увеличено, как в случае с редактированием шаблона.
Итог
Давайте ещё раз подытожим то, что получилось и какой образовался профит из всего вышесказанного.
Документ всегда создаётся по одной структуре. Стандарт – наш друг!
В документе только необходимая информация без лишнего шума и мусора. Чистота – залог здоровья!
Время работы над ТЗ сильно сократилось за счёт исключения многократных правок и сравнения, что лишнее, а что нет.
ТЗ на микросервисах! Если нам нужно изменить шаблон или добавить новые пункты, редактируются только отдельные независимые друг от друга процессы.
Онбординг новых специалистов в очередной раз стал легче и подключение системных аналитиков из других параллельных команд не вызывает трудностей.
У Петрушки и Ватрушки получился кекс.
Profit! Yeah!
Подходим к финалу и предлагаю всё же наконец взвесить 1 кг ТЗ по шаблону и 1 кг ТЗ по гайдланам. В одном случае это 20 постоянных пунктов, в другом – 9 переменных блоков. Так ответьте на вопрос, что же весит больше? ;)
СДЕЛАЙ СВОЙ ВЫБОР, КАК ПИСАТЬ ТЗ
Adios!
