Интернет-проект Куда деваются деньги или экономика 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

План работ Смета работ Scope Продукт 1.1. Продукт 1.2. Акт сдачи работ План проекта Смета проекта

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

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

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

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