| Все | Коллективные | Персональные | TOP |
 → |
Блог им. Alessandro → Золотые правила управления проектами
Проекты, по определению, уникальны. Каждый проект организуется для достижения своей специфической цели. Тем не менее, существуют некоторые общие принципы, на основании которых строится управление успешными проектами. Их называют «золотыми правилами» управления проектами.
1. Правильный старт
Для практически любого начинания последствия неудачного старта бывает очень трудно возместить в дальнейшем. Проекты в этом смысле не являются исключением. Неудачные проекты, как правило, имеют такую печальную участь из-за несоблюдения в самом начале проекта ряда основополагающих принципов. При запуске проекта особенно важно установить порядок ведения проекта и те рамки, в которых проект будет осуществляться.
2. Работа с заказчиком
Определяйте, кто наиболее заинтересован в успехе проекта и кто больше всего теряет в случае его неудачи. Необходимо установить, в чьих интересах выполнение проекта и, в частности, кто его финансирует. Как правило, это не одни и те же люди. Желательно выяснить сферы влияния этих людей, согласовать с ними, когда и как может быть востребована их поддержка. Менеджер проекта обречен на неудачу, если он не осознает цели, мотивы и направления деятельности всех вовлеченных в проект сторон. Один из наиболее эффективных способов добиться поддержки всех заинтересованных сторон — использовать такие организационные формы, как наблюдательный совет или комитет по управлению проектом. Так как покупают, создают и используют результаты проекта люди, поэтому если поддерживать цели, позиции и потребности этих людей, то можно добиться реальных выгод в бизнесе для заказчика и получить удовлетворение от хорошо выполненной работы.
3. Определение области применения проекта
Достигайте соглашения с заказчиком о четком определении области работ и взятых обязательствах. Такое соглашение должно быть как можно более детальным, чтобы его в дальнейшем можно было использовать в качестве основы для контроля изменений. Надо понять, каким образом область, в которой работает исполнитель, связана с бизнес-целями заказчика и какие основные выгоды получит заказчик при их реализации.
4. План
Не пытайтесь составлять план того, чего не знаете. Лучше планировать на короткий срок, подробно описав циклы «план — выполнение — результаты». Это самый простой и, возможно, самый эффективный способ управления рисками. Должен быть микроплан на текущий этап, затем микроплан на будущие этапы, включающий ключевые показатели выполнения. Следует обратить внимание на сделанные при подготовке плана предположения и допущения (особенно связанные с более поздними этапами), представив их на утверждение заказчику. Но отметим, что только ближайшее будущее может быть предсказано с определенной степенью точности.
5. Управление рисками
Определяйте основные риски, анализируйте их воздействие, разрабатывайте стратегии и планы их сдерживания. Риски должны контролироваться на каждой стадии проекта для того, чтобы вовремя привести в действие план по их сдерживанию. Любое изменение в требованиях к проекту, области его применения, подходе к проекту представляет собой риск, который должен быть обязательно оценен и включен в план. Если риски по проекту не отслеживаются, то, как правило, возникает ситуация, когда на первые 90% работ по проекту приходится 10% затрат, а последние 10% работ требуют 90% затрат. Необходима специальная методика для преодоления рисков, внесения соответствующих изменений и гарантии достижения критических факторов успеха.
6. Подбор команды
Любой тренер знает, что наилучшие шансы победить имеет та команда, в которой обеспечен правильный подбор из имеющихся в наличии игроков. Проекты в этом смысле не являются исключением. Надо определить оптимальную конфигурацию команды и включить в нее тех, кто «вписывается» в состав или имеет большие потенциальные возможности. Важное значение имеет способность индивида к адаптации, его умение «вписываться» в коллектив. Один, но способный быстро обучаться, зачастую бывает лучше нескольких «всезнаек». Следовательно, при подборе людей необходимо руководствоваться их профессиональными качествами, умением быстро адаптироваться и умением работать в команде.
7. Поддержка командного духа
Проводите больше времени вместе, чтобы у членов команды проекта возникало ощущение принадлежности к достижению целей проекта. Никогда не существует отдельного «я» в проекте — всегда есть «мы», как в случае успеха, так и в случае неудачи. Необходимо разъяснять цели проекта и как эти цели связаны с намерениями заказчика. Надо четко представлять, как эти цели будут достигнуты командой проекта. Это особенно важно для тех членов команды, кто «влился» в команду не с самого начала работ по проекту. Следует акцентировать внимание на персональной ответственности, но в то же время каждый член команды проекта должен четко знать, что от него ожидают и по каким показателям будет оцениваться выполненная работа. Необходимо создавать рабочую среду, наиболее подходящую для команды, находить время для того, чтобы поблагодарить людей, особенно, если это касается выполнения работы, выходящей за круг их обязанностей.
Признательность — один из основных мотивов, побуждающих к работе.
8. Искренность и уверенность в общении
Договоритесь о стандартах и принципах общения и подготовки отчетности о состоянии проекта, твердо придерживайтесь этих принципов. Будьте искренними в общении. Старайтесь вести работу так, чтобы избегать неожиданных ситуаций. В связи с этим необходимо всегда быть «в гуще событий». Не стоит ограничиваться формальными отчетами, можно использовать и презентации, и специальные брифинги, и контрольные встречи. Желательно использовать стратегию, направленную на минимизацию конфликтов, но избежать полностью конфликтных ситуаций вряд ли удастся. Нужно быть готовыми к возникновению таких ситуаций и уметь их разрешать.
9. Использование плана качества работ по проекту
В плане качества работ по проекту должно быть четко определено, каким образом будут исполняться обязательства по проекту. Важно, чтобы включенные в методологию проекта оценки, а также процессы планирования, контроля и управления изменениями, спорными вопросами, а также подготовка документации, подкреплялись реальным опытом практической деятельности. В плане качества работ по проекту должны быть описаны процедуры и стандарты, которые будут использованы в проекте и на основе которых будет проводиться аудит качества. Из этого следует, насколько важно утверждение данного документа со стороны заказчика.
10. Подготовка документации
Любой опытный менеджер проекта скажет, что любые действия, как со стороны исполнителя, так и со стороны заказчика должны быть согласованы в письменном виде. Необходимо документировать и сохранять все результаты, соглашения, решения, спорные вопросы, предпринимаемые действия (т.е. все, что может оказать влияние на ход выполнения проекта), а также всю переписку и протоколы совещаний. Все это необходимо хранить, так как никогда не знаешь, в какой момент это может понадобиться.
Письменные доказательства используются для того, чтобы избежать разногласий или урегулировать спорные моменты. Так, к примеру, хорошо проработанный контракт обеспечивает взаимную защиту как исполнителя, так и заказчика.
11. План завершения проекта
Умелое и эффективное завершение проекта может внести значительный вклад в его успех. Завершение проекта — заключительный этап процесса вносимых изменений. Планировать завершение проекта нужно заранее. Заключительное впечатление о проекте остается в памяти людей. Необходимо подготовить отчет об окончании проекта, в котором должно быть отражено: что было сделано хорошо, что было сделано плохо, что можно было бы сделать лучше. Такая самооценка необходима и тем, кто будет осуществлять будущие проекты, и как инструмент самосовершенствования.
http://hrm.by/
1. Правильный старт
Для практически любого начинания последствия неудачного старта бывает очень трудно возместить в дальнейшем. Проекты в этом смысле не являются исключением. Неудачные проекты, как правило, имеют такую печальную участь из-за несоблюдения в самом начале проекта ряда основополагающих принципов. При запуске проекта особенно важно установить порядок ведения проекта и те рамки, в которых проект будет осуществляться.
2. Работа с заказчиком
Определяйте, кто наиболее заинтересован в успехе проекта и кто больше всего теряет в случае его неудачи. Необходимо установить, в чьих интересах выполнение проекта и, в частности, кто его финансирует. Как правило, это не одни и те же люди. Желательно выяснить сферы влияния этих людей, согласовать с ними, когда и как может быть востребована их поддержка. Менеджер проекта обречен на неудачу, если он не осознает цели, мотивы и направления деятельности всех вовлеченных в проект сторон. Один из наиболее эффективных способов добиться поддержки всех заинтересованных сторон — использовать такие организационные формы, как наблюдательный совет или комитет по управлению проектом. Так как покупают, создают и используют результаты проекта люди, поэтому если поддерживать цели, позиции и потребности этих людей, то можно добиться реальных выгод в бизнесе для заказчика и получить удовлетворение от хорошо выполненной работы.
3. Определение области применения проекта
Достигайте соглашения с заказчиком о четком определении области работ и взятых обязательствах. Такое соглашение должно быть как можно более детальным, чтобы его в дальнейшем можно было использовать в качестве основы для контроля изменений. Надо понять, каким образом область, в которой работает исполнитель, связана с бизнес-целями заказчика и какие основные выгоды получит заказчик при их реализации.
4. План
Не пытайтесь составлять план того, чего не знаете. Лучше планировать на короткий срок, подробно описав циклы «план — выполнение — результаты». Это самый простой и, возможно, самый эффективный способ управления рисками. Должен быть микроплан на текущий этап, затем микроплан на будущие этапы, включающий ключевые показатели выполнения. Следует обратить внимание на сделанные при подготовке плана предположения и допущения (особенно связанные с более поздними этапами), представив их на утверждение заказчику. Но отметим, что только ближайшее будущее может быть предсказано с определенной степенью точности.
5. Управление рисками
Определяйте основные риски, анализируйте их воздействие, разрабатывайте стратегии и планы их сдерживания. Риски должны контролироваться на каждой стадии проекта для того, чтобы вовремя привести в действие план по их сдерживанию. Любое изменение в требованиях к проекту, области его применения, подходе к проекту представляет собой риск, который должен быть обязательно оценен и включен в план. Если риски по проекту не отслеживаются, то, как правило, возникает ситуация, когда на первые 90% работ по проекту приходится 10% затрат, а последние 10% работ требуют 90% затрат. Необходима специальная методика для преодоления рисков, внесения соответствующих изменений и гарантии достижения критических факторов успеха.
6. Подбор команды
Любой тренер знает, что наилучшие шансы победить имеет та команда, в которой обеспечен правильный подбор из имеющихся в наличии игроков. Проекты в этом смысле не являются исключением. Надо определить оптимальную конфигурацию команды и включить в нее тех, кто «вписывается» в состав или имеет большие потенциальные возможности. Важное значение имеет способность индивида к адаптации, его умение «вписываться» в коллектив. Один, но способный быстро обучаться, зачастую бывает лучше нескольких «всезнаек». Следовательно, при подборе людей необходимо руководствоваться их профессиональными качествами, умением быстро адаптироваться и умением работать в команде.
7. Поддержка командного духа
Проводите больше времени вместе, чтобы у членов команды проекта возникало ощущение принадлежности к достижению целей проекта. Никогда не существует отдельного «я» в проекте — всегда есть «мы», как в случае успеха, так и в случае неудачи. Необходимо разъяснять цели проекта и как эти цели связаны с намерениями заказчика. Надо четко представлять, как эти цели будут достигнуты командой проекта. Это особенно важно для тех членов команды, кто «влился» в команду не с самого начала работ по проекту. Следует акцентировать внимание на персональной ответственности, но в то же время каждый член команды проекта должен четко знать, что от него ожидают и по каким показателям будет оцениваться выполненная работа. Необходимо создавать рабочую среду, наиболее подходящую для команды, находить время для того, чтобы поблагодарить людей, особенно, если это касается выполнения работы, выходящей за круг их обязанностей.
Признательность — один из основных мотивов, побуждающих к работе.
8. Искренность и уверенность в общении
Договоритесь о стандартах и принципах общения и подготовки отчетности о состоянии проекта, твердо придерживайтесь этих принципов. Будьте искренними в общении. Старайтесь вести работу так, чтобы избегать неожиданных ситуаций. В связи с этим необходимо всегда быть «в гуще событий». Не стоит ограничиваться формальными отчетами, можно использовать и презентации, и специальные брифинги, и контрольные встречи. Желательно использовать стратегию, направленную на минимизацию конфликтов, но избежать полностью конфликтных ситуаций вряд ли удастся. Нужно быть готовыми к возникновению таких ситуаций и уметь их разрешать.
9. Использование плана качества работ по проекту
В плане качества работ по проекту должно быть четко определено, каким образом будут исполняться обязательства по проекту. Важно, чтобы включенные в методологию проекта оценки, а также процессы планирования, контроля и управления изменениями, спорными вопросами, а также подготовка документации, подкреплялись реальным опытом практической деятельности. В плане качества работ по проекту должны быть описаны процедуры и стандарты, которые будут использованы в проекте и на основе которых будет проводиться аудит качества. Из этого следует, насколько важно утверждение данного документа со стороны заказчика.
10. Подготовка документации
Любой опытный менеджер проекта скажет, что любые действия, как со стороны исполнителя, так и со стороны заказчика должны быть согласованы в письменном виде. Необходимо документировать и сохранять все результаты, соглашения, решения, спорные вопросы, предпринимаемые действия (т.е. все, что может оказать влияние на ход выполнения проекта), а также всю переписку и протоколы совещаний. Все это необходимо хранить, так как никогда не знаешь, в какой момент это может понадобиться.
Письменные доказательства используются для того, чтобы избежать разногласий или урегулировать спорные моменты. Так, к примеру, хорошо проработанный контракт обеспечивает взаимную защиту как исполнителя, так и заказчика.
11. План завершения проекта
Умелое и эффективное завершение проекта может внести значительный вклад в его успех. Завершение проекта — заключительный этап процесса вносимых изменений. Планировать завершение проекта нужно заранее. Заключительное впечатление о проекте остается в памяти людей. Необходимо подготовить отчет об окончании проекта, в котором должно быть отражено: что было сделано хорошо, что было сделано плохо, что можно было бы сделать лучше. Такая самооценка необходима и тем, кто будет осуществлять будущие проекты, и как инструмент самосовершенствования.
http://hrm.by/
Управление проектами → Scrum и XP: заметки с передовой
Выкладываю книгу по Scrum переведенную на русский язык. Для того что бы заинтересовать вас, предлагаю ознакомиться с предисловием авторов.
Скачать Scrum и XP: заметки с передовой
Чтобы прочитать эту книгу вам понадобиться всего лишь два-три часа. Чтобы её перевести участникам комьюнити Agile Ukraine потребовалось 4 месяца.
Командам необходимо знать основы Scrum'а. Как создать и оценить product backlog? Как получить из него sprint backlog? Как работать с burndown-диаграммой и вычислять роизводительность(velocity) своей команды? Книга Хенрика – это базовое руководство для начинающих, которое поможет командам перейти из состояния «мы пробуем Scrum» в состояние «мы успешно работаем по Scrum'у». Хорошая реализация Scrum'а становится всё важнее и важнее для команд, которые хотят получить инвестиции. Я выступаю в качестве тренера по гибким методологиям для группы компаний с венчурными инвестициями, помогая им в стремлении вкладывать деньги только в настоящие Agile-компании. Глава группы инвесторов требует от компаний, составляющих инвестиционный портфель, ответа на вопрос, знают ли они производительность своих команд. Многих этот вопрос ставит в тупик. Будущие инвестиции требуют от команд знания собственной производительности разработки программного обеспечения. Почему это так важно? Если команда не знает собственной производительности, следовательно product owner не может разработать стратегический план развития продукта с достоверными датами релизов. Без такого плана компанию может постичь неудача, в результате чего инвесторы потеряют свои деньги. С этой проблемой сталкиваются разнообразные компании: большие и маленькие, старые и новые, с финансированием и без. Во время недавнего обсуждения реализации Scrum'а компанией Google на лондонской конференции я решил узнать у аудитории, состоящей из 135 человек, кто из них использует Scrum? Я получил утвердительный ответ лишь от тридцати человек. Затем я поинтересовался, соответствует ли их процесс Nokia-стандарту итеративной разработки. Итеративная разработка – это ключевое положение Agile Manifest'а: «Постарайтесь предоставлять версии работающего программного обеспечения как можно чаще и раньше». В результате проведения ретроспектив с сотнями Scrum-команд в течение нескольких лет, Nokia выработала некоторые базовые требования к итеративной разработке:
• Итерации должны иметь фиксированную длину и не превышать шести недель.
• К концу каждой итерации код должен быть протестирован отделом качества (QA) и работать как следует.
Из тридцати человек, которые сказали, что работают по Scrum'у, лишь половина подтвердила, что их команды придерживаются первого принципа Agile Manifest'а и соответствую Nokia-стандарту. Затем я спросил их, придерживаются ли они Scrum-стандарта, разработанного Nokia:
• У Scrum-команды должен быть один product owner и команда должна знать, кто это.
• У product owner'а должен быть один product backlog с историями и их оценками, выполненными командой.
• У команды должна быть burndown-диаграмма, а сама команда должна знать свою производительность.
• На протяжении спринта никто не должен вмешиваться в работу команды.
Из тридцати команд, внедряющих Scrum, только у трёх процесс разработки соответствовал стандартам Nokia. Я думаю, что только эти три команды получат дальнейшие инвестиции от венчурных капиталистов.
Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog'а, и burndown-диаграмма. Вы также будете знать производительность вашей команды и сможете использовать все наиболее важные практики высокоэффективных Scrum-команд. Вы пройдёте Nokia Scrum-тест, за что инвесторы оценят вас по достоинству. Если вы – начинающая компания, то, возможно, вы получите такие жизненно важные для вашего проекта финансовые вливания. Возможно вы – будущее разработки программного обеспечения, вы – создатель нового поколения программ, которые станут лидерами рынка.
Джефф Сазерленд, доктор наук, соавтор Scrum
И Scrum, и XP (экстремальное программирование) требуют от команд завершения вполне осязаемого куска работы, который можно предоставить пользователю в конце каждой итерации. Эти итерации планируются таким образом, чтобы быть короткими и фиксированными по времени. Такая целенаправленность на выпуск рабочего кода за короткий промежуток времени означает только одно: в Scrum и XP нет места теории. Agile-методологии не гонятся за красивыми UML моделями, выполненными при помощи специальных case-средств, за созданием детализированных спецификаций или написанием кода, который сойдёт на все случаи жизни. Вместо этого Scrum и XP команды концентрируются на том, чтобы завершить необходимые задачи. Эти команды могут мириться с ошибками в ходе работы, но они понимают, что лучшее средство выявить эти ошибки – это перестать думать о софте на теоретическом уровне анализа и дизайна, и, закатав рукава, полностью посвятить себя созданию продукта. Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих. То, что Хенрик разделяет эти взгляды, видно с самых первых страниц книги. Он не предлагает нам длинное описание того, что такое Scrum; вместо этого он просто ссылается на необходимые веб-ресурсы. Первым делом Хенрик начинает с описания того, как его команда работает со своим product backlog'ом. Затем он проходит по всем элементам и практикам правильно поставленного agile-проекта. Без теоретизирования. Без справочных данных. Ничего этого не нужно: книга Хенрика – не философское объяснение, почему Scrum работает или почему мы должны делать так, а не иначе. Это описание того, как работает одна успешная agile-команда. Хенрик предлагает набор избранных практик и описывает живые примеры, чтобы помочь нам понять, как использовать Scrum и XP на передовой.
Майк Кон
Автор книг Agile Estimating and Planning и User Stories Applied for Agile Software Development.
Скачать Scrum и XP: заметки с передовой
Чтобы прочитать эту книгу вам понадобиться всего лишь два-три часа. Чтобы её перевести участникам комьюнити Agile Ukraine потребовалось 4 месяца.
Предисловие Джеффа Сазерленда
Командам необходимо знать основы Scrum'а. Как создать и оценить product backlog? Как получить из него sprint backlog? Как работать с burndown-диаграммой и вычислять роизводительность(velocity) своей команды? Книга Хенрика – это базовое руководство для начинающих, которое поможет командам перейти из состояния «мы пробуем Scrum» в состояние «мы успешно работаем по Scrum'у». Хорошая реализация Scrum'а становится всё важнее и важнее для команд, которые хотят получить инвестиции. Я выступаю в качестве тренера по гибким методологиям для группы компаний с венчурными инвестициями, помогая им в стремлении вкладывать деньги только в настоящие Agile-компании. Глава группы инвесторов требует от компаний, составляющих инвестиционный портфель, ответа на вопрос, знают ли они производительность своих команд. Многих этот вопрос ставит в тупик. Будущие инвестиции требуют от команд знания собственной производительности разработки программного обеспечения. Почему это так важно? Если команда не знает собственной производительности, следовательно product owner не может разработать стратегический план развития продукта с достоверными датами релизов. Без такого плана компанию может постичь неудача, в результате чего инвесторы потеряют свои деньги. С этой проблемой сталкиваются разнообразные компании: большие и маленькие, старые и новые, с финансированием и без. Во время недавнего обсуждения реализации Scrum'а компанией Google на лондонской конференции я решил узнать у аудитории, состоящей из 135 человек, кто из них использует Scrum? Я получил утвердительный ответ лишь от тридцати человек. Затем я поинтересовался, соответствует ли их процесс Nokia-стандарту итеративной разработки. Итеративная разработка – это ключевое положение Agile Manifest'а: «Постарайтесь предоставлять версии работающего программного обеспечения как можно чаще и раньше». В результате проведения ретроспектив с сотнями Scrum-команд в течение нескольких лет, Nokia выработала некоторые базовые требования к итеративной разработке:
• Итерации должны иметь фиксированную длину и не превышать шести недель.
• К концу каждой итерации код должен быть протестирован отделом качества (QA) и работать как следует.
Из тридцати человек, которые сказали, что работают по Scrum'у, лишь половина подтвердила, что их команды придерживаются первого принципа Agile Manifest'а и соответствую Nokia-стандарту. Затем я спросил их, придерживаются ли они Scrum-стандарта, разработанного Nokia:
• У Scrum-команды должен быть один product owner и команда должна знать, кто это.
• У product owner'а должен быть один product backlog с историями и их оценками, выполненными командой.
• У команды должна быть burndown-диаграмма, а сама команда должна знать свою производительность.
• На протяжении спринта никто не должен вмешиваться в работу команды.
Из тридцати команд, внедряющих Scrum, только у трёх процесс разработки соответствовал стандартам Nokia. Я думаю, что только эти три команды получат дальнейшие инвестиции от венчурных капиталистов.
Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog'а, и burndown-диаграмма. Вы также будете знать производительность вашей команды и сможете использовать все наиболее важные практики высокоэффективных Scrum-команд. Вы пройдёте Nokia Scrum-тест, за что инвесторы оценят вас по достоинству. Если вы – начинающая компания, то, возможно, вы получите такие жизненно важные для вашего проекта финансовые вливания. Возможно вы – будущее разработки программного обеспечения, вы – создатель нового поколения программ, которые станут лидерами рынка.
Джефф Сазерленд, доктор наук, соавтор Scrum
Предисловие Майка Кона
И Scrum, и XP (экстремальное программирование) требуют от команд завершения вполне осязаемого куска работы, который можно предоставить пользователю в конце каждой итерации. Эти итерации планируются таким образом, чтобы быть короткими и фиксированными по времени. Такая целенаправленность на выпуск рабочего кода за короткий промежуток времени означает только одно: в Scrum и XP нет места теории. Agile-методологии не гонятся за красивыми UML моделями, выполненными при помощи специальных case-средств, за созданием детализированных спецификаций или написанием кода, который сойдёт на все случаи жизни. Вместо этого Scrum и XP команды концентрируются на том, чтобы завершить необходимые задачи. Эти команды могут мириться с ошибками в ходе работы, но они понимают, что лучшее средство выявить эти ошибки – это перестать думать о софте на теоретическом уровне анализа и дизайна, и, закатав рукава, полностью посвятить себя созданию продукта. Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих. То, что Хенрик разделяет эти взгляды, видно с самых первых страниц книги. Он не предлагает нам длинное описание того, что такое Scrum; вместо этого он просто ссылается на необходимые веб-ресурсы. Первым делом Хенрик начинает с описания того, как его команда работает со своим product backlog'ом. Затем он проходит по всем элементам и практикам правильно поставленного agile-проекта. Без теоретизирования. Без справочных данных. Ничего этого не нужно: книга Хенрика – не философское объяснение, почему Scrum работает или почему мы должны делать так, а не иначе. Это описание того, как работает одна успешная agile-команда. Хенрик предлагает набор избранных практик и описывает живые примеры, чтобы помочь нам понять, как использовать Scrum и XP на передовой.
Майк Кон
Автор книг Agile Estimating and Planning и User Stories Applied for Agile Software Development.