Постановка задачи в ИТ-проектах

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

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

Постановка на реализацию (розовый блок на рисунке) выполняется в рамках проектирования (светло-зеленый) перед реализацией.

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

Далее на этапе Определения метода решения мы занимаемся Уточнением требований. Здесь уже появляется структура функций, ИТ-продуктов будущего проекта. А постановка на реализацию описывает, как мы эти функции и продукты будем реализовывать.

Постановка описывает конкретную функцию, модуль, что-то максимально локализованное. Объектами постановки могут быть отдельные компоненты, модули или функции – в зависимости от того, как мы декомпозировали функциональную структуру системы/решения в техническом задании.

Постановка помогает:

1. Определить границы, защититься от их изменений
2. Зафиксировать критерии успешного результата

Постановка на реализацию может содержать разделы:

1. Контекст задачи
2. Ключевые источники информации
3. Заинтересованные стороны
4. Критерии приемки результата
5. Нефункциональные требования и ограничения
6. Описание решения

В зависимости от проекта некоторые блоки могут быть опущены.

Рассмотрим эти разделы на примере:

Давайте пройдемся по разделам постановки и попробуем понять, какую информацию стоит в них отражать.

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

Контекст задачи помогает:

• сформировать «мостик» между заказчиком и исполнителем,
• минимизировать риск того, что решение будет оторвано от реалий будущего использования,
• разработчикам придумать лучшее решение,
• тестировщики могут разработать максимально приближенные к реальному использованию тест-кейсы,
• команде погрузиться в предметную область и прокачать экспертизу в предметной области,
• аналитику в трассировке требований на проблемы бизнеса.

Также данный раздел может содержать:

1. Описание функций бизнес-языком
2. Описание бизнес-процесса
3. Бизнес-требования
4. Перечень проблем бизнеса

Приведём пример описания контекста бизнес-языком:

Для чего этот бизнес-контекст разработчикам?

Ведь решение уже есть, для чего давать исходные данные в виде контекста? Дело в том, что в некоторых случаях описание решения может быть менее конкретным. Риски по формированию детального решения можно переложить на команду. Если члены команды являются экспертами в предметной области, понимают как пользователь и бизнес будут этими функциями пользоваться, то они сделают более качественное решение.

Итого, контекст задачи в постановке нужно описывать, потому что:

1. Мы можем делать постановку на разном уровне детализации.
2. Чем выше уровень детализации постановки, тем больше места для маневра команды разработки. Это позволяет выбрать лучший вариант для решения поставленной бизнесом задачи.

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

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

Другие примеры ключевых источников информации:

• Описание внешнего или ранее реализованного API (например, API компании-перевозчика). Разработчик не должен сам искать в интернете какую-то версию, т.к. она может оказаться не последней и не согласована с архитектором.
• HLD (high-level design, описание архитектуры)
• Стандарты заказчика, если речь идет про передачу листинг кода, а также когда есть свои определенные стандарты его оформления
• Ссылка на памятку по чтению постановки. В некоторых случаях формат постановки может быть достаточно объемным и в нем могут использоваться артефакты, которые не всегда будут понятны человеку со стороны (или даже разработчику команды, который может воспринять постановку неправильно). Поэтому ссылка, например, на соглашение о моделировании вполне может быть источником информации.

Заинтересованные стороны (далее ЗС) — это перечень людей, которые будут влиять на принятие решений и от которых зависит успех реализации.

Чем помогает перечень заинтересованных лиц:

• Определение принадлежности реализуемых в рамках постановки на реализацию требований к ЗС.
• Позволяет проверить, что все необходимые ЗС выявлены и привлечены.
• Дает понимание о том: кто принимает решения, с кем можно коммуницировать при реализации, кто будет в ходе испытаний принимать решение согласно критериям приемки.
• Можно использовать этот перечень при согласовании и демо.

Разница между проектными ролями и бизнес-ролями ЗС

Существуют разные роли, в которых выступают заинтересованные стороны по отношению к постановке. Например, бизнес-роли и проектные роли.

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

Например, у нас есть директор по развитию. На проекте он является куратором (улаживает какие-то вопросы и проблемы) — это его проектная роль. В качестве бизнес-роли он никем не выступает (строка №1).

Проектная роль директора по взаимодействию с подрядчиками — это заинтересованная сторона от какой-нибудь службы по взаимодействию с подрядчиками.

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

Маркетолог также может иметь и проектную, и бизнес роль. Т.к. маркетолог смотрит на то, как готовым продуктом будут пользоваться, то можно сказать, что он является клиентом компании и может диктовать требования от имени клиентов компании — это его бизнес-роль (строка №2).

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

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

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

Критерии приемки результатов — критерии, выполнение которых может говорить о том, что решение реализовано (definition of done постановки).

В широком смысле критериями приемки могут выступать:

• перечень исходных требований, реализуемых решением,
• сформированный перечень функций решения и результатов их выполнения,
• user story,
• и т.д.

Чем помогают критерии приемки:

• дают понимание границ реализации,
• обеспечивают полноту реализации,
• выступают чек-листом приемки (аналитиком при авторском надзоре и заказчиком)

Примеры требований, которые могут служить критериями приемки:

1. Необходимо учитывать время технологических операций по сбору заказа, хранению и транспортировке с производства до терминалов компаний-перевозчиков.
2. Информация по срокам доставки конкретных компаний – перевозчиков должна рассчитываться в момент оформления заказа
3. Перечень доступных для выбора компаний-перевозчиков должен формироваться с учетом возможности доставки компанией-перевозчиком по указанному адресу доставки

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

Ошибки при их проработке в последствии могут привести к очень серьезным проблемам и полной неработоспособности решения

К наиболее важным требованиям относятся:

• производительность (использование в нескольких филиалах) ,
• доступность (24/7),
• масштабируемость (количество сотрудников).

Необходимо также учитывать:

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

Примеры НФТ и ограничений:

1. Время расчета срока не должно превышать 1 секунду
2. Необходимо предусмотреть возможность подключения в дальнейшем неограниченного количества компаний — перевозчиков
3. Сервис расчета сроков должен быть доступен 24/7
4. Расчет срока возможен только при online-доступности

сервиса предоставления информации о сроках конкретной компании-перевозчика

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

Описание решения — это основная часть постановки, описывающая способ и границы реализации

Может содержать:

• Сценарии использования (UseCase)
• Информационные модели
• Статусные модели
• Алгоритмы
• Макеты интерфейсов (UX/UI)
• Компонентные схемы
• Описание интеграций

Диаграммы для UseCase ограничены, т.е. фиксируют конкретный набор функциональности, который, в свою очередь, помогает:

• аналитику ничего не забыть,
• разработчику реализовать данный сценарий,
• заказчику увидеть сценарий его будущего взаимодействия с системой,
• тестировщикам создать тест кейсы.

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

При определении объема документирования важно:

1. Включать только необходимый набор артефактов.
2. Разделять постановку и документирование ИТ-решения.

Постановка отвечает на вопрос «что нужно сделать?», а техническая документация — «как это сделано / как это работает?». Стоит заметить, что грамотно сформированная классификация постановок в терминах UML может стать частью документирования. Это может помочь, когда на проекте отсутствует отдельный процесс документирования.

Конкретика

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

Команда

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

Переиспользование артефактов

Чтобы была возможность переиспользовать артефакты, необходимо подумать об их:

1. Кодировании
2. Классификации
3. Хранении и обеспечении быстрого доступа
4. Доступности для модификации и совместной работы
5. Версионировании (т.к. видоизмененный в новой постановке артефакт, при отсутствии версионирования, не позволит доработать предыдущую версию артефакта по замечаниям от разработчика, например)

Счастливая команда – залог успеха

Счастливый менеджер понимает, что:

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

Счастливые разработчики понимают, что написано в постановке, у них нет необходимости просматривать справочники по нотациям моделирования для понимания артефактов.

Счастливые тестировщики понимают, какие есть пользовательские сценарии использования продукта, внутренних алгоритмов

Счастливые тимлиды понимают, как можно разбить задачу между исполнителями

Давайте рассмотрим факторы, влияющие на выбор того, какие разделы постановки нужны:

1. Квалификация того, кто пишет постановку
2. Квалификация того, для кого пишется постановка (команда)
3. Квалификация Заказчика (для тех случаев, когда заказчик читает и согласовывает постановку)
4. Необходимость формальных процедур согласования (внутри команды или с заказчиком)
5. Сложность решаемой задачи
6. Специальные требования к оформлению документации

Если команда имеет опыт и экспертов в предметной области, то для выполнения простой задачи ей будет достаточно:

• контекста задачи,
• ключевых источников,
• заинтересованных сторон,
• НФТ.

Для команды, не имеющей экспертов, помимо основных разделов, будут также необходимы критерии приемки.

А для неопытной команды будут необходимы все разделы.

Баланс в команде может достигается за счет сочетания опытной команды и неопытного аналитика или наоборот, опытного аналитика и неопытной команды.

При внедрении нового формата необходимо подумать о том, что:

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

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

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