От разработчика до руководителя. Менеджмент для IT-специалистов Фурнье Камиль

9

Культура бутстрэппинга18

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

В Rent the Runway у меня была возможность самой создать многие элементы культуры команды инженеров-разработчиков. Поскольку на тот момент команда являла собой типичную для стартапов нечетко структурированную модель, я смогла внести много нового и в культуру собственно команды, и в ее работу. Этот процесс стал для меня большой школой.

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

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

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

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

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

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

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

Одна из очень интересных работ об организационной политике в компаниях — статья известной деятельницы движения за права женщин Джо Фриман «Тирания бесструктурности»19. Хотя описываются ранние этапы существования феминистских и анархистских организаций, многие положения могут быть применены и к культуре стартапов. Внешнее отсутствие организационной структуры обычно сопровождается скрытой борьбой за доминирование различных групп, что неизбежно следует из природы человеческого общения. Интересно, что Фриман, в частности, описывает условия существования групп без прочной организационной структуры.

Такая группа должна быть полностью ориентирована на решение определенной задачи. Функции такой группы обычно бывают очень ограничены и конкретны, например организация конференции или выпуск газеты. Сама стоящая перед группой задача структурирует ее. Задача определяет, что должно быть сделано и когда. Она задает ориентиры, по ним люди могут сами оценивать свои действия и планировать будущую деятельность.

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

В такой группе должен существовать высокий уровень взаимопонимания. Информация в такой группе должна достигать каждого, мнения людей должны быть взвешенными, работа поровну разделена между всеми, члены группы должны принимать участие в принятии соответствующих решений. Это возможно только в небольшой группе, когда коллеги практически живут бок о бок на протяжении важнейших этапов решения задачи. Нет необходимости говорить, что количество внутренних связей в такой группе, охватывающих каждого, увеличивается с численностью группы. Это с неизбежностью ограничивает ее примерно пятью членами или приводит к тому, что остальные не смогут принимать участие в принятии решений. Успешные группы могут включать в себя и 10–15 человек, но при условии, что фактически они состоят из более мелких подгрупп, выполняющих конкретные части общей задачи. Такие подгруппы должны «перекрывать» друг друга, с тем чтобы информация о том, что каждая из них делает, легко могла бы распространяться по всей группе.

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

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

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

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

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

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

В небольших компаниях, напротив, более распространен запоздалый ввод элементов организационной структуризации. Проблемы в таких компаниях возникают незаметно. Один человек привыкает принимать все решения и часто их меняет. Такая стратегия работает в мини-организации, где есть только он и еще пара людей. Но когда такая схема применяется при работе с командой из 10, 20, а то и 50 человек, то сразу становится заметным высокий уровень взаимного непонимания и затраченных впустую усилий. Цена изменения решений становится все более высокой.

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

Оценка своей роли

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

Персонал

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

Возраст компании

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

Размеры существующей инфраструктуры

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

Порог рисков

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

Организационная структура компании растет по мере ее роста и возраста. Есть даже закон, описывающий эту связь. Он приводится в книге Джона Галла «Системантика»21:

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

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

Мой совет руководителям прост: когда случаются неудачи, исследуйте все аспекты окружающей действительности, приведшие к ним. То, что вы увидите, станет возможностью совершенствовать организационную структуру предприятия либо за счет создания дополнительных вариантов, либо за счет отказа от некоторых. Обдумайте вопрос, как часто вашу организацию постигают неудачи, сколько они стоят, и постарайтесь вынести оптимальное суждение относительно необходимых перемен. Использование неудачи как компаса для развития позволяет применять организационную структуру на нужном уровне. Если неуспех случается только в части системы (например, в одной из команд), можно осуществить структурные изменения только там, не затрагивая всей организации. А как с анализом успехов? Что же, вы можете кое-чему научиться на примере успеха, но, как правило, он плохой учитель. Как ни смешно, хотя судьба зачастую играет одинаковую роль и при успехе, и при неудаче, мы в большинстве случаев приписываем неуспех невезению, а успех — собственным действиям. Как гласит закон Галла, работающая простая система может развиться в систему сложную. Но это не означает, что применение уроков, полученных из успешной сложной системы, может позволить нам повторить успехи в других местах. Будучи людьми, мы склонны винить в неудачах фатум до тех пор, пока становится невозможным игнорировать собственную роль в них. Поэтому мы не слишком торопимся реорганизовывать структуру команд на основе опыта неудач. Напротив, успех заставляет нас верить, что везение позволит и дальше достигать высот. Но помните, что необходимо реально оценивать шансы на улучшение дел при более широком применении уроков успеха. Не забывайте, что для повторения успеха нужно хорошо понимать необходимый контекст.

В этом вопросе важную роль играют возраст компании и размер команды. Если вы работаете в организации, существующей уже в течение приличного времени и имеющей шансы на дальнейшее существование, эксперименты с организационной структурой (расширение или сокращение), нацеленные на повышение эффективности, могут быть очень полезны, даже если на первом этапе они окажутся весьма затратными. Это часть сделки. Обучение редко обходится бесплатно. Анализ ситуации и стремление к позитивным результатам требуют времени. Ваше время в будущем стоит меньше, чем в настоящем. Поэтому не следует слишком беспокоиться об экономии времени в будущем. То, что компания большая, имеет солидную историю и стабильна, еще не означает, что ее структура может быть такой жесткой и неизменной, как вы хотите. Изменения в технологиях часто делают рискованные в прошлом действия более безопасными по сравнению с неповоротливыми вариантами. Хороший пример — частота релизов. Частые релизы долго были трудным и дорогим делом. В значительной степени это происходило потому, что компании выпускали свое ПО потребителю в неизменном виде. Сегодня же, когда программное обеспечение стало услугой (SaaS)22, недочеты в нем могут быть легко устранены уже по ходу использования. Поэтому риски, связанные с изданием ПО, значительно снижаются по сравнению с небыстрой разработкой, что негативно влияет на конкурентоспособность продукции. Привязанность к старым понятиям структурности мешает многим людям воспринимать ее как таковую. Но если вы не признаете необходимость организационной структуры тогда, когда она нужна, то дела у вас могут пойти совсем плохо.

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

Создание собственной корпоративной культуры

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

Фредерик Лалу. Открывая организации будущего23

Тема культуры часто обсуждается при создании стартапов. Каковы базовые ценности компании? Что представляет собой ее корпоративная культура? Соответствуют ли ей новые работники? Или концепция «соответствия культуре» — всего лишь отговорка для дискриминации людей при приеме на работу?

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

Итак, что же такое культура? В обычном понимании — набор неписаных и разделяемых всеми правил поведения в обществе. Например, в американской культуре мы обязаны пожимать друг другу руки при встрече. Но у некоторых других народов прикосновение к другому человеку рассматривается как нечто очень странное и непривычное. Часть вашей культуры — то, как вы обращаетесь к людям с разным социальным положением или разным уровнем отношений с вами. Культура не подразумевает того, что каждый отдельный индивидуум разделяет одни ценности. Однако она руководит нами тогда, когда наши интересы пересекаются с интересами других людей, и создает определенный свод правил, которыми вы, не задумываясь, руководствуетесь во взаимоотношениях. Конечно, если вы глубоко вписались в соответствующую культуру.

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

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

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

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

Как это относится к вам? Если вы ответственный руководитель технической сферы, соучредитель или технический директор, все вышесказанное глубоко вас касается. Если вы создаете компанию с ценностями, сильно отличающимися от ваших личных, вы почувствуете шероховатости, осложняющие вашу жизнь. На верхних этажах руководства компаниями элементы корпоративной культуры глубоко пронизывают все, чем вы занимаетесь. Ведь значительную часть рабочего времени вы проводите в переговорах, налаживании взаимоотношений между людьми и командами, выполняющими различные функции. Это не означает, что вы не можете быть успешным в компании с другими, чем ваши, ценностями. В действительности редко бывает, что личные ценности каждого члена компании совпадают с общими. Ведь, скорее всего, вы не разделяете любую ценность всякого члена вашей семьи или друга! Однако то, какое количество ваших ценностей совпадает с ценностями команды, будет в значительной мере определять легкость вхождения в коллектив.

Применение базовых ценностей

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

Во-первых, определитесь с собственной культурой. Если перед вами набор ценностей компании, примерьте их на свою команду. Вы можете добавить пару ценностей, особенно важных для вашей команды, или интерпретировать ценности компании в нужном команде ключе. Например, в компании Rent the Runway мы особенно ценили разнообразие. Это означало, что при знакомстве с потенциальным работником нас больше интересовал его потенциал и разнообразие возможностей, чем умение правильно расставить птички в стандартных текстах на собеседовании. На высших позициях среди ценностей компании мы помещали способность учиться новому, потому что были уверены в важности этой ценности для нас, инженеров-программистов. Смысл в том, что каждая субкоманда могла сформировать свою, несколько отличную от общей, корпоративную культуру. Некоторые команды обращают особое внимание на высокую профессиональную подготовку членов, четкое соблюдение обычного расписания рабочих часов и режима работы в целом. Другие предпочитают придерживаться более раннего начала рабочего дня, или более позднего его окончания, или более свободной атмосферы на совещаниях, позволяющей неформальное общение.

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

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

Учитесь определять тех, кто не разделяет ценности компании или команды. Если в вашей компании нормально закатывать рукава и включаться в общее дело, тот, кто регулярно «подбрасывает» свою работу другим, явно не придерживается ценностей компании. Если компания провозглашает ценностью «радость и позитивность», тот, кто пыхтит на каждую идею и все критикует, с трудом сможет вписаться в коллектив. Иногда люди изменяют поведение, воспринимая ценности компании. «Радость и позитивность» — в действительности одна из базовых ценностей компании Rent the Runway. А я не могла сказать о себе, что пришла туда из организации, где ценилась радость. Даже более того, я пришла из корпоративной культуры, характеризующейся как исключительно узкопрофессиональная и критиканская. А в Rent the Runway я научилась смотреть на вещи оптимистично. Это не значит, что я полностью утратила прошлый критический подход и позитивный взгляд дался мне легко. Вообще, использование базовых ценностей, чтобы объединять людей, если они разъединены, может помочь формулировать ясные мысли вместо расплывчатых.

Используйте категории базовых ценностей в собеседованиях с кандидатами. Расскажите им о ценностях вашей команды и попросите описать те позиции, где, по их мнению, им будет легко или, наоборот, сложно встроиться в команду. Во многих собеседованиях применяется так называемый «маркер дружественности». Будущая совместимость кандидата с культурой компании определяется ответом на вопрос: «Хотели бы вы застрять с этим человеком в аэропорту?» Конечно, вы не заинтересованы принимать на работу человека, чье присутствие ваша команда вряд ли вынесет. Но подбирать людей, совместимых с корпоративной культурой, не то же, что подбирать друзей. У меня были прекрасные рабочие отношения с теми, с кем я вряд ли захотела бы часами общаться вне работы. И ужасные деловые отношения с теми, с кем я с удовольствием застряла бы в аэропорту. Более того, если совместимость с культурой компании измерять по тесту на дружбу, то результат будет всегда в каком-то смысле дискриминационным. Обычно люди вступают в дружбу с теми, с кем их связывает некий опыт: совместное обучение, принадлежность к одной расе, социальному классу или полу. Если вы думаете, что друзьям легче разделить общие ценности, то помните: это не всегда то, что нужно для формирования сильной команды.

Поэтому никогда не допускайте двусмысленности при обсуждении с кандидатом его возможной совместимости с компанией. Будьте очень конкретны. В чем состоят ценности данной организации, подходящие или не подходящие кандидату? Очень хороший программист, в работе ценящий превыше всего независимость, может не подойти команде, где прежде всего ценится тесное сотрудничество в работе над проектами. Человек, верящий, что в споре побеждают только аналитические аргументы, может не вписаться в команду, если там сочувствие и интуиция ценятся выше голого расчета. Я привожу примеры потому, что все эти ценности совместимы в одних ситуациях и несовместимы в других. Именно поэтому они так важны. Правильно понимайте ценности вашей компании, вашей команды и ваши собственные. Запишите их на бумаге, если они еще не записаны, при этом постаравшись выразить их как можно точнее. Используйте список при оценке кандидатов, выражая похвалы членам команды и доводя до них ваши заключения по работе.

Подготовка документов, касающихся корпоративной культуры

Разработка документации, касающейся корпоративной культуры компании, — сложный процесс, начать эту работу с нуля действительно трудно. К счастью, в настоящее время остается все меньше документов, которые действительно приходится создавать с самого начала: все больше компаний пользуется уже существующими положениями о корпоративной культуре, начиная от норм карьерного роста до шкалы оплаты труда и управления конфликтами. Однако зачастую наличия отправной точки и простого ее копирования недостаточно. Я поняла это на своем горьком опыте, когда впервые попыталась создать должностное расписание в IT-компании. Как я уже говорила, иногда наступает время, когда необходимо добавлять в работу элементы организационной структуры. И зачастую это происходит в момент неудач. Неудача, подвигшая меня на создание новой должностной сетки, постигла наш отдел персонала, когда оно проводило анализ расписания заработных плат у инженеров-программистов. Тогда я поняла, что у нас вообще нет системы заработной платы. Из-за этого многие работники получали ее в размерах, зависевших от зарплат на прошлых местах работы и способностей как переговорщиков. Вдобавок в то время мы с трудом понимали, каких работников нам надо нанять. Только ведущих инженеров? А что предпринимать в отношении менеджеров и других должностей?

В ответ на просьбу отдела персонала я засела за создание системы должностей, уже показанную отдельными фрагментами в данной книге. Я спросила у друзей, имевших свои стартапы, нет ли у них такой системы. У одного она была, и он поделился со мной. Система должностей имела восемь уровней, от начинающего программиста до исполнительного директора. Все должности были разделены по четырем категориям: технические, организаторские, «должности влияния» и руководящие. Я взяла схему, дополнила некоторыми деталями, переименовала уровни и выпустила в свет. Схема была очень простой. Для каждого уровня и специальности имелась всего пара предложений, характеризовавших требования к работнику. Даже с моими дополнительными замечаниями каждую категорию характеризовало не более четырех пунктов. Хуже всего были описаны должности начального уровня. Я довела новую должностную сетку до своей команды, сделав это в той же манере, что и мой друг, доводивший ее до своей команды. Я сказала, что новое должностное расписание должно обеспечить справедливость в оплате труда. Его можно использовать в беседах с менеджерами относительно служебного роста. Еще я сказала, что члены команды не должны зацикливаться на своем уровне. Потом я рассказала им о блоге Джона Олспоу «Что значит быть ведущим инженером», пытаясь побудить к движению вперед.

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

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

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

Создание должностного расписания

Ниже я привожу некоторые важные соображения. Ими следует руководствоваться при формировании должностного расписания в организации.

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

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

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

Используйте описания и в подробной, и в обобщенной форме. Я разбила расписание на два документа. Первый представлял собой довольно краткую таблицу, позволявшую мне одним взглядом окидывать должностные обязанности разных уровней и видеть, как они возрастают по мере повышения уровня должности работника. Это очень помогало, потому что по мере написания документа я могла видеть переход от одного уровня к другому и то, как расширяется объем работы сотрудника, набор необходимых навыков и умений, а также возрастают обязанности. Второй документ представлял собой расширенную версию первого. Его написание тоже помогало мне, потому что я могла изложить полное представление об исполнителях той или иной должности на том или ином уровне. Вместо того чтобы только зримо очерчивать набор навыков и качеств, необходимых работникам, полная версия должностного расписания, словно хорошее заключение по работе, дает описание работы сотрудника на том или ином уровне. Вы — и ваши сотрудники — можете увидеть, как профессиональные навыки взаимодействуют при росте адекватного данной позиции работника. Сколько уровней должно быть в вашем должностном расписании? Для ответа на этот вопрос вы должны ответить на два следующих: 1) как вы оплачиваете труд работников? 2) как вы оцениваете их особые достижения?

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

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

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

Там, где у вас меньше должностных уровней, используйте более широкие вилки зарплат. Меньшее количество должностных уровней и широкие вилки зарплат четче разграничивают уровень профессиональной подготовки, необходимой для каждого уровня. В таком случае становится легче определить, кто работает на каком уровне. При значительном разбросе должностей необходимо иметь более широкие диапазоны заработной платы, в идеале перекрывающие друг друга. Так, скажем, если инженер-программист получает зарплату в диапазоне $50 000–100 000, то «вилка» для ведущего инженера-программиста может составлять $80 000–150 000. Это означает, что сильный инженер-программист может зарабатывать больше ведущего инженера. Такой люфт нужен, чтобы удержать талантливых инженеров, хорошо работающих на достигнутом промежуточном должностном уровне, но еще не готовых взять на себя дополнительную ответственность, связанную с переходом на следующую должность. Этот же люфт хорошо работает при найме новых работников, готовых прийти в вашу компанию на более низкие должности в надежде на скорое продвижение по службе.

Внимательно относитесь к «горячим точкам» роста сотрудников. Распространено наличие в компаниях определенных должностных уровней, называемых «вверх или в сторону». На начальных должностных позициях долгое отсутствие карьерного роста может означать, что сотруднику пока не удалось достигнуть зрелости и независимости в работе, нужных, чтобы остаться в компании. В должностном расписании это открытые или скрытые точки разрыва. А каков в вашей организации самый низкий должностной уровень, где люди могут находиться всегда, не продвигаясь по карьерной лестнице, но вместе с тем и не работая плохо? Этот уровень в компании — критическая точка. Во многих случаях он располагается где-то вокруг должностной позиции ведущего инженера-программиста. Тот, кто находится в ней, зачастую надежный член команды, но по собственному выбору может оставаться на ней неопределенно долго. Следует ясно видеть критические точки в вашей организации. Вы даже можете использовать их, чтобы ясно представлять себе, с какого именно должностного уровня карьерный рост в вашей компании становится делом непростым. Лучше, если большинство членов команды будут находиться в этой точке, а меньшинство — выше или ниже.

Признавайте достижения. В некоторых компаниях стремятся хранить информацию о должностных уровнях в секрете. Но это невозможно. Люди всегда будут говорить друг с другом. В принципе, можно выйти из положения, нарочито выделяя определенные уровни, храня данные о других в секрете даже от сотрудников. В некоторых кадровых подразделениях существуют сетки заработных плат, никак не связанные с должностным расписанием. Я не сторонник таких вариантов. Однако считаю, что хотя бы определенные должностные уровни могли бы быть некими вехами продвижения работников по карьерной лестнице. Весь персонал признаёт их таковыми и радуется назначению коллег на них. Я считаю, что должность ведущего инженера-программиста — важное достижение. Точно так же как повышение штатного инженера до уровня главного инженера-разработчика (если у вас в компании есть такая должность). Что касается менеджмента, то человеку, разумеется, следует праздновать назначение на пост директора, равно как и вице-президента. Разделение таких вех в должностном росте определенной дистанцией дает людям мотивацию стремиться к очередной позиции не только ради получения более высокой зарплаты, но и в силу того, что такая должность может быть важна с точки зрения дальнейшей карьеры.

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

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

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

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

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

Кроссфункциональные команды

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

Я хочу уделить немного времени рассказу об одном замечательном опыте, вынесенном из работы в Rent the Runway, онлайн-сервисе аренды одежды. В ней была создана команда, совмещавшая функции разработчика ПО и подразделения по продуктам. Когда я пришла в компанию, команда инженеров-программистов была разделена примерно на две части: фасадную, занятую разработкой клиентской части сайта, и складскую, занимавшуюся поддержкой программного обеспечения, которое управляет логистикой. Мы быстро сделали так, что фасадная часть команды стала заниматься и пользовательским интерфейсом, и программно-аппаратным обеспечением, потому что переписывала код с РНР-монолита на микросервисные архитектуры, построенные на языках Java и Ruby.

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

Проект оказался очень успешным. Мы довольно быстро создали хорошую программу, причем все участники команды были довольны, потому что ясно понимали цели проекта и могли работать эффективно в составе многофункциональной группы. До этого проекта мы были сильно привязаны к схеме «мы против них». Главными были «мы» (инженеры, специалисты по продукту, аналитики, маркетологи), а вся остальная организация — «они». Новая схема была удачей в плане организационного здоровья команды. Поэтому мы решили, что во всей организации разработка нового продукта (в том числе и в смысле информационных технологий) должна строиться на основе таких кроссфункциональных групп. Их можно называть по-разному — «небольшая стая», «отряд» или «опорная колонна», — но многофункциональные образования становятся все более популярными по вполне определенным причинам. Объединяя работников, нужных для успешного осуществления проекта, мы тем самым помогаем им концентрироваться на проекте и делаем коммуникацию внутри группы гораздо более эффективной.

Закон Конвея24, часто упоминаемый в дискуссиях, гласит: «Организации, осуществляющие дизайн систем… часто обречены на то, что системы копируют структуру общения в самих организациях».

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

Организация кроссфункциональных команд

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

Разумеется, каждое функциональное направление сосредоточивается на конкретных обязанностях. Кто-то из инженеров-программистов контролирует создание базовых систем, и вокруг него работает несколько специалистов, занимающихся базовым веб-приложением, мобильными приложениями и базами данных. У меня эти функции были сосредоточены в небольшой инфраструктурной группе, непосредственно разработкой продукта не занимавшейся. Даже в подобных группах инженеры, разрабатывавшие конкретный продукт, должны иметь некоторый резерв времени, чтобы заниматься такими вещами, как помощь пользователям по телефонным звонкам (дежурства on call), интервьюирование пользователей или поддержка программ. Я на основе личного опыта и опыта коллег рекомендую, чтобы 20% рабочего времени инженеров-программистов отводилось на эту работу.

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

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

Я не стараюсь навязывать свое суждение, но призываю всегда понимать разницу между ориентацией на продукт или бизнес и ориентацией на технологии. Руководствуйтесь каждой там, где целесообразно. Что по-настоящему важно для успеха компании или организации? Если создание продукта, сочетающего разные стороны бизнеса, то вы, видимо, заинтересованы в лидерах, бизнес-интересы понимающих. Напротив, там, где прежде всего необходимы солидные инновационные информационные технологии, больше нужны инженеры и разработчики сложных систем. Зачастую вам не нужно полностью ориентироваться на один вариант. Но вам нужно сознавать, что одно из направлений должно быть ведущим. И особенно если вы один из высших руководителей компании: вы должны уметь сосредоточить внимание на направлении, наиболее ценном для компании, и сконцентрироваться на нем.

Создание технологических процессов в разработке ПО

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

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

Спросите технического директора: что такое технологический процесс

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

В последнее время ко мне стали приходить инженеры и жаловаться, что новые сотрудники используют в системах другой код. Я тоже недавно обнаружил, что кто-то пишет код на языке программирования Scala, хотя все мы используем Ruby. Этот человек один знает в нашей команде язык Scala, и я боюсь, что нам придется столкнуться с трудностями в поддержке этого кода. Но проект продвинулся далеко вперед, поэтому просто остановить его я не могу.

Что мне делать? Я опасаюсь переходить от ситуации полного отсутствия процессов к задействованию сразу нескольких. Но что-то надо менять!

Подумайте о процессах в контексте управления рисками.

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

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

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

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

Практический совет: старайтесь не персонифицировать принятие решений

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

Проверка кода

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

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

Используйте анализаторы стандарта оформления кода. Некоторые инженеры могут тратить уйму времени на стандарт оформления кода, особенно на форматирование. Это не самая важная тема для дискуссии при проверке кода. Примите решение относительно стандарта (свода правил и соглашений для написания кода) и используйте статический анализатор: он отформатирует код автоматически. Если стиль программирования становится предметом дискуссии в ходе проверки, это часто ведет к придиркам и критике, в лучшем случае непродуктивным, а в худшем — обидным.

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

Анализ сбоев

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

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

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

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

Ревизия архитектуры систем

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

Сколько людей в команде удовлетворены использованием данной системы или данного языка программирования?

Есть ли у нас стандарты разработки для новой системы?

Каков процесс ввода ее в действие и подготовки людей к работе?

Необходимы ли новые операционные условия для использования новой системы?

А вот некоторые рекомендации.

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

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

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

Обратимся к оценке вашего собственного опыта

Какова политика вашей компании? Какова существующая в ней практика? Положены ли они на бумагу? Когда в последний раз вы просматривали их?

Есть в вашей компании признанные ценности? Что они собой представляют? Как вы в команде относитесь к ним?

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

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

10

Заключение

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

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

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

Умение распознать голос своего «я» — один из важных плюсов медитации. Когда я писала первый вариант книги, он включал в себя определенные медитации для каждого должностного уровня. Лично для меня медитационные практики стали очень важным инструментом развития навыков самоуправления и самоосознания. Разумеется, медитация не панацея, но она может стать полезным упражнением для развития осознанности и понимания ваших реакций. Именно поэтому рекомендую ее вам, если вы заинтересовались. Моими излюбленными источниками по этой теме являются некоторые материалы на tarabrach.com, а также книги Пемы Чодрон25.

Еще одна хитрость, к которой я прибегаю, чтобы уйти от своего эго, — любознательность. У меня есть привычка записывать каждое утро одну-две страницы свободно текущих мыслей, чтобы прояснить ум и подготовиться к предстоящему дню. И всегда я заканчиваю мантрой «Будь любознательной». Для меня становление в качестве лидера сопровождалось горькими уроками, ошибками и многочисленными трудностями. Все давалось нелегко, и я часто была глубоко расстроена межличностными ситуациями. Когда я рассказывала коучу об этих ситуациях, то неизменно получала совет взглянуть глазами других людей. К чему они стремятся? Что ценят? Чего хотят или в чем нуждаются? Совет всегда один: быть любознательной.

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

Оставайтесь любознательными! Удачи на вашем пути!

Об авторе

Камиль Фурнье — опытный лидер. Она обладает уникальным сочетанием глубокой компетентности в области информационных технологий, опытом руководящей работы и IT-менеджмента.

Благодарности

Я очень хочу поблагодарить моих редакторов, Лаурел Рума и Эшли Брауна: они помогли мне, впервые публикующемуся автору, относительно безболезненно пройти путь создания книги.

Спасибо Майклу Маршалу, Кейти Маккэффри, Джеймсу Тёрнбуллу, Кейт Хьюстон, Марку Хедлунду, Питу Майрону, Бетани Блаунт и Ларе Хоган за то, что они поделились с читателями своими историями на тему лидерства.

Спасибо всем, кто дал мне ценные советы и рекомендации, в том числе Тимоти Данфорду, Роду Бегби, Лиз Крауфорд, Кейт Хьюстон, Джеймсу Тёрнбуллу, Джули Стил, Мэрилин Кол, Кэтрин Стайер и Адриану Говарду.

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

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

И последнее (но не по степени важности) — спасибо моему мужу Крису. Разговоры за семейным столом помогли мне написать самые сложные части книги. Его советы и идеи помогли мне по-настоящему стать автором.

Примечания

1. Rent the Runway — онлайн-сервис по аренде дизайнерской одежды и аксессуаров. Прим. ред.

2. Бакингем М., Коффман К. Сначала нарушьте все правила. Что лучшие в мире менеджеры делают по-другому. М. : Альпина Паблишер, 2013. Прим. ред.

3. Уолл Л., Кристиансен Т., Орвант Д. Программирование на Perl. М. : Символ-Плюс, 2006. Прим. ред.

4. JVM — виртуальная машина Java. Прим. ред.

5. Рефакторинг — работа над структурированием кода. Прим. ред.

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

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

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

9. Система управления версиями — программное обеспечение для облегчения работы с изменяющейся информацией. Прим. пер.

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

11. Принцип Питера — положение, выдвинутое и обоснованное в одноименной книге Лоуренсом Питером. Формулировка: «В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности». Прим. пер.