Три месяца ошибок, или как я создала чек-лист для проверки ТЗ

Привет! Меня зовут Настя, я системный аналитик в X5 Tech. В этой статье хочу поделиться своим опытом создания чек-листа для технического задания (далее – ТЗ), какие ошибки совершала на начальных этапах работы над продуктом, и как сформированный чек-лист помогает мне уже на протяжении трёх лет. Такой чек-лист может пригодиться не только для самостоятельной работы над ТЗ, но и как инструмент проверки уже готового документа.

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

Предыстория

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

Чек-листы в современном мире

Каждый день мы выполняем разные задачи: некоторые из них “на автомате”, другие требуют чуть больше времени и сосредоточенности. Но все они так или иначе состоят из списка действий, который мы и называем чек-листом. Возьмём, например, различные марафоны уборки (генеральная уборка за три дня) или элементарный список покупок – чем не чек-лист? Или список того, что нужно взять в путешествие. Ни одна моя поездка уже не обходится без такого чек-листа. Плюс ко всему, современному миру – современные решения: есть даже книги по написанию чек-листов и чек-лист для диджитал уборки.

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

• сокращают ошибки в наших действиях;

• экономят время на выполнение задач;

• помогают не думать о рутине (речь про частный случай, например, поход в магазин).

Ошибки: провал или опыт?

“Извлекай пользу из каждой ошибки.”

Людвиг Витгенштейн

Мне, как аналитику, свойственно упрощать не только работу программистов или заказчиков, но и свою собственную. В первые месяцы работы в Х5 Tech я столкнулась с большим объёмом информации:

• многообразие бизнес-процессов в магазинах “Пятёрочка”;

• состав и конфигурация внутренней системы магазинов;

• несколько смежных подразделений и команд разработки.

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

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

Первая версия выглядела так:

Как же я к этому пришла? Как ни банально, но большинство из нас учатся на ошибках, причём, на собственных. О них и расскажу.

Ошибка № 1: Забывать описывать то, что часто используется

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

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

• составить электронный акт разногласий;

• распечатать акт;

• подписать акт;

• отправить на рассмотрение в претензионный отдел.

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

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

Ошибка № 2: Забывать описывать то, что редко используется

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

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

Вот пример экранной формы с данными по выкладке товара на полке:

А вот так выглядит печатная форма:

Видно, что поля “Фейс шир./ Фейс выс./Стиль выкладки” присутствуют и в документе для печати, и на экранной форме, но изначально в ТЗ я не прописывала добавление этих данных на печатную форму.

Ошибка № 3: Забывать описывать изменения на всех устройствах

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

Заказчик ожидает, что функциональность будет внедрена на всех устройствах, а по факту оказалось, что в релизе поддержали изменения только в десктопной версии. Разработка на мобильных устройствах “переехала” на следующий релиз ввиду ограничения по срокам и ресурсам, которые изначально не запланировали. Доработки велись в последующие месяцы, и по факту, для пользователя мобильная версия на это время стала урезанной версией десктопной. Это отставание длилось на протяжении нескольких релизных циклов, но в конце концов всё выровнялось.

Были ещё несколько кейсов, в которых так или иначе всплывали доработки в уже согласованных требованиях.

Как мы это решали?

• некоторые ошибки исправлялись в момент согласования ТЗ и разработки;

• некоторые через CR (Change Request – запрос на изменение) уже после разработки, на пилоте новой версии системы;

• некоторые переходили на следующий релиз.

Мой чек-лист – моя прелесть

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

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

Формально мой чек-лист содержит следующие пункты:

Скачать обобщённый чек-лист можно здесь.

Мой список содержит проверку узконаправленных бизнес-процессов, за доработку которых отвечает наша команда. И если задача достаточно объёмная (бизнес-требования подразумевают доработку не на один спринт или релиз), то обязательно сверяю ТЗ с этим чек-листом.

Спустя год работы и по сей день он выглядит так:

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

Применение чек-листа для ТЗ

Если говорить о пользе своего чек-листа, то для себя я определила три ситуации, в которых его использую:

1. при согласовании бизнес-требований: проверить, всё ли учёл бизнес-аналитик и заказчик;

2. при написании ТЗ: легче разбивать на задачи для разработки. Например, можно оформить отдельные задачи на изменение БД, изменение экранных форм, интеграцию;

3. в процессе разработки: ответы на вопросы разработчиков и тестировщиков –  почему так, а не иначе написано в ТЗ. А потому что, следуя чек-листу:

   • согласовывала изменения с архитекторами;

   • использовала корпоративные гайдлайны;

   • общалась и согласовывала требования с бизнес-экспертами/заказчиком по различным бизнес-процессам.

Зачем ещё может понадобиться чек-лист для ТЗ?

• Чтобы не забыть что-то сделать:

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

• Чтобы не делать лишнего:

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