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

«До сих пор остались без ответа вопросы, почему вполне разумные организации предпринимают подобные проекты, и почему разумные менеджеры и технические специалисты соглашаются участвовать в таких проектах» [1]

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

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

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

«Наивный оптимизм юности: Мы сможем сделать это за выходные!»

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

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

Необходимо фиксировать версии

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

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

Впрочем, значимость «зафиксированной версии» шире. Во всех методологиях, подразумевающих инкрементальную разработку, фиксация версии является ключевым моментом для выбора тактики поведения на следующей итерации, принятия решения о необходимости внести изменения в используемую методику [5]. Это также единственный способ обеспечить возможность быстрого «отката» в случае неудовлетворительных результатов следующего этапа. Но есть и психологический аспект; необходимы четко зафиксированные вехи, дни, когда команда может вздохнуть и сказать: «Мы это уже сделали!»

«Серебряной пули нет»

Эта тема [2], казалось бы, исследованная вдоль и поперек, по-прежнему остается источником огромного количества ошибок. Вновь и вновь руководители команд приступают к проектам, выбрав очередную чудо-технологию и будучи искренне уверенными, что именно она станет залогом успеха. UML для проектировщика, ASD для менеджера проекта, компонентная модель для архитектора, Java для программиста... Число проваленных, превысивших все запланированные ресурсы, закрытых проектов меньше не становится.

Несмотря на много раз сформулированное правило — «ни одна технология не позволит повысить производительность труда в программировании на порядок», в целях снижения стоимости продукта заказчик настоял на том, чтобы в качестве платформы для реализации нового сервера приложений была выбрана ОС Linux с ядром 2.4. Наши предложения провести исследования и выяснить, годится ли платформа для решения поставленной задачи, заказчик отверг, ссылаясь на недостаток времени, консультации с экспертами и публикации в многочисленных изданиях, которые свидетельствовали о пригодности платформы. В результате, разработчикам пришлось столкнуться с огромным числом сложностей, связанных, в первую очередь, с несоответствием описаний тех или иных программных интерфейсов и их реализацией. Скажем, функции библиотеки pthreads работали совсем не так, как требует POSIX. Проект спас лишь предварительно разработанный слой, абстрагировавший код от конкретных реализаций необходимых ему сервисов (многопоточность, механизмы взаимодействия между процессами и потоками и т.д.), который позволил перенести решение на другую платформу.

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

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

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

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

Если делегировать руководителям проектов дополнительные полномочия, превышающие полномочия менеджеров, лишь предоставляющих отчеты на еженедельных собраниях руководства, и включить этих руководителей в бизнес, это во многом упростит механизм управления проектами. Использование метафоры «виртуального предприятия» имеет множество неоценимых достоинств: занятые в индустрии разработки программного обеспечения люди, как правило, являются весьма яркими личностями, не избегающими ответственности, а потому такая форма работы может оказаться для них более комфортной. Кроме того, значительно упрощается механизм оценки успешности проекта. Для его оценки значительно легче использовать технологии бюджетирования, описанные, например, в [6].

Вы не должны допускать, чтобы вы не знали языка, принятого в области, которой руководите» [4]

В проектах, связанных с разработкой программного обеспечения, роль менеджера не может сводится к общению с заказчиком и строгому наблюдению за «рытьем канавы» командой подчиненных. Понимание технологических проблем, с одной стороны и способность к их обсуждению, с другой, являются непременным требованием, предъявляемым к руководителю проекта. Однажды я наблюдал картину, как вновь пришедший руководитель проводил собрания своей команды. Исправно приходившие на собрание программисты достаточно быстро перестали общаться со своим руководителем — нечего было обсуждать. По сути, высокооплачиваемый менеджер среднего звена играл роль сержанта, загоняющего взвод на мероприятие. Достаточно дорогое удовольствие, не находите? На волне Internet-бума появилось большое число руководителей проектов, умеющих организовать разработку Web-представительства. Проблемы, встающие при разработке серьезного программного обеспечения и обычно несравненно более сложные, предполагают наличие у участников команды значительно большего профессионализма.

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

Если кто-то не смотрит, не спрашивает, не анализирует, попросите его уйти» [4]

Безразличный человек разрушает команду — в том случае, конечно, если команда заинтересована в успехе. Но как в условиях сжатых сроков, недофинансирования, задержанных отпусков и т.д. сохранить заинтересованность в успехе? Вообще говоря, Йордан про это уже все объяснил — «никак» [1]. Нет универсальных рецептов, которые помогут сохранить команду. Особенно, если ее нет. Устраиваясь на работу, я ни разу не слышал от интервьюирующего меня специалиста, о том, что компания израсходовала бюджет проекта, управлять которым меня приглашали, еще полгода назад. Или о том, что отдел разработки укомплектован абсолютно разными — культорологически, профессионально и социально — людьми, которые не в состоянии эффективно работать вместе. О взаимодействии между департаментами продаж и разработки можно только мечтать. С большим удивлением я узнавал о том, что на самом деле никаких стратегических планов нет, что «партнерские» компании не очень заинтересованы в совместном бизнесе и т.д. Декларируемые сертификаты ISO, CMM и т.д. — часто лишь красивые вывески для привлечения заказчиков, под которыми ничего нет или, в лучшем случае, сертификат.

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

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

«Неправильное решение, принятое ранее, может быть пересмотрено позднее. Правильное решение, принятое слишком поздно, ничего не может изменить» [4]

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

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

***

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

Литература

  1. Edward Yourdon, Death March. The Complete Software Developer?s Guide to Surviving Mission Impossible. Projects Prentice Hall, 1997. (есть перевод: Эдвард Йордан, «Смертельный марш. Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах». Перевод с англ. А.М. Вендрова.

  2. Frederick P. Brooks Jr., The Mythical Man-Month. The Essays on Software Engineering. Addison-Wesley, 1975. (Есть перевод: Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. Перевод с англ. С. Маккавеева. СПб.: Символ-Плюс, 2001.)

  3. Борис Шлаин, «Слабое звено в безупречной автоматизации...». CIO/Руководитель информационной службы, 2003, № 1.

  4. В. Куперштейн, В. Богданов, Сто правил руководителей проектов NASA.

  5. Alistair Cockburn, « Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121, USA. (есть перевод: Алистэр Коуберн, «Каждому проекту своя методология». http://www.maxkir.com/sd/methyperproject_RUS.htm.)

  6. Алексей Субботин, «Контроль бюджета проекта по графикам ?освоенного объема?». // «Директор информационной службы», 2002, №11.

Александр Эпштейн (alex_ep@hotmail.com) — независимый консультант и разработчик программного обеспечения (Москва).