21.05.2019

Как мы работаем

От лида до запуска вашего продукта

В этой статье мы подробно рассказываем о всех этапах работы над проектами и отвечаем на самые часто задаваемые вопросы заказчиков.

Примерная оценка

После заявки на оценку проекта, менеджер связывается с вами в течение 24 часов для уточнения деталей. Уже на этом этапе начинается сбор бизнес требований, при необходимости мы предлагаем созвониться в удобное для вас время. Чем больше подробностей мы имеем — тем точнее оценка. Наша первое коммерческое предложение обычно представляет из себя “вилку” по цене и срокам “от… до…”

Пример контурной оценки

Почему мы просим уточнить бюджет и предполагаемый дедлайн проекта?

Мы часто просим клиентов уточнить ограничения по бюджету и срокам. Мы делаем это вовсе не потому, что хотим выставить вам максимально большой счёт, а чтобы предложить более экономные варианты архитектурных решений, исключить некоторый функционал (создать MVP) или понять, что мы друг другу не подходим.

Почему примерная оценка отличается от конечной?

Есть несколько вариантов оценки проектов. На этапе предварительной оценки мы часто используем экспертную оценку. При этом мы порой не знаем многих деталей функционала, интеграций с базой, API и прочего. Бывает, что в процессе дальнейшего обсуждения заказчик хочет добавить дополнительные фичи, которые могут требовать смену и усложнение архитектурного решения.

Пример коммерческого предложения

Согласование бюджета и смета

Когда мы уверены, что примерная оценка удовлетворяет требованиям заказчика по бюджету и срокам, мы составляем смету. Руководитель проектов собирает все требования к программному обеспечению, на этот раз он ещё глубже погружается в бизнес процессы заказчика, проводит несколько интервью с клиентом, его сотрудниками, целевой аудиторией. Результатом исследовательской работы менеджера являются написанные user-stories, техническое задание на проект, скетчи. Всё это ещё раз согласовывается с заказчиком.

Пример user-stories

Затем собирается команда, для обсуждения и продумывания архитектурного решения и финальной оценки. Мы делаем оценку по трём точкам, на основе оптимистичной, пессимистичной и реалистичной оценок.

Оптимистичная оценка — количество часов, требуемое на реализацию при условии, что всё пойдёт хорошо, например, API базы данных имеет чёткую и понятную документацию и с лёгкостью может быть использовано в проекте. Пессимистичная — та, при которой всё пойдёт наперекосяк, например, API окажется не только не задокументированным, но и местами недописанным. Реалистичная оценка это самая приближенная к жизни оценка, по мнению разработчика. В ней учитываются риски, которые сыграют с наибольшей вероятностью.

Именно в точности реалистичной оценки и проявляется экспертность разработчиков и менеджера проектов, обязанности которого выяснить, в чём заключаются главные опасения команды и здраво оценить ситуацию, основываясь на личном опыте и опыте команды. Далее, на основе оценки по трем точкам и реестра рисков руководитель проекта составляет смету, которую представляет заказчику.

Договор, архитектура и дизайн

После принятия сметы, мы заключаем договор на разработку. Обычно мы работаем по предоплате в 30% от стоимости проекта. Работа по проекту всегда начинается с проработки и согласования дизайна. Если проект очень объёмный, то мы можем заключить договор на дизайн и составить смету на разработку уже после приёмки готового дизайна.

Пример иерархической структуры работ по проекту (помогает разбивать проект на составные части)

Сдача проекта, исправление багов и поддержка

Нас часто спрашивают, почему пункт тестирования в смете обходится так дорого? Объясняем. Тестирование ведётся в течение всего проекта, начиная с первых его недель, так как чем раньше выявлен и исправлен баг, тем дешевле его исправление.

Почему разработчики не могут сразу писать без ошибок? Они недостаточно опытные?
— Код всегда требует проверки работоспособности при множестве разных условий. Например, при добавлении нового функционала, ранее реализованный функционал может работать не так, как задумано. Для этого QA-инженер постоянно проверяет множество различных сценариев использования каждого функционального блока. Да, разработчик мог бы делать это сам, но кто бы тогда в это время делал новый функционал? Кроме того, его время обходится дороже, чем время QA-инженера.

Мы практикуем ручное тестирование и написание авто-тестов для больших долгосрочных проектов. При сдаче проекта проводится регрессионное тестирование — тестирование всего проекта с самого начала.

Некоторые ошибки могут быть выявлены только на большом количестве пользователей, так что иногда пользователи или заказчик могут обнаружить какие-либо недочёты уже после запуска продукта. Поэтому мы предоставляем 1 месяц  бесплатной техподдержки на разработку. Кроме того, мы оказываем услуги платной расширенной техподдержки продукта, в рамках которой мы отслеживаем производительность и работоспособность продукта, предотвращаем инциденты, связанные с его функционированием и восстанавливаем его работоспособность в случае отказа системы.

Мы постоянно мониторим и работаем над качеством наших менеджеров и команд, чтобы сделать процесс разработки максимально прозрачным и понятным для заказчика и комфортным для команды. О нашей открытости говорят сами клиенты.

Отзыв клиента на clutch.co
0 оценок