7 принципов описания требований на языке разработки
Контекст: трудности перевода
Любая узкопрофессиональная сфера обрастает собственным языком для специальных целей, и системная аналитика не исключение. Использование особой терминологии упрощает общение специалистов в пределах одной сферы и обеспечивает взаимопонимание между людьми. Однако у этого явления есть и обратная сторона: постоянно находясь в контексте и привыкая к определенной терминологии, становится сложнее доносить свои мысли до людей, не владеющих специальной терминологией. Это потенциально провоцирует недопонимание.
Поэтому одной из задач системных аналитиков является преодоление подобного недопонимания, чтобы собранные и описанные требования без искажений воспринимались разработчиками и в результате получался ровно тот продукт, который планировался.
После того, как с оглядкой на эпоху удаленного общения собраны все требования и настало время переносить их в конкретные задачи для разработчиков, я стараюсь делать это с учетом определенных принципов. О них и пойдет речь в статье.
Пошаговая инструкция для системных аналитиков: как описать требования, чтобы вас поняли
- Конкретизация задач не должна мешать целостному восприятию
При дроблении описания на мелкие задачи не забудьте оставить возможность взглянуть на всю функциональность целиком.
Бытует ошибочное мнение, что сохранить время разработчиков можно, если оградить их от излишней информации, — свести фокус внимания на конкретную задачу, без оглядки на глобальную картину. Это верно, если в задаче содержится четкое описание того, что дано изначально и что должно оказаться в итоге. В таком случае, скорее всего, исполнитель четко последует инструкциям и реализует задачу. Однако в этом подходе есть большой недостаток — зацикленность каждого участника разработки на своей части задачи без понимания общей картины, что провоцирует риск излишней раздробленности.
Например, возьмем глобальную задачу расчета скидок внутри заказа, где вы описываете подзадачу: подсчитать добавленные в корзину позиции. Помимо общей информации полезно указать, что в результате конкретный алгоритм должен предоставлять список заказанных продуктов и их общее количество с учетом доставок и подарочных продуктов.
Такая формулировка описания предотвратит ситуацию, когда разработчики забудут, что в заказе помимо обычных продуктов могут быть и подарочные. Хотя вполне возможно, что работа с подарочными продуктами — это отдельная большая задача, которая решается силами других разработчиков.
2. Спускайтесь на тот уровень детализации, который принят в команде
В одних командах будут очень опытные разработчики, которые хорошо знают продукт и принятые в нем подходы. В других командах недавно появилось несколько новых людей, которые только втягиваются в проект. В обоих этих ситуация уровень детализации может отличаться, поэтому нужно правильно его подобрать. Хорошим маркером служит количество вопросов, которые задают разработчики после прочтения подготовленного вами документа.
Если:
a) вопросов слишком много,
b) требуется часто уточнять какие-то детали,
c) нет четкого понимания того, чем мы все тут занимаемся,
— это очевидные сигналы, что уровень детализации недостаточен и нужно его усилить. Но делу также помогут и рекомендации из последующих принципов.
Если обратиться к нашему примеру с алгоритмом расчета скидок, то для опытных разработчиков будет достаточно указать, какие параметры участвуют в расчетах и как они взаимодействуют между собой. Для менее опытных разработчиков нужно будет дополнительно пояснить, например, типы тех или иных входных параметров, в каких диапазонах могут быть их значения, а также в какие моменты эти параметры нужно получать и сохранять.
3. Предоставляйте не только техническое описание, но и бизнес-обоснование
Этот пункт сильно пересекается с предыдущим, но все-таки имеет несколько другие причины и последствия. Даже если разработчики видят всю техническую картину реализуемой функциональности, не лишним будет дать вводную информацию и со стороны бизнес-процессов. В противном случае, если для описанного выше алгоритма расчета скидок не сделать пояснение , что заказы будут делаться не только маленькими компаниями, но и большими корпорациями с тысячами позиций, алгоритм расчета может быть просто не готов к таким серьезным нагрузкам. Это приведет к тому, что в какой-то момент из-за падения производительности его придется переделывать заново.
4. Оставляйте ссылки на клиентскую документацию, если она у вас есть*
*Важное дополнение к предыдущей рекомендации. Безусловно, с ней парой должно идти “создавайте клиентскую документацию, чтобы пользователи могли сами справляться с возникшими вопросами”, но сейчас мы оставим это за скобками. Об этом пойдет речь в одной из следующих статей.
Почему в техническом описании важно иметь ссылки на клиентскую документацию?
a) Клиентская документация будет содержать наиболее полный объем общей информации, поэтому поможет в случае необходимости еще больше погрузиться в контекст;
b) Если произошли изменения в процессе разработки, их проще будет отразить также и в клиентской документации при наличии ссылок на нее в техническом описании.
Обратимся снова к нашему примеру с расчетом скидок. Если в описании процесса есть ссылка на полную клиентскую документацию, то из нее можно узнать, что при завершении заказа приложение дополнительно откроет экран настройки доставок — это напрямую не связано со скидками, поэтому вряд ли будет описано в задачах на разработку алгоритма расчета скидок. Однако такая информация может быть полезна для понимания процесса в целом: после нажатия кнопки завершения заказа, фактически работа с ним не заканчивается, и какие-то данные внутри него могут быть изменены.
5. Подготовьте визуальные материалы, если задачи подразумевают не только разработку логики, но и интерфейсы
Невозможно на словах описать то, как должен выглядеть тот или иной экран, — подкрепляйте свои слова UX-прототипами и макетами. Обычно за это отвечают отдельные сотрудники, поэтому на данном этапе вам наверняка понадобится перевести требования разработки на графический язык и визуализировать пользовательский интерфейс**
** На эту тему также поговорим в следующих статьях
При создании дизайна необходимо ориентироваться на гайдлайны, которые варьируются и зависят от платформы, для которой разрабатывается ваш продукт. В нашем проекте по расчету скидок это может быть важно, если он реализуется сразу и в веб-, и в iOS-версии продукта. Для двух этих платформ отличается не только дизайн элементов, но даже их расположение, — что может быть важно для логики конкретного продукта.
Например, если нужно, чтобы все булевые значения выглядели как чекбоксы, то это будет ненативным отображением для iOS. По этой причине, скорее всего, разработчики предложат вам перейти к использованию стандартных для платформы переключателей.
6. Любые определения должны быть “переведены” в понятную терминологию
В зависимости от платформы вашего продукта, термины могут отличаться. Но вам обязательно нужно в них разобраться до того, как приступить к описанию задач. Например, popup, alert и dialog — это разные сущности, которые по своей сути похожи друг на друга, но служат для разных целей. Для нашего воображаемого проекта с расчетом скидок это актуально, потому что, не зная этих нюансов, все подобные элементы можно называть всплывающими окнами. Тогда как функционально они отличаются: какие-то служат только для информирования об ошибках внутри заказа, а какие-то не только информируют, но и предлагают на выбор одно из нескольких действий.
7. Если в процессе выполнения задачи что-то меняется, это нужно сразу же отразить в документации
Конечно, лучше подобного вообще не допускать, но в ходе реализации могут открываться новые ограничения и условия, с которыми нужно мириться. Очевидно, что если изменения произошли, их сразу нужно задокументировать. Однако часто из-за недостатка времени кажется, что правки можно внести потом — это плохо не только потому, что они могут просто потеряться и забыться. Гораздо опаснее здесь то, что с конкретным описанием могут работать и другие люди, которые не участвовали напрямую в изменении исходной постановки.
Если, как видно из первой рекомендации, у вас было общее описание всего процесса, то подобные неучтенные изменения могут снова помешать раздробленным разным задачам соединиться в один большой пазл.
Для примера вернемся снова к функциональности расчета скидок. Допустим, в какой-то момент вы вместе с разработчиками решили, что удаленные из заказа продукты будут оставаться в заказе в нулевом количестве, но забыли исправить это в документации. Человек, который разрабатывает алгоритм подсчета всех позиций в заказе, может не ожидать нулевого количества, ведь раньше таких позиций просто не могло быть, потому что они сразу удалялись из заказа. И это запускает дальнейшую череду неточностей и недопониманий, которые могут существенно повлиять на результат. Быстрая фиксация изменений поможет это предотвратить.
На этом мы завершим, наверняка, не полный, но достаточный список рекомендаций. Следование им облегчит понимание между отделами аналитики и разработки, устранит двусмысленность и проблему интерпретации.
Надо помнить, что в любой команде могут существовать свои специфичные правила, которые служат тем же целям.
А каким советам принято следовать в вашей команде? Пишите в комментариях 🙂
Об авторе
Systems Analyst и Product Owner в команде CT Software в группе компаний CT Customertimes corp — CT Customertimes, CT Consulting, Masterdata, CT Cloud
Участвует в разработке продуктов компании в качестве Systems Analyst. Управляет пакетом CT Mobile внутри платформы Salesforce в качестве Product Owner.
Больше информации о продуктах, кейсы и истории успеха здесь:
Сайт: https://masterdata.ru/
LinkedIn: https://www.linkedin.com/company/masterdata/
Instagram: https://www.instagram.com/masterdata_cis/
Facebook: https://www.facebook.com/1masterdata
