Ищете слаженную команду разработки?
Готовы помочь с дизайном и разработкой приложений для бизнеса и стартапов
Привет, я Антон Коломийчук, технический директор в Purrweb. Рассказываю о том, как не уронить перформанс команды, где только что ушел менеджер и разработать маркетплейс для фотографов
Забавный факт: доехал до Амстердама, чтобы попить пиво с заказчиком этого проекта быстрее, чем собрался с силами и таки оформил свои мемуары 🙂 В Амстер сейчас не сгонять, поэтому от души держите!
А история была такая.
В мае 2017-го нам прилетел запрос на проект от Домьена, маркетолога из Бельгии. Задача — разработать веб- и мобильное приложение для фотографов. Основная идея — дать фотографам новый способ продавать свои фотосессии. Вместо того, чтобы сначала продавать фотосессию, а потом снимать — делать наоборот.
Домьен — человек про маркетинг, в основном работал с товарными e-commerce площадками, разработка своего продукта — дело для него новое. Вариантов с кем пойти в разработку маркетплейса у него было несколько — почему выбрал нас? Глядя на проект ретроспективно, я рассуждаю так: уже на старте мы сильно заморочились с оценкой, хорошо вложились в переговорный процесс.
В то время нас в основном находили через фриланс-биржу Upwork. Это площадка c вариантами подрядчиков под самые разные задачи. Подешевле, подороже — выбираешь тех, кто подходит, и поехали.
Так вот, это был Upwork. Заказчик ничего не понимал в технологиях, мы же четко объясняли почему и что нужно сделать для создания маркетплейса для фотографов. Аргументировали почему оффер другой команды сделать «все и за дешево» не звучит как адекватная история. Много советовали: предлагали как сделать оплату, потому что он сам не думал об этом. Помогали решать вопросы, связанные с его бизнес-моделью — рассказывали про стоимость хранения фотографий, комиссии разных платежных систем. Домьен такую вовлеченность оценил и нанял нас.
О работе с «готовым» дизайном
На момент, когда Домьен пришел к нам в компанию, у него уже был готовый дизайн. Говоря точнее, у него было 300 каких-то экранов, из которых нужно было слепить работающий продукт.
Чтобы понять, насколько возможно сделать что-то внятное из уже существующей дизайн-версии, я решил досконально изучить каждый экран, попытался разбить все это на крупные функциональные блоки. Это была большая работа — я даже написал статью на эту тему.
По итогу вылезла куча несостыковок. Например, что дизайнер нарисовал список сообщений в мессенджере, но не сделал страницы отправки сообщения и страницы самого сообщения. Дизайнер не понимал, как будет работать получение денег фотографами за съемку от клиента через Daiokan, и нарисовал что-то совсем странное. В итоге эти экраны пришлось полностью переделать силами наших дизайнеров.
В итоге в работу мы взяли 100 экранов. Чтобы влезть в бюджет и сделать что-то рабочее, договорились следовать концепции MVP — оставить только самое важное. Конкретно для этого проекта «важным» был менеджер сессий (хранилище уже разбитых по клиентам фотографий), оплата и мобильное приложение. Всякие дополнительные штуки договорились закрывать по принципу «влезет/не влезет» — тот же блог и нотификации было легко отложить на следующий релиз.
Что такое Daiokan
Это маркетплейс, который помогает фотографам и клиентам найти друг друга
Логика работы такая:
— Фотограф регистрируется в веб-приложении и в оффлайне получает «форму».
Чтобы выделиться из толпы и найти желающих сфотографироваться
— Фотограф находит клиента. Далее с помощью мобильного приложения создает для него отдельную сессию (сюда попадут все снимки в рамках будущей фотосъемки) и указывает номер первого кадра. Один клиент — одна сессия. Провел за день 5 съёмок — создал 5 разных сессий.
— Камера, мотор! — Начинается фотосъемка. По завершению фотограф отметит последний кадр. Так, снимки разных клиентов не спутаются между собой.
— После съемки фотограф возвращается к веб-версии сервиса, куда загружает все отснятые кадры. Фотограф ранее создал сессии в мобильном приложении, поэтому справится за 5 минут.
— Фотограф отправляет клиенту ссылку на сессию. Клиент добавляет в корзину понравившиеся кадры и оплачивает покупку.
Рабочие процессы в команде
Проект по созданию маркетплейса для фотографов стартовал с менеджером, который вскоре перебрался в Москву. Оставались 3 разработчика, дизайнер, QA, я в роли project-лида и менеджер-новобранец. Короче, это была полноценная проектная команда.
Вот, что мы сделали, для того, чтобы всем было удобно:
Во-первых, после согласования с клиентом всех «отобранных» экранов, я распечатал ключевые flow: регистрацию фотографа, апрув фотографа админом и покупку фотографий.
Эти флоу стали нашими ближайшими ориентирами
Из-за пропавшего менеджера с приоритетами по началу было туго — в качестве решения мы договорились на старте брать любую задачу из сформированных флоу.
Установка была такая: какой бы задачей мы ни занялись — это точно будет полезно проекту
Во-вторых, расписали задачи по каждому флоу. Задачи по фронтенду были описаны в виде юзер-стори, по бэкенду — в свободной форме. Ключевой принцип — чтобы разработчики могли спокойно взять задачу сами, без необходимости выяснять, что там конкретно надо делать. Плюс, чтобы у задачи были явные границы — это сильно спасало на этапе оценки.
В-третьих, перебрались на Kanban Tool. С первым менеджером работа по проекту шла в Трелло.
Выглядело это примерно вот так
Я столкнулся с проблемой, что в Трелло неудобно планировать параллельную работу по разработке маркетплейса: фронтенд, бэкенд и верстку. Канбан Тул больше похож на классическую Канбан-доску, там не списки, а пространство — это сильно удобнее для визуализации.
Хоть выглядит Канбан Тул не так красиво, как Трелло, идея мониторить прогресс разработки маркетплейса там клиенту понравилась
В-четвертых, ввели ежедневные стендап митинги для обсуждения текущего прогресса, вопросов и проблем. Чтобы все это не скатилось в пустую болтовню, ввели дедлайн: 3 минуты на человека.
Плюс, мораторий на супер-технические темы, которые нужны не всей команде
По началу идея с митингами не была однозначно принята, однако по ходу проекта это стало отличным инструментом, позволяющим держать фокус команды на общей цели и синхронить работу на разных фронтах.
В-пятых, построили Extended Burn Down диаграмму, которая помогает предсказывать сроки.
Пример отчета для клиента
Для EBDC мы завели 2 практики: задачу, которую планируем делать, оцениваем очень детально, а большие функциональные блоки «на потом» — грубо.
А еще на этом проекте мы в первый раз протестировали недельные спринты. Сейчас наша команда так не работает, так как сильно много ежедневного напряга: чаще пингуешь клиента, чаще планируешь, куча отчетности. Короче, телодвижений много, но работает хорошо 🙂
Прием платежей
Домьену нужна была поддержка кучи разных валют и кредитных карт, поэтому мы изначально целились в PayPal.
По ходу работы над проектом выяснили следующее: mass payment PayPal’а работает только для зарегистрированных в США компаний. Клиент же решил оформить бизнес в Гонконге. Появилась проблема, которую нужно было как-то решить. Решили попробовать разные варианты их API.
Пока ковыряли API PayPal’а, поняли, что вариантов крайне мало: есть некий Payments API, который нормально работает только в Штатах и Канаде, хотя на сайте у них написано, мол, пишите и мы включим вас. Еще один вариант — Adaptive Payments API, которые также просят сперва писать их аккаунт-менеджеру. Оба способа, в целом, были так себе, потому как не позволяли аккумулировать деньги у нас на аккаунте PayPal. Но это были опции, которыми мы располагали.
Время на поиск решения резиновым не было — Домьен хотел как можно скорее запустить первых пользователей и показать им продукт. Уладить все непонятки с PayPal нужно было в течение 3-4 недель.
Мы решили сделать так: после того как клиент купил фото, а деньги попали на PayPal-счет компании, Домьен должен был вручную отправлять деньги фотографам — за минусом комиссии компании. Подход «ручками» помогал сильно ускорить ход работы и не вывалиться из обозначенных дедлайнов.
А теперь неожиданный поворот: в день, когда наша команда вышла тестировать оплату на живых деньгах, мы выяснили, что платежи с PayPal’а работали нормально, а вот поддержку кредитных карт через API PayPal убрал.
Решили попробовать Braintree, на тот момент этот сервис уже работал в Гонконге. Потратили время на интеграцию, попробовали получить продакшн ключи (чтобы начать сразу тестировать на живых деньгах) и Braintree нас заблокировали — сказали из-за того, что бизнес слишком рискованный. Никакие разговоры с ними, раскрытие бизнес-плана и бизнес модели делу не помогли. Вот такая подстава на самом финальном шаге.
Чем история закончилась: С Braintree у нас не пошло и мы выкатили MVP маркетплейса c PayPal’ом без кредитных карт, чтобы запуститься как можно раньше.
Почему не Stripe? Тут две причины:
- Во-первых, потому что, как сказали ранее, это был Гонконг. Во время работ по интеграции платежной системы Stripe Connect там не работал.
- Во-вторых, потому что была задача принимать платежи из как можно большего количества стран, а Stripe на тот момент был ограничен в Китае и Гонконге.
Что учесть при создании маркетплейса для фотографов?
Драматургии тут не будет, скорее сборная солянка из затыков и решений, к которым пришли по ходу работы над проектом.
Ограничения на загрузку фото
На одной из встреч с Домьеном я поделился опасениями по поводу того, что фотографы могут использовать сервис как бесплатное фото-хранилище. Изначально не были продуманы какие-либо ограничения на загрузку фото в портфолио, а потому такие ситуации вполне имели место быть.
По итогу решили сделать ограничение — 300 фото или 2 гб за одну сессию. Главная цель была — ввести это самое ограничение, пускай даже очень абстрактное. Прийти к какой-то более «осмысленной» цифре можно было и после релиза.
Блокировка фотографов
Так как это был маркетплейс, мы не могли просто так блокировать доступ человека к аккаунту. В блоке или нет, а ведь на платформе все еще продаются фото. Решили ввести запрет на создание новых сессий и загрузку новых фото.
Хранение фотоснимков
Хранить все фотосеты вечно — это было бы слишком дорого. Нужно было придумать какой-то механизм, который будет «чистить» фотографии спустя N-ное время. Договорились делать так: будем хранить файлы в течение года в Amazon S3, а потом удалять.
Инвойсинг
Выставление счетов работало так: деньги от клиентов приходили на банковский счет Дайокана. Чтобы навести прозрачность в денежных потоках, мы написали систему, генерирующую счета для клиентов, фотографов (когда выводят деньги) и Домьена (для понимания где прибыль, а что чужие деньги). Это была часть админки. С учетом работы в нескольких валютах — все это было очень интересно.
Апсейл покупателей
Ко второму релизу Домьен планировал, помимо фотографий, ввести продажу дополнительных товаров.
Кружек, подушек, плакатов
Поняли, что для печати и доставки этих товаров будет проще использовать сторонний сервис. Printful для MVP работал плохо — это только Штаты, доставка в Европу у них дорогая.
Присмотрелись к Text. Из минусов — у них нет билдера (конструктора для фотопечати), он был нужен для переноса фотоснимков на эти самые кружки-подушки. Просить их написать такой билдер самостоятельно — маловероятная история. Для понимания, что делать дальше, решили связаться с их командой.
Переговоры с ребятами из kite.ly дали нам следующее: нужно просто по шаблону собирать TIFF-файл (без слоев, альфа-каналов и сжатия) и отправлять на их приватный API. Это не звучало проблематично, но появилось 2 задачи: нужно было придумать, как сделать превью предметов и сам билдер. Из-за изменившихся планов Домьена завершить эту задачу нам не удалось — план действий придумали, поэтому если бы того требовала ситуация, точно дожали бы это дело до конца.
Что в итоге
Над Daiokan’ом мы трудились 8 месяцев. Веб- и мобильное приложение были готовы: все работало и работало хорошо. Вишенкой на торте стали $250 тысяч инвестиций, которые благодаря нашей работе удалось привлечь Домьену.
Чем все закончилось? Инвесторы привели свою команду, это были ребята из Беларуси. Мы связались с ними и благополучно передали оба приложения.
По ходу проекта Домьен перебрался в Лондон, а стартап переименовался из Diokan’а в Daiokan. В переводе с какого-то языка первое название звучало как что-то нелицеприятное — точная формулировка стала частью истории, которую я благополучно забыл 🙂 Думаю оно и к лучшему.
