Главное Авторские колонки Вакансии Образование
Выбор редакции:
283 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Шрамы проджект-менеджера

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

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

  1. Задача без срока — топливо для прокрастинации. Ставьте срок в задачах.
  2. Задача без трудоёмкости — генератор перфекционизма. Ставьте трудоёмкость в задачах.
  3. Проектов без срока не бывает. Всегда знайте срок сдачи проекта и помните о нём.
  4. Проект без руководителя — несбывшиеся мечты. Назначайте руководителя на проект.
  5. Два ПМа на проекте — результат непредсказуем. Руководитель на проекте может быть только один.
  6. Что-то пошло не так — эскалируй! Чем раньше ваш руководитель узнает о проблеме, тем проще её решить.
  7. Понял, что не укладываешься — двигай срок. Нельзя двигать срок — режь функционал.
  8. Поставил задачу — убедись, что её приняли. Исполнитель должен понимать задачу, срок, приоритет.
  9. Проект без спонсора не нужен заказчику. Выявите спонсора проекта на стороне заказчика, он поможет вам, так как больше всех заинтересован в результате и рискует своим бюджетом.
  10. Менеджер проекта — это его двигатель. Без двигателя не поедет. Будьте позитивным и проактивным, регулярно бодрите команду.
  11. Без плана проект обречён. Планируйте проект.
  12. Три кита работы с исполнителем: Пиши, звони, эскалируй! Написать человеку просто и быстро. Если не отвечает больше часа, нужно звонить. Если не берёт трубку, эскалируйте до руководителя.
  13. Не будь блокером для других. Если ваши действия являются начальным этапом для того, чтобы начали действовать другие, выполняйте эти задачи в первую очередь.
  14. Назначил встречу — напиши план. Все должны быть в курсе, о чём будет встреча, чтобы подготовиться.
  15. Провёл встречу — напиши резюме. Все участники встречи должны знать итоги и иметь возможность вспомнить их спустя время.
  16. Позвали на встречу — уточни цель. Не все встречи одинаково полезны, не везде вам действительно необходимо присутствовать.
  17. Слушай внимательно, отвечай ясно.
  18. Переспросить не страшно, страшно сделать не то. Уточняйте сразу всё, что не поняли в процессе общения.
  19. Задача более 10 чч — декомпозируй. Так будет проще выполнить задачу и вам и исполнителю.
  20. Задача понятна и требует рутинных действий — делегируй. Время менеджера очень ценно, не выполняйте ту работу, которую могут за вас выполнить другие.
  21. Планируй рабочий день. Не давайте возможности хаосу сбить вас с движения к результату.
  22. Ставь контрольные точки и обдумай план «Б». На проекте всегда случается ворох неожиданностей и разного рода проблем. Чтобы контролировать ход проекта, ставьте контрольные точки, в которых будете проверять промежуточный результат. Продумайте заранее, что будете предпринимать, если промежуточный результат не сойдётся с планом.
  23. Всё, что не записал — потерял. Не полагайтесь на память, информационный поток выбьет из неё половину важных задач.
  24. Незафиксированные договорённости — повод для конфликта. Фиксируйте договорённости в почте.
  25. Ошибаться можно, повторять ошибки — нельзя. Анализируйте причины ошибок, принимайте меры к недопущению в будущем.
  26. Всегда планируй с максимальным запасом. Не поддавайтесь на необоснованное давление по срокам. Лучше чуть дольше, но в срок и качественно, чем быстро и безрезультатно.
  27. По дизайну риск во вкусовщине. Не позволяйте заказчику предлагать визуальные решения, которые убивают качество проекта, ограничивайте количество правок дизайна на старте проекта.
  28. По программированию риск в программисте. Отдавайте оценку задач на ревью, проверяйте подходы к архитектуре, требуйте промежуточных результатов от программиста, отдавайте результаты на ревью старшим программистам.
  29. Оценку разработчика умножай на два. Даже проверенная оценка задачи разработчиком всегда оптимистична.
  30. По вёрстке риск в дизайне. При разработке дизайна думайте о том, возможно ли это качественно сверстать, подключайте верстальщика на промежуточном этапа для оценки дизайна.
  31. ПМ должен лучше всех понимать проект. Всегда читайте договор, ТЗ, в любой момент знайте что и для чего делается, знайте статус по задачам.

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.