O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Блиц-доклад "Как выбирать проектные методологии и как от них отказываться"

3.401 visualizações

Publicada em

Блиц-доклад (15 минут) - обозначение проблем выбора и внедрения проектных методологий

Publicada em: Engenharia
  • Seja o primeiro a comentar

Блиц-доклад "Как выбирать проектные методологии и как от них отказываться"

  1. 1. Как выбирать проектные методологии и как от них отказываться Иван Селиховкин ноябрь 2014
  2. 2. Про себя Иван Селиховкин → Любимые детища: Отделение PMI в СПб - pmi.org.ru Авторский сайт PMlead - pmlead.ru Опыт: 10+ лет в управлении проектами (не только ИТ- компании). Работа: Зам. директора по проектам (компания 600+ человек). Тренер, консультант. Связь: pmlead.post@gmail.com ru.linkedin.com/in/selikhovkin/
  3. 3. Реальный кейс
  4. 4. Приемы и методологии vs «жизнь»
  5. 5. Предопределенный жизненный цикл Фазы могут идти последовательно или перекрываться. Но «треугольник» спланирован на столько рано, на сколько это возможно. В каждой фазе – концентрируемся на том, чтобы выдать положенное в ее рамках содержание.
  6. 6. Продукт понятен и / или имеет ценность, когда поставлен весь сразу
  7. 7. Итеративно-инкрементный цикл Одни и те же стадии повторяются Постоянный прирост функциональности
  8. 8. Адаптивный жизненный цикл + + специфика (очень короткие итерации, фиксированные по времени и стоимости) итерации инкременты
  9. 9. Адаптивный жизненный цикл
  10. 10. Часть результата полезна конечному потребителю
  11. 11. Прерванный проект и «частичный результат» – ценен для потребителя
  12. 12. Не злонамеренная команда
  13. 13. Члены команд работают над одним продуктом в одно время
  14. 14. Можно плотно вовлечь в процесс заказчика или его «тень»
  15. 15. Наш случай Некоторые продукты не имеют ценности, если поставлены не полностью. Некоторые члены команды – злонамерены. Почти каждый член команды работает на нескольких проектах одновременно. Заказчика обычно нет, его «тень» – только начинает формироваться силами сотрудников При этом: Нет внятных правил игры Есть несколько «лидеров-методологов»
  16. 16. Служба контроля качества отвечает за аудит - ISO
  17. 17. Менеджеру проектов нужно держать под контролем ограничения
  18. 18. Высшему руководству – нужно принимать стратегические решения
  19. 19. Уменьшить «демократию» в команде?
  20. 20. Порочное понятие «эволюции»
  21. 21. Что значит «быть эволюционно- продвинутым?»
  22. 22. Что значит «быть эволюционно- продвинутым?»
  23. 23. Что значит «быть эволюционно- продвинутым?»
  24. 24. Что значит «выбирать подходящие практики?»
  25. 25. Три преобладавших вектора PMI: Устав (неизменный) + планы проекта (гибкие) = результат (продукт) Agile: Product vision + Pr. Owner = backlog / features = итеративно-инкрементная разработка Водопад: ТЗ – ЧТЗ – Работы по этапам.
  26. 26. Опасно! Карго-культ
  27. 27. Просто «засунем» Agile в PMI
  28. 28. «Просто» agile в PMI легко влезает, пока ограничения надуманные
  29. 29. Промежуточная идея А давайте сделаем Устав Гибкие планы будем вести в рамках Устава Если нужно – добавим ТЗ и ЧТЗ как отдельные работы.
  30. 30. Во что вылилось • Пишутся Уставы проектов и формально согласовываются (совет директоров). Сроки по ним все время сдвигаются (отдувается менеджер проекта – это удобно) • Agile используется для покрытия менеджеров злонамеренной команды (нет планов – нет ответственности) • ТЗ, ЧТЗ появляются фрагментарно, на тех проектах, где вообще ничего непонятно
  31. 31. Проблемы, которые остались • Не знаем «что делать» (в некоторых проектах очень быстро меняются приоритеты) • Не знаем «что делается» («разработка» творит непонятное, втихую допиливаются технологические платформы, которые нельзя продавать) • Не умеем планировать и прогнозировать • Имеем очень низкие показатели продуктивности, эффективности, полезности для пользователя, прозрачности и т.п. • Нехватка ресурсов (одни и те же люди на многих проектах) • Низкая мотивация, высокая текучка («надоел этот бардак») • Формально у нас «передовые методологии управления проектами, хоть и не в полном объеме», «agile, спринты и прочая демократия много где».
  32. 32. Де факто в Компании – в каждом лагере есть недовольные («а-я-же- говорил»).
  33. 33. Де факто в компании – фрагментарный воинствующий формализм
  34. 34. Де факто в компании – высокий уровень демотивации
  35. 35. Результат не нравится никому
  36. 36. Выводы Старые и новые подходы и методологии – это не «лучше» или «хуже», это эволюция, т.е. приспособление к разным условиям. Выбирая подходы и методологии нужно точно понимать под какие условия и как она сформировалась и учитывать это при «гибридизации».
  37. 37. Вывод: Простые гибриды не работают! Вероятность «карго-культа».
  38. 38. Доказательства?
  39. 39. Подходите в сообщество менеджеров …продолжим!
  40. 40. Спасибо за внимание! Селиховкин Иван, PMP Вице-президент Санкт-Петербургского отделения PMI. Заместитель директора по проектам (производственная и ИТ-компания). Консультант, тренер. Контакты: pmlead.post@gmail.com Сайт: www.pmlead.ru Филиал PMI: www.pmi.org.ru Facebook: https://www.facebook.com/ivan.selikhovkin Linkedin: ru.linkedin.com/in/selikhovkin/

×