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

2 / 23

Зачем вообще об этом нужно думать?

Потому что даже с хорошей методикой бывает, что все через одно место

3 / 23

Пример одного из изменений на сайте в марте

4 / 23

Может быть, это единственный случай?

После нескольких лет работы инфраструктура типовой компании крайне запутана

5 / 23

6 / 23

Ситуацию продолжают усугублять сами заказчики

Бизнес приходит к менеджерам проектов с типовыми запросами

7 / 23

• «Мы тут два месяца готовились и через неделю запускаем два новых пункта самовывоза»

• «Самое приоритетное в этом квартале: сделать правки для Москвы»

• «А еще мы решили в этом году запустить свой собственный колл-центр»

8 / 23

Запросы принципиально отличаются масштабом бедствия

Размер «хотелки» vs. объем работы

«Проектик»

9 / 23

«Проект» «Проектище»

- Мало Dev(10-20 часов)

- Нормально QA(неделя)

- Много PM(две-три недели)

- Нормально Dev(2-4 месяца)

- Нормально QA(одн-два человека)

- Нормально PM(50-100% времени)

- Нормально Dev(две-три команды)

- Много QA(две недели интеграции)

- Много PM(старший PM)

10 / 23

И нельзя забывать про поправочные коэффициенты

Дополнительные критерии, влияющие на трудоемкость

11 / 23

• Адекватность заказчика• Наличие внешних партнеров• Качество существующего кода• Доля инфраструктурных задач• Зрелость команды

12 / 23

Как подобрать методику?

Качественно, быстро, дешево

13 / 23

• Качественно для стратегических проектов (фокус на аналитике и системной разработке)

• Быстро для исправления критичных ошибок или при наличии внешних deadline-ов(фокус на коротком цикле анализ-разработка-тест)

• Дешево для проверки гипотез на прототипах(фокус на приоритезации и гибкости изменений)

14 / 23

Но усилий для поддержки трех процессов понадобится в три раза больше?

Разным проектам нужны разные уровни аналитики и планирования

15 / 23

• Малый: описание проекта и список задач• Средний: спецификация с декомпозицией

до features, проектный план с декомпозицией по итерациям

• Большой: архитектура проектов, спецификации проектов, прототипы, планы проектов и план внедрения

16 / 23

Но для поддержки разных процессов нужно будет больше людей?

Людей в командах можно поделить по ролям

17 / 23

18 / 23

Но все проекты столкнутся вместе на релизе?

Пересечение проектов на релизах не помеха при хорошей релизной схеме

19 / 23

• У всех проектов итерации кратны двум неделям

• У всех проектов общий план релизов• Постоянный ритм релизов: вторник, четверг• Три малых релиза• Каждый второй четверг большой релиз

20 / 23

И что нам это дало?

Стало понятнее

21 / 23

• как делать проекты• сколько нужно ресурсов• когда все будет готово• какие есть риски• как расставить приоритеты

22 / 23

Нам это не помогло!

Спасибо за внимание!

23 / 23

• Почта:dmitry.kruglov@lamoda.ru

• Основной сайт: www.lamoda.ru• Сайт компании:company.lamoda.ru

Контакты