Как мы делали билетный агрегатор

Написал статью про наш опыт разработки билетного сервиса - наши ошибки, выводы, советы. На связи КОД9🤙

https://vc.ru/dev/754196-agregator-biletov-v-ssha-kotoryy-proshel-techstars-kak-my-ego-delali-i-chto-sdelali-ne-tak

Кроме разработки, в этом кейсе есть еще непростая история нашего партнерства с европейски (испанскими) фаундерами.

Обязательно про это расскажу потом. Stay tuned.

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

Быстро стало понятно, что в агентском бизнесе тут очень активное сообщество — есть с кем пообщаться. Это мы и решили делать и запустили свой подкаст «Код за деньги».

Я буду приглашать коллег — основателей и директоров других студий, чтобы расспросить у них про бизнес и про то, как его развивать.

Хочется пообщаться со студиями разных размеров и получить что-то вроде библиотеки полезных практик: growth-лайфхаки, операционка, продажи, найм, создание бренда и культуры, пиар и маркетинг — у каждой студии найдется ценный опыт для рынка (потом напишу книгу и буду всех консультировать :)

Зацените, подпишитесь, критикуйте и приходите в гости:

Вот ссылка на Ютуб — https://youtu.be/DheToFAjm7A

Вот выжимка основных тейков, кому тяжеловато смотреть Ютуб — https://vc.ru/code9/756940-polovina-lidov-ot-partnerov-esli-v-dengah-eshche-bolshe-klyuchevye-mysli-iz-podkasta-s-ceo-agentstva-alto

Про биздев

Развивать бизнес это значит зарабатывать больше денег. Для этого есть 2 пути:

1) Искать новых клиентов
2) Увеличивать прибыль за счет текущих клиентов

Бизнес - это решение проблем за деньги. Будучи любопытным, можно увидеть массу дополнительных проблем, которые клиент (сюрпрайз) будет рад решить с вашей помощью. Кроме этого, решая все новые и новые проблемы своего клиента, вы в каком-то плане получаете vendor lock, только вендор - это вы!

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

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

Очень широкая тема и еще напишу про это.

Искать новых клиентов тоже надо nevertheless.

Написал про любопытство и вспомнил эту цитату мастера.

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

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

А без любопытства агентский бизнес становится скучным.

Про ремесло

Программирование это творческая профессия, но это и ремесленная профессия.

И тут работают все ремесленные правила:

1. Нужен наставник, чтобы быстро расти. А еще лучше, чтобы была команда.
2. Нужна практика
3. Сложность практики должна постепенно повышаться
4. Не должно быть длительного перерыва в практике

В противном случае наступает профессиональная стагнация.

Это все нужно учитывать при формировании команд разработки.

---

Интересно понять, какие правила из творческих профессий работают в программировании.

Про время и коммуникацию

Читаю Друкера "Эффективный руководитель"

“… хороший руководитель всегда стремится к консолидации, укрупнению своего дискреционного времени. Он понимает, что для решения творческих задач ему необходимы крупные блоки времени, потому что мелкие нельзя использовать эффективно. Установлено, что даже четверть рабочего дня, сгруппированная в крупные временные блоки, может быть достаточной для выполнения важной работы. И наоборот, три четверти рабочего времени могут быть потрачены совершенно безрезультатно, если раздроблены на блоки по пятнадцать-тридцать минут.”


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

Мы стараемся минимизировать кол-во стендапов и синхронной коммуникации в наших командах.

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

Но есть минимальный трешхолд:

а) в команде нет джунов
б) в команде нет новых сотрудников, т.е. команда сработалась

Понятно, что есть 37signals которые только текстом общаются. Мы сделали стендапы 3 раза в неделю в одной из команд - все норм.

Developer Experience (DevEx, DX)

DevEx это про то, насколько удобно работать разработчику.

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

- Базовая техническая документация
- CI/CD
- Четкий воркфлоу (как называть ветки в гите, кто смотрит PR, как часто, и т.п.)
- Качественная IDE
- Автотесты

В крупных компаниях есть отдельные команды, которые занимается DX.

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

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

Ну и можно постараться продать DX-настройку заказчику 😎

Блюр фона в зуме

Если ваш собеседник блюрит фон в зуме - значит ему есть что скрывать. Синк эбоут ит.

Процесс vs Задача

Прежде чем запускать что-то в работу, полезно понять - это будет задача или процесс.

Задача значит, что ее нужно один раз сделать и забыть. Такая ad-hoc штука.

А процесс это что-то, что будет делаться постоянно/регулярно. А если так - то хорошо бы сразу сделать необходимую инфраструктуру для поддержания процесса:

- админ ресурс или ответственный
- участники процесса
- регулярные синки/звонки с повесткой
- место для сбора артефактов процесса (ноушен, вики?)

Если запустить процесс без этих штук, то он быстро развалится и у всех останется неприятное послевкусие. 🙃

У нас в агентстве такое иногда бывает.

Как писать требования

В 17 году я написал статью для Smashing Magazine -- How To Write Mobile Application Requirements That Work.

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

1. Сделать общее описание идеи в паре предложений.
2. Написать, какие шаги будут внутри приложения у пользователя. Такой Customer Jorney Map, но на словах.
3. Посмотреть на конкурентов. Использовать эти референсы в описании своих требований.
4. Не сильно фокусироваться на деталях, чтобы не раздувать документ. Описывать только ключевые моменты.
5. Описать приоритеты. Что более важно, что менее важно.
6. Сделать варефреймы. Составить из них карту экранов.
7. Собрать все это вместе.
?????
8. PROFIT

Перечитал оригинал и думаю что это все еще актуально. Fun fact: smashing платит за все статьи, так что мне еще заплатили около $100.

Полная статья тут: https://www.smashingmagazine.com/2017/05/writing-mobile-application-requirements/

Про комфортный процесс для клиента

Чтобы клиент долго работал с агентством, нужно чтобы ему было комфортно. Для этого нужно:

1. Внимательно слушать, что говорит клиент. Слушать и вникать.

2. При начале работы, быстро показывать первый результат. Если нечего быстро показывать, все равно придумать, перестроить процесс и что-то показать. Это уберет очень сильный страх на стороне заказчика.

3. Быть на связи и подробно рассказывать о своей работе. Важно, чтобы клиент понимал, что происходит.

4. По дороге не менять главное контактное лицо.

5. Работать по time & material.

Это если коротко. 

Подробно написал в статье на VC: https://vc.ru/life/794780-klientu-didzhital-agentstva-dolzhno-byt-komfortno-kak-eto-sdelat-14-let-opyta-5-pravil-raboty

Про партнерские программы

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

Свои публичные партнерские программы есть у всех основных крупных агентств (Агима, Глобус и т.д). А непубличные - наверное у половины всех игроков.

При этом есть агентство-заказчик (отдает заказ), и агентство-подрядчик, которое забирает заказ и делится процентом (обычно 15-25% от бюджета).

Для чего это вообще нужно? Несколько основных причин:

- В заказной разработке нагрузка на ресурсы меняется во времени. В какой-то момент ваши разработчики могут быть незагружены (т.е. простаивать и сжигать деньги), в какой-то - загружены полностью. А к вам приходит новый проект, и надо быстро найти разработчиков - идете к партнерам и берете у них команду под проект.

- К вам приходит клиент с низким бюджетом, который вам не интересен. Можно отдать его партнеру (условной региональной студии), которая сделает проект, еще и поделится комиссией.


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

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

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

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

(скриншот с теглайна)

Где-то читал, что все большие и успешные SaaS-сервисы основные деньги получают от крупных заказчиков (т.н. enterprise-клиентов). А с мелким бизнесом часто работают в ноль, в надежде что он когда-то вырастет.


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

- SSO (Signle Sign-On) - передача функций аутентификации стороннему сервису (типа Okta, работали с ним на PowerDot),
- RBAC (Role Based Access Control) - детальное разграничение прав доступа по ролям (группам, пользователям),
- Аудит-логи - логирование всех действие пользователя (делали это для HIPPA-конмплаенса).

Выводов отсюда несколько:
- Заработать нормальные деньги можно только работая с крупными клиентами.
- Если агентство хочет работать с крупными клиентами, нужно так трансформировать бизнес (PR, маркетинг, производство), чтобы он стал понятен и знаком enterprise-заказчику.

Финансовая отчетность

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

Я долго не мог сделать качественную отчетность. Прошел курс на Финологе чтобы разобраться — чем Cashflow отличается от P&L. Делал их сам, получались примитивные и нерабочие версии. Пытался научить нашего бухгалтера, не взлетело. Даже общался с консультантами Финолога по этому поводу. Все не то.

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

Пишите в комментариях или в личку, поделюсь контактами.

Сегодня и завтра иду на Agima Partner's Weekend.

Если встретите меня там - подходите знакомиться 🙂

Буду возле закусок ну и периодически на потоке управления.

Вчера на конференции узнал, что в тг-каналы нужно чаще выкладывать свои фото.

Так лучше создается связь между автором и читателем.

📣 Сегодня есть отличный повод – запись подкаста со мной и Эдом из КОД9.

На фото мы ржем над чем-то. Слева - я. Справа - Эд.

Кстати, Эд тоже управляет компанией по it разработке на международном рынке и рассказывает про это в своем тг канале.