Доклад В.Б. Мамаева на 21-м семинаре РТД.

1. Интернет-проект
Откуда берутся
и куда деваются
деньги.
Юрий Шиляев,
Директор dev-центра
компании Artics.ru

2. О чем эта презентация
• Какие риски накладывают друг на друга
заказчик и разработчик и кто за это платит.
• Кейс: как не надо управлять большим
проектом
• Кейс: как им надо управлять
• Как при этом выжать из бюджета на
разработку максимум
• И быстро оборачивать вложенные средства
2

3. О чем я не буду рассказывать
• Как родить идею для интернет-проекта
• Как построить компанию
• Кому и сколько платить
• Как находить заказчиков
• … и заработать много денег.
3

4. КЕЙС №1. КАК ЭТО БЫЛО.
Жизненный цикл «проваленного» проекта
4

5. Кейс 1: С чего все начиналось.
• Первый крупный интернет-проект.
• «Громадный» объем. Аж 1000 ч/часов.
• Договорные отношения, как с
корпоративным сайтом = fixed price.
• Расплывчатые требования и scope.
• Жесткий график.
5

6. Как поступили:
• Шли по рельсам корпоративных проектов.
• Решили строго зафиксировать scope => 2
месяца аналитики и толстенное ТЗ.
• Провели оценку ТЗ, там где были белые
пятна – прикинули, что справимся.
• Составили план работ на 6-ть месяцев
вперед...
6

7. Scope, cost и жизненный цикл
Бюджет расходуется, ситуация вокруг
меняется, проект не разрабатывается.
$
$ $ $
$
$ $ $
Концепция
Бизнес-анализ
Формирование
требований
(Scope)
3 месяца
7

8. Проектный треугольник
Scope
ScheduleCost
Один плотник за 100 р. (cost) делает одну
табуретку (scope) за один день (schedule).
8

9. Проектный треугольник
Scope?
ScheduleCost
9

10. Бюджет
разработки
Экономика. Бюджет.
Бюджет проекта
10

11. Бюджет
разработки
Экономика. Бюджет.
Бюджет проекта
Бюджет
разработки
11

12. Бюджет
разработки
Экономика. Бюджет.
Бюджет проекта
Бюджет
разработки
Риски
12

13. Бюджет
разработки
Экономика. Бюджет.
Бюджет проекта
Бюджет
разработки
Риски
13

14. Экономика. Бюджет.
Расходы
Риски
Маржа
Бюджетпроекта
14

15. Экономика. Бюджет.
Расходы
Риски
Маржа
Риски
Бюджетпроекта
15

16. Итого столкнулись с проблемами:
• Боялись выбрать не верное
тех. решение и
перестраховались начав писать
новую систему.
• На scope влияло много
факторов: изменение условий
рынка, озарения заказчика,
технические проблемы.
• Строгие контрактные
обязательства, которые
невозможно было соблюдать.
16

17. КЕЙС №2.
ИТЕРАЦИОННЫЙ ПОДХОД.
Управляем бюджетом, а не ресурсом.
17

18. Кейс 2: С чистого листа.
• Крупный интернет-проект.
• Scope зафиксирован только на уровне
общей концепции.
• Мы выступаем и как консультанты и как
разработчики, т.е. тоже влияем на scope и
requirements .
• График абстрактный.
18

19. Потери времени и усилий
• Создание устаревающей документации
• Перепроизводство «фич»
• Ожидание
• Излишняя глубина проработки
• Лишние действия (fe: change management
process)
• Дефекты
• Удорожание процесса.
19

20. Мы понимаем, что…
Впереди технологические трудности.
1 год 2 год
ПосещаемостьПредел
технологического
решения
Этап модернизации
технологической
платформы…
20

21. Мы понимаем, что…
Нас подстерегают изменения.
$ $
$ $ $ $ $ $
Нет средств
$ $ $
21

22. Ответ: итерационный процесс
$
$ $ $ $
$ $
$ $ $ $
Быстрый старт и последовательное развитие.
Проблема
Бета Релиз
$
$
22

23. Ответ: итерационный подход (agile)
• Короткие итерации:
– Быстрый запуск.
– Меньше scope => меньше переделок
• Инкрементная разработка.
• Постоянная интеграция:
– Постоянное добавление новых «фич».
– Лучше тестирование.
• Гибкость к изменениям.
• Сокращение потерь и ускорение коммуникаций.
• Разделение и минимизация рисков.
23

24. Бюджет в Agile
Расходы
Риски
Маржа
24

25. Бюджет в Agile
25

26. Бюджет в Agile
26
time
План работ
Смета работ
Scope
Продукт 1.1. Продукт 1.2.
Акт сдачи работ
План проекта
Смета проекта

27. Итерации для заказчика
• Быстрый запуск и постоянная интеграция =>
– Ускорение оборачиваемости средств
• Готовый релиз в конце итерации =>
– Прозрачная система оплаты работы по факту.
– Гарантия постоянной готовности продукта.
• Готовность к изменениям.
• Снижение рисков, снижение потерь =>
снижение стоимости работ.
• … при неизменном качестве услуг.
27

28. Ограничения для заказчика
• Управление бюджетом => полномочный
менеджер проекта.
• Увеличение коммуникаций => менеджер
проекта должен быть постоянно доступен и
информирован.
• Email-переписка на уровне юридической
силы (Skype?).
• Часть требований останется на словах.
28

29. КРИЗИС
Че делать?
29

30. Экономим
Стоимость
Качество
30

31. Кризис vs Agile
• Разделение рисков между разработчиком и
заказчиком.
• Возможность тактически влиять на цель
проекта. Быть готовым к изменениям.
• Финансировать проект небольшими
частями и платить только по факту.
• В случае прекращения финансирования –
иметь готовый продукт.
31

32. В итоге:
• Ускоряем процесс
создания и вывода на
рынок проекта.
• Гибко управляем тактикой
и стратегией проекта.
• Используем итеративный
подход в решении задач и
распределении бюджета.
• Оптимизируем бюджет за
счет снижения потерь, но
не за счет экономии на
качестве.
32

33. FIN
ВОПРОСЫ?
Юрий Шиляев,
Директор dev-центра
компании Artics
Пишите: yshilyaev@artics.ru
Читайте: http://yuri.shilyaev.com
Заходите: http://artics.ru
33