Продолжаем двигаться по ключевым результатам этапа 1 реализации проектов внедрения “Обследование и анализ”. В этом посте - про детальную оценку разработки.

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

▫️составить перечень задач с описанием оных в объеме, достаточном для проведения оценки;

▫️ провести оценку трудозатрат в разрезе: - постановка задачи; - разработка; - тестирование; - демонстрация; - резервы на доработку; - итого по задаче.

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

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

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

▫️ после проведения разработки и оценки разработки тимлидом разработки;

▫️ после тестирования;

▫️ после демонстрации разработанной функциональности.

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

Хочу именно отдельной строкой отметить, что объем разработки складывается не только из доработки функциональности ИС, но ещё и доработок, связанных с интеграционными механизмами и механизмами загрузки первоначальных данных.

Кроме того, разработка - это не единственный источник трудозатрат следующего этапа. Помимо этого, ещё нужно будет понести затраты как минимум на:

▫️ развертывание площадок;

▫️ настройку стандартной функциональности ИС;

▫️ проведение показа функциональности после всех доработок и настроек (а если задачи по подготовке к ОЭ не выделены в отдельный этап, то ещё и проведение комплексных предварительных испытаний для допуска к проведению опытной эксплуатации системы.

Итак, зачем же нам ТЗ на разработку (не путать с ТЗ к договору, с ЧТЗ и постановками задач на разработку):

▫️ база для уточненного расчета трудозатрат по ролям разработки;

▫️ база для создания бэклога проекта (не путать с бэклогом спринта);

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

В случае отсутствия данного результата возможны следующие негативные последствия: ▫️ привлечение недостаточного количества специалистов нужной компетенции и, как следствие, просрочка сдачи этапа 2;

▫️ невозможность построения ИСР, а значит потенциально увеличение сроков в виду переключения команды разработки между задачами (например, начали делать задачу, поняли, что для ее реализации нужно сперва сделать другую, сделали, по новой начали вникать в отложенную, на такие переключения теряется время и снижается общая эффективность работ);

▫️ “внезапные” дополнительные расходы вследствие того, что нет специалиста с нужной компетенцией плюс лаг по времени на период поиска специалиста;

▫️ снижение качества результата в виду передачи работ непрофильному специалисту в виду отсутствия спеца с нужной компетенцией (например, аналитик специализируется на определенном БП, а ему передают ещё и задачи на интеграцию; задачи-то он поставит, вопрос сколько раз придется переделывать);

▫️ часть функциональности может оказаться не разработанной (в виду отсутствия бэклога проекта), что может выясниться только в конце 3-го этапа при проведении предварительных комплексных испытаний или (что ещё хуже) после старта ОЭ (если в ПМПИ также забыли включить соответствующие тест-кейсы).

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