Ключевой элемент методологии

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

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

Рассмотрим на небольшом абстрактном примере одну проблему, возникающую при внедрении в проекте методологии.

Одним прекрасным утром начальник отдела разработки коммерческой фирмы "Круглые подшипники" М., по совместительству заместитель директора по информационным системам, по совместительству менеджер проекта "Автоматизированная Система Кручения Подшипников", собрал участников проекта:

- Я знаю, почему наш проект, рассчитанный на выполнение за полгода, уже третий год не может завершиться. Вчера я встретился со специалистом крупной консалтинговой фирмы. Он сделал мне отличное предложение. Его фирма решит наши проблемы с проектом всего за три месяца, поставив всю разработку на современные рельсы самой лучшей методологии "Модифицированная крутизна". Их консультант прибудет к нам завтра для обследования. Вопросы есть?

Вопросов не было.

Какие же надежды возлагаются на сторонних специалистов? Основная преследуемая цель - ускорение разработки проекта. Менеджер предполагает, что знает основную причину задержки проекта. Он считает, что дело все в неправильном проектировании архитектуры. Если бы мы с самого начала спроектировали архитектуру правильно, думает он, мы не были бы сейчас в такой… беде.

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

Первое знакомство консультанта с проектом:

- Здравствуйте, я консультант К. Расскажите, пожалуйста, о распределении ролей в вашем проекте.

- Чего?

- Ну, кто за что отвечает?

- Я за все отвечаю!

- Понятно. Скажите, чем занимаются ваши люди?

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

- О'кей, - консультант понял, что нужно действовать иначе, - Хорошо, расскажите мне о вашей системе.

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

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

- Он сегодня за столом сам взял ложку!

Поскольку консультант об этой особенности знает, он может попытаться провести независимое расследование.

- Спасибо, а как устроена ваша система?

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

Так что вы возьмите эти документы, почитайте. Да, когда будете читать, везде, где написано "язык C", надо читать "язык J" - мы недавно решили, что это более перспективно, ну вы разберетесь.

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

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

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

Менеджеру очень интересно, что будет делать консультант:

- У вас есть опыт в организации таких разработок?

Консультант:

- Да, конечно, мы участвовали в… (следует пространное описание предыдущих проектов и козыряние громкими именами заказчиков).

Менеджер:

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

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

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

- Где я могу посмотреть, как вы работаете с исходным кодом?

Менеджер с подозрением смотрит на консультанта:

- Зачем вам исходный код?

- Незачем. Мне интересен не исходный код, а ваши правила работы с ним.

- А, правила… Ну, какие там правила? Все наши разработчики достаточно серьезные специалисты. Им даже не нужно говорить, они и так все сделают.

- Но разве их изменения в коде не мешают друг другу?

- Не понял, вы о чем?

- Ну, если два разработчика параллельно вносят изменения в один модуль, то как они между собой договариваются?

- Зачем им договариваться? Каждый работает на своем компьютере, у каждого есть полный исходный код. Какие проблемы?

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

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

- Хорошо. Кто строит конечную версию системы?

- Как - кто? Разработчики, конечно. Мы же пользуемся современными компиляторами, система строится в течение двух минут на любом рабочем месте.

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

Консультационная фирма для автоматизации своей методологии в проекте порекомендовала и поставила программы фирмы ХХХ.

Консультант:

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

Менеджер:

- Вот спасибо. А это лучшая программа?

- Э-э, да, конечно, одна из лучших. Она особенно хороша в интеграции с другими программами той же фирмы.

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

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

Консультант рекомендовал менеджеру регулярно проводить собрания для обсуждения изменений в архитектуре.

Менеджер собрал сотрудников проекта:

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

Никто высказываться не хотел.

- Что нам надо изменить в архитектуре? Какие есть предложения?

Разработчик Р. из дальнего угла, тихо:

- Известно, какие предложения… Переделать все с самого начала, вот и все предложения…

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

Менеджер:

- Так, понятно. Еще предложения есть? Господин Р., вы закончили модуль ввода, который вы обещали сделать на прошлой неделе?

- Нет еще. Я был занят - из отдела расчетов позвонили, сказали, что им срочно нужен расчетный модуль с новой функцией.

- Хорошо, тогда когда вы сделаете этот модуль ввода?

- Мне нужна еще неделя.

- Смотрите, через неделю я проверю.

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

Менеджер:

- Господин А., ваша модель базы данных закончена?

Аналитик А. уверенно отвечает:

- Конечно, позавчера. Я уже сказал об этом Р.

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

Менеджер:

- Вот это отлично. Господин Р., вы построили базу данных по модели?

- Построил, только я вместо трех таблиц сделал одну - так быстрее работать будет.

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

Аналитик так и сделает, но упустит при этом различие в типах данных двух полей таблицы.

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

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

Как-то в среду утром менеджер собрал участников проекта на внеочередное совещание:

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

Аналитик А.:

- По нашему новому плану у нас должно пройти еще две итерации до полноценного внедрения системы, поэтому мы вряд ли успеем.

Менеджер М.:

- Хорошо. Теперь давайте спросим разработчиков. Как, по-вашему, вы успеете реализовать все функции за оставшиеся три дня?

Разработчик Р.:

- Наверняка успеем. В принципе у нас осталось доделать только самую простую функциональность. Но мы не успеем все как следует протестировать.

М.:

- Так. А сколько вам нужно времени, чтобы все реализовать?

- Ну, если нас не будут отвлекать, и не нужно будет возиться с этими новыми программами, которые поставил нам консультант, то все равно меньше чем за три дня реализовать не получится.

М.:

- Хорошо, я все понял. Значит, решаем так. Первое. С сегодняшнего дня мы работаем только над заданием отдела закупок. Второе. Разработчики уходят вечером с работы, только тогда, когда я об этом объявлю. Если кому-то это не нравится, то можете прямо сейчас писать заявление об уходе. Третье. Тестировщики и разработчики выходят на работу в субботу и в воскресенье. Четвертое. Разработчики должны закончить к вечеру четверга реализацию всех функций и в пятницу утром должно начаться тестирование. И последнее. Возню с новыми регламентами и программами оставляем на потом. Сейчас главное - сделать работу вовремя.

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

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

Предыдущие нарушения сроков только убеждают менеджера в неприменимости вообще какого-либо планирования к проектам разработки.

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

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

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

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