Как добиться успеха в безнадежных проектах

Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули «забирают» все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект.

Все это признаки типичного безнадежного проекта [1]. Интерес к способам решения проблем, возникающих в процессе разработки проектов, не ослабевает. Основной методологией разработки в нашей организации является Rational Unified Process (RUP), поэтому представленные в статье решения ориентированы на продукты компании Rational Software. Однако тех же результатов можно достичь, используя аналогичные инструменты.

Основные черты безнадежных проектов изложены в [2]; там же рассказывается, что делает их таковыми и как их распознать еще до принятия стратегических решений. Напомним факторы, которые переводят проекты в разряд безнадежных:

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

Информационную систему крайне трудно разрабатывать без четкой методологии. В своих проектах мы используем адаптированную под наши нужды технику RUP. При этом артефакт Business Vision становится Концепцией Системы, документом на 5-10 страниц, описывающим основные архитектурные моменты информационной системы. Business Use Case Model в нашем понимании становится Техническим Заданием (ТЗ), документом, который согласовывается с заказчиком и описывает информационную систему с его точки зрения. Составные части ТЗ: бизнес-процесс, организационная структура предприятия, состав документов, технология проекта, различные поясняющие диаграммы (схема движения информации, основные потоки работ и т.п.). Далее, мы выделяем Технический Проект (Analysis Model), в котором описывается вид на систему с точки зрения программистов: структура выходных форм; список запросов и таблицы базы данных; внешние интерфейсы; доступные модулям процедуры сервера приложений и перечень функций каждого модуля.

На рис. 1 отображено распределение ролей в проекте. Системный аналитик пишет ТЗ и согласовывает его с заказчиком, проектировщик делает ТП и ставит задачи программистам. Реализованная информационная система тестируется отделом контроля качества совместно с программистами и представителями заказчика; в случае успеха отдел тиражирования занимается внедрением программного обеспечения.

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

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

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

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

К сожалению, «идеальных» заказчиков мало и проблемы прозрачности и изменяющихся требований приходится решать иными методами. Для наглядности информации в ТЗ мы применяем графические стереотипы основных терминов и понятий системы; до написания кода приложений согласуем формы интерфейса, а текущая бизнес-модель, автоматически сформированная модулем WebPublisher из Rational Suite, всегда доступна для просмотра в формате HTML. В случае изменения бизнес-требований заказчик сообщает об этом системному аналитику, и тот исправляет модель информационной системы. Проектировщик определяет масштабы изменения и отражает их в ТП, а затем передает новую постановку задач программистам (рис. 2).

Рис. 2. Технология цикла разработки

Проблемы изменения требований оказывают еще более негативное влияние на проект в случаях, когда затруднены коммуникации — как между заказчиком и командой, так и внутри нее. Наш заказчик «распылен» (деятельность нашей организации связана с автоматизацией госструктур и построением единых регистров населения, транспорта, правовых единиц и т.п.), поэтому основными средствами взаимодействия становятся совещания и рабочая документация проекта. Чтобы совещание было успешным, следует учесть ряд моментов. Тему совещания надо четко определить, подготовив список конкретных вопросов; приглашаются только нужные люди с полномочиями принятия решений; оптимальное число участников — 4-7 человек; по каждой проблеме нужно достичь хотя бы временного, «промежуточного» решения.

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

Как известно, среди проблем проектирования ключевое место занимает проблема отсутствия концептуальной целостности и непротиворечивости архитектуры. Поэтому важно назначить архитектора продукта, ответственного за все его стороны. Кроме того, необходимо отделить архитектуру (т.е. определение продукта в восприятии пользователя) от его разработки [1]. Однако ничто так не вредит переходу от проектирования к программированию, как оторванность ТЗ от реального кода. Системного аналитика и проектировщика нужно подключить к программированию. Это позволит добиться осведомленности системного аналитика (а, следовательно, и заказчика) и проектировщика о реальном положении дел, лучшей согласованности между архитектурой и реализацией, более действенной коммуникации. Именно так можно построить эффективную команду, а не просто группу разработчиков.

В этих аргументах есть некоторые расхождения с «постулатами» RUP, но на практике безусловное разделение функций между архитекторами и исполнителями, чьи творческие таланты и идеи подавляются, приводит к плачевному результату. Архитекторы «витают в облаках», разрабатывая маловразумительные спецификации, а кодировщики вынуждены заполнять информационные пробелы собственным пониманием проблемы, о чем аналитик и заказчик узнают последними. Дело вовсе не в том, чтобы дать кодировщикам широкие возможности по реализации своих творческих замыслов, напротив, «собственное мнение» кодировщику противопоказано — программирование сегодня не искусство, а ремесло. Однако довести до архитекторов проблемы непосредственно кодирования необходимо; менеджер проекта должен представлять себе, как диаграммы, прекрасно выглядевшие на бумаге, реализуются в коде. Поэтому наиболее эффективно привлечение многофункциональных специалистов, имеющих знания в нескольких смежных областях. Разработка программного обеспечения более сложна, многообразна и непредсказуема, чем конвейерное производство типовых моделей.

Непонимание между заказчиком и разработчиком требует создания единого словаря терминов разрабатываемой информационной системы. У нас такой глоссарий системы представляет собой продукт совместной разработки системного аналитика и проектировщика. С учетом того, что модели ТЗ и ТП создаются с помощью CASE-инструментария Rational Rose, мы используем возможность автоматизированного управления глоссарием, который находится в отдельной модели, доступной по сети всей команде. Только один человек добавляет или модифицирует данные глоссария, остальные же автоматически получают его текущую версию при работе со своими моделями. Эта возможность обеспечивается за счет синхронизации информации в разрабатываемой модели (Project.mdl) и глоссария, встроенного «по ссылке» в модель, но в то же время существующего отдельно (Glossary.cat). Благодаря этому становится реальной параллельная работа системных аналитиков и проектировщиков при централизованном управлении глоссарием и последовательной обработке запросов на его изменение (рис. 3).

Рис. 3. Работа с глоссарием

Для разделения информационных систем на модули используется множество методов — от описания предметной области на английском языке (при этом существительные станут классами, а глаголы их методами), до практики использования CRC-карт (Class-Responsibility-Collaborator — идентификация объектов информационных систем, меры их «ответственности» и механизма взаимодействия). Наше решение зависит от требований заказчика, штатной структуры компании и функциональных обязанностей служащих. При этом обеспечивается максимальная интеграция с уже существующим программным обеспечением; автоматизируются только те участки, в которых возникла необходимость и которые реально переработать за установленные сроки и в конкретных условиях, остальное же остается «как есть» и разрабатываются «переходники» для связи между «новыми» и «старыми» модулями.

Среди проблем собственно кодирования, следует выделить нежелание использовать компоненты сторонних производителей; между тем, часто дешевле купить готовый модуль, чем разработать, протестировать и внедрить собственный. При написании кода также могут использоваться готовые программные конструкции, так называемые «паттерны» (design pattern). Последняя версия Rational Rose XDE поддерживает паттерны и интегрирует их с Visual Studio .Net.

Хорошим проектным решением является стандарт на оформление программных форм, нормативы на количество и размеры информационных и управляющих элементов, характеристики цветовой гаммы и т.п. Помочь в данном случае может стандартный репозиторий программных форм. Кроме того, программный код обязательно оформлять с учетом так называемых «правил кодирования», приняв соглашение по форматированию, названиям объектов, механизмам использования памяти и обработки ошибок и т.п. Нашей организации разработать полноценный стандарт кодирования еще предстоит, поэтому пока для нужд непосредственно программирования используется репозиторий объектов. Сотрудник, ответственный за техническую поддержку репозитория, модифицирует его с учетом изменяющихся требований по функциональности и эффективности форм. Кроме того, в связи с использованием метода round-trip engineering (синхронизация между кодом и моделью в обоих направлениях) с помощью RoseDelphiLink_3_2, разработано положение о документировании программного кода, цель которого — автоматическое получение документации через шаблоны Rational SoDA. В перспективе будет использоваться инструментарий компании BoldSoft, средства которого вошли недавно и в Borland Delphi7 Architect Studio.

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

Рис. 4. Эффективность различных видов коммуникаций

Мы решили задачу автоматизированного создания и модификации ТЗ и ТП за счет использования шаблонов Rational SoDA. При этом из моделей Rose формируются готовые файлы в формате Word, соответствующим образом оформленные и готовые для согласования (рис. 5). Таким образом, достигается главная цель — налаживается взаимодействие удаленных друг от друга участников проектной команды, а ее создание не является обременительным процессом.

Рис. 5. Принцип работы автодокументирования

И последний вопрос — тестирование, которому по-прежнему уделяется мало внимания. Между тем, сохраняет свою актуальность мнение, высказанное в [1]: 1/3 времени проекта должно занимать планирование, 1/6 — написание программ, 1/4 — тестирование компонентов и предварительное системное тестирование, 1/4 — системное тестирование при наличии всех компонентов. В нашей организации имеются планы по использованию средств типа Ghost, TestComplete, систем сбора дефектов (Rational ClearQuest), программ определения утечки памяти, «охват» кода и скоростные параметры функций (Rational Purify, PureCoverage и Quantify), но из-за недооцененности этих проблем тестирования руководством, серьезных инвестиций в данную область пока нет. Одним из показателей зрелости ИТ-компании, как известно, является наличие у нее стандарта тестирования, где представлена функциональная модель тестирования, определены сроки, роли и обязанности участников, изготовлены тестовые классы, подсистемы, скрипты, инструменты, имеется соответствующая документация.

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

Литература

Константин Берлинский (berlicon@yahoo.com) — системный аналитик Департамента информационных технологий при Правительстве Республики Молдова (Кишинев).