Когда в команде больше семи человек, а руководитель продолжает ежедневно писать код и настраивать серверы — это настораживает. В большинстве ситуаций такой подход к управлению не идёт на пользу проекту. А ещё это выглядит как отсутствие доверия к сотрудникам, что тоже не очень хорошо.
За 20 лет я успел поработать и в стартапах, и в IT-гигантах, с командами из трёх человек и из сорока. Каждая новая конфигурация требовала менять подход к управлению — то, что работало вчера, переставало работать сегодня. В этой статье поделюсь своим взглядом, как подходить к управлению командой в зависимости от её размера и этапа развития проекта.
Сейчас я руковожу Поиском ВКонтакте, до этого работал с командами разного размера в Яндексе, Рамблере и парочке стартапов. Опыт подсказывает мне, что основная задача руководителя — постоянно ломать структуры, формировать новые и помнить, что через время это придётся делать снова.
Этапы роста команды
Самый первый этап — стартап с командой из нескольких человек. По мере развития и усложнения проекта она разрастается: 9–12 человек ещё укладываются в одну команду, редко — больше. На следующем этапе для проекта уже требуется две команды, постепенно количество специалистов вырастает до 40. Это этап, на котором нахожусь я.
Дальше есть ещё две стадии, с которыми мне работать не приходилось. Однако я позволил себе пофантазировать, опираясь на то, что вижу вокруг. Если компания большая, можно увидеть, что происходит в смежных подразделениях, научиться у руководителей или аппроксимировать свой опыт. Ещё я получил знания об устройстве системы управления в других компаниях, когда общался с рекрутерами. А также окончил курсы по бизнес-трекингу во ФРИИ — на них учили работать со стартапами, рассказывали, как правильно, а как нет.
Проект с нуля
В новом проекте руководитель может либо начинать со стартапа, либо прийти в крупную компанию и организовывать в ней новую команду. Эти два варианта различаются по своим подходам. Сперва расскажу про первый.
С чего начать в стартапе? Сначала нужно просто собирать продукт из того, что уже есть. Максимум — сделать лендинг, чтобы проверять бизнес-гипотезы. Строить команду в этом случае нужно исходя из поступающих задач, не загадывая наперёд. Людей стоит нанимать по мере необходимости с прицелом на горизонт планирования в 3–6 месяцев. А через год-полтора всё переписать заново.
Я считаю, единственно верный подход в новом проекте в стартапе: решать задачи по мере поступления и не заморачиваться с архитектурой, не стараться «делать правильно». Это частая «болезнь» тех, кто ранее работал программистом.
На старте карьеры я тоже был разработчиком на С++ и постепенно дошёл до руководства отделом в 20 человек. Это было 15 лет назад. Мы старались сразу делать всё правильно, поэтому наш стартап бесследно и скоропостижно завершился.
В действительно правильных стартапах так делать не стоит. Надо просто отдавать себе отчёт, что через год будет новый опыт, продукт надо будет менять, переписывать, и скорее всего, с нуля. Поэтому на старте можно попробовать себя в роли архитектора, который собирает Lego из элементов, существующих на рынке.
Я бы посоветовал на этапе запуска проекта экономить ресурсы и максимально использовать готовые, опенсорсные и мультиплатформенные решения.
Есть ещё один вариант развития нового проекта, который тоже имеет право на жизнь. Бывает, что основатель компании придумывает суперсистему и считает, что она нужна людям, не спрашивая пользователей. Во ФРИИ это называли «экспертизой головного мозга». Подобные стартапы часто уходят в производство без контакта с аудиторией. Если повезёт, и создатель компании угадал с потребностью аудитории, которую нужно закрыть, то проект продолжит своё развитие и выживет. Но статистика напоминает, что 98% стартапов через год умирают.
Когда основатели на 100% уверены в своей идее, команда строится сразу с техническим директором, проектируется архитектура, а горизонт планирования составляет 9–12 месяцев. Но если не повезло, и не удалось угадать, что нужно рынку, спроектированную архитектуру пытаются тащить дальше на новые изменения продукта. Это как чемодан без ручки: и тащить неудобно, и бросить жалко.
Третий вариант стартапа — это бесконечный цикл производства, когда следом за одной функциональностью руководителю хочется вторую, а потом третью… Этот процесс тянется бесконечно. Я в таком работал на старте карьеры, и производство продукта заняло пять лет. Мы тогда тоже делали поисковую систему. Строили команду и сразу продумывали архитектуру, нанимали сотрудников.
В такой системе критерий качества исходит от определённой группы лиц, а не от пользователей и рынка. Нет опоры на спрос аудитории, и все участники процесса не очень счастливы.
Создание нового продукта в крупной компании
В проектах крупных компаний есть особенности: команды растут медленно, а во время запланированного роста возникают внешние факторы. Например, фриз найма. Также значение имеет готовность HR к найму и степень развития HR-бренда.
Представьте человека, который приходит руководить новым проектом в крупную компанию, а там уже есть два бэкенд-разработчика. В этом случае руководителю важно ориентировать их на высокоуровневые цели компании. Например, у организации есть цель привлечь больше пользователей или зарабатывать деньги. Если ранее эти два разработчика пилили какой-нибудь очередной новый движок, то они должны перестать это делать и заняться тем, что нужно компании. Это первоочередная задача, когда руководитель попадает в такой проект.
Если нанять ещё одного разработчика, встаёт вопрос — какие задачи выбрать для него и как распределить ответственность. Чтобы найти ответ, необходимо посмотреть, какие задачи выделены под вакансию или начать работать с болью пользователей. Обычно у большой компании уже есть рынок, аудитория, и нужно ориентироваться на её потребности. Но также компания имеет цели, которые нужно соизмерять с потребностями аудитории. При этом важно не забывать, кто главный пользователь. Часто, прочитав книги по продакт-менеджменту или окончив курс, руководитель проекта идёт к боссу и говорит, что лучше знает, что нужно пользователю. Только компания — это тоже его пользователь. И, как правило, он важнее, чем пользователь с рынка, потому что именно компания платит зарплату руководителю подразделений, а босс компании определяет направление её развития.
Когда в команду приходит третий разработчик, руководитель становится полноценным тимлидом. Но каждый разработчик команды по-прежнему отвечает за высокоуровневые цели. На этом этапе развития желательно строить работу так, чтобы три разработчика из четырёх не отвлекались на прилетающие извне задачи и не отрывались от существующих планов. Ещё лучше, если все четверо будут заниматься своими запланированными делами, а все поступающие задачи удастся решать ресурсами смежных команд. Если постоянно отвлекать команду прилетающей текучкой, то план на полгода или год можно не выполнить.
Когда в команду приходит пятый разработчик, у лида проекта должна появиться полноценная замена. Это очень важно. Наступило время перестать быть тимлидом. Кто-то из команды должен начать выполнять функции лида, а руководитель — заботиться о дальнейшем развитии и задавать направление работы.
Чтобы человек стал полноценной заменой лиду, нужно нанимать таких людей, которые способны его заменить. Скорее всего, они будут в чём-то лучше, и, наверное, благодаря этому руководитель сможет чему-то научиться и стать сильнее. Это очень хороший шанс. Но у тимлидов всегда есть страх: а вдруг новичок займёт моё место?
На самом деле, именно это и необходимо. Руководитель наверняка хочет расти — значит, ему нужна замена. А он сможет пойти дальше.
Банальная истина: если руководитель не может отдать своё место, то не сможет расти.
Следующая ступень, когда в команде от пяти до девяти человек. Есть золотое правило эффективной системы управления: любая команда — это семь плюс-минус два человека.
Когда в команде от пяти до девяти человек, то должна быть часть людей, которые отвечают за core-функциональность. Этим следует заниматься тимлиду, который пришёл на замену руководителю. Последний же берёт маленькую часть команды, начинает делать новые подпроекты и думает, куда инвестировать время, чтобы развивать продукт или проект.
Новый, начинающий лид руководит большей частью команды (это важно), а руководитель — меньшей, потому что у него должно быть больше времени на развитие.
Зрелый проект
Проект можно назвать зрелым, когда команда доросла до 9–16 человек. На картинке я показал, каким вижу её идеальный состав.
Команду нужно разделить на две части:
Команда discovery: продакт и дизайнер, ещё, возможно, бизнес-аналитик.
Команда delivery: проджект, фронтенд-, бэкенд- и ML-разработчики, тестировщик и DevOps.
Важно, что продакт не должен делать работу проджекта. Как в анекдоте: «Уличный музыкант сидит перед банком и играет на скрипке. В шляпе лежит мелочь. К нему подходит человек и просит разменять деньги. А скрипач отвечает, что у них с банком договор — банк не играет на скрипке, а он не даёт размен». Точно так же продакту и проджекту нельзя мешать одну работу с другой. Продакт заботится о будущем, а проджект — о настоящем. При этом проджект достаточно глубоко погружается в продукт и особенности работы команды, чтобы понимать, как декомпозировать все поступающие фичи.
У меня был случай, когда я пришёл в сформированную команду работать продактом. Начал вникать в дела и понял, что можно быстро поднять доход, если предпринять определённые шаги. Проджект предложил мне заводить задачи в Jira под каждую новую функциональность. В результате никакого Scrum, и весь процесс сломался. Я по факту выполнял задачи проджекта и продакта, а проджект заскучал и со временем уволился. Какое-то время мы обходились без него. Оказалось, что можно работать и так, но тогда эту функцию должны выполнять продакт или лиды. В такой системе мы просуществовали недолго, и через какое-то время проджекта всё-таки наняли. Но такого, который был способен заменить меня. Вскоре мне предложили работу ВКонтакте, и я ушёл.
Очень важный момент: когда в команду приходит хороший специалист, проект должен сразу расти. Либо рост возможен в этой команде и компании, либо он случится в другом месте, куда уйдёт специалист.
Совсем зрелый проект
На определённом этапе сотрудников становится слишком много для одной команды
Когда в команде от 12 до 20 человек, она становится совсем зрелой. На этом этапе руководителю нужно перестать быть человеком, управляющим чем-то. Необходимо, чтобы в подразделении была минимальная рабочая единица, которая способна самостоятельно запускать и делать продукт. Всегда есть желание поуправлять, но лучше пусть оно останется просто желанием.
Мой совет для расширения команды зрелого проекта: не стоит нанимать продакта, лучше — руководителя команды.
Главному руководителю необходим человек, который умеет управлять командой, знает, чем она занимается и в каком направлении будет развиваться продукт. У человека с опытом проджектовой и продуктовой работы есть навык декомпозировать задачи. Он понимает, что делают разработчики, умеет работать с аудиторией, представляет, что ей нужно, как это анализировать, по каким метрикам строить. Он должен создать полноценное мини-подразделение в команде. Одной частью людей продолжит управлять руководитель, а второй — заместитель, у которого должна быть группа побольше.
При всех структурных изменениях важно сохранить эффективность. Нужно понимать, что до появления продакта эффективность работы команды зависела не только от руководителя, но и от его тимлидов. Это очень существенный момент, и я благодарен людям, которые со мной работают, за то, что они помогают.
Когда мы разделили сферы ответственности с новым продактом, первоначально у нас получилась структура управления с горизонтальным делением.
Задачи, которые я привык решать, оставил себе, а те, что не хотел, отдал продакту. Ему ушли все продукты, которые пользователь мог почувствовать. Всё остальное осталось мне. Получилась достаточно кривая система, потому что для части визуальных задач нужны были бэкенд-разработчики и ML-специалисты. Поэтому продакт приходил ко мне за ресурсами, а мне приходилось делать дополнительную работу — приоритизировать задачи и распределять людей. Для более эффективной работы предлагаю другое деление — вертикальное.
В этой системе руководитель отвечает за одну часть проекта, а продакт — за другую. Однако есть риск, что где-то просядет эффективность. Поэтому нужны лиды, которые помогут и будут контролировать процесс. Руководитель в этом случае управляет подразделением и продуктовой линейкой в нём.
Большой проект
Если в команде от 20 до 40 человек, в проекте могут быть три продуктовые линейки, которые ведут отдельные руководители. Тогда можно использовать систему, где у каждого продакта есть часть, за которую он отвечает.
Только непонятно, что в такой системе делать лидам. Они постепенно выходят за контур производства. В этой структуре лиды могут стать руководителями подразделений. У меня в целом так и случилось. Никто их не заставлял. Кто захотел и проявил инициативу, постепенно стал руководить целыми командами и продуктовыми линейками. Появляется ещё один вопрос: что же делать главному руководителю?
Что продолжать делать руководителю
Заниматься стратегией. Варианты работы для руководителя: усиливать слабые места, запускать новые направления, думать, как ломать неэффективную структуру и строить новую, планировать дальнейшее развитие команды, выводить систему из равновесия.
Развивать команду, продукт, проект и процессы. Необходимо, чтобы вся система управления не превратилась в сплошные процессы. Пусть они будут немногочисленными, но эффективными.
В моём случае добавилась минимум одна встреча с руководителями подразделений, на которой мы смотрим на всё, что неэффективно, и пытаемся придумать решение. Если в рамках существующей системы находим решение, то внедряем его. Если же нет, то ищем, какой новый процесс должен возникнуть. К счастью, пока этой дополнительной встречи хватало для оптимизации работы.
Развитие продолжается
Я не руководил командой больше 40 человек. Позволю себе предложить систему, которая могла бы быть. Я наблюдал её в Яндексе и наблюдаю ВКонтакте.
Это не единственная возможная система управления. Когда растёт число продуктовых лидеров и каждый управляет своим подразделением, очень важно, чтобы все руководители отвечали за какую-то минимальную бизнесовую единицу. И чтобы по возможности было минимум перекрёстных связей между подразделениями.
Свыше 100 человек
Когда в команде станет больше 100 человек, подходы к управлению вновь будут меняться. Но пока для меня это далёкий горизонт. Здесь, как мне кажется, могут появиться продакт-лиды или руководители бизнес-юнитов. У каждого продакт-лида есть целый мини-продукт, а в нём продуктовые линейки или стримы, которыми руководят продакты.
Новый размер — это новые процессы, которые должны появляться. Но нужно строить команду и нанимать людей, чтобы работа не превратилась в сплошной контроль и процессы. Доверие важно, но оно зависит целиком от руководителя, потому что он формирует свою команду. Самое главное — процессы должны меняться.
Основные инструменты управления в проекте
Инструменты в случае управления в команде — не конкретные программные продукты. Это то, что мы должны взять как стадии, как чеклист. Прежде всего у руководителя должны быть цели и способ их достижения — roadmap, проекты, фичи и регулярные встречи с командой.
Цель, как правило, измеряется численно, и это то, что мы хотим получить к концу года. Горизонт планирования у этой истории примерно год. У нас ВКонтакте это называется инициативами. Важно работать на изменение конкретного параметра: больше денег заработать, больше аудитории привлечь, повысить конверсии.
Roadmap
Roadmap — способ достижения целей. Если мы хотим попасть из точки A в точку B к концу года, то наполняем roadmap определёнными проектами, задачами, которые помогут нам добиться желаемого.
Фичи, эпики, спринты, разные названия — это уже конкретные задачки, которые мы делаем обычно в рамках квартала.
Какие методы использовать
Scrum, Kanban, Waterflow, Agile — это лишь способ встроиться в команду или выстроить процесс на достижение цели к концу года.
Какой из этих способов выбирать, неважно. Главное, чтобы выбранная методология была комфортна команде и помогала достигать поставленных целей. Можно вообще работать в чате мессенджера, если для вас это эффективно.
Daily или стендапы
Нужен ли стендап или ежедневный созвон? Часто это организует и помогает команде собраться. Единственный плюс от стендапа, который я наблюдал — команда таки собиралась к 12:00 в офисе. Всё это было до пандемии. Но сидеть рядом друг с другом не обязательно, вполне достаточно ежедневно получать сообщение в чатике команды.
Weekly
На мой взгляд, еженедельная встреча всей команды обязательна. Спринты могут быть даже месячные, но раз в неделю надо собираться всей командой. Речь про подразделение до 40 человек. Собрать вместе 100 человек, наверное, будет сложно. Но раз в неделю каждое подразделение должно полностью собираться, и все должны друг друга слышать хотя бы онлайн.
До очной встречи у меня все — и разработчики, и тестировщики, и аналитики — пишут, что они сделали за неделю. Это фокусирукт, заставляет обдумать сделанное идаёт каждому личную ответственность перед другими людьми за то, что он делает.
Особенности работы на удалёнке
Был опыт, когда наступила пандемия, и мы все разошлись по домам. Тогда я обрадовался, так как до этого 15 лет проводил в дороге с работы и на работу минимум три часа в день, поэтому в тот момент удалёнка была просто счастьем. Как оказалось, не все разделяют такую позицию — многим нужен офис. Особенно если человек живёт один. Рабочий коллектив для него — семья, и это важно учитывать. Это способ получить живое общение. Поэтому важно при работе с командой, так же как и при работе с вашей аудиторией, ориентироваться не только на себя. Нужно смотреть, как команда реагирует, что сейчас болит и что для неё важно.
Главное — цель
Не так важно, в какой организации вы сейчас работаете, на каком уровне развития она находится и какой у вас размер команды. Методология и инструменты тоже играют не первую роль.
Важно добиваться целей, которые стоят перед вами, чтобы прийти из точки A в точку B. Всё остальное должно работать на достижение целей команды и бизнеса. Если они не противоречат друг другу, а находятся в гармонии и дополняют — руководитель всегда достигнет намеченного результата.
В основе статьи — доклад на Saint TeamLead Conf 2023. Вы можете посмотреть запись выступления.
Там же, на канале TeamLead Conf, в хабе компании Конференции Олега Бунина, в блоге VK и сообществе VK Team будет ещё много статей и докладов об управлении и масштабировании. Актуальность этой темы вряд ли когда-нибудь изменится: окружение и внутрянка будут продолжать меняться и надо будет догонять запросы рынка и времени, чтобы успевать меняться следом за ними. Остаёмся на связи, впереди новые кейсы, основанные на профессиональном опыте, и другой полезный контент.