Образец договора на разработку мобильного приложения

Договор на разработку мобильного приложения

Зачем нужен договор

У любого договора есть две функции — коммуникативная и юридическая. Коммуникативная помогает убедиться в том, что стороны правильно поняли друг друга. Они обсуждают условия работы, приходят к согласию и фиксируют эти договорённости на бумаге.

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

В чём особенность договора на разработку мобильного приложения

Разработка приложения — длительный и сложный процесс, на который влияет множество факторов как со стороны заказчика, так и со стороны исполнителя. Прописать все нюансы и учесть все риски в техническом задании невозможно. В ходе разработки появляются новые идеи, которые нужно учесть, меняются условия использования дополнительных сервисов, возникают технические проблемы, наступают кризисы. Это приводит к срывам сроков и изменению общей стоимости проекта.

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

Структура договора на разработку мобильного приложения

Договор на разработку мобильного приложения комбинирует два типа договоров — на оказание услуг (исполнитель работает над приложением) и на передачу права интеллектуальной собственности (заказчик получает результат чужого интеллектуального труда). Он состоит из десяти пунктов:

1. Предмет и основные условия. Что? Для кого? За сколько? В этом пункте договоритесь об обязательствах сторон, этапах работы, о процессе оплаты и об электронной подписи.

2. Расчёты. В этом пункте — про условия оплаты. Облагается ли она налогами? Когда считается завершённой? Нужно ли отправлять бумажную версию отсканированного счёта? Ответы должны устраивать обе стороны.

3. Сдача и приёмка работ. Пункт про то, как работа сдаётся исполнителем и принимается заказчиком. Помимо очевидных вещей, в пункте прописано как себя вести, если пошло не так: заказчик долго не выходит на связь с исполнителем или исполнитель предоставляет некачественный результат.

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

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

Пример. Вы разрабатываете мобильный мессенджер с платной подпиской. Чтобы сэкономить время, вы используете модифицированный код Telegram, который находится в открытом доступе. Согласно его условиям распространения, вы должны открыть финальный код своего приложения для всех.

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

6. Конфиденциальность. В этом пункте стороны договариваются о неразглашении информации, заказчик разрешает исполнителю опубликовать результаты работ в портфолио. Аналогичное соглашение подписывается с третьими лицами, если они участвовали в разработке.

7. Ответственность и обстоятельства непреодолимой силы. Что происходит, когда стороны не выполняют свои обязательства. В пункте — начисление неустоек за срыв сроков и порядок досудебного разбирательства с последующим обращением в суд. Вы избегаете ответственности только в том случае, если на вашу работу повлияли обстоятельства непреодолимой силы. Но без справки от компетентных органов в это никто не поверит.

8. Действие и расторжение. Про сроки действия договора, возможность его продления и расторжение. В пункте говорится, что о пожелании расторгнуть договор нужно предупредить за месяц, и описывается порядок досрочного расторжения.

9. Иные условия. В пункте — стандартные вещи про документооборот: договор действует на основании ГК РФ, а дополнительные соглашения являются его неотъемлемой частью.

10. Реквизиты. Здесь указываются актуальные данные заказчика и исполнителя: адреса, налоговые идентификаторы, номера счетов, ставится дата и подпись.

Готовый договор от «Лайв Тайпинга»: скачайте и начните разработку сейчас

Компания «Лайв Тайпинг» не любит бюрократию, но любит делать свою работу хорошо. Нам важно, чтобы сотрудничество было в кайф обеим сторонам. Поэтому начинать каждую сделку мы решили с понятного и прозрачного договора, который защищает обе стороны от рисков. Мы разработали шаблон договора вместе со специалистами Центра Управления Законом — они делают документы без воды и мусора. Наш шаблон написан человеческим языком, который понимают . Он максимально короткий — 4 страницы, и в них нет места для двусмысленности и заковыристых конструкций.

Работать с шаблоном от «Лайв Тайпинг» несложно: в нём есть интерактивное оглавление, с которым вы быстро просмотрите все разделы. Наш договор — рамочный, в нём прописаны общие правила и обязанности сторон, а договорённости и детали по конкретному проекту вам придется самостоятельно зафиксировать в дополнительных соглашениях. Вы найдете их под основным документом. В приложениях также есть шаблоны технического задания.

Чтобы получить готовый договор, вам нужно:

  1. Скачать шаблон договора на разработку мобильного приложения.
  2. Выбрать дополнительное соглашение, которое подходит для вашего типа сотрудничества.
  3. Заполнить допсоглашение конкретными деталями по вашему проекту (техническое задание, , текстовое описание проекта, смета, ).
  4. Заменить данные в желтых полях на реальные данные заказчика и исполнителя.
  5. Согласовать договор с партнёром.

Какое дополнительное соглашение выбрать

Допсоглашения конкретизируют условия рамочного договора. Их основная задача — во всех деталях описать то, что клиент хочет получить от студии по итогу работы. Наш договор предусматривает три варианта шаблонов дополнительных соглашений, подходящих для разных видов сотрудничества:

1. Fixed price. Заказчик покупает законченный продукт или его часть. Например: создание кликабельного прототипа приложения, разработку дизайна мобильного приложения или разработку приложения под iOS целиком с нуля. Это доспоглашение описывает этапы работы с фиксированными ценой и сроками. Вариант Fixed price подходит для работы над простыми проектами с понятной функциональностью, чётко прописанной в ТЗ. Выход за рамки ТЗ с сохранением прежних сроков и стоимости работы невозможен. Если заказчик хочет на лету менять требования и не зависеть от ТЗ, то лучше выбрать более свободную модель оплаты.

2. Time&Materials. Заказчик платит за время специалистов, потраченное на работу над его проектом. Круг задач и стоимость часа работы оговариваются в допсоглашении. Например, клиенту нужно создать приложение для iOS. Для этого нужны менеджер проекта, дизайнер, разработчик и тестировщик. В течение месяца эти специалисты трудятся на проекте, а в конце месяца клиент получает отчёт о количестве затраченных часов и оплачивает их. Этот вид сотрудничества хорош тем, что клиент гораздо быстрее видит результат и может вносить изменения в процессе. Этот вариант подходит для долгосрочных проектов.

Лучше разобраться в тонкостях Fixed price и Time&Materials вам поможет наша статья.

3. Time&Materials period (он же Retainer). Данная практика пришла в ИТ из юридического бизнеса. Заказчик «оптом» выкупает всю команду, нужную для ведения проекта, на долгий срок. Период, состав команды и цена фиксируются в допсоглашении. Оплата и приём работ происходят раз в месяц/неделю. Это самый эффективный вариант работы над проектом, потому что в нём не нужно бесконечно подписывать документы, скрупулёзно считать часы и согласовывать каждый шаг. В начале периода заказчик и разработчик составляют план работ, в конце — подводят итог и фиксируют результаты, подписывая акт, который передаёт клиенту права на сделанные работы. Одновременно он является актом приёмки этих работ. Способ подходит для сложных и долгосрочных проектов, на которых важна полная вовлечённость всех участников команды.

Читайте также  Судебный пристав янао алексанова алина юрьевна

Максимально подробно договоритесь о всех условиях до начала разработки приложения. Убедитесь, что договор защищает вас и покрывает возможные риски, чтобы не возвращаться к нему в дальнейшем. Юридическая безопасность и доверие между сторонами сделают работу над приложением быстрой и спокойной. Кстати, у «Лайв Тайпинга» за 10 лет работы не было ни одного суда. Хотите разработать ваше мобильное приложение без нервов и юридических споров? Заполняйте нашу контактную форму или звоните .

Договор на разработку мобильного приложения или сайта. Часть 1

Эта статья будет полезна тем, кто задумался о разработке мобильного приложения или сайта и уже начал искать подрядчика. На рынке существует множество разработчиков. Критерии выбора подрядчика могут быть любые. Я поделюсь с вами некоторыми соображениями, которые могут вас защитить, независимо от того, с кем вы будете работать.

В статье я постараюсь ответить на вопросы:

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

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

А теперь поговорим о договоре. Содержание договора может рассказать о компании больше, чем любая презентация. Чтобы было предельно понятно, проведу аналогию:

С чего начать?

Сначала обратите внимание на конструкцию пакета договорных отношений. Лучше всего придерживаться общепринятых международных практик. Без учета нюансов, договор международного образца будет выглядеть следующим образом:

Далее подробнее рассмотрим каждый элемент схемы, разберем, за что они отвечают, и на что обратить внимание.

Договор или Соглашение на оказание услуг (Service Agreement – SA) – большой документ, который содержит все основные условия сотрудничества. «Рамочный» означает, что договор предусматривает максимально возможные виды услуг и способы взаимодействия сторон. Это позволяет не согласовывать новые условия на каждый новый чих, что очень удобно и экономит много времени всем сторонам.

В теле договора обязательно надо обратить внимание на следующие моменты:

Перечень возможных услуг.
Укажите все: проектирование мобильных приложений, разработка под IOS и Android, поддержка и сопровождение, продвижение и другие услуги, согласованные сторонами. Такая формулировка позволит избежать необходимости согласовывать новые договора.

Условия сотрудничества.
Укажите, как определяется и что означает оплачиваемая ставка, из чего состоит и как формируется фиксированная цена. Это упростит сотрудничество по разным услугам. Проектирование – по фиксированной цене, разработка – по ставке и т.п.

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

Конфиденциальная информация.
Даже если у вас уже подписано соглашение о неразглашении (Non-disclosure agreement – NDA). Определите, что входит в понятие «конфиденциальная информация», обязательно со ссылкой на закон конкретного государства, в рамках правового поля которого вы заключаете договор.

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

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

Тут есть один простой и довольно эффективный лайфхак, – если договор меньше 10 страниц, то, скорее всего, он не отражает многих важных моментов.

В следующей статье рассмотрим, что такое Заказ на услугу (Work Order – WO), зачем нужны Соглашение об уровне услуг (Service Level Agreement – SLA) и Состав услуги (Service Design Package – SDP).

Договор на разработку сайта/мобильного приложения при работе по scrum

Людям, не искушенным в документообороте, этот текст может показаться довольно запутанным. А тем, для кого оформление контрактов — рутина, наоборот, слишком простым. Но нас часто спрашивают, как у нас организована работа по scrum с точки зрения документооборота, и как выглядят наши договоры.

Даже если вам покажется, что получается слишком много бумаг, или всё слишком сложно — это не так. Мы используем простые и понятные контракты, в которых проработаны интересы как клиента, так и студии. Адекватно. Без перегибов. На уровне здравого смысла. Моя политика простая — либо win-win, либо не связываться.

Наши шаблоны договоров рассчитаны в первую очередь на работу по scrum . То есть на итеративную разработку, когда проект запускается поэтапно. Сначала — самые важные с точки зрения бизнеса функции. С которыми уже можно жить и обеспечивать продажи. Затем системно выпускаются новые версии. Состав работ можно менять на ходу — что-то убирать, добавлять или заменять на равноценные функции. Это позволяет заказчику проверить свою бизнес-идею и запустить самое важное как можно быстрее. Поэтому мы подписываем с заказчиком рамочный договор, где фиксируем общие условия сотрудничества. Принципы. То, на чем пожали руки. На отдельные этапы работ мы подписываем приложения к договору.

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

Если вы пользуетесь нашими шаблонами образца 2015 года — обратите внимание, что новые шаблоны приложений совсем не совместимы с ними. Чтобы начать пользоваться новыми шаблонами, обязательно перезаключите рамочный договор с заказчиком.

Подготовка договоров и приложений

В начале работы над проектом вместе с рамочным договором мы подписываем приложение на агрегацию требований .

Мы исходим из предпосылки, что ни клиент, ни мы сами точно не знаем, как и в каком виде лучше всего сделать проект. И нужно выполнить предпроектную работу:

  • выделить стейкхолдеров, составить цели проекта, если возможно — оцифровать в виде KPI;
  • изучить пути пользователей по сайту;
  • поработать с семантикой или, используя метод персон, определиться с наиболее важными функциями.

Эта работа стоит денег, но она — относительно дешевая. Заказчику психологически проще оплатить первый счет, когда он в пределах 24-60 часов. К тому же только после этапа агрегации требований у нас появляется согласованная структура, верхнеуровневый roadmap будущего проекта: мы можем уточнить список страниц, которые необходимо прототипировать.

Вторым этапом мы подписываем приложение на разработку прототипов страниц, и, если этого просит клиент, — технического задания. В классическом scrum-е технического задания не предполагается, вместо него используется бэклог — список всех хотелок, которые клиент хочет когда-нибудь реализовать. Однако многие по старинке хотели бы иметь такой документ. Проблем нет, мы его готовим, причем именно с той целью, чтобы затем раздербанить на бэклог. Наличие технического задания на проекте не заставляет нас строго следовать его букве. Конечный состав работ определяется СМЕТАМИ в приложениях на каждый отдельный спринт.

Далее нам нужно собрать первую версию программного продукта. От которой будем дальше плясать и итеративно развивать во что-то более глобальное. Замечу, что первая версия должна быть функциональной. Она должна быть «клёвенькая», а не полуфабрикат, на который жалко смотреть. Тут — работает, тут — не работает, тут — рыбу заворачивали. Такая версия может быть разработана за несколько спринтов. То есть не факт, что итог первого же спринта пойдет реальным пользователям на боевой сервер. Это несколько противоречит концепции scrum образца 2000-го года, но лучше вписывается в современные подходы и адекватнее воспринимается разработчиками и заказчиками.

Читайте также  Как узнать на какой штрафстоянке стоит машина

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

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

В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций). Это позволяет добиться высокой утилизации, но довольно сложно управляется. Нагрузка высокая, причем на менеджера и со стороны студии, и со стороны заказчика. Много бумаг, много потоков, много нужно держать в голове. Но это цена за точные оценки сроков и бюджетов, их фиксацию в договоре и высокую скорость работ.

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

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

Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:

  • Использовать единые шаблоны договоров. Каждый новый договор мы обязательно делаем из шаблона, а не из договора от предыдущего заказчика. Чтобы руководителям проектов было проще при подготовке документов, места, которые могут меняться, выделены в цветом.
  • Править шаблон сразу, если обнаружили в договоре какую-то нестыковку или неожиданный нюанс (которым, естественно, больно прилетело по лбу). Так важные изменения в договорах гарантированно будут тиражироваться по всем последующим документам.
  • Периодически проводить ревизию шаблонов и актуализировать их. Мы обычно делаем это один-два раза в год.
  • Не отправлять договоры заказчикам без дополнительной проверки. При проверке приложений дополнительно надо обращать внимание на сроки, сверять все строки сметы, пересчитывать итоговые суммы.

Подробный кейс читайте в блоге scrum-студии «Сибирикс» — https://blog.sibirix.ru/2017/07/12/contract-2017/ .

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

Особенности разработки мобильного приложения для службы доставки: кейс B2B-сервиса Cargo

Время чтения: 6 минут

На примере B2B-сервиса Cargo рассказываю о проблемах, с которыми сталкивается команда, когда разработка мобильного приложения для доставки начинается после подписания договора с клиентом, и объясняю как с этими проблемами справиться.

Кто из стартаперов не мечтал о том, чтобы получить первых клиентов еще до релиза приложения или сервиса? Кажется, что это гораздо надежнее и перспективнее, чем запускаться в условиях неопределенности, однако все не так однозначно. Например, в B2B-сегменте подобная стратегия требует очень грамотного управления продуктом, в противном случае есть риск не оправдать ожидания клиента.

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

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

Продажа еще не готового мобильного приложения для доставки происходит с помощью дизайн-концептов и кликабельных прототипов, которые демонстрируют эффективное решение боли рынка. Однако в отличие от инвесторов, клиенты не готовы рисковать и ждать годами релиза, поэтому они купят только те сервисы, которые через 2-4 месяца будут как минимум стабильно работающими MVP (Minimum Viable Product).

Наш кейс начался с того, что стартапер Gurpreet Jajj из Арабских Эмиратов обратился в Purrweb за дизайн-концептом мобильного приложения для службы доставки. П ланировалось, что решение будет оптимизировать логистику в малом и среднем бизнесе: например, в интернет-магазинах, ресторанах, прачечных. Мобильное приложение для доставки должно было стать приложением-шаблоном (White Label), которое органично интегрируется в бизнес-процессы клиентов, делая доставку по городу прозрачной и эффективной.

Дизайн-концепт​

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

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

Разработка на максимально допустимых скоростях: угрозы и правила безопасности

Мобильное приложение для доставки: планирование и приоритеты

В разработке мобильного приложения для доставки по сценарию «вначале продажа — потом продукт» необходимо грамотное планирование и расстановка приоритетов. Причем приоритеты важнее, потому что даже идеальное планирование не спасает от ситуаций, когда заказчик в середине спринта приходит с новыми идеями и «хотелками». Двигать сроки нельзя, игнорировать пожелания — тоже не вариант.

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

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

Основной флоу: главный экран, второй, маршрутный лист

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

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

Читайте также  Можно ли получить права досрочно

Дополнительный флоу: электронная подпись, профайл

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

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

Frontend driven development: первым делом интерфейсы

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

Чтобы оптимизировать наше взаимодействие с командой бэкенд-программистов, мы решили работать по принципу frontend driven development. Так как главное преимущество нашего приложения — пользовательские сценарии, вначале мы делали клиентскую часть, и только потом серверную. Именно мы решали, когда и какие запросы отдавать на сервер, и определяли структуру ответа.

Одна из самых сложных задач в разработке мобильного приложения для доставки — составление маршрута

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

​ Экран навигатора

Минимализм — не только про чистоту и воздух

При дизайне интерфейсов приложений формата White Label надо учитывать, что сервис должен легко мимикрировать под любой брендинг. Фактически приложение White Label — это шаблон приложения, но данный факт не должен сказывается на дизайне, более того, сжатые сроки — не повод жертвовать визуальной составляющей. Чтобы интерфейсы не выглядели, как заготовка, а само приложение было живым и ярким, мы много внимания уделили деталям. Например, даже неинформативный полупустой экран «Отсутствие заданий» мы сделали гармоничным и сбалансированным за счет аккуратной иконки.

Экран отсутствия заданий

Есть и другие нюансы при работе с приложениями White Label: они касаются цветовой гаммы. Традиционное решение — продумать систему из основных и дополнительных цветов, которые будут меняться на фирменные цвета из брендбука клиента.

Но из-за сжатых сроков мы выбрали более простой путь и сформировали максимально универсальную, при этом логичную палитру. Акценты мы расставили с помощью «светофорных» цветов, интуитивно понятных каждому водителю. Зеленый — операция прошла успешно, действие одобрено, а красный — ошибки и недоступные элементы.

Цветовая палитра

Ручное тестирование

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

В нашем случае основная сложность опять же заключалась в навигаторе: для его проверки тестировщикам пришлось не раз выбираться из офиса и гулять по окрестностям. Чтобы избежать багов мы выделили на эту задачу дополнительные ресурсы и в целом потратили больше времени, чем обычно. Но все равно меньше, чем на написание тестов.

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

React Native

Для попадания в дедлайны и обеспечения стабильной работы приложения, крайне важна скорость исправления багов. Именно поэтому весь фронтенд мы решили делать на React Native: несмотря на предубеждения, этому фреймворку практически нет равных в создании кроссплатформенных приложений с красивыми адаптивными интерфейсами в кратчайшие сроки.

К React Native много претензий со стороны разработчиков из-за ряда сложностей с поддержкой библиотек и зависимостей. Однако мы давно работаем с этим фреймворком и научились справляться с его ограничениями и недостатками. В данном случае для навигатора мы использовали готовую открытую библиотеку MapBox, которая после небольшой отладки стала четко и стабильно работать.

Новый уровень: один клиент хорошо, а три — лучше

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

Наш MVP пережил испытание масштабированием: выбранный технологический стек (React Native, Realm, Mapbox) позволил успешно развивать сразу несколько версий приложения. А сам сервис стал популярным решением, которое сейчас предлагается в рамках линейки продуктов IT-компании Illuminate Software Solutions.

Образец договора на разработку мобильного приложения

В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций). Это позволяет добиться высокой утилизации, но довольно сложно управляется. Нагрузка высокая, причем на менеджера и со стороны студии, и со стороны заказчика. Много бумаг, много потоков, много нужно держать в голове. Но это цена за точные оценки сроков и бюджетов, их фиксацию в договоре и высокую скорость работ.

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

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

Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:

  • Использовать единые шаблоны договоров. Каждый новый договор мы обязательно делаем из шаблона, а не из договора от предыдущего заказчика. Чтобы руководителям проектов было проще при подготовке документов, места, которые могут меняться, выделены в цветом.
  • Править шаблон сразу, если обнаружили в договоре какую-то нестыковку или неожиданный нюанс (которым, естественно, больно прилетело по лбу). Так важные изменения в договорах гарантированно будут тиражироваться по всем последующим документам.
  • Периодически проводить ревизию шаблонов и актуализировать их. Мы обычно делаем это один-два раза в год.
  • Не отправлять договоры заказчикам без дополнительной проверки. При проверке приложений дополнительно надо обращать внимание на сроки, сверять все строки сметы, пересчитывать итоговые суммы.

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

Сам документооборот в студии и другие шаблоны и регламенты мы разбираем в нашем с Теглайном курсе управления digital-проектами. Присоединяйтесь!