Можно ли построить долговечный дом без проекта и чертежей? Можно ли оценить стоимость его постройки без сметы? Конечно, нет. Действительно, если речь не о дачной избушке, никому не придёт в голову идея строить дом без проектирования.
В то же время заказчики мобильных и веб-приложений часто упускают такой важный этап, как проектирование. Из-за этого возникают конфликты с разработчиками, разрыв ожиданий, в результате — провал проекта, потерянные деньги и время.
Мы расскажем, как нам удаётся делать классные мобильные и веб-приложения и оправдывать ожидания наших клиентов.
Жизненный цикл любого продукта состоит из трёх стадий:
Содержание
Стадия Discovery
В Polygant работа над любым проектом начинается с этой обязательной стадии. Она занимает около 100 рабочих часов команды и стоит 7000 USD. В результате работы формируется комплект документации, описывающей будущее приложение:
спецификация (ТЗ);
мокапы экранов.
На основе этих документов мы подготавливаем расчёт стоимости и сроков реализации проекта, затем отправляем её на согласование заказчику. Как только он утвердит расчёт, мы переходим к стадии Delivery.
⚠️ Мы не оцениваем стоимость и сроки проектов без детальной спецификации, подготовленной нашими специалистами.
Стадия Delivery
Разработка продукта ведётся строго по согласованной спецификации. Процесс работы обычно разделяется на 3–4 этапа, каждый из которых имеет чёткие показатели готовности. Оплата тоже может проводиться поэтапно.
Мы используем методологию Agile с разделением на спринты продолжительностью по 2 недели. В течение каждого спринта обновляем рабочую версию продукта, а наши клиенты могут наблюдать за процессом разработки и прогрессом проекта в реальном времени.
Стадия Support
После того как мы разработали и запустили продукт (или MVP), переходим к поддержке и доработке. Мы предлагаем платную поддержку и сопровождение всех проектов, созданных нашей командой, на неограниченный срок.
Принципы работы нашей команды
Работаем с проектами трудоёмкостью от 1000 часов. Не берёмся за проекты меньшей трудоёмкости.
Стараемся не брать проекты, которые «должны быть готовы вчера», поскольку не можем работать в спешке.
Всегда работаем после полной или частичной (не менее 50%) предоплаты.
Не участвуем в тендерах и госзакупках.
Не работаем с чужим кодом и legacy, кроме заказов рефакторинга.
Подробнее о стадии Discovery
Как хороший дом невозможно построить без проекта и чертежей, так и хорошее приложение невозможно разработать без детального описания.
Спецификация проекта, также известная как техническое задание (ТЗ) или дизайн-документ в мобильных играх, — это то, с чего необходимо начинать разработку любого продукта. И это первое, с чего начинаем мы.
⚠️ Без технического задания невозможно точно оценить стоимость и сроки разработки.
Сначала мы формируем рабочую группу, в которую войдут:
представитель заказчика;
проектный менеджер;
проектировщик пользовательского интерфейса;
аналитик.
После этого мы согласовываем дату и время первичного звонка. В ходе него мы выясняем, как заказчик видит проект и что желает, и проходимся по заранее подготовленным вопросам.
Мы готовим документ в Google Docs, доступ к которому сразу предоставляем заказчику. Мокапы экранов готовим в Figma. Так заказчик может следить за подготовкой документа в реальном времени, вносить в него коррективы и предложения.
⚠️ При необходимости мы можем добавить в рабочую группу более узких специалистов не только по технической, но и по юридической части.
Что такое спецификация
Спецификация, или ТЗ — это документ, который содержит детальное описание будущего продукта с различных сторон: концептуальной, стороны юзабилити и юзкейсов, технических требований.
В создаваемые ТЗ наша компания зачастую включает схемы экранов будущего приложения, что значительно упрощает восприятие.
Какие задачи решает спецификация
ТЗ позволяет детализировать проект, проработать все нюансы, от которых могут сильно зависеть стоимость и сроки. А они интересуют заказчика больше всего.
Синхронизировать понимание проекта между заказчиком и исполнителем. Часто это понимание может существенно различаться и без проработанного ТЗ приводить к конфликтам.
Определить пути решения сложных аспектов проекта.
У нас ТЗ разрабатывают специалисты высшей квалификации, с опытом в различных областях. Они способны увидеть оптимальные решения там, где другие не могут.
Из чего состоит спецификация
У каждого ТЗ своя структура, но можно выделить 5 основных разделов:
Описание проекта. Простое объяснение, что за продукт или сервис разрабатывается, для чего нужен, как работает.
Структура компонентов. Какие компоненты будут у продукта: бэкенд, фронтенд, мобильные приложения; как они будут взаимодействовать.
Технологический стек. Какие языки программирования будут использоваться, технические требования к программному обеспечению.
Юзкейсы. Сценарии использования приложения пользователями. В этом разделе также могут быть карта экранов и мокапы ключевых экранов.
Безопасность и отказоустойчивость. Как будут реализовываться защита от взлома, устойчивость к нагрузкам и масштабирование.
В среднем ТЗ занимает 20–40 страниц A4. В конце него наша команда предоставляет расчёт стоимости и сроков выполнения проекта.
Подробнее о стадии Delivery
После того как заказчик примет оценку стоимости и сроков, проект разделится на этапы и поступит предоплата за первый этап, мы переходим к стадии Delivery.
Добавляем в ранее созданную команду новых участников, как правило:
2–3 бэкенд-разработчиков (Python);
2–3 фронтенд-разработчиков (JavaScript), если нужно веб-приложение;
2–3 Flutter-разработчиков, если нужно мобильное приложение;
DevOps;
QA-инженера;
дизайнера;
дополнительных специалистов, например Solidity-разработчика, в зависимости от ТЗ.
Команда из 10–14 человек планомерно разрабатывает продукт. Спринт за спринтом он всё сильнее обретает контуры и степень готовности.
Если стадия Discovery пройдена правильно и не возникает дополнительных работ или изменений, то с большой вероятностью мы уложимся и в сроки, и в бюджет. Хотя такое редко случается на рынке.
Подробнее о стадии Support
Когда основная часть разработки выполнена и MVP запущен, мы переходим в режим поддержки и доработок. Если доработок не очень много, то мы обычно оставляем на проекте небольшую команду с частичным (25%) вовлечением:
проектного менеджера;
QA-инженера;
бэкенд-разработчика;
фронтенд- или Flutter-разработчика;
DevOps.
Если планируется много доработок и новых функций, то мы можем расширить команду.
Также, если это предусмотрено контрактом, специалисты Polygant могут подготовить пользовательскую документацию и обучить команду заказчика использовать продукт.
Если заказчик отказывается от дальнейшей поддержки, после всех взаиморасчётов мы передаём исходный код и переводим команду из этого проекта в другие. А если он запросит внести изменения в продукт, нам придётся пересобрать команду. Такое целесообразно только при масштабных доработках на более 500 часов.
Телеграм 
WhatsApp
WhatsApp
