Explore
Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
Заказчики — Тайлер и Бен — подкованные в фитнесе ребята. Они обратились к нам в ноябре 2020 года с идеей сделать приложение, которое будет связывать клиентов с их тренерами. Ребята задумывали так: можно заниматься в приложении с тренерами, которые раньше работали с клиентами в залах, либо найти нового тренера в приложении.
Заказчики знали, что мы специализируемся на MVP, и у нас был опыт разработки фитнес-приложений — проект FitForce.com. Проект им нравился, хотелось сделать что-то подобное. Мы быстро договорились об условиях и приступили к работе. Команду собрали из девяти человек.Каждой стороне свое: кому веб, кому мобильное фитнес приложение
Мы разрабатывали FitnessApp с нуля. У заказчиков уже был сайт, но он их не устраивал. Организовать процесс тренировки и общаться с тренером через сайт не очень удобно, другое дело — через мобильное приложение.
Чтобы уложиться в бюджет MVP, мы решили разбить проект на две части. Первая — веб-версия сервиса для тренера, вторая — мобильное фитнес приложение для клиента. Иными словами: не делать веб для обеих сторон и не делать мобилку для обеих сторон, потому что функциональность для каждой роли разная. Это было грамотным распределением ресурсов.
А вот теперь самое интересное: в этой части истории я расскажу, как мы рассчитали проект на 1200 часов, а потом поняли, что переоценили силы и недооценили проект.
На старте мы прикинули проект по фичам, которые должны были войти в MVP: получилось 1200 часов. Нам цифра показалась реальной, заказчика она тоже устраивала. Мы подписали документы и стартанули.
Разработчики и дизайнеры работали параллельно, и когда мы получили дизайн, поняли, что ошиблись в оценке: времени нужно больше. Мы подключили к проекту CTO Purrweb Сергея Пономарева. Он сделал переоценку, нашел рисковые моменты и насчитал работы на 2000 часов. Поэтому некоторые фичи пришлось вынести за рамки скоупа и согласовать как отдельные работы. Заказчик принял наши аргументы: после дизайна картинка наиболее четкая, кроме того — дизайн добавляет небольшой набор маленьких фич то тут, то там, поэтому сроки работы над проектом неизбежно увеличиваются.
Мы продолжили работу в нормальных сроках и с понятными дедлайнами. А еще настроили процесс оценки на будущее. Теперь у нас два правила:
Мы обсудили с клиентом фичи, которые он хотел бы видеть в мобильном фитнес приложении и в веб-версии. Со стороны тренера это:
Со стороны клиента это:
Поначалу мы хотели добавить в MVP систему мотивации: человек заносит свои метрики, видит прогресс, радуется (ну, или разочаровывается). Но потом подумали: человек платит тренеру деньги и должен сам за всем следить и все вносить? Поэтому решили вернуться к идее графика прогресса позже.
Хоть заказчик и упоминал наш предыдущий спортивный проект Fitforce.com, мы повторять дизайн не стали, только использовали как референс. Кроме того, к моменту работы над новым проектом, Fitforce уже слегка устарел, поэтому мы решили смотреть вперед.
На этапе дизайна созванивались с заказчиками два раза в неделю и показывали промежуточный прогресс. Быстро получали обратную связь и вносили правки.
Чем отличается этот проект от Fitforce? Дьявол в деталях:
Часто на этапе дизайна случается так: дизайнер готовит экраны, мы согласовываем их с заказчиком и отдаем в разработку… Но по факту разработать все, что спроектировал дизайнер не удается, что-то меняется и адаптируется по ходу проекта. Чтобы не терять время на такие моменты, мы ввели чек-лист важных моментов, которые часто забываются на этапе дизайна. На старте проекта разработчик проходится по нему и смотрит, все ли сделали.
Мы не хотели тратить много времени на тестирование и поиск багов, ведь нам нужно было уложиться в амбициозные 1200 часов. Построили работу так:
Таким образом каждый спринт был готов к демонстрации заказчику сразу после реализации, а мы не рисковали уткнуться в бесконечный багфикс в конце проекта. Благодаря этому уложились в три месяца.
Этапы разработки были такими:
В качестве языка программирования выбрали typescript. У typescipt строгая типизация, а значит у разработчика меньше свободы действий, что ведет к меньшему количеству багов. Мобильное фитнес приложение писали на React Native, веб — на React, бэк писали на Node.js, использовали фреймворк nest.js — на нем удобно писать изолированные модули и потом при необходимости использовать в других проектах заказчика. Все это наш стандартный стек.
Часть функциональности решили реализовать за счет сторонних сервисов, чтобы успеть в оговоренные сроки. Мы так часто делаем при работе над MVP, чтобы уложиться в бюджет и сроки. Мы применили:
Готовые решения занимают примерно пятую часть всего кода. Например, авторизацию можно написать самим и потратить на это 25 часов, но с сервисом можно сделать это за 5.
Мы доделали фичи, которые изначально не вошли в скоуп MVP и опубликовали приложение в App Store. Вот что мы сделали:
После релиза мы тестируем проект нашей внутренней командой, чтобы убедиться, что в продакшене все хорошо работает. Мы уложились в 1200 часов, хоть и некоторые фичи пришлось вынести за рамки первоначальной оценки. Но мы договорились с заказчиком и смогли обосновать, почему они должны реализовываться отдельно. Этот проект оказался хорошим “материалом” для отстройки и совершенствования наших процессов.
А как вы считаете, можно ли менять первоначальную оценку или «взялся за гуж, не говори, что не дюж»?
.svg)
%20(1)%20(1)%20(1).png)
