Презентация на тему Интернет-проект Куда деваются деньги или экономика agile-проекта.

Интернет-проект Куда деваются деньги или экономика agile-проекта.

Юрий Шиляев,
Epam Systems
Agile.by

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

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

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

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

Часть первая,

в которой пойдет речь о несколько неудачном опыте

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

Первый крупный интернет-проект.
«Громадный» объем. Аж 1000 ч/часов.
«Водопадный» процесс, другого не знали.
Расплывчатые требования и scope.
Жесткий график + fixed price.

Готовое ТЗ

Оценка ТЗ

План проекта

Договор

Разработка

Риски

Маржа

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

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

Расходы

Риски

Маржа

Риски

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

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

Расходы

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

Scope проекта увеличился из-за неточно описанных требований, а они еще начали меняться (озарения, технические проблемы, изменяющиеся условия).
Длительность проекта выросла, что повлияло на себестоимость проекта.
Строгий договор, который был скорее выгоден заказчику, нежели нам.

Часть вторая,

где рассказывается о циничных принципах капитализма.

Принцип #1

Следствие #1: Заказчик всегда старается привязать оплату к результату посредством договора.

Следствие #2: Если оплата слишком далека, то мы рискуем "помереть с голоду"..

Принцип #2

Scope – Schedule - Resource

Следствие #1: Если scope может быть расширен, то он будет расширен.

Дополнение к Следствию #1: Если scope можно расширить без расширения бюджета, он будет расширен без расширения бюджета.

Снова экономика

Часть третья,

где показывается успешный проект.

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

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

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

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

Бюджет в Agile

Бюджет в Agile

Бюджет в Agile

План проекта

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

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

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

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

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

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

Юрий Шиляев,
Epam Systems
Agile.by