В любом малом бизнесе есть процесс перешагивания из малого в средний или крупный. Ну или уютная самозанятость для предпенсионера. Например, для малого бизнеса достаточно 1–2–3–4, может, в край, 5 разработчиков. Эти люди могут взять отдельные направления и работать крайне эффективно. Как только их становится больше, начинают появляться внутренние коммуникативные издержки. То есть вклад следующего будет уже не 1/N, а размытым.

При не очень продуманном руководстве, где-то до 20–30 человек, можно и не особо заметить прироста эффективности в плане решения практических задач — и только после этого выйти на рост заново. С другой стороны, начиная примерно от 30 человек у вас появляется полная взаимозаменяемость и стабильность, что на малой команде просто невозможно.

Я сейчас очень упрощаю, конечно, но почувствовать бюрократию вы можете довольно легко и на других объёмах.

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

▍ Проблемы роста

1. Налоговая реформа. Оборот выше какой-то суммы будет добавлять НДС. То есть как только вы увеличитесь до какого-то размера, вести бизнес банально станет дороже. Дальше у вас либо рентабельность упадёт, либо цена станет менее конкурентной. В любом случае размер стоит денег, и надо просто подготовить продукт к этому. Самое неприятное — находиться на грани, когда вы уже платите НДС, но ещё не ворочаете миллиардами. Большая часть хостеров болтается либо в зоне упрощёнки до 300 миллионов в год (и им выгоднее создать новый бизнес с нуля и растить его независимо), либо же начинает переходить в экономические зоны, где освобождают от уплаты НДС тем или иным способом. Теперь появилась ещё одна ступенька с 5 % НДС, это уже более-менее терпимо. Но принципиально на этих порогах нужен качественный скачок, иначе малым быть банально выгоднее.
2. Стабильность уже-не-стартапа. Задача стартапа — как можно быстрее сдохнуть или показать что-то эффективное. Там никто особо не заморачивается со стабильностью команды. Если начнёт что-то получаться, уже удастся нанять управляющего с нормальными навыками администрирования, а до этого все горят и творят хаос. В первую очередь в нашем случае это касается команды — а именно её минимизации. Про это расскажу чуть подробнее ниже. В целом — вам так или иначе надо набирать людей, что увеличивает издержки на координацию между ними, обслуживание всей этой структуры и так далее.
3. Компания свыше определённой выручки. Добавляется новый уровень сложности из-за контроля налоговой, возможностей проверок и так далее. Выпавшая вам проверка — это почти как аудит MS, только начинается она в случайный момент.
4. Бухгалтерия чуть подрастает. Начинает увеличиваться количество административных функций. Количество рутины растёт в разных направлениях, в основном в бухгалтерии и в разработке (точнее, уже поддержке). Когда костяк команды начинает заниматься функциями поддержания, это прямо сказывается на продукте. В итоге качество снижается, потому что все горящие задачи — это то, что нужно сделать срочно, но что не очень двигает продукт.

▍ Про команду отдельно

У нас команда VDS-хостинга примерно в 8–10 раз меньше, чем принято на рынке. В смысле, в маркетинге, например, не 50 человек, а от 2 до 5 (в разные периоды) и так далее. Это, с одной стороны, очень помогает с точки зрения экономики — а с другой стороны, рождает некоторые ограничения.

Хорошая по эффективности команда — это когда отдел равен человеку. То есть один разработчик у себя в голове проводит все совещания (секунд так за 5), сам с собой договаривается про архитектуру, стек и решения и всё делает. Он точно знает, где и что лежит, какое у чего API и так далее. Рядом где-то один админ, который так же идеально понимает, как и что крутится. Маркетолог тоже один, но у него на случай тяжёлых задач есть фрилансеры или агентства.

Естественно, это возможно только в стартапе.

Когда админ заболеет, это абзац. А люди болеют, переезжают, ищут новые места работы, уходят на фронт, умирают по естественным причинам (у нас и такое было, увы), беременеют (теоретическая возможность относится примерно к половине сотрудников) и так далее.

Как после выхода со стадии стартапа вы начинаете дублировать инфраструктуру — два банка, два шлюза приёма платежей и так далее — так и начинаете дублировать роли людей. Минимум два админа (а лучше три) и так далее.

Дальше начинает падать эффективность на договорённостях внутри команды. Например, если разработчиков стало 5, то один из них становится тимлидом естественным путём. Растёт ли при этом его эффективность — далеко не всегда.

Что точно растёт — издержки на внутренние договорённости.

Потом начинаются сложности с заменой людей: поиск и онбординг занимают время (минус 2–3 месяца на этой роли каждый раз).

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

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

Например, в плане администрирования мы всё ещё обходимся достаточно малой командой и поэтому имеем возможность долго выбирать админов и долго с ними работать. В смысле, по 4+ года минимум сейчас, что очень много для сферы. Но здесь, когда мы говорим про админов, стоит сказать и пару слов про ИТ-рынок труда в целом.

▍ Пара мыслей про ИТ-рынок

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

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

Они приучают людей, что если вы девопс — то можно обновлять только сервер, только синий и только этот. Всё было бы ничего, если бы не сберовский же уровень оплаты: при относительно малых объёмах работы оплата там высокая. Лень людям не чужда, убивать квалификацию за такие деньги или готовиться к пенсии с 25 лет там — вполне нормально. Поэтому они уходят туда. В итоге как таковой экосистемы для развития фулстек-специалистов почти не получается, потому что всегда можно продолжать узко специализироваться и получать деньги в Сбере.

Другой пример — маркетинг. Там микрофрагментация специальностей. Это очень неудобно для небольших команд, но очень практично и удобно для крупного бизнеса. Если раньше маркетинг закрывался двумя людьми, то сейчас нужно минимум 3 и у каждого свой сектор. Если кто-то выпадает на больничный или в отпуск, вы работаете со скоростью 66 %, а один из секторов выпадает.

С другой стороны, в малом и среднем бизнесе ещё есть место как раз для людей с широкой квалификацией, способных затащить направление. Это как раз то, ради чего идут в такие проекты — сначала вы получаете кучу практического опыта, потом руководите направлением, потом, если проект в целом успешен, становитесь руководителем в среднем или крупном бизнесе. Ну или получаете резюме, с которым можно на пенсию в ИТ-гиганта. В малых компаниях ещё есть шансы получить опцион (чаще всего на стадии стартапа) и быть причастным к проекту, то есть почувствовать его своим. Для кого-то важно сделать что-то отличное от «винтика в большой системе», так что плюсы всё же у таких вакансий есть.

Есть ещё и третий тип команды — как у Телеграма, где вроде бы основная команда 60 человек, из которых 30 человек — разработка. Но именно в случае Телеграма как раз Дуров-то может позволить отбирать в ядро людей очень тщательно, потому что это уже не стартап, а для многих — мечта.

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

Но вернёмся в целом к рынку в России.

Вначале мы столкнулись с трудностями в поиске подходящих людей, поэтому привлекли шесть агентств и сами активно шерстили все доступные рекрутинговые сайты. Но «ищущий да обрящет» — мы всех нашли.

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

Это как с авиацией, конструктор и инженер — это просто разные профили.

Наша экономическая модель подразумевает гомогенное железо по всему миру, мы не сидим в PowerShell (потому что вручную администрировать 1–2 сервера ещё ок, но вот 200–300 уже не выйдет). Все типовые операции мы добавляем в бэклог и увеличиваем функционал админпанели. Это всё равно пришлось бы делать и в других моделях, но в нашей это ещё развитие продукта.

Во многих других хостинг-компаниях такое в принципе невозможно. Мы не используем распространённые коммерческие решения в виде админпанелей. У нас своя разработка, это накладывает специфику. С одной стороны, это значит, что у нас всегда должна быть разработка, и это не совсем выгодно на старте, с другой — надо поддерживать гомогенность железа и инфраструктур, но есть и очевидные плюсы, например, возможность лучше работать с сетями и защитой. Не автоматизируется замена дисков (зато хорошо аутсорсится поддержка ЦОДов), не автоматизируется, но аутсорсится осмотр железа.

В общем, квалификация админа нужна в понимании сетей.

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

▍ Итого

Итого мы пока умудряемся держаться малой командой. В бухгалтерии помогает абсолютно типовой процесс — всем одинаковый счёт, если клиент просит коррупционную схему с ретробонусом, то он идёт лесом в интерфейс. Некоторых это отталкивает, но наша политика — без таких вот индивидуальных договоров. Хотя бы по причине сложности их поддержки, если не говорить про законы и мораль. В администрировании — автоматизация, в разработке — фулстечность (а не как в крупняке, когда один видит, другой слышит, третий умеет читать). У нас нет сложных маршрутов ограничения прав для защиты от внутренних злоупотреблений — на малых командах с этим сильно проще. У нас нет огромного отдела кадров с психологической поддержкой, потому что это не нужно в малой команде. И так далее.

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

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

© 2024 ООО «МТ ФИНАНС»

Telegram-канал со скидками, розыгрышами призов и новостями IT ?