Теория и практика реализации проектов разработки программного обеспечения под заказ

Акт первый: Жили-были…

Компания-разработчик ПО разработала большую аналитическую систему для общенационального заказчика, а также обеспечивает постоянную поддержку системы в дальнейшем. Со временем система начинает устаревать и компания заказчика принимает решение создать новую версию. Компания имеет растущие амбиции и новый проект был объявлен «проектом международного уровня». Сбор и обработка информации заканчивается готовым техническим заданием на разработку программного обеспечения. Тут и возникают первые разногласия между ожиданиями обычного клиента (имеющего опыт работы со старой версией программы) и потенциального заказчика. Обычный заказчик имеет сильное влияние на проект, поэтому компромисс оказался очень близок его позиции. К сожалению, согласованный компромисс не был четко указан в требованиях к разработке ПО, и тут начинается точка бифуркации! Версия, как результат разработки, и версия клиента, "как получилось". 

Акт второй: Запуск процесса

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

Акт третий: Процесс восстановления

Наконец всем становится ясно, что ситуация бесповоротно провальная, и после традиционной "охоты на ведьм" принимаются первые шаги для улучшения общего рабочего процесса. Сначала это только общее формальное планирование, отчетность, инструменты ... Хорошая попытка, но недостаточная! Что дальше? Общие роли и обязанности + процедура эскалации. Эскалация не работает! ... Внутренний аудитор?! ... нет результата?... Внешний аудитор! (имеет хороший уровень доверия со стороны менеджера проекта или спонсора). Идеальный результат! Отслеживание вопросов. Да! Общие хранилище документов и источников? Отложить ...

Акт четвертый: Прохладный ветер

Процесс настроен хорошо, но клиент ожидал готовность продукта в указанный срок. А очевидно, что система не может быть завершена в установленные сроки. Жесткие переговоры выносят на поверхность следующие проблемы: дискуссии привели к напряженности в отношениях между Клиентом и Разработчиком, а окончательный прием почти всех запросов клиента создает дополнительное проблемы со временем / бюджетом и процессом. Из двух зол было выбрано... оба (крах отношений, крах планированию). Следствие конфликта – реорганизация управления в Компании разработчика. Более того, это было сделано не одним выстрелом, но продлена большая работа в течение некоторого периода («охота на ведьм 2"). Это действительно не совсем благоприятно влияет на климат в команде, но основные процессы установлены и работают, так что разработка продолжается и производительность сильно увеличилась.

Акт пятый: Конец

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

Ошибки, которые приводят проект к краху:

Отсутствие конкретной стратегии управления ожиданиями клиента. Если клиент "жесткий", следует планировать и контролировать ожидания клиента. Худший исход - расширение конфликта и отказ от некоторых запросов на изменения и, наконец, принятие всего "как есть". Отсутствие опыта управления крупными проектами с участием международных и распределенных команд. Опыт работы отечественных команд разработчиков "в офисе" не дает гарантий эффективности проекта при применении тех же методов управления к оффшорной команде. Местные проекты являются более стабильными и имеют более сильную тенденцию к самоорганизации. Таким образом, в действительности, начиная местный проект как «узкоспециальный», можно ожидать реализацию процесса где-то на уровне 2 - 3 после довольно короткого периода времени. В распределенных проектах эта "самоорганизация" практически невозможна и нужно позаботиться заранее о планировании и осуществлении процесса управления распределенными оффшорными командами. Ясное представление о роли и обязанности для каждого игрока, а также конкретные правила эскалации могут сэкономить много времени, особенно на начальных стадиях. В противном случае можно столкнуться с дублированием работы.