72 совета менеджеру проектов

Управление проектами

Алек Сатин, PMP

Случалось ли вам в самом разгаре проекта или задания задавать себе вопрос: «Нет ли решения получше?» Если да, то вы не одиноки. Управление проектом — нелегкая задача. Чем дольше вы находитесь в этом бизнесе, тем больше вы сможете изучить, и тем больше пользы это принесет вашим проектам.

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

I. Старт проекта (Инициация)

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

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

2. Проект ли это? Проект — это усилия, которые вы прилагаете в течение определенного времени, чтобы достигнуть определенных результатов или целей. Если ваш проект бесконечен и/или не имеет определенных границ, то вы можете прилагать значительные усилия, но это нельзя будет назвать проектом. В этом случае вам понадобится немало времени, чтобы убедить команду, что вы добились успеха.

3. Если работа над проектом не закончится в ближайшие 3-6 месяцев, сможете ли вы разбить его на несколько проектов меньшего масштаба?

4. Думаете ли вы о проектном треугольнике?

5. Есть ли у вас устав/описание проекта? Если нет, напишите его для вашего же блага. Четкое описание поможет избежать спорных моментов во время работы над проектом.

6. Кто является главной заинтересованной стороной? Кто еще заинтересован в проекте?

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

8. Есть ли у вас четкое описание ролей и обязанностей сотрудников? Кто входит в команду? Кто в нее не входит?

9. Понимают ли члены команды свои роли в проекте, согласны ли они с таким распределением?

Самодисциплина

10. Есть ли у вас библиотека шаблонов? Если нет, обзаведитесь ей.

11. Есть ли у вас подборка хорошо составленных проектных документов (написанных вами или другими сотрудниками)? Если нет, подготовьте такой пакет.

12. Как вы работаете с описаниями результатов проекта, проектной документацией и заметками по проекту? Собраны ли они в конкретном месте? Все ли члены команды ознакомлены с ними?

13. Делаете ли вы бэкапы (документации, результатов, кодов, прочего)? Как давно вы проверяли резервную копию? Проверьте ее сегодня же и посмотрите, что произойдет.

Стоимость и бюджет

14. Каков ваш одобренный бюджет? Если это вам не известно, как можно это узнать?

15. Кто отслеживает расход бюджета? Если это — не вы, можете ли вы получить доступ к выставленным счетам и произведенным оплатам?

16. Каким образом вы отчитываетесь за расход бюджета?

17. Как много вы уже израсходовали? Если вам кажется, что к концу проекта вы превысите бюджет примерно на 10%, что вы предпримете? Можете ли вы получить дополнительные средства? Можете ли вы уменьшить масштаб проекта? Что вы скажете заинтересованным лицам?

18. Каково текущее состояние бюджета?

II. Планирование

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

Объем работ

19. Есть ли у вас одобренный план по объему работ?

20. Включено ли в этот план что-то, что не касается непосредственно вашего проекта?

21. Понятным ли языком изложено описание объема работ? Все ли сокращения расшифрованы?

Риски (и проблемы)

22. Ведете ли вы реестр рисков? Это список потенциальных негативных или позитивных факторов, которые могут повлиять на проект. Если вы не имеете такого списка, почему бы его не завести?

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

24. Обсуждаете ли вы значительные риски (с высокой вероятностью появления и серьезным влиянием на проект) с заинтересованными лицами заблаговременно, чтобы это не явилось для них неожиданностью?

25. Ведете ли вы записи о том, что именно вы и команда планируете сделать, делаете или сделали в отношении рисков и проблем, возникающих в ходе проекта? Это будет очень ценной информацией при реализации будущих проектов.

Календарный план и структура декомпозиции работ

26. Определили ли вы все результаты проекта?

27. Задействуете ли вы команду при разработке пошагового плана по достижению результатов?

28. Используете ли вы PERT (Метод оценки и пересмотра планов) или другие методы для оценки сроков проекта? Вы уже оценили сроки проекта? Сверили ли вы эти сроки с командой, которая реально будет работать над проектом?

План управления проектом

PRINCE2 (Управление проектом в контролируемых условиях) определяет план управления проектом как «положения, описывающие методы достижения целей проекта».

29. Каким образом собирается ключевая информация по проекту? Как она распространяется? По электронной почте? На совещаниях? Wiki? Twitter? Повседневное общение? Как правило, это называется планом коммуникации.

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

31. Как вы поступите при изменениях требований или объема работ? Если в компании существует общий план по работе с изменениями, каким образом изменения в вашем проекте будут вписаны в него? Иногда это называют планом управления изменениями.

32. Каким образом будут приниматься решения по закупкам? Как вы будете выбирать потенциальных поставщиков? Будете ли вы пользоваться запросами на предложение (RFP)? Существуют ли какие-либо стандарты в вашей компании? Это принято называть планом закупок или планом работы с поставщиками.

33. Как будут определены уровни доступа к продукту для проектной команды, клиентов и заинтересованных лиц? Нужна ли кому-либо из членов команды помощь в исполнении обязанностей по проекту? Как будут проходить тренинги? Онлайн? Через печатные инструкции и мануалы? Индивидуальные тренинги? Тренинги в группах? Это называется учебным планом.

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

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

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

Требования

37. Есть ли у вас список сгруппированных требований по проекту?

38. Как вы можете определить, что требования проекта расширились? Как вы будете решать эту естественную в ходе работ ситуацию?

39. Являются ли эти требования основой для разработки и тестирования? Если нет, почему?

40. Вся ли команда задействована в проекте и проинформирована относительно требований? Как вы можете задействовать разработчиков? Как вы задействуете тестеров?

III. Работа над проектом (Реализация)

Реализация — третья фаза жизненного цикла проекта. На этой стадии происходит реальное воплощение проекта. Это самый долгий и дорогостоящий этап (как правило).

Совещания

41. Следите ли вы за длительностью совещаний? Чем больше людей участвует в них в каждый конкретный момент, тем меньше времени остается на работу.

42. Позволяете ли вы сотрудникам отказываться от совещаний? (Совет: когда это возможно, приглашайте сотрудников выборочно.)

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

44. Уверены ли вы, что каждый присутствующий четко понимает цели встречи?

45. Проста ли для сотрудников процедура участия в совещаниях?

46. Назначается ли сотрудник, ответственный за ведение протокола совещания?

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

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

49. Вы планируете встречи за 30 минут до начала?

50. Вы планируете график встреч заранее на неделю (или меняете дни и время), исключая экстренные совещания? (Экстренные совещания собирают раз или два в год.)

51. Всегда ли вы начинаете совещание вовремя? Позднее начало удобнее тем, кто часто опаздывает, но это — проявление неуважения к тем, кто приходит вовремя.

52. Всегда ли завершаете совещания в запланированное время? Если нет, почему?

Статус проекта и коммуникация

53. Ваш статус-репорт содержит всю сколько-нибудь важную информацию?

54. Ваш статус-репорт читают? Как вы это понимаете?

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

56. Если вы нуждаетесь в отчете от своих сотрудников, поставщиков или кого-то еще, вы получаете его?

57. Если вы получаете отчеты, содержат ли они полезную информацию? Если нет, как можно изменить их, чтобы они стали полезными?

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

Тестирование

59. Разработаны ли необходимые сценарии тестирования до начала разработки? Это значительно сокращает цикл тестирования. Если нет, почему бы не попробовать этот метод, работая над следующим проектом?

60. Знают ли заинтересованные лица проекта, как проводится пользовательское тестирование? Что вы предпринимаете, чтобы ускорить ход этого тестирования?

61. Можете ли вы определить стратегию тестирования и работать согласно ей, чтобы четко представлять, что именно тестируется?

62. Согласовываете ли вы с заинтересованными лицами до начала тестирования те условия, которые необходимы для его успешного проведения?

63. Восприимчив ли ваш проект к проблемам, которые, как правило, возникают из двух классических фатальных ошибок тестирования: (a) «Желательно получение релиза, свободного от багов» и (b) «Хорошее тестирование должно выявить максимальное количество багов»?

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

IV. Завершение проекта

Завершение — последняя фаза жизненного цикла проекта. На этом этапе вы формально завершаете работу и сообщаете об уровне успешности проекта заинтересованным сторонам.

«Разбор полетов»

65. Проводите ли вы «разбор полетов» в целях повышения своей эффективности в работе над следующими проектами? Или эта информация используется в большей степени для наказания виновных?

66. Можете ли вы создать открытую, спокойную обстановку для получения честной обратной связи от людей, работавших над проектом? Если нет, может ли кто-то еще в вашей компании или вне ее провести «разбор полетов» для вас?

67. Когда вы в последний раз обсуждали итоги проекта?

68. Почему вы не делаете этого на текущем проекте?

Сбор отзывов пользователей

69. Существует ли обратная связь между вами и вашими пользователями, клиентами или заинтересованными лицами? Вопрос может быть поставлен приблизительно так: «Что можно было сделать лучше?»

70. Если вы собираете отзывы, включены ли в анкету как базовые вопросы, так и вопросы, связанные с лояльностью? Например, базовый вопрос может звучать так: «Удовлетворены ли вы результатами работы проектной команды?» Пример вопроса, определяющего уровень лояльности: «Будете ли вы работать с данной проектной командой снова?»

71. Планируете ли вы провести анонимный опрос среди членов проектной команды? Примерные вопросы, которые можно задать: «Что в проекте было сделано хорошо? Что могло быть сделано лучше? Что может помочь вам в работе над следующим проектом? Что поможет лидеру проекта работать эффективнее?»

Полное закрытие проекта

72. Документ, сообщающий о полном закрытии проекта — это специальная форма в виде подписанного электронного письма или одностраничного документа, который официально закрывает проект и снимает обязательства с членов команды. Приходилось ли вам когда-либо сталкиваться с ним? Что нужно сделать, чтобы убедиться, что такой документ о вашем проекте составлен?
  • ,
  • ,
  • avatar
  • 1
  • +3
  • 18740

0 комментариев

Оставить комментарий

Комментировать при помощи:


Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.