Николай Товеровский |
Даниил! Я не советую браться за проекты, где клиенту всё равно, когда запустится продукт. Скорее всего, такой клиент будет наплевательски относиться к согласованию результатов, и вы потратите своё время зря. Другое дело, если клиент не видит пользы в ограничении срока разработки. В этом случае я предлагаю обратиться к логике. Допустим, клиент хочет сделать проект, в котором четыре функции, и ему не слишком важен срок. И допустим, мы оценили проект в четыре месяца. Это значит, что через четыре месяца клиент получит продукт с четырьмя функциями: Теперь вопрос. Чем запуск функций по отдельности отличается от запуска большой пачки функций? Если всё пойдёт по первоначальному плану, то через те же четыре месяца у клиента будет продукт с четырьмя функциями, как он и хотел: При работе небольшими итерациями каждая отдельная функция начнёт приносить аудиторию и доход гораздо раньше, а если в процессе работы мы поймём, что первоначальный набор функций и план были неверными, сможем скорректировать работу. Может статься, хватит и трёх функций, и клиент потратит меньше времени и денег. Кроме того, частые запуски позволят найти и исправить ошибки, и финальный продукт будет качественнее. Дополнительно можно рассказать об ограниченности времени жизни, о том, что проект — это экспедиция, а не доставка апельсинов, и о том, что стопроцентных проектов не бывает. См. краткое введение в ФФФ. |
Илья Бирман. Внутренний дедлайн |