Можно ли построить хороший дом без проекта и планов? Можно ли оценить стоимость его постройки без сметы? Конечно же нет, скажете вы. Действительно, если речь не о дачной избушке никому и в голову не придет строить дом без этапа проектирования.
В то же время при создании мобильных и веб приложений очень часто заказчики упускают такой важный этап как проектирование. Результатом становятся конфликты с разработчиками, разрыв ожиданий и в результате провал проекта, потерянные деньги и время.
Ниже мы расскажем как нам удается делать классные мобильные и веб приложения и попадать в ожидания наших клиентов.
Жизненный цикл любого продукта состоит из трех фаз:
Содержание
Основное
DISCOVERY фаза
Работа над любым проектом в POLYGANT начинается именно с этой стадии. Этот этап является обязательным и стоит 7 000 USD, занимая около 100 рабочих часов команды. В результате работы формируется комплект документации, описывающей будущее приложение:
Спецификация (ТЗ)
Мокапы экранов
На основе этих документов мы подготавливаем оценку стоимости и сроков реализации проекта, после чего отправляем её на согласование. Как только оценка утверждена, мы переходим к следующему этапу — DELIVERY.
⚠️ Мы не оцениваем проекты по стоимости и срокам без детальной спецификации, подготовленной нашими специалистами.
DELIVERY фаза
Разработка продукта ведётся строго по согласованной спецификации. Процесс работы обычно разделён на 3-4 этапа, каждый из которых имеет чёткие показатели готовности. Оплата также может осуществляться поэтапно.
Мы используем методологию Agile с разделением на спринты, продолжительность одного спринта — 2 недели. В течение каждого спринта обновляется рабочая версия проекта, а наши клиенты могут в режиме реального времени наблюдать за процессом разработки и прогрессом своего продукта.
SUPPORT фаза
После того как продукт (или MVP) разработан и запущен, мы переходим к поддержке и доработке. Мы предлагаем платную поддержку и сопровождение всех проектов, созданных нашей командой, на неограниченный срок.
Важное
Наша команда работает с проектами трудоемкостью от 1 000 часов. Проекты меньшей трудоемкости, к сожалению, не интересны.
Стараемся не брать проекты в режиме “должно быть готово вчера”, мы не будем работать в спешке.
Всегда работаем по полной или частичной (не менее 50%) предоплате.
Не участвуем в тендерах и госзакупках.
Не работаем с чужим кодом и legacy, кроме случаев рефакторинга.
Стадия DISCOVERY
Как хороший дом невозможно построить без проекта и чертежей, так и хорошее приложение невозможно разработать без детального описания.
Спецификация проекта (также известная как «техническое задание» или «дизайн документ» в мобильных играх) – это именно то с чего необходимо начинать разработку любого продукта и это первое с чего начинаем мы.
⚠️ Без технического задания невозможно точно оценить стоимость и сроки разработки.
Мы начинаем с того, что формируем рабочую группу, в которую войдут:
Представитель заказчика
Проектный менеджер
UI — проектировщик
Аналитик
После этого мы согласовываем дату и время первичного звонка. В рамках первичного звонка мы выясняем как заказчик видит проект, его пожелания и проходимся по заранее подготовленным вопросам.
Документ готовится на платформе Google Docs, доступ к которому сразу предоставляется заказчику. Мокапы экранов готовятся в Figma.
Таким образом заказчик может в режиме реального времени следить за подготовкой документа, вносить в него коррективы и предложения.
⚠️ При необходимости в рабочую группу могут быть добавлены более узкие специалисты не только с технической, но и с юридической стороны.
Что такое Спецификация
Спецификация (Техническое задание) это документ, который содержит детальное описание будущего продукта с различных сторон, концептуальной, стороны юзабилити и юзкейсов, технических требований.
В ТЗ, создаваемых специалистами нашей компании, мы зачастую включаем схемы экранов будущего приложения, что значительно упрощает восприятие.
Какие задачи решает Спецификация
Сроки и стоимость — важнейшее что интересует заказчика. ТЗ позволяет детализировать проект, проработать все нюансы, от которых может в значительной степени зависеть стоимость и сроки проекта.
Синхронизировать понимание проекта между заказчиком и исполнителем. Очень часто это понимание может сильно отличаться и без проработанного ТЗ приводит к конфликтам.
Определить пути решения сложных аспектов проекта.
Над Спецификацией обычно работают специалисты с наивысшей квалификацией и опытом в различных областях, это позволяет им видеть оптимальные решения там, где другие не могут.
Из чего состоит Спецификация (техническое задание)
У каждого технического задания своя структура, но в целом можно выделить основные разделы:
Описание проекта. Простыми словами объяснение что за продукт или сервис разрабатывается, для чего нужен, как работает.
Структура компонентов. Какие компоненты будут в проекте: backend, frontend, будут ли мобильные приложения, как они между собой взаимодействуют.
Технологический стек. Какие языки разработки будут использоваться, технические требования к программному обеспечению.
Юзкейсы. Сценарии использования приложения пользователями. В этом разделе может быть также карта экранов и мокапы ключевых экранов.
Безопасность и отказоустойчивость. Каким образом будет реализовываться защита от взлома, а также устойчивость к нагрузкам и масштабирование.
В среднем техническое задание занимает 20-40 страниц A4.
В конце технического задания, которое выполняют специалисты нашей компании, мы предоставляем расчет по стоимости и срокам выполнения проекта.
Стадия DELIVERY
После того как оценка по стоимости и срокам принята заказчиком, проект разделен на этапы и получена предоплата за первый этап, мы переходим к стадии DELIVERY.
В ранее созданную команду добавляются новые участники, как правило это:
2-3 Backend (Python) разработчика
2-3 Frontend (JS) разработчика — если речь про WEB приложение
2-3 Flutter разработчика — если речь по мобильное приложение
DevOPS
QA инженер
Дизайнер
Могут быть добавлены дополнительные специалисты, например Solidity — в зависимости от ТЗ.
В составе команды из 10-14 человек происходит планомерная разработка продукта. Спринт за спринтом он все сильнее обретает контуры и степень готовности.
Если фаза Discovery пройдена правильно и не возникает дополнительных работ или изменений, то с большой вероятностью мы уложимся и в сроки и в бюджет, что крайне редко случается на рынке.
Стадия SUPPORT
Когда основная часть разработки выполнена и MVP запущен, мы переходим в режим поддержки и доработок. Если доработок не очень много, мы обычно оставляем на проекте небольшую команду с частичным (25%) вовлечением:
Проектный менеджер
QA инженер
Backend разработчик
Frontend или Flutter разработчик
Devops
Если планируется много доработок и нового функционала, команда может быть расширена.
Также, если это предусмотрено контрактом, наши специалисты могут подготовить пользовательскую документацию и произвести обучение команды заказчика по использованию продукта.
Если по каким-то причинам заказчик отказывается от дальнейшей поддержки, после всех взаиморасчетов мы передаем исходный код и убираем команду с проекта, перенося ее на другие проекты.
В случае, если возникает запрос на внесение изменений в продукт нам потребуется пересобрать команду, это целесообразно только при масштабных доработках от 500 часов и больше.