Методические рекомендации по жесткому внедрению

Project Manager Guide to "Mission Impossible" project

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

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

Этот опыт позволяет мне дать очень частные, но конкретные советы о том как выжить в пикирующем проекте.

Границы оптимальной применимости методических рекомендаций:

• Высокие политические риски. Проект является частью политической игры между менеджерами компании Заказчика или Исполнителя. Игра может быть следствием здоровой конкуренции подразделений, так и не здоровые выяснения отношений.
• Проект убыточен и неуправляем. Убытки и неясность перспективы, как следствие падение морального духа команды. От вас в первую очередь ожидают прекращения убытков и предсказуемости результатов.
• Сверхвысокий уровень ответственности. Ответственность сторон (юридическая и политическая) за результат важнее качества и цены.
• Большое количество вовлеченных в принятие решений лиц. В принципе, это разновидность политических рисков.
• Политическая среда такова, что вам не удастся вести разработку по "правильным методам". Заказчик настаивает на определенных наборах требований/цен/сроков/процедур, которые не дадут вам действовать наилучшим с вашей точки зрения образом.
• Вы не можете нести ответственность за качество идей Заказчика. Заказчик может быть опытнее вас в требованиях и процедурах проекта и вы ему нужны только в качестве реализатора его идей по его технологии. Вопрос в данном случае в том, что вам не следует брать на себя ответственность за качество идей Заказчика. Ваша ответственность заключается в качестве реализации этих идей. Это не одно и тоже, о том, как развести ответственность, ниже.

• Кризис качества. "Не продукт, а прототип". Обычно это один или несколько прототипов системы, которые Заказчик и Исполнитель по наивности или по некомпетентности считают продуктом. Назовем их прототипами потому, что такие программы обычно не отвечают требованиям к продукту таким как:
  - продукт реально эксплуатируется, реализован весь жизненный цикл работы пользователей (в Прототипе обычно реализована только часть рабочего цикла);
  - для поддержания готовой функциональности Продукта практически не требуется постоянный контакт с Исполнителем (Прототип находится в состоянии перманентного ремонта, речь идет не о доработках, а исправлении разного рода ошибок).
• Кризис качества архитектуры "Отсутвие стабильности". Прототипы могут нравиться или не нравится Заказчику. Обе ситуации ничего особо хорошего не сулят. Прототип, который "нравится" может быть (и был) сделан в ненадлежащей задаче архитектуре. Для устранения всех его дефектов потребуются просто фантастические усилия, тем не менее, это можно решить, причем без героических усилий. О технике стабилизации проекта см. ниже. Прототип, который не нравится Заказчику, следует просто выбросить и провести нормальный цикл разработки итеративными методами, с правильным специфицированием... Все это хорошо, но может быть, вы питаете иллюзию относительно возможности это сделать, т.к. см. самый первый пункт о политических рисках.
• Проверено на технологиях и продуктах:  Domino, Delphi, SAP R/3, SQL Server, IIS, 1C, Галактика и др.

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

Если это не делалось до этого, сразу начинайте использовать программу планирования типа MS Project. В противном случае вы запутаетесь в бесчисленном количестве задач.

Не стоит сразу чертить в MS Project план завершения проекта, на первых порах попользуйтесь им почти как записной книжкой, регистрируя ход событий де-факто. Иными словами, дайте  каждому разработчику задание на 2-3 дня, сохраните это задание в MS Project как базовый план (base line). Затем спокойно зарегистрируйте, сколько дней на самом деле ушло у каждого и каков был реальный состав задач. Так вы получите реальную статистику производительности своих подчиненных.

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

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

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

Если не предусмотреть специальных действий, то Заказчик будет считать нечеткость своих требований вашей проблемой. Что делать? Прежде всего, честно сказать, что ситуация такова и предложить взять ответственность за нечеткость требований на себя, но потребовать за это увеличения сроков и стоимости проекта пропорционально вашим статистическим расчетам реальных затрат. В простейшем случае это означает следующее: вы  умножаете сроки и цены на 4-5 . Если Заказчик согласится, то переходите к спиральной методике ведения проекта.

Однако Заказчик может не согласится, т.к. питает иллюзию относительно того, что его требования правильные и окончательные. Другая причина заключается в том, что Заказчик уверен в себе как в постановщике и не хочет потерять контроль, отдав вам на 100% управление ситуацией. Еще одна причина - политические игры внутри Заказчика/Исполнителя. Вполне возможно, что вы окажитесь в ситуации скорее сведения счетов во время  разработки программного продукта.

В любом из этих случаев вы не можете контролировать изменение требований Заказчика.

Несколько простых и эффективных советов:

1. Записывайте и подписывайте все договоренности
2. Не признавайте никаких договоренностей, которые не были документально зафиксированы. Не заключайте устных договоренностей принципиально.
3. Не спорьте с Заказчиком, записывайте его требования максимально подробно и формально.
4. Выдерживайте позицию, что новое требование всегда приводит к коррекции трудоемкости/сроков/стоимости.
5. Сразу укажите, что вы гарантируете только соответствие системы своему описанию, а не решение проблем Заказчика. Ответственность решения проблем лежит на Заказчике, формулирующего требования для задания. Ваше ответственность только в выполнении задания.
6. При записи требований не используйте декларативный стиль описания. Применяйте только конкретные сценарные описания типа use case. Добивайтесь, что бы сценарии разбивались на множество элементарных и не подлежащих различному толкованию шагов.
7. Не допускайте возможностей различных толкований обозначений и методов формализации. Составьте и утвердите документ, в котором указано, что стоит за каждым обозначением в описании. Например, если вы приводите в ТЗ список полей документа, то должно быть зафиксировано, что этот список означает не более чем набор полей, в которые можно внести значения и более ни какой дополнительной функциональности.
8. Если система обладает даже незначительным ограничением, отразите это в задании в виде примечания.
9. При окончательной договоренности потрудитесь письменно согласовать, какие документы имеют силу. В противном случае к вам могут прийти с протоколом о намерениях годичной давности.
10. Найдите измеряемые критерии качества продукта. Обычно это контрольные тесты; добейтесь, чтобы продукт был принят именно путем замеров параметров качества, а не путем толкований задания.

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

Для проектного управления группой желательно использовать специальные системы, такие как MS Project Central Server. Это позволит вам автоматизировать сбор статистики от сотрудников. Должно стать правилом отсылать  отчет менеджеру о выполнении работ и фактических затратах времени раз в 2-3 дня.

Управляемость и прибыльность достигается за счет последовательного соблюдения технологии ведения проекта.

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

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

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

Сколько бы ни было ошибок в Системе, которую вам вручили, это не повод для отчаяния.

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

1) Введите контроль дефектов системы. Очень часто разработчики не ведут учет дефектов, поэтому и не могут от них избавится.

2) Зарегистрируйте все дефекты, какие только можно найти всеми способами: осмотр программы, сверка с описанием, замечания пользователей.

3) Для получения статистики классифицируйте дефекты по следующим признакам:

• модуль
• кто должен исправить
• тип дефекта
• состояние обработки дефекта
• приоритет дефекта
• причина дефекта

4) Проанализируйте статистику, выявите самые главные причины дефектов.

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

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

7) После анализа причин ошибок составьте план исправления самых критичных дефектов.

8) Согласуйте с Заказчиком контрольные тесты, условьтесь, что только они являются критерием безошибочности работы системы.

9) Проверяйте  программу по тестам и исправляйте ошибки, пока  100% тестов не завершаться успешно. Организуйте проверку исправлений программистов, так называемое регрессивное тестирование.

10) Примерно на 8й цикл проверок и исправлений все дефекты будут исчерпаны.

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

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

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

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

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

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