Project Manager Guide to “Mission Impossible” project
Жесткое внедрение - внедрение в условиях жесткого формального управления, пониженного доверия и повышенной ответственности Заказчика и Исполнителя. Жесткое внедрение обычно является следствием сильных политических рисков.
Как сразу навести порядок?
Как не брать на себя ответственность за
чужие ошибки?
Как обезопасить себя от неприятностей в
связи с изменением требований?
Как добиться предсказуемости проекта?
Как уйти от убытков проекта и получить
прибыль?
Как прекратить войну подразделений?
Как добиться стабильности
разваливающегося продукта?
Что делать, если проект уже убыточен и
безнадежен?
Рекомендации расширяются по вашим запросам. Пишите: ivanov-soft@inbox.ru
см. также Семинары по проектному управлению на базе MS Project 2000
Когда данные рекомендации оптимальны?
В моей практической деятельности мне часто приходится играть роль реаниматора гибнущих софтверных проектов, находящихся в условиях сильных рисков, в первую очередь политических. Приходится бороться за управляемость и рентабельность разработки достаточно жесткими действиями.
Этот опыт позволяет мне дать очень частные, но конкретные советы о том как выжить в пикирующем проекте.
Границы оптимальной применимости методических рекомендаций:
Первое, с чего надо начать, это планирование. Если в успешном проекте, идущем по спирали, достаточно делать прикидку плана на очередной этап, в пикирующих проектах менеджмент должен быть жестким, причем с минимальными интервалами между контрольными точками.
Если это не делалось до этого, сразу начинайте использовать программу планирования типа MS Project. В противном случае вы запутаетесь в бесчисленном количестве задач.
Не стоит сразу чертить в MS Project план завершения проекта, на первых порах попользуйтесь им почти как записной книжкой, регистрируя ход событий де-факто. Иными словами, дайте каждому разработчику задание на 2-3 дня, сохраните это задание в MS Project как базовый план (base line). Затем спокойно зарегистрируйте, сколько дней на самом деле ушло у каждого и каков был реальный состав задач. Так вы получите реальную статистику производительности своих подчиненных.
Заставьте членов своей команды выполнять обязательства по сроками и качеству. Делайте инспекции, разбирайте проблемы групповым анализом, не давайте людям отвлекаться на внеплановые задачи. Если человек в течении месяца не способен удержаться в вашем плане, увольте его. В спиральном проекте некоторая необязательность может быть простительна, т.к. нет четких заранее поставленных задач, однако в жестких проектах за отклонение от договоренностей вас четвертует Заказчик, причем, возможно, в суде.
Помните, что разработчики сильно отличаются по производительности труда. Один классный профессионал может заменить целую команду из 3-5 человек. Тем, кто работает за десятерых, платите сколько сможете, никакой уравниловки и ложной экономии. ЗП разработчиков - далеко не главный источник расходов.
Как не брать на себя ответственность за чужие ошибки?
Цель Заказчика - не построить ряд программных модулей, а решить некоторые проблемы своего бизнеса. Решение своих проблем Заказчик обычно видит в программном продукте, который удовлетворяет некоторому набору требований. Проблема в том, что никогда не бывает, чтобы Заказчик мог сформулировать сразу все требования в формально четком виде. Обычно Заказчик может сформулировать лишь ряд требований, причем расплывчато, упуская важные ключевые места и т.д. Потребуется несколько версий системы и целая серия прототипов, чтобы удовлетворить должным образом все требования. Причем причина этого в первую очередь заключается в принципиальной нечеткости задания, а не в ошибках проектирования и программирования.
Если не предусмотреть специальных действий, то Заказчик будет считать нечеткость своих требований вашей проблемой. Что делать? Прежде всего, честно сказать, что ситуация такова и предложить взять ответственность за нечеткость требований на себя, но потребовать за это увеличения сроков и стоимости проекта пропорционально вашим статистическим расчетам реальных затрат. В простейшем случае это означает следующее: вы умножаете сроки и цены на 4-5 . Если Заказчик согласится, то переходите к спиральной методике ведения проекта.
Однако Заказчик может не согласится, т.к. питает иллюзию относительно того, что его требования правильные и окончательные. Другая причина заключается в том, что Заказчик уверен в себе как в постановщике и не хочет потерять контроль, отдав вам на 100% управление ситуацией. Еще одна причина - политические игры внутри Заказчика/Исполнителя. Вполне возможно, что вы окажитесь в ситуации скорее сведения счетов во время разработки программного продукта.
В любом из этих случаев вы не можете контролировать изменение требований Заказчика.
Как обезопасить себя от неприятностей в связи изменением требований?
Несколько простых и эффективных советов:
Как добиться предсказуемости проекта?
Предсказуемость достигается через планирование и статистический учет. Собирайте достоверную статистику о ходе работ. Заставьте сотрудников заполнять табеля рабочего времени. Ведите учет в данных табелях по видам работ.
Для проектного управления группой желательно использовать специальные системы, такие как MS Project Central Server. Это позволит вам автоматизировать сбор статистики от сотрудников. Должно стать правилом отсылать отчет менеджеру о выполнении работ и фактических затратах времени раз в 2-3 дня.
Как уйти от убытков проекта и получить прибыль?
Управляемость и прибыльность достигается за счет последовательного соблюдения технологии ведения проекта.
Зафиксируйте максимально однозначно требования к Системе и применяйте регулярное планирование, базирующееся на статистических оценках как то описано выше. Оценив статистикой верную трудоемкость и сроки, не поддавайтесь на попытки сбить вас ниже себестоимости. Если ваша себестоимость и качество на среднерыночном уровне, то Заказчик не откажется от ваших услуг. Если ваша разработка явна выше по себестоимости, заказываете все у подрядчиков. Лучший способ что-то сделать - это купить.
Если вы будете последовательны в применении указанных принципов, то ваше дело быстро станет прибыльным. Следует отметить, что достижение прибыльности часто идет в ущерб популярности. Заказывая у подрядчиков, вам возможно придется лишить заказа внутреннее “лобби” программистов. Вы можете не быть популярны и у Заказчика своей жесткой позицией, когда за любое изменение требований приходится платить. Однако вы получите поддержку топ-менеджмента, и вряд ли без вашей жесткой позиции у Заказчика была бы информационная система без вас.
Как прекратить войну подразделений?
Чем больше ваша компания, тем больше вероятность, что она представляет собой много конкурирующих команд. Это нормально и очень хорошо, если топ-менеджмент смог добиться здоровой конкуренции через бюджетирование и хозрасчет. Однако может выяснится, что топ-менеджеры выясняют отношения между собой, в этом случае и образуется "лобби". В какой-то степени "лобби" всегда есть, как фаворитная команда. Если вы попали не на разработку, а на войну, то постарайтесь разборки привести в состояние здоровой конкуренции. Найдите союзников, большинство топ-менеджмента заинтересовано в прибыльности дела, а не в разборках. Найдя союзников, постарайтесь помочь им создать честные правила конкуренции подразделений. Обычно такие правила закрепляются как политика бюджетирования и хозяйственной самостоятельности подразделений.
Как добиться стабильности разваливающегося продукта?
Сколько бы ни было ошибок в Системе, которую вам вручили, это не повод для отчаяния.
В первую очередь следует добиться прекращения создания новых ошибок (ликвидировать или ослабить их причины), а существующие можно удалить следующим методичным подходом.
1) Введите контроль дефектов системы. Очень часто разработчики не ведут учет дефектов, поэтому и не могут от них избавится.
2) Зарегистрируйте все дефекты, какие только можно найти всеми способами: осмотр программы, сверка с описанием, замечания пользователей.
3) Для получения статистики классифицируйте дефекты по следующим признакам:
4) Проанализируйте статистику, выявите самые главные причины дефектов.
5) Составьте план устранения причин появления дефектов (проблемы архитектуры, организационный недосмотр и т.д.).
6) Не боритесь с конкретными ошибками до выявления их причин, т.к., возможно, вы имеете дело с неверной архитектурой, и возможно легче переделать отдельные модули системы заново. Оцените, что более трудоемко: устранить причины дефектов или устранить сами дефекты и только потом приступайте к работе.
7) После анализа причин ошибок составьте план исправления самых критичных дефектов.
8) Согласуйте с Заказчиком контрольные тесты, условьтесь, что только они являются критерием безошибочности работы системы.
9) Проверяйте программу по тестам и исправляйте ошибки, пока 100% тестов не завершаться успешно. Организуйте проверку исправлений программистов, так называемое регрессивное тестирование.
10) Примерно на 8й цикл проверок и исправлений все дефекты будут исчерпаны.
Следует отметить, что дефекты уйдут, но останутся проблемы. Предлагайте разработать новую Систему для их устранения, настаивайте на том, что текущие договорные обязательства по качеству выполнены.
Что делать, если проект уже убыточен и безнадежен?
Быть может, вы обнаружите, что успехи у проекта до вас близки к нулю. Заказчики недовольны или покупателей нет совсем, система весьма некачественная или ее нет как таковой вопреки утверждениям.
Это, конечно, пример радикальных случаев. Но вообще убыточность и безнадежность проекта не должна шокировать менеджера. Независимо от состояния проекта, который вам передали, рекомендуем провести процедуру его закрытия. Закрытие проекта может означать завершение или его ликвидацию. Затем, скорее всего, вы откроете новый проект с тем же персоналом.
Проводя процедуру закрытия, вы должны определить критерии окончания проекта и довести проект до них. Желательно иметь критерии измеряемого типа. Проект может быть удачным или неудачным, но он всегда должен быть закончен неким формальным действием. Оцените результаты проекта после его закрытия, выясните сколько на самом деле пришлось затратить ресурсов.
Вполне возможно, что вы, закрывая проект, посчитаете нужным совсем свернуть разработку и возместить убытки, нанесенные клиенту. Так можно сохранить значительные деньги своей компании и Заказчика, вовремя остановив убыточное дело. Да и для персонала такой вариант часто является решение проблем, т.к. пикирующий проект обычно заставляет выкладываться на все 100% за маленькие деньги. Кроме того, надо учитывать, что любой проект, как любой товар, имеет точку смерти. За этой точкой товар не покупают, нужен новый товар (проект).
После процедуры закрытия проекта вы получите ситуацию, когда все обязательства снова сбалансированы, и вы можете начать действовать с развязанными руками. Сразу после этого включайте перечисленные выше антикризисные средства: планирование/контроль, четкая фиксация требований/измеряемые критерии и т.д.
Владимир Иванов
