Примечания автора

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

Заголовок не отражает всей сути статьи, кульминация и развязка будут ниже.

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

Действующие лица:

• контрагент/ исполнитель – компания, разрабатывающая продукт;

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

Немного занудства, или для справки

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

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

Об этом говорится всегда и везде, но почему-то, что аналитики, что руководители проектов, даже с опытом работы, периодически пренебрегают этими правилами. Поэтому в некоторых компаниях на собеседованиях аналитику задают такой вопрос: «Вы пришли в проект, где нет никакой документации, а люди, которые разрабатывали ПО давно уволились. Все. Что вы будете делать? Где и как будете искать информацию?» Ситуаций таких даже в наше время достаточно, но давайте посмотрим, к чему это может привести.

Начало

Проект по меркам компании был небольшой, поэтому у него была ограниченная команда:

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

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

Спустя ещё пару месяцев количество вопросов увеличилось, и компания приняла решение нанять на проект руководителя проектов.

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

И вот спустя примерно 3 месяца взяли на проект меня, предупредив, что статус проекта примерно такой: «очень сложно, не понятно, что делать, сроки уже сорваны 2-3 раза».

Что было дано на старте, когда я пришла в проект:

• продукт (коробочное решение), исправно работающий 1 год, с возможностью кастомизации, расположена на стороне контрагента;

• проект в стадии развития: требуется доработка (разработка, интеграция и внедрение дополнительного модуля), есть срок;

• коробку с разрабатываемым модулем необходимо перенести в контур компании;

• риск – запрет на работу системы в случае неудовлетворения требований в последний утверждённый срок;

• выбор и согласование новой архитектуры затянуты на несколько месяцев, нет итогового решения;

• один аналитик со стороны контрагента;

• руководитель проектов, который уволился 3 месяца назад;

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

Что требовалось сделать:

• согласовать архитектурную схему;

• продолжить разработку модуля;

• успеть в срок.

Любая работа аналитика на новом проекте начинается с изучения предметной области: как выстраивается бизнес-процесс, как работает или будет работать система, какие требования есть, и соответствуют ли эти требования бизнес-правилам и ограничениям. И первое, с чем я столкнулась – это полное отсутствие документации (за исключением двух архитектурных схем с новым модулем). Казалось бы, продукт молодой, команда, работающая над продуктом в полном составе, осталось только пойти и спросить. Так я и сделала, однако, следующие результаты меня не очень удовлетворили:

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

• отсутствие подписанного договора на разработку («они успешно внедрили текущий продукт, нареканий у нас (заказчиков) нет, можно договор в процессе работы заключить»);

• отсутствие концепции, либо другого документа, где написано, какие требования должны быть применимы к новому модулю;

• на новой архитектурной схеме был дополнительный модуль, которого не было на текущей схеме, но он уже был внедрён на стороне контрагента и работал («мы с ними по-дружески договорились, они расширили функционал нашей системы, нет, мы его ни с кем не согласовывали, мы им верим»);

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

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

Из-за отсутствия документации пришлось проводить очень много встреч только для восстановления цепочки событий. Это отняло ценное время, и проект не был завершён в последний обозначенный срок. Служба безопасности отключила продукт примерно на месяц. В это время шли активные переговоры внутри компании, чтобы нам разрешили пользоваться продуктом дальше.

Какая работа была проведена мной:

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

2. Описана текущая архитектура, все модули. Это позволило выбрать и согласовать будущую архитектурную схему.

3. Общение с вендором переведено в деловое русло: все встречи запланированы, а итоги встреч зафиксированы. Плюсы внедрения такого подхода:

   3.1.  спорные вопросы стали решаться быстро;

   3.2. забыть что-то стало невозможно.

   Возникшие сложности внедрения такого подхода:

   3.3. исполнитель стал менее активным в решении вопросов;

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

4. Достигнута договорённость о включении незафиксированного, но обязательного требования в текущую разработку без изменения стоимости.

5. Составлены варианты использования новой функциональности.

6. Написано техническое задание. Согласовать не удалось.

Казалось бы, удалось стабилизировать проект и договориться о продолжении работы продукта, но после решений выше общение с контрагентом стало крайне тяжёлым: согласование написанной документации шло медленно, а документация, предоставляемая с стороны исполнителя, требовала частых вопросов и корректировок. В «новом» обязательном требовании не удалость согласовать с контрагентом вариант реализации, переговоры зашли в тупик.

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

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

Итоги кейса

1. Если бы требования были зафиксированы на старте проекта, то проект бы не затянулся на столько месяцев.

2. Если была составлена хотя бы минимальная документация, не пришлось бы тратить впустую как мой ресурс (для восстановления документации), так и ресурс коллег, с которыми я постоянно взаимодействовала. Здесь отлично подходит афоризм «время – деньги». Документация появилась, а проект закрыли.

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

4. Если бы на проекте каждый выполнял свои обязанности, как требуется, то такого хаоса не произошло. Изначально я думала, что проблема в отсутствии документации по продукту, но проблема оказалась в самом управлении проектом: выстраивание здоровых отношений, фиксирование договорённостей и контроль работы и результатов специалистов.

Так как история не терпит сослагательного наклонения, поэтому «если бы» мы оставляем в мечтах и убираем проект на полку «опыт».

Другие интересные истории из мира IT, а также о том, как в этот мир попасть, читайте в моём канале.