Наш подход к проектам

Жизненный цикл любого продукта состоит из трех фаз:

Основное

DISCOVERY фаза

Работа над любым проектом в POLYGANT начинается именно с этой стадии. Этот этап является обязательным и стоит 7 000 USD, занимая около 100 рабочих часов команды. В результате работы формируется комплект документации, описывающей будущее приложение:

• Спецификация (ТЗ)
• Мокапы экранов

На основе этих документов мы подготавливаем оценку стоимости и сроков реализации проекта, после чего отправляем её на согласование. Как только оценка утверждена, мы переходим к следующему этапу — DELIVERY.

⚠️ Мы не оцениваем проекты по стоимости и срокам без детальной спецификации, подготовленной нашими специалистами.

DELIVERY фаза

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

Мы используем методологию Agile с разделением на спринты, продолжительность одного спринта — 2 недели. В течение каждого спринта обновляется рабочая версия проекта, а наши клиенты могут в режиме реального времени наблюдать за процессом разработки и прогрессом своего продукта.

SUPPORT фаза

После того как продукт (или MVP) разработан и запущен, мы переходим к поддержке и доработке. Мы предлагаем платную поддержку и сопровождение всех проектов, созданных нашей командой, на неограниченный срок.

Важное

1. Наша команда работает с проектами трудоемкостью от 1 000 часов. Проекты меньшей трудоемкости, к сожалению, не интересны. 
2. Стараемся не брать проекты в режиме “должно быть готово вчера”, мы не будем работать в спешке. 
3. Всегда работаем по полной или частичной (не менее 50%) предоплате.
4. Не участвуем в тендерах и госзакупках.
5. Не работаем с чужим кодом и legacy, кроме случаев рефакторинга.

Стадия DISCOVERY

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

Спецификация проекта (также известная как «техническое задание» или «дизайн документ» в мобильных играх) – это именно то с чего необходимо начинать разработку любого продукта и это первое с чего начинаем мы.

⚠️ Без технического задания невозможно точно оценить стоимость и сроки разработки.

Мы начинаем с того, что формируем рабочую группу, в которую войдут:

• Представитель заказчика
• Проектный менеджер
• UI — проектировщик
• Аналитик

После этого мы согласовываем дату и время первичного звонка. В рамках первичного звонка мы выясняем как заказчик видит проект, его пожелания и проходимся по заранее подготовленным вопросам.

Документ готовится на платформе Google Docs, доступ к которому сразу предоставляется заказчику. Мокапы экранов готовятся в Figma.

Таким образом заказчик может в режиме реального времени следить за подготовкой документа, вносить в него коррективы и предложения.

⚠️ При необходимости в рабочую группу могут быть добавлены более узкие специалисты не только с технической, но и с юридической стороны.

Что такое Спецификация

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

В ТЗ, создаваемых специалистами нашей компании, мы зачастую включаем схемы экранов будущего приложения, что значительно упрощает восприятие.

Какие задачи решает Спецификация

• Сроки и стоимость —  важнейшее что интересует заказчика. ТЗ позволяет детализировать проект, проработать все нюансы, от которых может в значительной степени зависеть стоимость и сроки проекта.
• Синхронизировать понимание проекта между заказчиком и исполнителем. Очень часто это понимание может сильно отличаться и без проработанного ТЗ приводит к конфликтам.
• Определить пути решения сложных аспектов проекта.

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

Из чего состоит Спецификация (техническое задание)

У каждого технического задания своя структура, но в целом можно выделить основные разделы:

1. Описание проекта. Простыми словами объяснение что за продукт или сервис разрабатывается, для чего нужен, как работает.
2. Структура компонентов. Какие компоненты будут в проекте: backend, frontend, будут ли мобильные приложения, как они между собой взаимодействуют.
3. Технологический стек. Какие языки разработки будут использоваться, технические требования к программному обеспечению.
4. Юзкейсы. Сценарии использования приложения пользователями. В этом разделе может быть также карта экранов и мокапы ключевых экранов.
5. Безопасность и отказоустойчивость. Каким образом будет реализовываться защита от взлома, а также устойчивость к нагрузкам и масштабирование.

В среднем техническое задание занимает 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 часов и больше.