Обреченный на успех StartUp. Глава 3
Введение
В этой главе нашей эпопеи расскажу про то как выглядела первая in-house команда разработки нашего уже родного The StartUp, какие у нее были цели и какие результаты получились, а также посмотрим, что делал бизнес и как поменялось его отношение к разработке.
Ссылка на предыдущие главы тут
А что получите вы, мои дорогие читатели? Вы получите опыт построения IT-команды с нуля, узнаете какие 50 оттенков менеджеров бывает и конечно вместе со мной заглянете за кулисы VIP-беттинга.
Команда родилась
Создание своей команды разработки началось с найма CEO, по совместительству большого поклонника Agile подхода. CEO, благодаря своим обширным социальным связям в IT-сообществе, собрал первую команду: аналитик, дизайнер и СТО. А СТО пригласил первых разработчиков, CPO и команду тестирования. CPO, в свою очередь, пополнил команду своими аналитиками и пригласил в команду арт-директора.
Все сотрудники, проникавшие в компанию, были лично знакомы хотя бы с одним членом команды, а зачастую с несколькими. И каждый новоприбывший лично знакомился и проходил официальное одобрение основателем бизнеса.
Бизнес хотел знать в лицо буквально каждого сотрудника в новой команде.
У бизнеса был запрос на лучших специалистов, и, по моему мнению, этот запрос был выполнен на 100%. Команда была великолепной. Обнимаю каждого!
Новый менеджмент
Процесс общения команды с бизнесом происходил через менеджмент: CEO, CTO, CPO и арт-директор лично и часто общались с основателем. Остальная команда (за исключением операционной) находилась в другой локации и встречалась с владельцем бизнеса 1–2 раза в год, когда всё становилось плохо. Встречи с ТОП-менеджментом на 70% носили характер “про жизнь”, но после каждой встречи команда выходила с важными новыми наставлениями и порцией мотивации: улучшить процесс, ускорить разработку, срочно внедрить новую фичу, нарисовать новый дизайн и переделать старый. Основатель бизнеса де-факто был владельцем продукта — все идеи новых фичей, которые шли в разработку, исходили только от него.
У каждого из менеджеров команды были свои "супер-силы".
CEO любил собирать всех-всех на встречи, на которых непременно обсуждались планы, сроки, статусы — и так по кругу несколько раз в день. CEO хотел составлять планы и писать много документации, чтобы потом было что обсудить на встречах.
"Ну что ты, в самом деле, пристала к этим встречам?" - скажет внимательный читатель. "У меня недостаточно литературного таланта, чтобы объяснить на сколько сильно CEO любил встречи", - отвечу я.
CTO читал много книг и первые пять лет был "женат" на работе. Наш герой хотел выстроить процесс разработки так, чтобы всё было быстро и дешево, а главное — чтобы все работали по 25 часов в сутки. До прихода в нашу историю CTO работал на галере, и практики микроменеджмента галеры активно применялись в команде.
CPO, по сути глава аналитики, хотел, чтобы work-life balance способствовал созданию качественного продукта, эффективным демо для бизнеса и гармонии в команде. Он защищал сотрудников от нападок CTO и владельца бизнеса. CPO стремился разобраться в прикладной области и много общался с операционной командой.
Иногда казалось, что мы все его рабочие дети — такая витала забота.
Арт-директор был неприклонен и влюблен в дизайн. Единственный, кто мог оспорить готовый дизайн, был основатель. У остальных не было ни единого шанса. “Долго, дорого, почти невозможно”, - никакие аргументы не действовали на арт-директора, и дизайн не менялся ни на 1 пиксель.
Как идеи бизнеса превращались в продукт
Как мы говорили ранее, источником всех новых фичей был сам бизнес. Новые фичи либо появлялись в процессе тет-а-тет разговора с одним из менеджеров, либо становились причиной такого разговора.
То, что в начале кажется хаосом, после многократного повторения становится процессом.
Кому бы ни была вброшена задача, сначала рисовался детальный дизайн, поскольку в процессе его согласования суть фичи могла измениться на 180 градусов. Буквально каждый пиксель клиентского дизайна согласовывался с бизнесом, чаще всего в несколько итераций. На таких согласованиях иногда присутствовал CPO, СТО или оба, чтобы быть в курсе запросов бизнеса из первых уст.
После или параллельно с дизайном готовились продуктовые требования, которые впоследствии вместе с согласованным дизайном передавались в разработку. Требования бизнес не читал; дизайн был единственным касанием бизнеса с командой разработки.
Дальнейший процесс был стандартный: разработка -> QA -> UAT операционной командой -> PROD для демонстрации бизнесу -> сбор многочисленных замечаний -> возврат на новый круг.
Детально процесс разработки сформирован не был, но глобально все двигалось в сторону Scrum с итерациями, синками и ритуалами.
Основной целью первой новой команды разработки было подготовить продукт к Чемпионату Мира-2018. На это было примерно полгода.
На этом мы пока оставим нашу команду разработки и посмотрим, что у нас происходило с операционной командой.
Все команды счастливы одинаково
Операционная команда, конечно, тоже готовилась к Чемпионату, больше морально. Ей предстояло не просто провести чемпионат, а продемонстрировать продукт клиентам в его лучшем виде.
Операционная команда нестрого разделилась на 2 группы: беттинг и IT. Беттинговая часть команды готовилась принимать ставки в прематче и лайве, и общаться с клиентами через чат. А айтишная часть команды занималась подготовкой требований (я бы назвала это PRD: начальный уровень), которые впоследствии превращались аналитиками в задачи на разработку.
Чемпионат Мира-2018 - это концентрированный стресс 15 часов в сутки
Количество клиентов на ЧМ увеличилось в 10 раз. Неопытная операционная команда не стала идеальным слаженным организмом, но ставки мы принимали...чаще всего в чате, потому что продукт еще не был совершенным. Прием ставок в чате, когда матч уже идет (в лайве) - это как лететь самолете в турбулентности - тебя мотает, а ты ничего не можешь с этим поделать, и ко всему прочему, на тебя кричит пилот.
Жизнь операционной команды усложнялась, на тот момент, еще сырым бэк-офисом, из-за чего было решено дублировать все ставки в Excel. В последний день чемпионата благодаря этому документу и двойной проверке была выявлена ошибка, которая сэкономила компании $150,000.
Приоритизация и другие уроки ЧМ-2018
Для операционной команды любая проблема на проде казалась критичной. Каждый день чемпионата начинался с сообщений команде разработки о проблемах на проде. Источника этих сообщений прозвали "Алина-блокер на проде" (да, дорогой читатель, это имя неспроста кажется тебе знакомым). Команда разработки героически помогала находить обходные пути всем проблемам. Мы справились: релизились на прод всего пару-тройку раз за время ЧМ.
Чемпионат мира выявил проблемы в продукте и показал направления для улучшений.
Бизнес, в свою очередь, остался недоволен результатами чемпионата мира: чемпионат сыгрался почти в ноль по выручке, новые клиенты ушли безвозвратно.
Заключение
Новая команда разработки выглядела сильно более слаженной, профессиональной и отзывчивой. Весь менеджерский состав команды был не просто в постоянном контакте с бизнесом, но и старался лучше понять предметную область.
Операционная команда (по крайне мере та ее часть, которая не ушла в IT c головой) перестала быть самоназначенными аналитиками, продактами и тестировщиками, а стала источником истины в предметной области и стала по-настоящему принимать ставки.
Бизнес не был доволен качеством и скоростью разработки, поэтому было решено масштабировать продукт, увеличивать количество разработчиков и увольнять неэффективных менеджеров.
Обо всем этом вы, дорогой читатель, узнаете совсем скоро - уже в следующей главе.
Для тех, кто дочитал, я подготовила RoadMap следующих глав и там же можно найти ссылки на предыдущие, чтобы вы знали, что ещё интересного вас ждёт.