Как пережить взлеты и падения ИТ-проектов

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

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

• Разработать список того, что должно быть выполнено
• Спрогнозировать примерные затраты на выполнение
• Достичь соглашения по данным определениям и затратам
• Спроектировать первый формальный дизайн
• Создать все элементы
• Протестировать элементы
• Выпустить в использование данные элементы

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

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

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

Несмотря на  сложность в определении "фактов", настройка и исправление функциональности может привести к разделению 80/20, где 80% затрат производят всего 20% всех преимуществ, и наоборот - вот тут клиентам стоит задуматься. На протяжении 2-3-летнего проекта вполне естественно  могут произойти значительные изменения и в бизнес-требованиях. Это является причиной принятия концепции быстрой разработки приложений (Rapid Application Development -RAD).

Сложность в составлении хорошего прогноза

Очень сложно создать хорошее прогнозирование и оценки.  Увеличение степени разбиения может привести к увеличению границ надежности (то есть, если минимальная единица составления прогноза - 1 день, то все, что заняло 1 час, будет записано, как 1 день усилий, что означает 7 часов на действие такой длины). Прогнозы должны быть определены на основе исторических данных для составления временных рамок, но они должны быть очень осторожно указаны и использованы для того, чтобы все было как можно эффективнее.

Вероятно, в  данном случае более желательно, чтобы  «оценка  была проконтролирована демократически,  а  выполнение включало авторитарные методы, нежели  наоборот.

Принятие фактов

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

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

Концепция быстрой разработки приложений (Rapid Application Development - RAD)

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

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

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

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

И опять мы понимаем, что структура проекта может иметь значительное влияние на эффективность и реальность разработки.

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

Vernon Riley