Правило № 6. Изучай историческую науку
Лишь немногие учатся на примерах прошлого. Но истории свойственно повторение, она не слишком большой выдумщик. Многие ИТ-проекты так похожи, что создается впечатление, что вообще ничего не меняется. Принципиально важно приобрести навык видеть новый проект в свете предыдущего опыта, для чего необходимо проанализировать новый проект шаг за шагом на предмет схожести проблематики и различий, а также определить, что из предыдущих методов работы с проектами приложимо к данному новому проекту, что нет. После того как подобные проекты прошлого идентифицированы, правильным шагом будет организовать серию интервью с участниками прошлых проектов, проштудировать отчеты аудита и т. п.
Правило № 7. На все должна быть бумажка
Эту старую формулу, как правило, связывают с бюрократией. Однако в управлении проектами разумная бюрократия просто необходима. В большинстве проектов члены команды выполняют колоссальное количество работы, к сожалению, часто усилия не успевают задокументироваться, знания и экспертные оценки постепенно теряются. Не обольщайтесь - это большая потеря для компании. Документирование решений, оценок и прочей информации дает огромное преимущество. Качество работы над проектом возрастает, если есть четкие записи, что было сделано, как, и почему именно так. Наличие такой документации позволяет в будущем сосредоточиться на специфике проектов, а не фокусироваться на решении стандартных, уже возникавших проблем.
Ситуации и решения на проектах обычно не документируются, ведь решение дает немедленный результат, и сотрудники не видят причин дополнительной административной нагрузки. И даже там, где это документирование ведется, важная информация часто теряется в общем потоке проектной документации. Для того чтобы изменить состояние дел необходимо ввести создание документации в разряд необходимых действий, а также создать общий формат для такой документации до начала проекта.
Правило № 8. Нужно учиться общаться
Большинство проектов проваливаются в связи с проблемами коммуникации. Хотя все и понимают важность хорошей коммуникации для достижения успеха, однако коммуникация на проекте по-прежнему находится в плачевном состоянии. Одна из причин состоит в том, что люди путают средство коммуникации и коммуникацию как таковую. Средство коммуникации это просто инструмент. Окруженные электронной почтой, видеоконференциями и Интернетом, многие полагают, что они достаточно хорошо связаны, однако надо понимать, что средство общения не является общением.
Другая причина некачественной коммуникации состоит в том, что члены команды плохо понимают разницу между данными и информацией. Данные являются необработанными, информация представляет собой данные, которые обработаны и несут в себе какой-то смысл, имеющий отношение к делу. Очень часто члены команды путают эти два вида данных, затрудняя тем самым коммуникацию и отбирая ценное время проекта. Наконец, третья проблема - актуальность информации по проекту. Одна из самых распространенных проблем состоит в том, что поступающая информация устарела. Не так давно мне довелось видеть специальный сайт, созданный для нормального общения команды проекта, информация на котором не обновлялась три месяца (проект был сроком на один год). Информация на подобном сайте должна соответствовать текущему состоянию проекта, максимальная задержка не должна превышать одного-двух дней.
Хотя это звучит банально, но придется повторить: правильная коммуникация обеспечивает поступление нужной информации в нужное время в нужной пропорции и тем, кому это нужно. Когда коммуникация поставлена таким образом, команда 'входит в информационный резонанс'. В результате члены команды лучше адаптируются к решениям, которые принимаются на проекте.
Правило № 9. Без мотивации проект - это процесс
Без мотивации членов проектной команды, ключевых менеджеров нет проекта. Без этого он превращается в бесконечный, лишенный финала процесс. В отсутствии заинтересованности участников проекта проблемы начинаются уже в самом начале - при оценке времени выполнения определенных задач. В этом случае оценки, как правило, нереалистичны и основаны на каких то непонятных предположениях. Минимальный необходимый способ мотивации проектной команды - премии по результатам каждого этапа проекта. Но есть и более действенные средства. Например, перевод ключевых менеджеров проектной команды на персональные контракты с существенным (в два и более раза) увеличением оклада. Для того чтобы отработать уровень обязательств менеджера, руководителю проекта необходимо провести 'опись' его знаний, экспертных областей, опыта и исполнительности. Такой прием крайне рекомендуется в связи с тем, что подписание подобного документа затрудняет возможность отрицать принятые обязательства.
Наиболее мощное средство мотивации при управлении проектами - это сделать участников проекта его совладельцами. Обязательная покупка членами проектной команды акций данного проекта создает максимально возможную степень ответственности и надежности. В свою очередь, облегчается управление проектами. Не так много усилий требуется для того, чтобы прослеживать задачи. К тому же подобный подход к проекту сильно увеличивает инициативу участников. К сожалению, этот подход неприложим к большинству проектов (но дает отличный уровень сравнения с тем, как это должно быть в идеале).
Наконец, еще один совет - руководитель проекта должен измерять не только способность выполнять определенную задачу, но также и энтузиазм. Подчас член команды проекта имеет достаточный опыт и соответствующие навыки, но отсутствует необходимая приподнятость и желание работать на проекте.
Правило № 10. Самые правильные решения - простые
Всегда есть тенденция усложнять ситуацию настолько, насколько возможно. Там надо что-то 'дочистить', здесь надо что-то слегка подправить… Прежде чем кто-либо успеет что-то понять, результат оказывается полностью противоположен тому, который ожидался. Все проекты имеют тенденцию к усложнению, однако хороший результат проекта, как правило, прост. Простота характерна для кратчайшего пути.
Симптомы сложности или простоты вполне очевидны. Например, многие члены команды проекта требуют дополнений, изменений, переопределений, переделок, так что план становится переполнен исключениями в дополнительных непредвиденных обстоятельствах. Другой симптом сложности состоит в том, что руководителю проекта постоянно приходится объяснять значение различных частей проекта.
По контрасту простота дает ясность мысли, демонстрируя ясность понимания направления движения. Она также требует меньше времени и ресурсов для выполнения плана и дает большую уверенность потому что цели и задачи ясны и понятно что надо делать для достижения. Для того чтобы простота решения стала возможной члены команды должны обладать как можно большим опытом. Мудрость приходит только с опытом.
В большинстве своем ИТ-проекты редко применяют даже несколько изложенных выше принципов. Чаще всего команда продвигается вперед пытаясь решить проблему сложными путями, которые как правило представляют собой переизобретение решений которые уже были найдены в одном из предыдущих проектов, далее, смотри по тексту начала статьи. Если проблема остается нерешенной, работа замирает и все ожидают что проблема как то разрешится, занимаясь при этом решением других менее важных проблем. Графики выполнения начинают плавать, бюджеты перерасходуются, качество падает. Даже если половина из того о чем здесь говорилось будет введена в ИТ-проект, его производительность возрастет. Но, как показывает опыт настоящая проблема состоит в том что бы заставить ПМ и членов проекта принять данные рекомендации.
