📥 Еще про аутстафф

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

При этом хороший сервис в аутстаффе всё равно важен:

1. Нужно предложить подходящих людей: не всех подряд, а тех, у кого есть нужный опыт и навыки.

2. Разработчиков нужно качественно заонбордить в команду заказчика.

3. Затем — мониторить перформанс. Смотреть, сколько задач сделал, с какой скоростью, сколько замечаний к пулл-реквестам.

4. Заранее заметить, что что-то может пойти не так — и превентивно решить проблему. Может, вашему сотруднику просто нужно пойти в отпуск.

5. Можно ещё раз в квартал или раз в пол года проводить ревью вместе с командой заказчика. Это поможет с пунктами 3 и 4.

🤔Что с тендерами зарубежом

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

1. У крупных компаний всё более casual, чем в России. Могут запросить у разных агентств предложения (RFP - request for proposal), потом сравнить и начать работать. У нас такое было с Microsoft: процедура точно проще. (и да, Microsoft выбрали не нас)

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

Читаю Venture Deals, книга про нюансы венчурных сделок.

Вот что пишут авторы про поиск инвеcторов (aka VC, venture capitalist):
- While it may seem obvious, engaging a VC that you don't know via social media can be useful as a starting poing to develop a relashionsheep.
- It doesn't have to be all business -- engage at a personal level, offer suggestions, interact, and follow the best rule of developing relationships: "give more than you get".
- And never forget the simple notion that if you want monet, as for a advice.

По сути своей, это классика Account Based Marketing и B2B продаж. Значит поиск инвестиций это как B2B продажи. А продажи - это как поиск инвестиций.

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

Книга вот: https://www.venturedeals.com

Согласование договоров

У нас нет штатного юриста. Когда подрядчик присылает нам договор, мы проверяем его своими силами.

Обычно договор это минимум 5-7 листов стандартного текста, а действительно важными являются несколько моментов:

- сроки, сумма
- условия оплаты
- порядок приемки
- передача прав на результат работы
- задание (обычно в приложении)

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

Было бы круто при отправке договора записывать короткий loom или видео-презу, где будет коротко рассказываться про ключевые моменты договора. Это упростит вычитывание ваших бумаг, а вам будет стоить 5 минут спокойного рассказа.

Мы попробуем так делать с нашими бумагами и посмотрим на результат.

Если заказчик пришел с готовым качественным ТЗ на большой проект - это window shopping.

У вас запросят оценку, но едва ли будут с вами работать. Так случилось и с нами: мы сделали оценку проекта на 30M, со стороны заказчика был полный комплект документации и варефреймы. И он в итоге выбрал другого подрядчика.

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

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

Про размер ниши

В заказной разработке и агентском бизнесе надо смотреть на размер рынка и ниши - можно ли в ней вырасти во много раз. Может быть так, что зайти в этот сегмент не сложно, но потенциал там небольшой.

Мы общаемся со специалистами в ювелирной нише. Там есть заводы, которым нужна разработка, но их всего штук 50. Даже если отхватить 20% процентов от такого рынка, это всего 10 клиентов. Допустим каждый закажет на 10M, итого 100M. Миллиардом не светит.

Надо ли туда идти? Надо, но сразу думать о смежной нише, куда пойти дальше.

Как мы ищем операционного менеджера

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

Но как искать в тех случаях, где на одно место приходят сотни кандидатов? Нужно строить более многоступенчатую воронку. Ниже наша история.

Изначально мы искали и фильтровали кандидатов по такой схеме:

1) Вакансия на hh
2) Длинное собеседование (30-40 минут)
3) Тестовое задание

Собеседование проводил один из основателей, у которого не так чтобы супер много времени. 7-8 собеседований в неделю, и на нормальную сфокусированную работу по другим задачам времени не остается.

Быстро стало ясно, что

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

Вот новая воронка:
1) Вакансия на hh
2) Заполнение анкеты
3) Короткое собеседование (10 минут) - проводит любой скринер по списку из 5-6 вопросов.
4) Асинхронное тестовое задание (ссылка на задание в ноушене, отправка результатов по почте)
5) Полноценное собеседование (30-40 минут)

В результате перебрали ~200 кандидатов. По времени все заняло несколько месяцев. Кажется, что нашли подходящего человека, схема рабочая.

Пишите в комментариях если нужен список вопросов или тестовое задание.

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

Написал статью про наш опыт разработки билетного сервиса - наши ошибки, выводы, советы. На связи КОД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 штука.

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

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

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

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