сторически договорные отношения между агентствами/студиями и заказчиками оформлялись на основания договора с фиксированной стоимостью работ и фиксированными сроками. Однако зачастую у клиентов есть потребность в разработке нового сервиса в сжатые сроки с пониманием бизнес-логики, но без готового ТЗ. Внедрение гибких методологий в разработку (SCRUM, AGILE) позволяет найти компромисс в такой ситуации. Однако, как будет выглядеть ценообразование? Какие риски для студии/агентства несет внедрение модели Time&Material? Как уговорить клиента вести разработку по модели оплаты, гарантирующей операционную рентабельность? Для каких проектов такой подход оправдан, а где несет огромные риски?

1. КАК ПЕРЕЙТИ НА МОДЕЛЬ TIME&MATERIALS
и не ударить лицом в грязь
Антон Черноталов

2. МОДЕЛЬ TIME&MATERIALS
1. Оплата затраченного на проект времени сотрудников
2. Оплата всех расходов (materials), понесенных для
выполнения проекта

3. В КАКИХ ПРОЕКТАХ МОДЕЛЬ T&M ЭФФЕКТИВНА
• При разработке сложных интернет-сервисов со сжатыми
сроками;
• На этапе поддержки интернет-сервисов, когда сильно
расширяется функциональность.
T&M не эффективна:
• При создании относительно типовых-решений
(например, корпоративных сайтов).

4. ВАЖНОЕ УСЛОВИЕ СЛОЖНОЙ РАЗРАБОТКИ
• Заказчик понимает бизнес-логику интернет-сервиса;
• Объективное отсутствие конкретных требований к технической
реализации;
• Отсутствие технических требований, потому что заказчик не знает
чего он хочет/на самом деле ничего не хочет;
• Хочется быстрее запуститься, не будем писать ТЗ;
• Выделенный PM на стороне клиента с техническим бэкграундом.

5. ЦЕНООБРАЗОВАНИЕ
• Ставка по нормочасу по каждому типу специалиста:
– проектный менеджер,
– бизнес-аналитик,
– системный архитектор,
– контент-менеджер,
– арт-директор,
– дизайнер,
• Учет времени по всем сотрудника, кроме PM;
• PM = 15-25% от суммарного времени остальных сотрудников, есть минимальный фикс;
• Минимальный объем закупок в месяц или минимальный объем отгрузки по сотруднику;
• Максимальная стоимость проекта, максимальная стоимость этапа;
• Выделение системы KPI и премиальной составляющей (20%), которую получит исполнитель
после выполнения этапа проекта/проекта целиком.
– разработчик,
– фронтенд разработчик,
– тестер.

6. РИСК №1 ДЛЯ ИСПОЛНИТЕЛЯ
Длительное принятие работ после ежемесячного отчета
в стиле «Угадай мелодию»
Решение:
• PM-клиента интегрирован в работу команды, участвуют в scrum-митингах,
принимает участие в обсуждении плановых затрат на выполнение задач;
• На старте работ делаем отчетность еженедельно и доносим отчет до ЛПР;
• Как проверять время, затраченное на разработку. Кто будет «судьей»;
• Шаг в оценке задачи: 15 мин, 30 мин, 1 час.

7. РИСК №1 ДЛЯ ЗАКАЗЧИКА
У подрядчика работают непрофессионалы, за обучение которых
нужно платить.
Решение:
• Наличие PM на клиентской стороне с техническим/девелоперским
бэкграундом на этот проект;
• Тестовая задача для оценки качества работы;
• Участие в scrum-митингах по проекту.

8. СРЫВ СРОКОВ/БЮДЖЕТВ ПО ПРОЕКТУ
Срыв сроков по проекту.
Решение: Важно составить документ, в котором указать конкретные сроки
запуска проекта или его этапа. Иначе T&M выгоден только для исполнителя.
Отсутствие верхней планки по стоимости проекта.
Решение: В рамках проекта определить либо максимальную стоимость проекта,
либо максимальную стоимость работ в месяц.

9. РИСК №1 ДЛЯ ЗАКАЗЧИКА
У подрядчика работают непрофессионалы, за обучение которых
нужно платить.
Решение:
• Наличие PM на своей стороне с техническим/девелоперским бэкграундом
на этот проект;
• Тестовая задача для оценки качества работы;
• Участие в scrum-митингах по проекту.

10. ЗА ЧТО ПЛАТИМ/БЕРЕМ ДЕНЬГИ?
Что входит/не входит в оплачиваемое время:
• Время разработки;
• Рабочие совещание;
• Встречи с клиентом для обсуждения проекта;
• Время, затраченное на транспорт до клиента (актуально при работе с удаленными
клиентами и/или когда команда состоит из нескольких человек).
Материалы, которые входят в разработку:
• Специализированное ПО (передается, если лицензия разрешает, заказчику);
• Тестовые серверы.

11. ДОГОВОРНЫЕ ОСОБЕННОСТИ
• Четкий регламент работ и постановки задач;
• Присутствие PM со стороны клиента на scrum-митингах;
• Подтверждение плана работы представителем клиента.
Чего делать нельзя:
• Без согласования с клиентом запускать в работу задачу.

12. ВОПРОСЫ?
Антон Черноталов
facebook.com/chernotalov
chernotalov@morizo.ru
www.morizo.ru