Один из интересных и не очень часто освещаемых вопросов ИТ-менеджмента – расширение команды инженеров и ошибки, которые можно совершить на этом пути. Я сам активно развиваю свои проекты и поэтому интересуюсь этой темой. Мне удалось поговорить с Алиной Зурабовой, Head of Engineering and Testing в компании Smartcat. Этот стартап с российскими корнями, который развивает платформу управления переводами и привлек более $14 млн. Соответственно, за последние пару лет серьезно выросла и его техническая команда.
Мы поговорили о том, какие трудности возникли на этом пути, какие правильные и неправильные ходы были сделаны и как в итоге изменились процессы от поиска разработчиков до их внедрения в команду. Ниже – выжимка главных мыслей из этой беседы.
Введение: зачем понадобилось расширять команду
За несколько лет активной работы мы устаканили видение продукта, поняли, как именно он должен выглядеть хотя бы на текущий момент – понятно, что все может меняться. Мы разобрались с тем, кто наши клиенты, какие у них боли и проблемы – то есть нащупали, как говорят в США, product/market fit.
В частности, стало ясно, что наша модель – это all-in-one-product, то есть мы хотим сделать систему, которая покрывает все бизнес-процессы пользователей разных ролей внутри индустрии переводов. Здесь есть и заказчики, которым нужно как-то получить перевод, и компании-поставщики таких услуг, а есть конечные исполнители, которые переводят контент. Мы хотим автоматизировать работу каждого участника этой цепочки.
При этом под капотом:
извлечение переводимого текста из файлов офисных форматов,
куча ассинхронных операций, выполняемых на процессинге – расчет статистики, поиск глоссарных терминов, индексация миллионов unitов из баз переводов,
маркетплейс переводчиков (их умный подбор, тестирование и ранжирование внутри конкретного аккаунта),
поддержка мультиюзерного сценария работы внутри CAT-системы,
система биллинга и инвойсирования, работающая в интеграции с разными платежными провайдерами),
и т.п.
И все эти компоненты должны работать в тесной связке друг с другом и без перебоев, ведь в нашей системе каждый день работают более десяти тысяч пользователей с очень разными сценариями. Плюс каждое из направлений мы хотим активно развивать. В общем задач и возможностей всегда больше, чем ресурсов, и без расширения команды их не решить.
Процесс поиска и найма новых людей в стартап как раз может быть совсем непростым, постоянно подкидывать трудности. Вот, чему мы научились в ходе различных попыток решить эту задачу.
Урок #1: структура внутри команды не должна ограничивать рост
Когда мы начинали, в команде было порядка 15 разработчиков, то есть это был классический стартап. Все ответственные за все, продукт был небольшим, видение его будущего было еще не сформировано, мы его искали. В той реальности лучше работала схема максимальной взаимозаменяемости, когда каждый инженер мог взять любую часть продукта и понять, что с ней делать, внести изменения или протестировать.
Мы работали по гибридной модели «скрамбана» (по крайней мере, мы так на тот момент называли этого монстра): был какой-никакой релизный цикл, бэклог, продакты, чья воля транслировалась через аналитиков, был менеджер, распределяющий задачи программистам.
От этой модели при расширении команды пришлось отказаться по ряду причин:
звено менеджера стало бутылочным горлышком, bus factor начал зашкаливать;
выросло количество запросов к системе / пожеланий от пользователей;
наблюдалась потеря информации в узлах передачи информации от клиента к разработчиками;
сформировалось понимание продукта, на которое не ложилась текущая схема работы, продукт большой, и все не могут разбираться во всем, слишком разные процессы. Да и “все за все" – не есть структура, давайте не будем забывать про знаменитый знаменитый закон Конвея.
Начали думать, как изменять модель, чтобы победить все эти сложности. В итоге (ничего нового я вам не открою) пришли к тому самому Scrum-процессу. Каждая команда отвечает за один из элементов цепочки – продукт для заказчиков перевода, сервис-провайдеров или конечных исполнителей, задачи дробятся в рамках этих направлений (платежи, подбор исполнителей, отчетность и т.п.) Такую систему можно без проблем масштабировать и адаптировать под потребности бизнеса, да и потери и TTM (Time To Market) там меньше.Одним из важных шагов на пути прихода к такому сетапу стала книжка Hyper Growth, если бы знала о ней раньше – могли бы пройти некоторые шаги и сделать открытия гораздо быстрее. В общем, да, рекомендую к прочтению всем IT-менеджерам, потом не забудьте сказать мне спасибо за 70 листов отборной полезной информации.
Урок #2: нужно четко планировать расширение команды и адаптировать процессы
Приведу вам пример расширения команды, на котором мы многому научились:Это было в самом начале работы над продуктом – мы делали cat-систему, куда просто загружается проект, а затем делается перевод. То есть основной юзкейс такой: у компании есть свои переводчики, и они в режиме мультиюзера переводят проект в нашей системе, используя большую пачку дополнительных ресурсов для ускорения процесса (памяти переводов, МТ, словари и прочее). Функции подбора внешних исполнителей, взаимодействий с ними и оплаты тогда не было.
Первый шаг на пути тестирования гипотезы all-in-one-product заключался в создании еще одного важного компонента – системы маркептлейса исполнителей.
Для ее реализации мы собрали команду для разработки прототипа. Чтобы ускорить найм, даже выбрали другой стек, отличающийся от устоявшегося тогда в компании. Это было проще и дешевле.
Спустя какое-то время после начала проекта стало понятно, что тема перспективная. То есть мы пришли к ситуации, когда новая команда сделала маркетплейс, который нужно было интегрировать в исходный продукт cat-системы, сделанный изначально командой на другом стеке технологий. Интеграционные API, вот это вот все.
Итак, две команды делали куски работы каждая на своей стороне, при этом плохо представляя себе задачи и цели друг друга, закономерно, в продуктах начали появляться дублирующие сущности – например и в маркетплейсе, и переводческом продукте была сущность user. Притом user в системе перевода – это вообще не то, что интересует команду в контексте работы маркетплейса.
Собственно, в один день все узнали о существовании друг друга, и это стало настоящей головной болью. По факту у нас было два непонятно как связанных с собой продукта, написанных на разных технологиях, которые должны были выглядеть как один, команды которых при этом друг с другом раньше не взаимодействовали никак.
Сначала мы упорно не хотели сливать проекты вместе и по сути отказываться от доброй половины свежесобранной команды и гордо шли по пути боли и унижения – выбрали путь дублирования одного и того же UI в двух разных системах (откиньте эту мысль подальше, если вдруг подобное придет вам в голову). Естественно, по мере развития систем, проблема дублирования никуда не девалась, а только нарастала.
Ну и наконец, мы сдались и приняли важное для системы решение – заморозить разработку продукта маркетплейса и правильно интегрировать/мигрировать с основным приложением. Хоть и было больно, но все равно я больше расцениваю этот опыт как положительный:
мы успешно протестировали гипотезу маркетплейса, т.е. по сути мигрировали к себе уже готовый клиентский продукт (нам не надо было еще раз экспериментировать и тратить на это время);
ну и теперь мы точно знаем, о чем нужно думать при привлечении новой команды: о четких зонах ответственности и выстраивании правильной межкомандной коммуникации.
Урок #3: в стартап нужно нанимать особенных инженеров
Надо понимать, что сильный инженер, может пойти работать в условный «Яндекс». Мы же хоть и развиваемся, но все еще стартап, где все другое. Для кого-то это явный минус, но мы стараемся доносить до разработчиков плюсы работы в такой компании. В частности, это возможность очень серьезно влиять на продукт и видеть результаты своего труда, воплощенные идеи очень быстро реализуются по сравнению с крупными компаниями.
Пойти на работу в Google могут многие, а вот сделать «Яндекс» самому – это вызов совсем другого уровня. Оказалось, что этот тезис нужно отдельно доносить до инженеров.
Это может звучать как довольно очевидная вещь, но по опыту собеседований оказывается так, что для многих инженеров пункты выше не совсем понятны. Есть ощущение, что на этапе первичного контакта с кандидатами нам пока не удается по максимуму «подсветить» преимущества, поэтому приходится уделять этому внимание уже на собеседованиях.
Это непросто, но дает свои плоды. Например приводит к более низкому оттоку специалистов – команда молодая, постоянно приходят новые люди, продукт развивается, нет профессионального застоя. То есть одни из главных причин, почему разработчики могут захотеть уйти, снимаются самой природой работы в стартапе. Ты каждый год как будто бы оказываешься в новой компании.
Сейчас людей, связанных с разработкой, у нас около 50 (разработчики, тестировщики, скрам-мастера), за следующий год хотим вырасти в 2 раза и не планируем останавливаться.
Выводы: о чем помнить при расширении IT-команды в стартапе
В завершение, еще раз выделим ошибки и возможные решения:
Расширять команду без продуманных зон ответственности – плохая идея. Нанимать новых разработчиков или целые команды нужно тогда, когда четко понятно, чем они будут заниматься, как это будет влиять на продукт и каким будет взаимодействие с командами, ответственными за другие его части.
Нужно работать над коммуникациями в компании и прозрачностью информации. Ситуация, когда в компании две команды делают проекты параллельно и почти не пересекаются, приведет к трудностям и конфликтам, когда пересечься все-таки придется. А еще надо четко разделять зоны ответственности и работать над их пониманием в команде.
Плюсы работы в стартапе нужно доносить постоянно. Даже при первом контакте, когда отсекается большая часть кандидатов, важно рассказывать не только о продукте, но и важной стартап-специфике, это позволит получать на собеседованиях людей, которых интересует именно такая работа.
Делитесь своими примерами трудностей при развитии технической команды в стартапе – соберем максимально полный список проблем и решений в комментариях!
