Интернет-проект. Откуда берутся и куда деваются деньги.
Download as PPT, PDF4 likes805 views
Презентация Юрия Шиляева касается управления бюджетом и рисками в agile-проектах, обсуждая как неудачные, так и успешные кейсы. Обсуждаются циничные принципы капитализма, риски увеличения объема работ и важность гибкости в управлении проектами. Основной акцент сделан на итерационном подходе и постоянной интеграции для улучшения качества и снижения затрат.
Интернет-проект. Откуда берутся и куда деваются деньги.
- 1. Интернет-проект Куда деваются деньги или экономика agile- проекта. Юрий Шиляев, Epam Systems Agile.by
- 2. О некоторых циничных принципах капитализма. О том какие риски накладывают друг на друга заказчик и разработчик и кто за это платит. О том как не надо управлять большим проектом и о том как им надо управлять Как при этом выжать из бюджета на разработку максимум… И быстро оборачивать вложенные средства О чем эта презентация
- 3. О чем я не буду рассказывать Как родить идею для интернет-проекта Как построить компанию Кому и сколько платить Как находить заказчиков … и заработать много-много денег.
- 4. Часть первая, в которой пойдет речь о несколько неудачном опыте
- 5. Кейс 1: С чего все начиналось. Первый крупный интернет-проект. «Громадный» объем. Аж 1000 ч/часов. «Водопадный» процесс, другого не знали . Расплывчатые требования и scope. Жесткий график + fixed price .
- 6. Готовое ТЗ Оценка ТЗ План проекта Договор Разработка
- 16. Риски Маржа Бюджет проекта Экономика. Бюджет. Расходы
- 17. Риски Маржа Бюджет проекта Экономика. Бюджет. Расходы
- 18. Итого столкнулись с проблемами: Scope проекта увеличился из-за неточно описанных требований, а они еще начали меняться (озарения, технические проблемы, изменяющиеся условия). Длительность проекта выросла, что повлияло на себестоимость проекта. Строгий договор, который был скорее выгоден заказчику, нежели нам.
- 19. Часть вторая, где рассказывается о циничных принципах капитализма.
- 20. Принцип # 1
- 21. Следствие # 1: Заказчик всегда старается привязать оплату к результату посредством договора. Следствие # 2: Если оплата слишком далека, то мы рискуем "помереть с голоду"..
- 22. Принцип # 2 Scope – Schedule - Resource
- 23. Следствие # 1: Если scope может быть расширен, то он будет расширен. Дополнение к Следствию # 1: Если scope можно расширить без расширения бюджета, он будет расширен без расширения бюджета.
- 26. Снова экономика Риски Маржа Бюджет проекта Расходы
- 27. Часть третья, где показывается успешный проект.
- 28. Кейс 2: С чистого листа. Крупный интернет-проект. Scope зафиксирован только на уровне общей концепции. Мы выступаем и как консультанты и как разработчики, т.е. тоже влияем на scope и requirements . График абстрактный.
- 32. Ответ: итерационный подход (agile) Короткие итерации: Быстрый запуск. Меньше scope => меньше переделок Инкрементная разработка. Постоянная интеграция: Постоянное добавление новых «фич». Лучше тестирование. Гибкость к изменениям. Сокращение потерь и ускорение коммуникаций. Разделение и минимизация рисков.
- 33. Бюджет в Agile Риски Маржа Расходы
- 34. Бюджет в Agile
- 35. Бюджет в Agile План проекта Смета проекта План работ Смета работ Scope Продукт 1.1. Продукт 1.2. Акт сдачи работ
- 37. Итерации для заказчика Быстрый запуск и постоянная интеграция => Ускорение оборачиваемости средств Готовый релиз в конце итерации = > Прозрачная система оплаты работы по факту. Гарантия постоянной готовности продукта. Готовность к изменениям. Снижение рисков, снижение потерь = > снижение стоимости работ. … при неизменном качестве услуг.
- 38. Ограничения для заказчика Управление бюджетом = > полномочный менеджер проекта. Увеличение коммуникаций = > менеджер проекта должен быть постоянно доступен и информирован. Email- переписка на уровне юридической силы ( Skype ?). Часть требований останется на словах.
- 39. Разделение рисков между разработчиком и заказчиком. Возможность тактически влиять на цель проекта. Быть готовым к изменениям. Финансировать проект небольшими частями и платить только по факту. В случае прекращения финансирования – иметь готовый продукт .
- 40. Юрий Шиляев, Epam Systems Agile.by