Или другой пример, в рамках разных секторов рынка IT - если ты набрал опыта по игрострою, то ты можешь использовать такие приемы, как «геймификация» в продуктах, не являющихся играми (вспомните Duolingo - штука для обучения, но цикл ее использования построен как игра).

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

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

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

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

Но мы рассмотрим еще более простой способ - это искать вдохновение, новые идеи и концепции совсем не в IT, но при этом подходящие под применение в IT, на стороне, как, например, делал Алан Кэй, один из разработчиков концепции ООП (объектно-ориентированное программирование), который вдохновлялся клеточной биологией, перенося поведение клеток на объекты в программировании, и при этом у него не было образования биолога - это было просто ему интересно.

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

Про наше масштабирование

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

И действительно, я вспомнил, как лет пять назад работал с одним польским издателем мобильных игр, представляя со своей стороны отечественную фирму-разработчика игр, и был удивлен тому, насколько одновременно грамотно у них поставлены процессы, и какие хреновые у них технические решения. Я тогда шутил, что это «высокоорганизационная поставка неверных решений». Т.е. хоть и от обратного, но наблюдение подтвердилось: мы, как и свойственно стране постсоветского пространства, имеем сильную инженерную часть (предположу, что это благодаря большому количеству специалистов из-за бесплатного образования), но при этом слабый организационный элемент в бизнесе (думаю, хоть мы и быстро построили капитализм, все-таки это такая история, которую сложно обогнать).

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

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

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

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

Пример кривого масштабирования

Для конкретики давайте рассмотрим известный мне случай:

Условная фирма «Есть кибертемка». Условные 8 программистов под прямым управлением Овнера (owner, владелец компании) за пару лет создают на костылях продукт (что нормально для выхода на рынок), который выстреливает и очень быстро завоевывает часть аудитории, подтверждает гипотезы и обеспечивает первый поток прибыли. Точно ясно - надо точно копать дальше, дело стоящее.

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

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

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

И при этом из изначальных 8 программистов ушли 4, 1 ушел к конкуренту, 1 судится за авторство идеи и оставшиеся 2 борются за то, кто будет тимлидом, подставляя друг друга и не успевая рассказывать новым программистам, как этот код вообще был написан.

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

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

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

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

Проектная модель и роли

Что пошло не так?

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

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

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

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

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

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

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

А при чем тут дрожжи?

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

Но есть вещи, которым нельзя обучить, их можно только впитать - это ценности и культура.

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

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

Нельзя написать список из пунктов «1. Будь честным. 2. Будь соучастным. 3. Будь крутым» и надеяться, что после прочтения данной инструкции человек станет честным, соучастным и крутым - это просто так не работает, а вот кринжа вызовет достаточно, если кто натыкался на такое.

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

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

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

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

На решение меня подтолкнуло то, как устроено производство сыра среди ремесленного бизнеса.

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

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

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

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

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

Выводы

Думаю, читателю уже очевидно, к чему я вел.

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

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

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

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

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

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

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

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

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

Поздравляю, у вас две команды.

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

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

Можно делать медленнее, последовательно, через зиро-команду, если этот процесс налажен и дает нужные результаты. Более медленную историю интеграции процессов проще контролировать.

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