Интернет-проект Откуда берутся и куда деваются деньги.

Юрий Шиляев, Директор dev-центра компании Artics.ru

О чем эта презентация

• Какие риски накладывают друг на друга заказчик и разработчик и кто за это платит.

• Кейс: как не надо управлять большим проектом

• Кейс: как им надо управлять• Как при этом выжать из бюджета на

разработку максимум• И быстро оборачивать вложенные средства

2

О чем я не буду рассказывать

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

3

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

4

Кейс 1: С чего все начиналось.

• Первый крупный интернет-проект.• «Громадный» объем. Аж 1000 ч/часов.• Договорные отношения, как с

корпоративным сайтом = fixed price.• Расплывчатые требования и scope.• Жесткий график.

5

Как поступили:

• Шли по рельсам корпоративных проектов.• Решили строго зафиксировать scope => 2

месяца аналитики и толстенное ТЗ.• Провели оценку ТЗ, там где были белые

пятна – прикинули, что справимся.• Составили план работ на 6-ть месяцев

вперед...

6

Scope, cost и жизненный цикл

Бюджет расходуется, ситуация вокруг меняется, проект не разрабатывается.

$$ $ $

$$ $ $

КонцепцияБизнес-анализ

Формирование требований (Scope)

3 месяца

7

Проектный треугольникScope

ScheduleCost

Один плотник за 100 р. (cost) делает одну табуретку (scope) за один день (schedule).

8

Проектный треугольник

Scope?

ScheduleCost

9

Бюджет разработки

Экономика. Бюджет.

Бюджет проекта

10

Бюджет разработки

Экономика. Бюджет.

Бюджет проекта

Бюджет разработки

11

Бюджет разработки

Экономика. Бюджет.

Бюджет проекта

Бюджет разработки

Риски

12

Бюджет разработки

Экономика. Бюджет.

Бюджет проекта

Бюджет разработки

Риски

13

Экономика. Бюджет.

Расходы

Риски

Маржа

Бюдж

ет п

роек

та

14

Экономика. Бюджет.

Расходы

Риски

МаржаРиски

Бюдж

ет п

роек

та

15

Итого столкнулись с проблемами:

• Боялись выбрать не верное тех. решение и перестраховались начав писать новую систему.

• На scope влияло много факторов: изменение условий рынка, озарения заказчика, технические проблемы.

• Строгие контрактные обязательства, которые невозможно было соблюдать.

16

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

17

Кейс 2: С чистого листа.

• Крупный интернет-проект.• Scope зафиксирован только на уровне

общей концепции.• Мы выступаем и как консультанты и как

разработчики, т.е. тоже влияем на scope и requirements .

• График абстрактный.

18

Потери времени и усилий

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

process)• Дефекты• Удорожание процесса.

19

Мы понимаем, что…

Впереди технологические трудности.1 год 2 год

ПосещаемостьПредел технологического решения

Этап модернизации технологической платформы…

20

Мы понимаем, что…

Нас подстерегают изменения.

$ $

$ $ $ $ $ $

Нет средств

$ $ $

21

Ответ: итерационный процесс

$$ $ $ $

$ $$ $ $ $

Быстрый старт и последовательное развитие.

Проблема

Бета Релиз

$$

22

Ответ: итерационный подход (agile)

• Короткие итерации:– Быстрый запуск.– Меньше scope => меньше переделок

• Инкрементная разработка. • Постоянная интеграция:– Постоянное добавление новых «фич».– Лучше тестирование.

• Гибкость к изменениям.• Сокращение потерь и ускорение коммуникаций.• Разделение и минимизация рисков.

23

Бюджет в Agile

Расходы

Риски

Маржа

24

Бюджет в Agile

25

Бюджет в Agile

26

time

План работ

Смета работ

Scope

Продукт 1.1. Продукт 1.2.

Акт сдачи работ

План проекта

Смета проекта

Итерации для заказчика

• Быстрый запуск и постоянная интеграция =>– Ускорение оборачиваемости средств

• Готовый релиз в конце итерации => – Прозрачная система оплаты работы по факту.– Гарантия постоянной готовности продукта.

• Готовность к изменениям.• Снижение рисков, снижение потерь =>

снижение стоимости работ.• … при неизменном качестве услуг.

27

Ограничения для заказчика

• Управление бюджетом => полномочный менеджер проекта.

• Увеличение коммуникаций => менеджер проекта должен быть постоянно доступен и информирован.

• Email-переписка на уровне юридической силы (Skype?).

• Часть требований останется на словах.

28

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

29

Экономим

Стоимость

Качество

30

Кризис vs Agile

• Разделение рисков между разработчиком и заказчиком.

• Возможность тактически влиять на цель проекта. Быть готовым к изменениям.

• Финансировать проект небольшими частями и платить только по факту.

• В случае прекращения финансирования – иметь готовый продукт.

31

В итоге:• Ускоряем процесс

создания и вывода на рынок проекта.

• Гибко управляем тактикой и стратегией проекта.

• Используем итеративный подход в решении задач и распределении бюджета.

• Оптимизируем бюджет за счет снижения потерь, но не за счет экономии на качестве.

32

FINВОПРОСЫ?

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

33