Теория и практика реализации проектов разработки программного обеспечения под заказ
Компания-разработчик ПО разработала большую аналитическую систему для общенационального заказчика, а также обеспечивает постоянную поддержку системы в дальнейшем. Со временем система начинает устаревать и компания заказчика принимает решение создать новую версию. Компания имеет растущие амбиции и новый проект был объявлен «проектом международного уровня». Сбор и обработка информации заканчивается готовым техническим заданием на разработку программного обеспечения. Тут и возникают первые разногласия между ожиданиями обычного клиента (имеющего опыт работы со старой версией программы) и потенциального заказчика. Обычный заказчик имеет сильное влияние на проект, поэтому компромисс оказался очень близок его позиции. К сожалению, согласованный компромисс не был четко указан в требованиях к разработке ПО, и тут начинается точка бифуркации! Версия, как результат разработки, и версия клиента, «как получилось».
Три выделенные команды нанимаются для разработки отдельных частей проекта параллельно с командой Компании-разработчика. Планировалось начать с описания процесса автоматизации бизнес-процессов, но в действительности все стартовало с переработки уже существующей системы, как единственного источника технической информации. Тут появляется второе разногласие: роли и обязанности команд и игроков сформулированы не четко. В результате все 5 «актеров» на сцене справляются с задачами на собственное усмотрение. И все это в темной комнате, «под свечкой субъективности». Говоря «под свечкой субъективности», мы имеем в виду, что каждая команда работает согласно своих внутренних планов, средств отслеживания ошибок, управления версиями, и т.д. Отсутствие централизованной системы «перегревают» Команду-разработчика, которая в этой ситуации ответственна за управление планированием, отслеживанием ошибок и тд..
Наконец всем становится ясно, что ситуация бесповоротно провальная, и после традиционной «охоты на ведьм» принимаются первые шаги для улучшения общего рабочего процесса. Сначала это только общее формальное планирование, отчетность, инструменты … Хорошая попытка, но недостаточная! Что дальше? Общие роли и обязанности + процедура эскалации. Эскалация не работает! … Внутренний аудитор?! … нет результата?… Внешний аудитор! (имеет хороший уровень доверия со стороны менеджера проекта или спонсора). Идеальный результат! Отслеживание вопросов. Да! Общие хранилище документов и источников? Отложить …
Процесс настроен хорошо, но клиент ожидал готовность продукта в указанный срок. А очевидно, что система не может быть завершена в установленные сроки. Жесткие переговоры выносят на поверхность следующие проблемы: дискуссии привели к напряженности в отношениях между Клиентом и Разработчиком, а окончательный прием почти всех запросов клиента создает дополнительное проблемы со временем / бюджетом и процессом. Из двух зол было выбрано… оба (крах отношений, крах планированию). Следствие конфликта – реорганизация управления в Компании разработчика. Более того, это было сделано не одним выстрелом, но продлена большая работа в течение некоторого периода («охота на ведьм 2″). Это действительно не совсем благоприятно влияет на климат в команде, но основные процессы установлены и работают, так что разработка продолжается и производительность сильно увеличилась.
Новый менеджмент Компании-разработчика наконец стабилизировал внутренний процесс: рабочий компромисс между правильным формальным процессом и минимальная организация. Это дало возможность полностью переключиться на удовлетворение ожиданий клиента … но слишком поздно. Да, был какой-то положительный эффект: работы продолжались, но в любом случае заказчик ожидал большего и раньше. Окончательный поворот жестких переговоров с клиентом закончился отменой контракта. Таким образом, практически готовый к использованию продукт (бета-версия) не имеет применения, как крупными клиентами, так и международным заказчиком.
Отсутствие конкретной стратегии управления ожиданиями клиента. Если клиент «жесткий», следует планировать и контролировать ожидания клиента. Худший исход — расширение конфликта и отказ от некоторых запросов на изменения и, наконец, принятие всего «как есть». Отсутствие опыта управления крупными проектами с участием международных и распределенных команд. Опыт работы отечественных команд разработчиков «в офисе» не дает гарантий эффективности проекта при применении тех же методов управления к оффшорной команде. Местные проекты являются более стабильными и имеют более сильную тенденцию к самоорганизации. Таким образом, в действительности, начиная местный проект как «узкоспециальный», можно ожидать реализацию процесса где-то на уровне 2 — 3 после довольно короткого периода времени. В распределенных проектах эта «самоорганизация» практически невозможна и нужно позаботиться заранее о планировании и осуществлении процесса управления распределенными оффшорными командами. Ясное представление о роли и обязанности для каждого игрока, а также конкретные правила эскалации могут сэкономить много времени, особенно на начальных стадиях. В противном случае можно столкнуться с дублированием работы.
