Из стартапа в энтерпрайз. Как не повторять чужие ошибки и превентивно решать проблемы
Глава 1. Кто я и для кого статья?
Приветствую. Это моя первая статья на Хабре, в которой я решил раскрыть такую тему, как переход от стартапа к энтерпрайзу.
Я решил об этом написать потому, что тема по сути своей довольно востребована. Это в том числе и крик души от того, с чем я сталкивался лично. Мне показалось, что никто ранее не собирал все сложности перехода в одном месте и не предлагал для большинства из них решений. Это будет своего рода рецепт — мой авторский.
Фактически, почти любой бизнес — это рецепт приготовления блюда.
Если вы следуете рецепту — вы его приготовите и сможете насладиться вкусом, а с опытом, научитесь играться со специями и улучшать его исполнение.
Сам я работаю системным аналитиком. Проектирую и описываю информационные системы. Также присутствует некоторый опыт Project/Product Management. Стремлюсь прокачать свой личный бренд и стать экспертом в области управления IT-компанией со своим продуктом.
ВАЖНО: Я терпеть не могу объяснять что-то сложным языком и скатываться в академическую духоту. Статья будет сопровождаться некоторым визуальным сопровождением в формате мемов, дабы придать некоторый эмоциональный окрас проблемам и позволить читателю иногда расслабиться.
Данный материал подготовлен для менеджмента высокого и среднего звена тех компаний, которые собираются идти в здоровые процессы, вырасти как по качеству внутренних процессов, так и финансово. Теперь же предлагаю не оттягивать и перейти к следующей главе.
Глава 2. О чем мы говорим?
Начнем с определения границ и рассмотрим те уровни зрелости компаний, которые бы я выделил.
Стартап (Startup) Самая первая стадия становления компании. Если сказать прям простыми словами, есть глобальная идея, что вы хотите сделать. Нет понимания, будет ли продукт успешным, нет нормальных процессов разработки и четких границ ответственности. Все занимаются всем ради MVP.
Полуэнтерпрайз (Half-Enterprise) Ступень к переходу к зрелым процессам, грамотному менеджменту. Появляется разделение зон ответственности у людей. Компания уже не такая гибкая, как при стартапе, поскольку начинает зарождаться более долгосрочное планирование, но все еще позволяет прощать ошибки. MVP уже реализован, появляются новые фичи и ориентир к повышению прибыли.
Энтерпрайз (Enterprise) Зрелая компания, отдельные команды которой работают по четко сформированному процессу. Исключены лишние звенья в структуре управления. Подчиненность имеет линейный характер. Все крупные изменения в процессах, будь то релизные циклы, будь то процесс разработки, происходят медленно, поскольку каждое значимое изменение может нести за собой крупные финансовые риски для компании, и как следствие — появляется необходимость пройти несколько кругов согласования перед внедрением изменений. В целом, принцип работы энтерпрайза стремится к принципам работы любого государства. Компания генерирует выручку и стремится к минимизации расходов.
Экосистема (Ecosystem) Компания успешно прошла шаг энтерпрайза, диверсифицирует направления своей деятельности и повышает лояльность аудитории за счет предоставления большего спектра услуг в рамках одного пакета. Помогает выполнить переход дочерним компаниям и инвестирует в их деятельность. Задача экосистемы — превратить дочерние компании из стартапов в энтерпрайз.
***Компания-масон (Masonic Company)
Супер интересная вариация компании, об этом будет сказано в 5 главе на сладенькое.
В данной статье мы рассмотрим только первые 3 типа компаний, поскольку, проблемы экосистемы носят совершенно иной характер.
Глава 3. Какие проблемы решаем?
Давайте начнем с ряда проблем, с которыми сталкиваются большинство компаний. Ниже будет перечислен набор наиболее часто встречающихся и болезненных точек, разумеется, существуют и другие, но о них в рамках данной статьи мы разговаривать не будем.
Вот их перечень:
Низкое качество бизнес-требований (далее по тексту — БТ). Из-за нечетко сформулированных требований страдают чаще всего те люди, которые получают их на вход, как правило, это системные аналитики, которые переводят БТ на технический язык, по которому разработчики реализуют продукт. Чаще всего не учитываются какие-то корнер кейсы или выявляется неполнота описания каких-либо процессов.
Неочевидная бизнес-потребность. Фактически в большинстве случаев вытекает из предыдущей проблемы, но может существовать и само по себе. При неполной/некорректной (подчеркните нужное) формулировке требований теряется идея, или же идея изначально не была полезной и можно было бы задвинуть ее последним приоритетом. Банально придется каждый раз объяснять людям, зачем оно надо.
Отсутствие нормативных документов по типу Definition of Ready и Definition of Done. Само отсутствие документов я бы не стал выделять, как основную проблему. Скорее, я бы отметил различное понимание у сотрудников того, что должен содержать результат работы со стороны тех или иных компетенций.
Рознящиеся процессы в командах. Каждая команда может иметь специфику в своей работе и расширять/исключать цепочки в общем процессе. В связи с этим могут возникать кейсы, когда при работе над одним проектом, выходные артефакты одной команды могут не соответствовать ожиданиям другой.
Нечеткие границы ответственности в команде. Все еще присутствуют отголоски стартапа, когда аналитика могут заставить писать бизнес-требования и ругать его за то, что он не учел то, что «ведь обсуждали на звонке» или переписке. Каждый делает свою работу и несет ответственность за актуальность документации/кода.
Неумение расставаться с людьми. Это довольно распространенная проблема, и слышал я о ней очень много откуда. По большей части я связываю это с тем, что людям просто повезло оказаться в нужное время на конкретной должности, либо они попросту не готовы адаптироваться к новым реалиям по переходу в нормальный энтерпрайз. Кто-то просто не хочет выходить из зоны комфорта, а кто-то не вывезет, так как им повезло оказаться в управлении среднего и высшего звена во времена дружеской атмосферы стартапа.
Отсутствие школы наставничества и онбординга. Бывает и так, что человек сам по себе не глупый, но быстро адаптироваться в новой компании к ее условиям тяжело. Или у человека недостаточно экспертизы в подходах к работе или технологиям. Человеку нужен человек. Помоги ближнему своему.
Отсутствие сильной школы планирования и работы с приоритетами. Да, мы гибкие, да, мы работаем по Agile/Scrum и все такое, но только сегодня у нас хотелки одни, а завтра другие. Или давайте посреди спринта вкорячим другую задачу. И это не ок. Это излишняя трата человеческих ресурсов и демотивация всей команды.
Отсутствие регламента по работе с техдолгом. Новые фичи фичами, но нельзя забывать о старых костылях, которые мы сделали ради релиза в срок и обгона конкурентов с уникальной на нашем рынке фичей. Рефакторинг тоже нужен.
Итак, с проблемами мы определились. Они в целом довольно понятные.
Основные вопросы: как их решать, как быстро это сделать, кто должен этим заниматься? Сразу дам спойлер с ответом на вопрос про скорость — совсем не быстро. Долго и болезненно. Но плоды свои оно даст. А еще вы потеряете часть команды. Не все будут готовы мириться с новыми правилами.
Отвечая на вопрос: КТО должен этим заниматься?
Ответ прост: ВСЕ заинтересованные лица в рамках процесса.
Ответ на 1 вопрос будет ниже. По сути он будет раскрывать тему повышения зрелости всех членов команды за счет стандартизации процессов до того уровня, когда все эти нормативные документы будут восприниматься не как «ААА БЕЖИМ ОТ БЮРОКРАТИИ», а как обыденность, которая позволит упростить всем жизнь.
Когда я обсуждал часть мыслей со своим хедом (непосредственным руководителем отдела), он также посчитал, что это путь в бюрократию, и что зрелость должна повышаться за счет самостоятельной работы и внутрикомандной коммуникации. Отчасти я с этим согласен. Но иногда данный период может занимать довольно продолжительный период времени, а ждать мы не хотим. А фонд оплаты труда (далее — ФОТ) в IT-компаниях сами знаете, довольно внушительный.
В связи с этим я не вижу смысла пускать все на самотек и предлагаю уйти в эффективный менеджмент. Крайне не хочу задеть чьи-то чувства — тут речь совсем не про то, чтобы стоять над сотрудниками с палкой и требовать поминутный отчет о проделанной работе. Речь про договоренности, которые помогут избежать проблем в работе.
Как видят эффективных менеджеров остальные
СЧтобы нормально начать работать — надо просто научить людей нормально работать, другими словами, привить поведенческие паттерны в их профессиональной деятельности.
А то, о чем будет написано ниже, является самым что ни на есть ответом на то, как к этому прийти.
Глава 4. Наконец-то суть!
Давайте наконец-то начнем.
Разберем проблему некачественных бизнес-требований и неочевидных бизнес-потребностей.
Мы сейчас не будем отдавать дань уважения господину Вигерсу, который смог дать определение данным терминам, мы лишь поговорим о том, почему очень многие проблемы начинаются тут.
Обратимся к формулировке качественной User Story:
Я, как ХХХ, хочу YYY, чтобы ZZZ.
По сути все ясно:
ХХХ — конкретный пользователь, принадлежащий к какой-то группе
YYY — конкретная цель, которую мы хотим достичь
ZZZ — конкретная ценность, которую мы стремимся получить при достижении цели.
Какую проблему мы часто наблюдаем? Заказчик или Product Owner не может объяснить, а зачем оно (ZZZ)? Фича ради фичи? Или это поможет заработать денег для компании? Или повысит конкретную метрику? Не понятно…
А по факту любая описанная фича должна четко обозначать ценность, которая ожидается от реализации. Зачем? А все просто, чтобы бабки посчитать, сколько мы потратим, и сколько мы заработаем от внедрения того или иного функционала. Мы же помним, что в enterprise все двигается по общему процессу. На мой взгляд, все фичи, предлагаемые к реализации, должны быть обязательно вынесены на защиту перед CPO и CFO, так мы приходим к тому, что фичи не выпускаются ради фичей, ведь клиенты и так растут в весе как на дрожжах, обогащаясь все новой и новой логикой.
Например, по данным https://sensortower.com/blog/ios-app-size-growth-2021 размер самых популярных приложений AppStore с 2016 по 2021 вырос в 3 раза, а перед этим с 2013 по 2017 год — примерно в 10 раз.
Вот вам для примера картиночка с Gmail, который сделал х19 с 2016 года
Статистика роста ТОП-10 приложений App Store с мая 2016 года
Если вспомнить историю приложений с 2016 года — можем ли мы оценить прирост в количестве реально полезного функционала кратным даже не 19, а хотя бы 3? Сомневаюсь. В среднем по палате это в лучшем случае х1,5. А сколько было потрачено денег? Страшно представить. Но тем не менее, эти компании уже всем все доказали и заработали достаточное количество денег. А тот, кто читает эту статью — подозреваю — нет, поэтому, будьте так добры, начните считать. Процент маржи от реализации и методики расчета выручки определяйте сами, я лишь подсказываю вам верный с моей точки зрения путь по решению данных проблем. Для упрощения работы с описанием рекомендую прямо-таки внедрить Definition of Ready & Definition of Done. Благодаря данным документам вы сможете четко формализовать правила по написанию требований и сопутствующей документации и закрепить за ответственными компетенциями данные обязанности.
Следующие 3 проблемы, которые мы затронем — различные процессы работы, размытые зоны ответственности членов команды и неумение расставаться с людьми.
Очень часто при переходе от функциональных команд к продуктовым (частный случай проблемы) люди не хотят или не могут перестроиться на новый процесс работы, который, как часто бывает, не однороден.
Из-за отсутствующего опыта работы в таком ключе — возникают расхождения в порядке работы команды, ответственности ее членов и даже банально различного Jira Flow, что в конечном итоге влечет за собой ряд сложностей кросс-командного взаимодействия. Одна команда не понимает, как работает вторая, банально не может прочитать в некоторых случаях статус задач на доске и порядок планирования их работ, к тому же и сама этапность работ может отличаться. Все это решается стандартизацией процессов.
Первое, и самое важное, что нужно сделать — закрепить за конкретными ролями те обязанности, которые им присущи. Например, Product Owner ОБЯЗАН формализовать бизнес-требования и бизнес-потребность, и ему СЛЕДУЕТ сопровождать разработку макетов дизайна до их согласования перед CPO, он ОТВЕТСТВЕНЕН за качество продукта и значения метрик, связанных с ним. И такие ОБЯЗАН/СЛЕДУЕТ/ОТВЕТСТВЕНЕН должны быть закреплены за каждым из членов команды. Это один из самых простых способов определить границы зон ответственности. Его можно использовать на старте до момента, пока не будут выявлены все тонкости при взаимодействии внутри и за пределами команды.
В дальнейшем можно переходить на довольно популярный RACI-подход, при котором все стандартные задачи в рамках выполнения проекта имеют в разной степени связь с каждым из членов команды. В данном случае мы однозначно исключаем все дальнейшие разногласия в части того, кто и что должен был сделать. Как правило, это супер удачно вяжется с нормативными документами DoD и DoR. RACI-матрица описывает, кто и что должен сделать, а нормативные документы — как это должно быть сделано. В целом про RACI-подход есть много статей в интернете. Вот пример подобной статьи: https://skillbox.ru/media/management/chto-takoe-matritsa-raci-i-kak-ona-pomogaet-vypolnit-proekt-v-srok-ne-rasteryav-zadachi/
Наконец, когда мы определились, кто и за что должен отвечать, надо связать этапы выполнения задач воедино. В рамках компании в связи со спецификой работы могут применяться разные методологии. Например, у продуктовых команд есть долгосрочное планирование, и для них важно прописать, какой этап за каким следует. А у инфраструктурных специалистов по типу SRE/OPS/SECOPS долгосрочное планирование отсутствует. Поэтому для них Scrum как таковой и не применим. Достаточно просто Kanban-доски с общим пулом задач, которые выполняются в порядке приоритетов для тех иди иных продуктов. Это говорит лишь о том, что для подобных вопросов должен быть зафиксирован свой собственный регламент со своими DoD и DoR.
От себя скажу, как от человека, который составлял для своей команды RACI-матрицу — это довольно трудоемкий процесс с точки зрения исследования и описания. Поэтому, я могу предложить такой вариант для старта (его я увидел на одном из собеседований в стартап-компании, когда мне объясняли, как они работают — процесс взят с потолка для визуального упрощения восприятия), обозначаем роли своими цветами, показываем основные этапы работы, выделяем задачи по цветам в соответствии с той ролью, которая занимается их решением:
Пример того, как можно легко описать процесс работы в команде
2 наиболее сложных проблемы решаются способами, которые описаны выше. Есть и другие их вариации, но лично мне они ближе всего.
Остается главное: объяснить людям, почему важно работать именно так. И вот тут-то начинаются главные проблемы. Я не слышал еще ни разу, чтобы кто-то с радостью воспринимал такие нововведения. Зачастую все это выглядит людей, как уход в бюрократию и повышение контроля за их работой. Поверьте, вас обязательно в этом упрекнут. Не так много людей, которые действительно понимают важность таких работ. Вот тут и настает сложный этап, когда вы либо договариваетесь со своими сотрудниками, либо расстаетесь с ними. В некоторых случаях потери для компании будут очень ощутимыми, но это не должно стать препятствием для стандартизации всего процесса работы и избавлению от большинства казалось бы детских болячек, которые понемногу, но оттягивают T2M и увеличивают расходы на ФОТ.
Итак, мы определили, как работать с 6/9 упомянутых проблем, остаются еще 3:
Отсутствие школы наставничества и онбординга
Отсутствие школы планирования и приоритизации
Отсутствие регламента по работе с тех-долгом
По-хорошему, некая вариация школы наставничества как правило присутствует в любой организации, где-то это просто чек-лист, который должен пройти новоиспеченный сотрудник, где-то ему просто говорят обращаться за помощью и советом к руководителю. Тем не менее, задача данного этапа состоит в том, чтобы быстро объяснить сотруднику, как вы работаете, и дать четкое понимание той картины мироустройства, которая сформирована в вашей компании. Объяснять можно и на словах, но когда это уже формализовано в документ, доступный и единый для всех — уверяю, оно сразу становится прозрачным. Даже если с 1 раза будет тяжело погрузиться, то на 2 или 3 раз в течение непродолжительного времени работы в компании, все будет разложено по полочкам.
А наставник нужен для того, чтобы он направлял новичков в правильное русло и раскрывал те этапы процесса, которые выглядят темными пятнами. Вот собственно и все.
Теперь про планирование. Выше я писал про развитие культуры описания бизнес-ценности и ее защиты, то есть определения той выгоды, которую принесет внедрение той или иной фичи. Как правило, у CPO присутствует видение долгосрочного развития продукта, это видение нужно использовать для разбивки кусочка продукта по доменам (командам). Таким образом, в рамках каждой команды Product Owner должен определить, как извлечь выгоду из задачи, которая перед ним стоит, и как выразить ее в рамках того кусочка продукта, за который он отвечает. Разумеется, не всегда та или иная фича принесет деньги или количественный прирост по определенным показателям. Но основная идея состоит в том, чтобы мастерски управлять бэклогом, и определять приоритеты исходя из направления развития компании. Если в компании будет еще и единая сетка оценки задач, то обеспечить более менее качественный груминг и планирование на 2 квартала вперед (больше нужно только для более крупных юнитов, таких как стримы — несколько продуктовых команд, объединенных по одному бизнес-направлению) обеспечат для ваших сотрудников понимание, к чему они идут и возможность заложить в продукт те основы, которые позволят безболезненно обрастать функционалом.
Ну и на последок, техдолг.
Ну, вы поняли)
Залог любого продукта для пользователя — это не количество фичей в нем, а стабильность его работы. Будьте вы хоть самыми яркими невероятными и покрывайте все возможные пользовательские сценарии -, но если приложение будет долго запрашивать ответ с сервера для отрисовки странички пользователю или постоянно вылетать — найдется на рынке тот, кто предложит что-то получше. Техдолг должен занимать какой-то объем при планировании спринта/квартала. Где-то этому достаточно уделить 10% всего объема человеко-часов, где-то все 30%, но откладываться на потом это не должно. Иначе с каждой новой фичей, ложащейся на старый плохо работающий функционал, количество костылей в приложении будет расти по экспоненте. Не даром я приводил в пример вес приложений в AppStore. Будьте уверены, это все не только из-за появления новых фичей, но и по причине некачественной работы с техдолгом.
На этом у меня все. Переходим к спорной вариации компании-масона, о которой я говорил во второй главе и к заключению.
Глава 5. Компании-масоны
Почему такое название? Все же помнят мемы и теории заговора про масонское ложе, которое предопределяют судьбу миллионов людей в этом мире?
В порядке бреда можно выделить и такие компании. Я не стал бы включать их в свою классификацию, но это довольно интересная тема для дискуссий. Такие компании лоббируют в правительстве свои интересы. Например, в США корпорации напрямую в открытую могут спонсировать деятельность политиков в своих интересах. Также и у нас это возможно, но в более завуалированном формате. Я знаю примеры такого и в России, но в целях избегания конфликтов с большим братом не буду упоминать никаких юрлиц. Все и так все понимают. Тем не менее, это все та же компания-экосистема, обросшая достаточной силой на политической арене и способная менять законодательство в своих интересах под предлогом развития и пользы людям. Государству по факту ссориться с такими компаниями нельзя, они являются одними из главных налогоплательщиков, поэтому и допускаются некоторые поблажки. Но это лишь тема для дискуссий и не более. Не захотел выделять это в классификации выше, чтобы не забивать голову дорогому читателю. А тут уже можно.
Теперь же — к итогам!
Глава 6. Почему вы должны мне верить?
Вы никому ничего не должны. Важно понимать, что все описанное выше является моим субъективным мнением, основанным исключительно на моем опыте и опыте моих коллег/друзей. Но именно так я бы строил свою продуктовую компанию!
Фактически, я чертов дилетант с мнением, что что-то да понимаю в этом мире. А считаю я так в результате проведенных мной исследований и наблюдений. Часть из предложенных рекомендаций внедрялась на моих глазах и дала реальный результат. Тяжело количественно оценить значения метрик, так как реальных замеров не производил, но качественная оценка более чем высока.
А еще на последок от меня лайфхак:
Eсли происходит жопа, никакие методы решить проблему не помогают, наблюдается повсеместное выгорание — просто дайте людям работать!
Если вам понравилась данная статья, я бы предложил перейти в мой небольшой телеграм-канальчик, в котором я переодически выдаю свои мысли и сообщаю об обновлениях в части своей общественной деятельности (или просто рассказываю истории из жизни).
Переходить сюда: https://t.me/sa_shevelev
Буду рад подписке и реакции (с какашкой) поддержки меня под постами.
