Оценка проекта — первый и неизбежный этап создания продукта. Какие трудности ожидают в процессе работы и как их преодолеть — читайте в нашей статье.
Подойдите к оценке серьёзно. Это не только информация для заказчика, но и планирование работы в принципе. Важно правильно распределить ресурсы и выделить достаточное количество времени на каждую из задач.
При оценке необходимо учитывать особенности конкретного продукта, платформы, аудитории. Иногда компании используют шаблоны. Но это подходит только для типовых проектов.
Шаг 1. Обсудить проект
Не оценивайте проект до начала работы с заказчиком. Это потеря времени. Говорите с клиентом. Если он чётко понимает, что нужно в итоге, адекватно рассуждает о сроках, сложности и стоимости работ — вам повезло. В таком случае обговорите продукт, цели, функционал. Обсудите организационные вопросы. Выберите каналы дальнейшего общения. Задавайте вопросы. Чем больше информации получите, тем меньше шансов ошибиться.
Если клиент не понимает, что нужно — придётся выбирать из 2 вариантов:
- выделить время и сотрудника на обсуждение и составление списка функций продукта. Часто этим занимаются продукт-менеджеры и (или) технические писатели;
- предложить на выбор 2–5 вариантов базовых решений, исходя из уже готовых похожих проектов. В этом случае важно показать отличающиеся наборы функций, объяснить разницу, плюсы и минусы каждой. Заказчик должен понимать, что выбирает.
«Лайфхак»: клиенты видят и ценят человеческое отношение, поэтому при оценке проекта старайтесь учесть специфику задумки и сферы, видение и пожелания заказчика. Если это невозможно — объясните это и адаптируйте идею. Ведите с заказчиком диалог. Начните общение до того, как создадите файл «Оценка проекта для …».
Шаг 2. Обратиться к разработчикам
Нет, файл «Оценка проекта для …» создавать ещё нельзя. Можно и нужно записать важную информацию из разговора с заказчиком, проанализировать её и обсудить с экспертами. Неважно, как хорошо вы разбираетесь в технической части продукта. Мнение эксперта не будет лишним.
Если оценка проекта на менеджере — технические специалисты подскажут, что из задуманного займёт больше времени, сил и денег. Расскажут, что реально сделать к нужному дню (или в принципе), а что нет. По факту именно группа разработчиков устанавливает сроки работ. Ведь только непосредственные исполнители знают, сколько часов потребуется на ту или иную задачу.
Если оценкой проекта занят разработчик — всё равно нужно сходить к коллегам. Возможно, они заметят то, что вы упускаете. Не пренебрегайте советами более опытных. Прислушивайтесь даже к тем, кто ниже уровнем. Новички могут заметить какие-то мелкие баги, задать вопросы, которые вы посчитаете очевидными, но потом точно услышите от клиента.
Шаг 3. Рассчитать время
Можно создавать файл.
Если вы с тех. отделом рассчитали время работы команды — это не значит, что оценка готова. Важно учесть и другие нюансы.
Например, время на правки, их обсуждение (это часто долго), документацию и заключение договоров с подрядчиками и контрагентами, каникулы в App Store и Google Play и прочее. Технические моменты: время на получение имени домена, программного обеспечения, SSL-сертификата, тестирование и другое. Да, на тестирование уже выделены часы. Но неизвестно, какие со стороны заказчика придут правки. Возможно, продукт переделают настолько, что тесты потребуют больше времени, чем запланировано.
Не стоит торопиться с оценкой. Если заказчик требует предоставить это за сутки — скажите, что вам и команде нужно ещё какое-то время, аргументируйте вашу просьбу. Объясните, что это снизит риск крупных правок и т. д.. Подробная, взвешенная оценка проекта выгодна обеим сторонам. Лучше подождать немного вначале, чем получить некачественный продукт в конце. Или не получить его в нужный срок в принципе.
Оценивайте спокойно.
Не паникуйте и не пытайтесь прописать в оценке намного больше часов, чем указали вам разработчики и посчитали вы сами. Да, небольшой запас для форс-мажора можно и нужно иметь. Однако чем больше времени уделяется рискам, тем больше нервничает заказчик. При этом неважно, какую причину вы указали в оценке. Можно раскидать эти часы по всем задачам. Клиенту всё равно не понравится. Как минимум потому, что ваша команда специалистов тоже успела подстраховаться, из-за чего сроки вышли гигантскими.
Пытаться выглядеть лучше и уменьшать время в оценке тоже не стоит. Вы или не уложитесь, или сделаете работу кое как. Клиент, конечно, порадуется небольшой круглой цифре в начале работы. Но будет ли человек так же рад продукту в конце?
Аргументируйте все временные затраты и объясняйте заказчику, почему на конкретную задачу выделено такое количество времени.
Шпаргалка, которая пригодится, когда вы сядете распределять часы.
Рекомендуем обратить внимание на:
- общение с командой и обсуждение проекта;
- выходные, праздники и отпуска в вашей компании;
- работу с документацией;
- заключение договоров с подрядчиками и контрагентами;
- правки и их обсуждение: и с клиентом, и с тех. отделом;
- время работы организаций, связанных с созданием продукта: выходные поставщиков техники, техподдержек, каникулы магазинов приложений и другое;
- время работы и время на работу государственных структур (если продукт создаётся для них и (или) согласовывается с ними);
- получение доменного имени;
- получение SSL-сертификата;
- получение ПО и доступа к аккаунтам;
- стабилизацию, особенно при разработке на Android;
- тесты и приёмо-сдаточные испытания;
- риски: каждой из задач отдельно и проекта в принципе.
Если вы всё ещё в замешательстве — предлагаем 5 методов оценки проектов разного уровня сложности. Выберите подходящую вашему случаю и ориентируйтесь на неё.
Ознакомительная (вилочная) оценка
Рассматривается всё, но в общем. Даётся две оценки: наиболее и наименее вероятная. Разница между ними обычно в два раза и больше. Это обусловлено тем, что анализ проводится исключительно с помощью предположений и самых базовых формул.
Подойдёт для первичной оценки проекта. Чаще всего вилочную оценку используют, когда о предстоящих задачах известно мало или почти ничего. И как таковой план команда не разработала.
Вилочную оценку используют, чтобы понять, стоит ли соглашаться на эту работу. Ещё с помощью этого метода можно кратко ввести в курс дела и предстоящих затрат клиента. Это делается даже без обращения к техническим специалистам.
Однако не стоит использовать вилочную оценку в работе. Метод неточный, не даёт много информации, не отвечает на важные для клиента и команды вопросы. Если у вас несложный проект, используйте следующий метод.
Для проектов низкого и среднего уровня сложности
Оценка в попугаях
Ещё одно название этого метода — story points. Но и отсылка к советскому мультику обоснована: за единицу измерения берётся самая небольшая задача. С помощью неё далее измеряются задачи большего размера. Сумма таких попугаев (мини-задач) в каждом спринте равна скорости работы команды.
Подойдёт для оценки стандартных проектов. Не рекомендуем брать для оценки новых проектов и проектов с фиксированной оплатой. В первом случае будет сложно рассматривать отдельные процессы и задачи в ходе работы. Во втором — нет никакого смысла измерять скорость работников на фикспрайс.
Стоимость качества
Нетривиальный метод, в основе которого лежит разделение стоимости. Сначала оценивают разработку функционала без учёта рисков и доработок. Затем — считают стоимость работ по устранению неполадок. Количество неполадок берут среднее, отталкиваясь от конкретного продукта.
Подойдёт для оценки большинства проектов низкой и средней сложности. Во время оценки проекта можно учитывать также стоимость тестирования, исправления внешних проблем по интеграции, покупки и установки ПО.
Для сложных проектов
Оценка вероятного
Проект разбивают на задачи. Команда рассматривает каждую из задач в трёх вариантах: идеальной (без рисков), с частично реализованными рисками и со всеми реализованными рисками. В обсуждении решается, какие из перечисленных рисков максимально вероятны. Именно их закладывают в оценку проекта.
Этот метод требует времени. Так как вся команда занята проецированием и анализом не одной, а трёх ситуаций. Подойдёт, если задача неординарная и подразумеваем много рисков. Помогает заранее составить список задач, предусмотреть возможные проблемы на каждом этапе и подстраховаться.
PERT
С помощью PERT вы составляете три оценки: оптимистическую, пессимистическую и наиболее вероятную. В этом поможет теория вероятности и математика в принципе. Полное описание алгоритма оценки по PERT и формулы этого метода смотрите в научной статье М. А. Фридлянова (с. 20).
Подойдёт для длительных, единовременных, сложных проектов, так как помогает дать оценку и рабочий график проекта без точного знания деталей и необходимого времени для всех составляющих. Минусы PERT — сложность и время. Если клиент понимает, что заказ сложный, и готов ждать — оценивайте проект по PERT.
Немного о нас
Методов много. Некоторые из них основаны на прошлом опыте компании, они анализируют предыдущие проекты и уже просчитанное соотношение оплата — часы. Другие уходят в статистику и науку. Мы выбрали одни из самых эффективных и удобных, на наш взгляд.
Какой из них выбрать — решайте сами.
Лично мы оцениваем проекты в часах и деньгах. Менеджер по продукту изучает поверхностный бэклог, по которому разработчик оценивает проект целиком. Мы всегда задействуем профессионалов в оценке проекта и просим заказчиков предоставлять максимально точные данные. Чем подробнее описание проекта, тем лучше будет видение продукта, его понимание. И тем точнее будет оценка.
Наши специалисты рекомендуют заказчикам при подаче заявки иметь конкретную цель проекта, понимать основные разделы и фичи. Это и постоянный диалог с менеджером поможет разработать именно то, что хочет клиент.
«Самое важное — понимание сути проекта у всех, кто участвует в оценке».
— менеджер по продукту Infoshell, Александра
Если вы — будущий заказчик, и пытаетесь оценить задумку самостоятельно, — пишите нам. Мы не только оценим и «посчитаем» ваш проект, но и объясним всё доступным не-технарю языком.
