Переходим ко второму этапу проекта “Разработка и настройка”.

Начну с потенциально самого сложного и дорогостоящего результата - доработка ИС, интеграционных механизмов и механизмов загрузки. “Потенциально” - потому что, чисто теоретически, можно найти такую ИС, у которой бизнес-логика полностью покрывает автоматизируемые процессы, интеграция с другими ИС минимальная и полностью настраиваемая, загрузка данных заключается в наполнении пары одноуровневых справочников.

Более того, в посте о подготовке к внедрению я писал о том, что как раз одним из критериев подбора ИС является минимальный объем будущих доработок. Но на практике же в том или ином виде, особенно в больших проектах внедрения, разработка все равно присутствует.

Итак, с чем мы выходим на разработку: ▫️ общее Техническое задание к проекту (по которому определяем общие рамки проекта);

▫️ частное (или детальное) техническое задание (ЧТЗ), в которое сводим детализацию по требованиям, полученным в ходе 1-го этапа (о документации пока не писал, будет позже);

▫️ спроектированная и согласованная архитектура внедряемой информационной системы;

▫️ задание на разработку, тоже результат первого этапа, в котором следует указать конкретику по разработке (по функциональным разрывам, механизмам интеграции и загрузке первоначальных данных);

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

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

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

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

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

Общий перечень ключевых результатов, в том числе и по этапу 2 “Разработка и настройка”, находится в этой статье.