Мухи от котлет, или Зачем классифицировать проекты
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Мухи от котлет, или Зачем классифицировать проекты

on

  • 485 views

Презентация Дмитрия Круглова. Конференция Software Project Management Conference-3.

Презентация Дмитрия Круглова. Конференция Software Project Management Conference-3.
6 декабря 2013, Казань.
http://www.spmconf.ru

Statistics

Views

Total Views
485
Views on SlideShare
444
Embed Views
41

Actions

Likes
1
Downloads
3
Comments
0

2 Embeds 41

http://spmconf.ru 40
http://www.spmconf.ru 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Объяснение слайда в конце. Стимул дослушать.
  • Представление как о ненужном, вспомогательном, аналитическом, для галочки.
  • Крупный холдинг, 15 лет на рынке. Налажены процессы. Удаленная разработка. Продуктовый комитет. KPI на выполнение тикетов.
  • Ляпов с кривой методикой полно. Практика оценки изменений в деньгах. Бизнес фантазирует. Пишет по 50-80т евро в месяц.
  • Осложняется легаси. Постоянно промахиваешься в оценках. Вылазят косяки. Требуется чистка, рефакторинг.
  • Взять и исправить не получится. Постоянно приходят из бизнеса.
  • - Какие роли нужны для каждого типа проекта и как они укладываются в команды

Мухи от котлет, или Зачем классифицировать проекты Presentation Transcript

  • 1. Мухи от котлет, или Зачем классифицировать проекты
  • 2. Зачем вообще об этом нужно думать? 2 / 23
  • 3. Потому что даже с хорошей методикой бывает, что все через одно место Пример одного из изменений на сайте в марте 3 / 23
  • 4. Может быть, это единственный случай? 4 / 23
  • 5. После нескольких лет работы инфраструктура типовой компании крайне запутана 5 / 23
  • 6. Ситуацию продолжают усугублять сами заказчики 6 / 23
  • 7. Бизнес приходит к менеджерам проектов с типовыми запросами • «Мы тут два месяца готовились и через неделю запускаем два новых пункта самовывоза» • «Самое приоритетное в этом квартале: сделать правки для Москвы» • «А еще мы решили в этом году запустить свой собственный колл-центр» 7 / 23
  • 8. Запросы принципиально отличаются масштабом бедствия 8 / 23
  • 9. Размер «хотелки» vs. объем работы «Проектик» «Проект» «Проектище» - Мало Dev - Нормально Dev - Нормально Dev - Нормально QA - Много QA - Нормально PM - Много PM (10-20 часов) - Нормально QA (неделя) - Много PM (две-три недели) (2-4 месяца) (одн-два человека) (50-100% времени) 9 / 23 (две-три команды) (две недели интеграции) (старший PM)
  • 10. И нельзя забывать про поправочные коэффициенты 10 / 23
  • 11. Дополнительные критерии, влияющие на трудоемкость • • • • • Адекватность заказчика Наличие внешних партнеров Качество существующего кода Доля инфраструктурных задач Зрелость команды 11 / 23
  • 12. Как подобрать методику? 12 / 23
  • 13. Качественно, быстро, дешево • Качественно для стратегических проектов (фокус на аналитике и системной разработке) • Быстро для исправления критичных ошибок или при наличии внешних deadline-ов (фокус на коротком цикле анализ-разработка-тест) • Дешево для проверки гипотез на прототипах (фокус на приоритезации и гибкости изменений) 13 / 23
  • 14. Но усилий для поддержки трех процессов понадобится в три раза больше? 14 / 23
  • 15. Разным проектам нужны разные уровни аналитики и планирования • Малый: описание проекта и список задач • Средний: спецификация с декомпозицией до features, проектный план с декомпозицией по итерациям • Большой: архитектура проектов, спецификации проектов, прототипы, планы проектов и план внедрения 15 / 23
  • 16. Но для поддержки разных процессов нужно будет больше людей? 16 / 23
  • 17. Людей в командах можно поделить по ролям 17 / 23
  • 18. Но все проекты столкнутся вместе на релизе? 18 / 23
  • 19. Пересечение проектов на релизах не помеха при хорошей релизной схеме • У всех проектов итерации кратны двум неделям • У всех проектов общий план релизов • Постоянный ритм релизов: вторник, четверг • Три малых релиза • Каждый второй четверг большой релиз 19 / 23
  • 20. И что нам это дало? 20 / 23
  • 21. Стало понятнее • • • • • как делать проекты сколько нужно ресурсов когда все будет готово какие есть риски как расставить приоритеты 21 / 23
  • 22. Нам это не помогло! 22 / 23
  • 23. Спасибо за внимание! Контакты • Почта: dmitry.kruglov@lamoda.ru • Основной сайт: www.lamoda.ru • Сайт компании: company.lamoda.ru 23 / 23