Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет! Меня зовут Настя, я системный аналитик в X5 Tech. В этой статье хочу поделиться своим опытом создания чек-листа для технического задания (далее – ТЗ), какие ошибки совершала на начальных этапах работы над продуктом, и как сформированный чек-лист помогает мне уже на протяжении трёх лет. Такой чек-лист может пригодиться не только для самостоятельной работы над ТЗ, но и как инструмент проверки уже готового документа.
Статья будет полезна, как мне кажется, системным и бизнес-аналитикам, владельцам продуктов и тем, кто работает с разработкой требований.
Предыстория
Несколько интернет-источников говорят нам, что впервые чек-лист придумали в авиации (описание можно почитать тут или тут). Если кратко, то в 1934 году во время испытания новой модели Boeing произошло крушение: достаточно опытный пилот совершил ошибку. Именно этот случай показал, что человеку, пусть и подготовленному, сложно держать в голове много информации. Так был придуман некий список, включающий самый важный перечень процессов управления и подготовки к полёту. Такой список помогал техническим специалистам в авиации, а со временем модернизировался, да и вовсе перешёл в повседневную жизнь многих людей.
Чек-листы в современном мире
Каждый день мы выполняем разные задачи: некоторые из них “на автомате”, другие требуют чуть больше времени и сосредоточенности. Но все они так или иначе состоят из списка действий, который мы и называем чек-листом. Возьмём, например, различные марафоны уборки (генеральная уборка за три дня) или элементарный список покупок – чем не чек-лист? Или список того, что нужно взять в путешествие. Ни одна моя поездка уже не обходится без такого чек-листа. Плюс ко всему, современному миру – современные решения: есть даже книги по написанию чек-листов и чек-лист для диджитал уборки.
Так зачем же мы их используем? Чтобы упрощать и структурировать. Сейчас вокруг нас много информационного шума, дел и задач, и с легкостью можно упустить что-то важное. Чаще всего наши списки не такие сложные, и забывчивость не приводит к крушениям самолётов. Тем не менее, пользу чек-листов сложно отрицать, ведь они:
сокращают ошибки в наших действиях;
экономят время на выполнение задач;
помогают не думать о рутине (речь про частный случай, например, поход в магазин).
Ошибки: провал или опыт?
“Извлекай пользу из каждой ошибки.”
Людвиг Витгенштейн
Мне, как аналитику, свойственно упрощать не только работу программистов или заказчиков, но и свою собственную. В первые месяцы работы в Х5 Tech я столкнулась с большим объёмом информации:
многообразие бизнес-процессов в магазинах “Пятёрочка”;
состав и конфигурация внутренней системы магазинов;
несколько смежных подразделений и команд разработки.
Мне стало интересно разбираться в процессах, коммуницировать с разными людьми, собирать и выявлять требования. Но держать все данные в голове – сложно, память стала подводить, а разработчики и тестировщики стали чаще замечать недочёты в ТЗ.
В итоге, спустя три месяца, для повышения качества постановок на разработку (и, в основном, для сокращения поступающих вопросов от коллег :)) я сформировала свой чек-лист того, что необходимо учитывать в ТЗ.
Первая версия выглядела так:
Как же я к этому пришла? Как ни банально, но большинство из нас учатся на ошибках, причём, на собственных. О них и расскажу.
Ошибка № 1: Забывать описывать то, что часто используется
Информационная система, над которой мы с командой работаем, устроена таким образом, что пользователь видит свои рабочие документы с разными статусами на разных экранных формах: форма с активными документами (с которыми ещё можно работать) и форма с архивными документами (не доступными для изменений). Так вот, изменения чаще всего касались формы активных документов – добавить подсказку к полю, новую колонку в таблице, новое поле. А т. к. архивная форма чаще повторяла активную, то изменения в ней должны быть аналогичные.
Для примера рассмотрим процесс составления претензии к поставщику относительно качества товара. Директору магазина необходимо в этом случае совершить такие действия:
составить электронный акт разногласий;
распечатать акт;
подписать акт;
отправить на рассмотрение в претензионный отдел.
Согласование акта зависит от того, был ли он оформлен в первые минуты приёмки товара при водителе или в течение суток уже без водителя. Таким образом, специалисту по претензиям нужно было видеть способ оформления акта. Но даже при наличии всей информации в электронном виде (тут у нас идёт интеграция между системами), специалист и директор между собой могут обмениваться уточняющей информацией. И если директору нужно посмотреть, каким способом выставлен акт (в электронном архиве документов), то, очевидно, мы должны были добавить отображение этого способа и в архивном акте. Что я и “успешно” забыла указать в ТЗ и чего не было прописано в бизнес-требованиях…
Получалось так, что путь пользователя заканчивался на этапе работы с активным документом и не описывал его действия с архивным. Проблема обнаружилась разработчиком в одной из задач, когда он увидел в коде связь активной и архивной формы. Посовещавшись на троих – я, разработчик и тестировщик, – мы решили доработать этот момент в текущем релизе и не переносить на следующий. Так изменения для пользователя выглядели более логичными и не вызывали вопросов относительно разных интерфейсов одной и той же формы.
Ошибка № 2: Забывать описывать то, что редко используется
Не все задачи включают изменения одной и той же функциональности. Например, могут быть изменения только экранных форм и не затрагивать изменения в печатных формах, или наоборот. То же касается и изменений конфигурации системы. Не так часто это используется в повседневной разработке, но может быть частью новой фичи. А без этой части картина для пользователя, опять же, будет неполной.
Иногда тестировщики при проверке задачи проходятся не только непосредственно по доработкам и альтернативным сценариям, но и тестируют “около”. Это значит, что может быть проверена функциональность, связанная с путём пользователя, который мы улучшаем, но не входящая в начальный скоуп разработки. Так мы обнаружили, что в одной из задач нам не хватило доработки печатной формы. И т. к. изменения были небольшими, то внесли это в уже написанное ТЗ.
Вот пример экранной формы с данными по выкладке товара на полке:
А вот так выглядит печатная форма:
Видно, что поля “Фейс шир./ Фейс выс./Стиль выкладки” присутствуют и в документе для печати, и на экранной форме, но изначально в ТЗ я не прописывала добавление этих данных на печатную форму.
Ошибка № 3: Забывать описывать изменения на всех устройствах
Если система имеет десктопную и мобильные версии, то изменения должны быть и там, и там. Команды, занимающиеся мобильной разработкой и разработкой десктопа, разные. Аналитики, тестировщики, разработчики между собой пересекаются не во всех доработках, а бизнес-требования чаще формулируются для системы в общем.
Заказчик ожидает, что функциональность будет внедрена на всех устройствах, а по факту оказалось, что в релизе поддержали изменения только в десктопной версии. Разработка на мобильных устройствах “переехала” на следующий релиз ввиду ограничения по срокам и ресурсам, которые изначально не запланировали. Доработки велись в последующие месяцы, и по факту, для пользователя мобильная версия на это время стала урезанной версией десктопной. Это отставание длилось на протяжении нескольких релизных циклов, но в конце концов всё выровнялось.
Были ещё несколько кейсов, в которых так или иначе всплывали доработки в уже согласованных требованиях.
Как мы это решали?
некоторые ошибки исправлялись в момент согласования ТЗ и разработки;
некоторые через CR (Change Request – запрос на изменение) уже после разработки, на пилоте новой версии системы;
некоторые переходили на следующий релиз.
Мой чек-лист – моя прелесть
Все предыдущие ошибки и решения помогли мне сформировать свой чек-лист, который я использую для валидации ТЗ. По нему я сверяю документ перед тем, как отдать его в разработку: а всё ли я учла в описании? Все ли альтернативные сценарии указаны? Все ли устройства описаны и т. п.
И, конечно, я была очень рада, когда он перестал наполняться. Ведь это означало, что большинство шишек уже набиты, а, значит, можно составлять более полные и точные ТЗ.
Формально мой чек-лист содержит следующие пункты:
№ | Описание | Пример |
1 | Чаще всего дорабатывается в каждой задаче | Изменения в базе данных (формат и размерность полей); доработка экранных форм. |
2 | Редко дорабатывается | Отчёты; печатные формы; экранные фильтры. |
3 | Является специфичным для бизнес-процесса | Разные пути пользователя для достижения одной и той же цели: доработки должны быть описаны для всех таких возможных ситуаций. |
4 | Наличие разных форматов или устройств | Десктоп, мобильная версия. Мобильная версия с разным интерфейсом на разных физических устройствах (устройство под Android или Windows). |
5 | Конфигурация системы | Дополнительные параметры развёртывания, настройки системы. |
6 | Интеграция с другими системами | Формат и размерность параметров интеграции между системами; все ли системы учтены. |
7 | Проверка описания форматов данных или сообщений на соответствие принятым стандартам/гайдлайнам разработки | Если есть корпоративные стандарты, то необходимо их соблюдать. |
Скачать обобщённый чек-лист можно здесь.
Мой список содержит проверку узконаправленных бизнес-процессов, за доработку которых отвечает наша команда. И если задача достаточно объёмная (бизнес-требования подразумевают доработку не на один спринт или релиз), то обязательно сверяю ТЗ с этим чек-листом.
Спустя год работы и по сей день он выглядит так:
Ещё хочу добавить, что если проект или сфера автоматизируемой деятельности сложная (включает много деталей или просто много информации), то лучше заранее создать свой чек-лист. Попробуйте сформировать его целенаправленно, а не на ошибках. Надеюсь, это будет менее болезненно для команды, и мой чек-лист поможет вам в этом.
Применение чек-листа для ТЗ
Если говорить о пользе своего чек-листа, то для себя я определила три ситуации, в которых его использую:
при согласовании бизнес-требований: проверить, всё ли учёл бизнес-аналитик и заказчик;
при написании ТЗ: легче разбивать на задачи для разработки. Например, можно оформить отдельные задачи на изменение БД, изменение экранных форм, интеграцию;
в процессе разработки: ответы на вопросы разработчиков и тестировщиков – почему так, а не иначе написано в ТЗ. А потому что, следуя чек-листу:
согласовывала изменения с архитекторами;
использовала корпоративные гайдлайны;
общалась и согласовывала требования с бизнес-экспертами/заказчиком по различным бизнес-процессам.
Зачем ещё может понадобиться чек-лист для ТЗ?
Чтобы не забыть что-то сделать:
проходясь по такому чек-листу, я понимала, что иногда в готовом ТЗ забывала указывать какие-то требования на разработку. И, тем самым, чек-лист помогал мне заранее исправить ситуацию, когда изменения пришлось бы вносить уже в момент разработки.
Чтобы не делать лишнего:
порой функциональность могла присутствовать на одной форме и отсутствовать на другой намеренно, но благодаря чек-листу я знала, что заказчику нужна такая разница в требованиях, а не то, что он или я просто забыли указать это в документах для разработки.
