Отправить статью

Бизнес-коммуна: как построить горизонтальную структуру в IT-компании и не скатиться в хаос

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

Бизнес-коммуна: как построить горизонтальную структуру в IT-компании и не скатиться в хаос
Фото: Примавера
Сооснователь CRM «Пачка» и директор по развитию IT-компании «Примавера»
На заре 2000-х годов стартапы с их инновациями и более плоскими структурами начали всерьез конкурировать с вертикальными корпорациями. И это несмотря на производственные возможности гигантов. Так называемая top-down structure рано или поздно сталкивается с бюрократией. Идеи и указания путешествуют по этой вертикали неделями, и решения, необходимые компании для успеха на изменчивом рынке, принимаются слишком долго.

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

Стартап из стартапов: как мы шли к нынешней модели

Наша компания началась с того, что семь лет назад мы втроем со знакомыми попробовали силы в создании разных IT-решений, и один из наших облачных сервисов занял второе место на хакатоне TechСrunch Disrupt 2013 в Сан-Франциско.

Сегодня у нас уже 6 своих продуктов для бизнеса, а в компании работают более 40 человек. В таком режиме поддерживать системность в работе сложно, и необходимо было придумать какие-то правила игры, при которых человек может оставаться собой, а не пытаться втиснуться в строгие рамки. Расскажем, какой путь мы прошли и как организована работа сейчас.

Болезни роста

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

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

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

Привести себя в форму

Команда продолжала расти и составляла уже десятки человек. Недельные циклы окончательно сломались. Мы перестали даже выпускать обновления раз в неделю. Тогда мы поняли, что назрела пора меняться дальше, а через несколько месяцев у команды решения по управлению проектами Basecamp вышла новая книга Shape Up. В ней нас зацепил пример процесса, где совмещены качественное планирование и свобода творчества. Отдельная группа людей определяет рамки задачи, а команда сама решает, как в них вписаться.

Немного адаптировав их опыт, мы перешли на пятинедельные циклы, где было четыре недели активной разработки и одна неделя для мелочей и планирования. Так мы ушли от мелких задач к крупным проблемам и целям. Мы назвали их Большие штуки (БШ). Первый цикл прошел на «ура». Всем понравилось, что у разработки появился смысл и четкий результат.

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

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

Большие и маленькие штуки: как все устроено сейчас

Так мы решили взять лучшее из прошлых двух подходов. Наш текущий процесс состоит из Больших и Маленьких штук (БШ и МШ). Если кратко, то суть нового процесса в разных подходах к задачам разной сложности, объема и приоритета.

Большие штуки

Большие штуки занимают две недели и делаются в рамках двухнедельного цикла. У каждого участника команды может быть только одна БШ на цикл. В среднем в одной команде БШ 7 человек.

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

Маленькие штуки

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

Лидер и команда

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

Подведение итогов

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

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

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

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

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

Расскажем три наших главных принципа, что они означают и как работают на практике.

1. Зарабатывать доверие в коллективе и учиться доверять людям

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

2. Говорить и воспринимать правду

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

3. Не делать лишней работы самому и не давать делать другим

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

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

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

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

Если вы заметили опечатку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Деловой мир в
и
Деловой мир в
и
1 комментарий
Владимир Зонзов
30 октября в 06:37
Статью прочел "по-диагонали". Впечатление -- скептическое.
По теме статьи есть книга Г.Минцберка "Структура в кулаке". Там изложена теория базовых оргструктур.
Самоорганизация -- это ложь, паразитирующая там, где желательна базовая структура "адхократия".
0
0
Ответить
Отправить
Чтобы оставить комментарий, авторизируйтесь или зарегистрируйтесь