Масштабирование команды разработчиков наряду с ростом бизнеса: с нуля до выхода на рынок

Все продуктовые технологические компании так или иначе сталкиваются с вопросом оптимизации разработки: как выстроить процессы, аутсорсинг или in-house, сколько людей нанять, каких специалистов нанять и что со всем этим делать при развитии бизнеса.

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

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

Запуск проекта и начало процесса разработки

В целом я вижу три пути, по которым может пойти основатель или генеральный директор на ранних этапах:

1. Аутсорсинг разработки MVP
2. Начните собирать собственную команду.
3. Начинаем без инструментов кода

Как принять правильное решение? Ваш первый шаг будет зависеть от характера продукта.

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

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

Если основная ценность вашего продукта — в технологиях (все виды AI, IoT, AR/VR/XR и т. д. или просто необычное решение), то вариант без кода отсутствует, поскольку невозможно реализовать технологически сложные проекты с использованием этих инструментов. Более того, если вам нужен MVP, чтобы проверить гипотезу и определить, существует ли рыночный спрос на ваш продукт, лучшим вариантом, вероятно, будет работа с командой аутсорсинга. Если у продукта есть рыночные аналоги, вероятность неудачи возрастает, поэтому лучше не тратить первичные ресурсы.

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

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

Формирование команды

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

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

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

В процессе разработки нет необходимости изобретать велосипед. Если ваше приложение содержит логику, которую есть в любом другом продукте на рынке (уведомления, мониторинг, выставление счетов и т. д.), существует 90% вероятность того, что вы найдете готовый SaaS-сервис или решение с открытым исходным кодом, которое удовлетворит ваши потребности. за небольшую плату или бесплатно. Сконцентрируйтесь на самом важном: создании решения, которое выделяет ваш продукт. В дальнейшем, при необходимости, вы сможете реализовать свои специализированные системы уведомлений или тот же биллинг.

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

В самом начале, когда вы написали 0 строк кода, внедрять Scrum или любой Agile-подход со спринтами обычно бессмысленно. В действительности, начальные этапы разработки требуют выполнения базовых задач, таких как развертывание инфраструктуры, выбор библиотек, создание базовых сущностей и реализация минимальной бизнес-логики. Такие задачи бывает сложно оценить, поскольку у команды нет ощутимых результатов, которые можно было бы оценить. Вместе со своей командой определите основные домены, сущности и процессы для вашего продукта, а затем создайте канбан-доску с карточками, содержащими эти основные задачи и сотрудников, назначенных для их выполнения. Скорее всего, эти карты будут случайным образом сливаться и разделяться в процессе работы; Там нет ничего плохого; пусть разработчики структурируют их так, как им удобно - бюрократия на этом этапе не требуется.

Спринты полезны и удобны; их можно реализовать после того, как разработчики заложат основу будущего продукта.

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

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

Выполнение MVP

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

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

При необходимости вы можете нанять дополнительных исполнителей. Например, если проект предполагает нагрузку на сервер, непропорциональную количеству пользователей (сложные вычисления, обработка больших объемов данных), используйте DevOps, чтобы приступить к построению масштабируемой инфраструктуры.

Как только MVP заработает, продолжайте разработку продукта

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

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

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

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

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

Каждая команда может разрабатывать свои собственные внутренние процессы, такие как изменение цикла выпуска и методов оценки задач. Однако было бы предпочтительнее, если бы везде соблюдались некоторые общие принципы.

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

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

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

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

Каждый бизнес уникален

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

н

---

Оригинал