Вы придумали блестящую идею, в которую верите. Ваш MVP получил реальный интерес у целевой аудитории. Вы увидели потенциал рынка. От скорости развития будет зависеть то, какую долю этого рынка вы захватите, пока не появились конкурирующие продукты. Вот почему важно видеть свое развитие на несколько шагов вперед и подготовить почву для быстрого масштабирования.
Однако собственники бизнеса настолько увлекаются деталями собственного продукта, что не уделяют должного внимая грамотному развитию структуры управления компанией и процессов, что сильно снижает эффективность, повышает внутренние затраты и мешает развитию. Как следствие, конкуренты обгоняют, и момент теряется. В этой статье расскажу, как оценить готовность к росту компании, которая развивает IT-продукты.
Почему пути продукта и компании должны разойтись
IT-продукт зарождается в виде идеи, вынашивается путем анализа рынка и конкурентной среды, рождается в виде MVP, и растет вместе с IT-компанией до определенного момента. Но дальше пути компании и продукта должны разойтись, ибо продукт со временем устаревает или уже не приносит дохода, а компания должна остаться и продолжить свое развитие. Ключевая задача предпринимателя – не упустить время. Нужно вовремя подготовиться к росту, вовремя делегировать свои задачи, вовремя увидеть закат продукта и, самое главное, продолжать искать и находить идеи, развивать их в новые продукты.
Готова ли компания к будущему росту?
Основные сложности возникают как раз на первых этапах становления компании, потому что нет еще подобного опыта, поэтому риск забуксовать и потерять преимущество выше. Чтобы этого не произошло, предлагаю проверить вашу компанию по чек-листу.
1. Существует ли стратегия развития бизнеса?
Даже если бизнес пока находится в зоне неопределенности и четкого пути еще не просматривается, это не означает, что стратегии не должно быть. Она может быть сформулирована у фаундера в голове хотя бы крупными мазками/направлениями. Эти мысли нужно зафиксировать, по возможности детализировать и иметь в виде документа, который будет отправной точкой как для целей на ближайший период, так и для управления изменениями. От этого будет дальше строиться вся модель управления. Если такого документа нет, то любые изменения, а их будет довольно много, превратят работу в хаос.
Ответственный: владелец компании.
2. Сформулированы ли цели компании на период?
Я не зря поставил эту задачу второй по значимости, потому что техника целеполагания является эффективным инструментом управления, который способен направить усилия всех сотрудников в одно русло и быстрее достичь результата. Цели могут совпадать с целями продукта на первое время, главное, чтобы они были сформулированы, озвучены и превратились в планы работ каждого отдела путем проведения OKR мероприятий или стратегических сессий. Нужно не забывать, что цели должны быть сформулированы по принципу S.M.A.R.T.
Ответственный: владелец компании/CEO.
3. Описана ли организационная структура?
Даже если численность компании не превышает десять человек, уже должна быть подготовлена организационная структура, которая отражает текущее положение ролей и описаны зоны их ответственности. Уже на данном этапе нужно думать, как данная структура будет выглядеть, если численность персонала вырастет кратно, или если в стратегии заложена экспансия в регионы или открытие филиалов, то это тоже надо отразить в структуре.
Ответственный: CEO.
4. Описаны ли сквозные процессы?
По мере роста численности будут формироваться отделы (продажи, разработка, поддержка…). Как только в отделе становится более двух человек, нужно подготавливать регламенты работы и взаимодействия. Взаимодействие между отделами должно быть бесшовным – все следуют принципу достижения общих целей, а KPI отделов разработаны так, чтобы если одно из звеньев не справляется, то у других появляется стимул ему помочь. Взаимодействие между отделами описывается как процесс с пониманием, что и в каком качестве должно приходить на вход, и что и через какое время должно из отдела выходить. У процессов существуют метрики, по которым операционный директор отслеживает эффективность как сквозного процесса целиком, так и его частей, чтобы вовремя идентифицировать узкие горлышки и принять меры.
Ответственный: операционный директор.
5. Внедрен ли процесс разработки продукта?
Если с продажами все хорошо и количество пользователей стабильно растет, то надо понимать, что, подбрасывая в топку уголь, необходимо успевать класть рельсы. Для этого в производстве должно все четко и прозрачно работать. Это достигается тем, что сначала необходимо определиться с процессом разработки – обычно это либо традиционный водопад, либо гибкие методологии. В продуктовой разработке на стадии, когда степень неопределенности еще высока и постоянно ищутся и тестируются разные гипотезы, лучшей методологией будет Scrum. Ему учат, его внедряют, создаются регламенты, описывающие процессы от зарождения требования до сдачи результата в эксплуатацию. Тут же есть методики, позволяющие быстро масштабироваться или наоборот отщипнуться на другое направление. Самое главное, что когда процесс есть и описан, то всегда можно просчитать, когда и что будет сделано, сколько это будет стоить, быть уверенным в качестве результата.
Ответственный: операционный директор/IT директор.
6. Существуют ли показатели эффективности продукта?
Оценка результата возможна только тогда, когда есть цифры и факты, поэтому при работе с продуктом должна быть выстроена система измерений показателей (продуктовые метрики), по которым можно не только следить за состоянием продукта, но и определять его сильные и слабые функции, и на основе анализа данных принимать решения о развитии. В какой-то момент собственнику уже не должны быть важны все показатели, достаточно смотреть за финансовой частью, которую можно поставить в KPI владельцу продукта, а свое время и усилия направлять на поиск и проверку новых идей, чтобы наращивать продуктовый портфель и тем самым увеличивать стабильность компании.
Ответственный: владелец продукта.
7. Запущен ли регулярный менеджмент?
Казалось бы, самая базовая практика, но про нее забывают, хотя систему постановки задач и контроля результата нужно организовывать, как только появляются подчиненные. Стоит сразу вложиться в хороший удобный инструмент автоматизации, чтобы потом не заниматься миграцией данных, когда бесплатное решение перестанет соответствовать потребностям.
К регулярному менеджменту также относится система контроля достижения целей и KPI. Необходимо идентифицировать, где находится компания на пути к целевым показателям, делать корректирующие действия. Важно делать это регулярно, чтобы организация работала в определенном ритме, руководители знали о наступлении дедлайна и готовились. Это можно сделать не только путем настройки регулярной отчетности руководителей подразделений, но и проведением ретроспективного анализа, запуска квартальных итоговых сессий.
Ответственный: операционный директор.
8. Разработана ли кадровая политика?
В IT-отрасли кадры действительно «решают все». Высококлассные специалисты способны вывести продукт в топ, от них зависит успех компании, на одном энтузиазме собственника далеко не уедешь. Сколько вкладывать во вновь пришедших работников, чтобы они стали отбивать эти вложения? Грамотно выстроенная кадровая политика способна не только сэкономить затраты на персонал, но и достичь результатов быстрее, вывести компанию на уровень сильных HR-брендов.
Иногда руководители считают, что лучше нанять двух дешевых и менее квалифицированных специалистов, чем одного дорогого. Практика доказывает, что это плохое решение, потому что дорогой специалист находит более эффективные решения, работает быстрее и качественнее. Это тоже стоит учитывать в кадровой политике. В любом случае, важно чтобы сотрудник работал в компании как можно дольше с постоянным уровнем мотивации, а результат его оценивался. Для этого развивают корпоративную культуру и HR-процессы.
Что предпринять, чтобы держать производительность труда на высоком уровне:
- Сформировать процесс онбординга.
- Следить за рынком зарплат и вовремя проводить корректировки.
- Составлять планы развития сотрудников и проводить регулярные перфоманс ревью.
- На постоянной основе получать обратную связь от работников.
- Внедрить культуру открытости мнений и приветствия инициатив.
- Утвердить политику вознаграждения: фикс за квалификацию, премия за результат.
- Развивать доверительный микроклимат в коллективе: радуемся успехам других, помогаем тем, кому сложно.
- Обеспечивать прозрачность коммуникации.
Ответственный: HR-директор.
9. Информация актуальна и доступна для каждого руководителя?
Все документы, регламентирующие деятельность компании, планы развития, цели, результаты стратегических и контрольных сессий, а также процессы и регламенты должны находиться в общем доступе, чтобы всегда можно было сверить свои действия с документом. Я также рекомендую держать в открытом доступе описание зон ответственности ролей, чтобы избежать пересечений или избегания ответственности. Естественно, информация в процессных и регламентирующих документах должна регулярно обновляться, иначе все потеряет смысл.
Помимо этого рекомендую создать базу знаний, куда выкладывать полезную другим информацию для переиспользования: кейсы работы с клиентами, варианты договоров, презентации для клиентов, анализ конкурентов, даже куски кода, если они решают типичные задачи и хорошо написаны.
Ответственный: каждый руководитель за свою область.
Что может помешать:
- Боязнь делегирования ответственности/ микроменеджмент.
- Частые бессистемные смены приоритетов.
- Экономия на специалистах.
- Экономия на документировании: описание работы функций продукта должны создаваться с самого начала.
- Экономия на инструментах автоматизации.
Выводы
Человеческая природа такова, что создав хороший продукт, фаундер начинает им жить, кажется, что никто лучше и эффективнее не сделает, а только испортит или уведет не в ту степь. Однако стоит отдавать себе отчет, что если вовремя не делегировать полномочия специалистам, то физически не хватит времени качественно управлять. В этом случае фаундер становится тормозом развития своей компании, даже если работает 24 часа в сутки.
Помните, что сказал Стив Джобс: «Мы нанимаем умных людей, чтобы они говорили нам, что делать». Эти умные люди уволили его из собственной компании, но сделали его триллионером.
Также читайте:
Хороший текст, спасибо.
Со многим можно согласиться, хотя список обсуждаемых задач и действий, на мой взгляд, превышает возможности компаний размером, скажем, до 10 человек (см. п.3).
Первый вопрос: поискал слово "продажи" и нашёл его только один раз - и то через запятую. Хотя о сбыте нужно думать с первых минут. Хуже, что слово "маркетинг" не нашёл вообще. Что является входными данными для черновика стратегии, кем и как эти данные - пока не знаю.
Как описываемая компания собирается зарабатывать?
Проблема не в том, что люди не знают того, что вы написали в статье...
Проблема В ТОМ, что для управления компанией НЕТ нормальных инструментов... А инструменты решают все....
Соглашусь, CFO нанимают одним из первых, но ключевой вопрос: какую задачу ему ставят? Часто это «наладить учет и отчетность», но очень редко - «построить масштабируемую финансовую систему, которая будет работать без тебя через 2 года».
Именно здесь и кроется проблема. CFO с опытом аудита (той же Большой четверки) - профи в анализе готовых процессов, но не всегда в их создании и автоматизации для быстрорастущего бизнеса. В результате фаундер делегирует «финансы», но не получает главного - уверенности, что этот «скелет» компании не треснет при первом же серьезном росте. Проблемы в учете и управлении денежными потоками есть у большинства, но их не видно до тех пор, пока они не становятся критическими. Причина в том, что не каждый CFO умеет говорить с собственником на языке бизнес-рисков и возможностей, а не только на языке отчетности. Да и не каждый CFO готов взять на себя ответственность за автоматизацию и/или признать, что у компании реальные проблемы из-за несоответствия инструментов учета масштабам бизнеса.
Это круто!
Интересно, как на такое кандидаты реагируют?
Двухлетний срок - это конечно условность / гипотеза, которая призвана подчеркнуть важность и устойчивость создаваемой системы.
Реакция действительно может быть разной, и она очень показательна. Она сразу отделяет исполнителя от стратега.
Если CFO видит себя в роли «хранителя отчетности», который поддерживает текущие процессы, то такая задача его пугает или не мотивирует. Он может даже согласиться, но по инерции продолжит заниматься рутиной, не двигая систему вперед.
Совсем иначе реагирует эксперт продвинутого уровня. Для него такая задача - это вызов и возможность создать работающий механизм, а не просто занять должность. Такой специалист уверен в своей ценности: он знает, что после успешного построения системы его либо попросят остаться для решения более сложных задач, либо он легко найдет новый вызов - возможно, даже в рамках той же компании, но в другом качестве. Да и прогресс, и компания на месте не стоят, систему можно улучшать и совершенствовать очень долго и постоянно преодолевать новые вызовы. При этом критически важно обеспечить такого эксперта всеми необходимыми ресурсами: техническими, административными, а также снабдить полномочиями, чтобы он имел возможность принимать решения.
Вы правильно уловили нюанс: речь не о том, чтобы нанять CFO на двухлетний проект. Это не проектный менеджер. Речь о том, чтобы с первого дня ставить перед ним амбициозную стратегическую цель - создать финансовый «хребет» компании, который в будущем сможет устойчиво работать даже при гипотетическом уходе CFO или его переходе на новую роль.
Мне вообще понравилась идея формулировать задачу кандидатам так, чтобы это было интересным вызовом для сотрудника.
Так можно более интересных сотрудников собрать.
Статья понравилась. По некоторым моментам выскажу соображения.
1. Компания является монопродуктовой или это бизнес-инкубатор? Идея "отпустить продукт жить своей жизнью" и заняться управлением компанией предполагает, что есть еще продукты, которые нужно развивать. В монопродуктовой компании достаточно проблематично разделить сам продукт и корпоративный менеджмент. Если продуктовая линейка широка - тогда вопрос снимается.
2. При качественном корпоративном управлении C-Level уделяет внимание именно вопросам создания ценности - вся цепочка Портера + финансовое планирование. Продукт остается важным, но как только MVP подтверждается, сам продукт переходит в регулярный товар, следовательно, вопросы мерчендайзинга не могут решаться от него отдельно. А выбор ниши предшествует созданию MVP, т.е. создатель бизнеса должен иметь представление о правилах индустрии. Можно посмотреть на предпосылки этого выбора и риск-факторы, которые при этом оценивались.
3. Масштабирование бизнеса предполагает понятность бизнес процессов, следовательно, они должны быть построены, как и разделение ответственности - матрица RACI. Отмечу, что наличие формальной структуры в малых (5 - 10 чел.) коллективах весьма желательно, но вторично по отношению к разделению функционала в матрице.
4. Стратегия развития исходит из вИдения собственника, которое должно, как минимум, существовать, и уже конкретные шаги по имплементации стратегии находят свое отражение в SMART-целях и их контроле через KPI/OKR.
5. Вопросы доступности информации решаются на уровне доступов к системе учета (в идеале - ERP) с возможностью онлайн-детализации визуализации (PowerBI/Tableau/Loginom/Deductor).
Итого: статья отвечает именно на поставленный в заголовке вопрос (что очень радует), а написана для целевой аудитории, занятой вопросами аудита корпоративных систем. "Просто собственник" может не увидеть весь процесс business studies, но понять, как подготовиться к аудиту, статья помочь может.
Судя по постановке вопроса, там еще до аудита много чего надо сделать, чтобы было чему аудит проводить.
Интересный разбор, но есть один момент, который в реальности чаще работает иначе.
Вы пишете, что фаундер должен “вовремя” описать процессы, выстроить структуру, делегировать и т. д. — но на практике большинство IT-компаний просто физически не могут сделать это заранее. Пока нет стабильного продукта и прогнозируемой выручки, документирование и регламенты воспринимаются как роскошь, а не необходимость.
На мой взгляд, критично не столько «описать всё заранее», сколько правильно определить минимальный набор процессов, который действительно масштабируется. Многие компании тратят месяцы на создание красивых схем, которые перестают работать через квартал.
И ещё важный момент — автоматизация. В статье звучит скорее как “желательно”, но по факту без автоматизированной операционки рост обычно заканчивается пожарным режимом.
В целом тезисы верные, но жизненный цикл внедрения намного хаотичнее, чем кажется на бумаге — и это то, о чём собственники часто забывают.
Абсолютно согласен