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

3

Технический руководитель группы

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

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

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

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

регулярные (еженедельные) встречи руководителя с членами группы;

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

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

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

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

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

Возможно, самое краткое выражение сущности роли технического руководителя группы содержится в книге Патрика Куа «Разговор с техническими руководителями» (Talking with Tech Leads).

Руководитель, отвечающий за работу команды программистов, проводит по крайней мере 30% времени в написании кода вместе со своей группой.

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

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

Что значит быть техническим руководителем

Исполнение обязанностей технического руководителя — упражнение на влияние на людей без реальной власти. Я руковожу коллективом в качестве ведущего технического специалиста, но мы все отчитываемся перед одним и тем же менеджером. Поэтому я должна влиять не только на коллег, но еще и на менеджера по вопросам правильного определения приоритетов в работе. Поначалу мне пришлось совсем туго, потому что один из первых порученных мне проектов формулировался так: остановить разработку новых программ и вместо этого сосредоточиться на проблеме «технического долга»6. Мне стало ясно, что «консервную банку» под названием «технический долг» гоняли по полю уже достаточно долго: развертывание нового кода давалось с трудом, использование действующих систем становилось все более дорогим, а техподдержка в режиме «по первому зову» 24/7 была адски трудна. Я была уверена, что нам нужно притормозить, чтобы в будущем нагнать темп. Однако в этом было трудно убедить наших разработчиков: они хотели создавать новые интересные программы. Или менеджера: его захлестывал постоянный поток запросов от заказчиков. Мне удалось привлечь членов команды на свою сторону, показав, какие позитивные моменты каждый сможет получить от проекта. Для некоторых было важно иметь более надежный сервис, для других — повысить скорость итерации, а для третьих — уменьшить количество срочных запросов в техподдержку, что дало бы им возможность спокойно спать. В беседах с менеджером особый упор я делала на снижение эксплуатационных издержек, что позволило бы команде в будущем разрабатывать более интересные программы.

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

Кейти Маккафри

Все хорошие технические руководители знают одну хитрость

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

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

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

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

Основные моменты позиции технического руководителя группы

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

Главные функции технического руководителя

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

Архитектор системы и бизнес-аналитик

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

Планировщик проекта

Планировщик должен уметь делить проект на приблизительно равные промежуточные части. Исполняя эту роль, вы должны учиться находить эффективные пути разбивки, чтобы команда работала быстро. Часть задачи — организовать параллельное движение частей работы в максимальном объеме и максимально продуктивно. Это сложно, потому что вы, скорее всего, привыкли думать только о своей работе, а не о работе группы. Ключ — найти пункт приложения всего согласованного в теории. Например, если речь идет о внешнем интерфейсе, использующем простой формат обмена данными JSON на базе API (интерфейса прикладного программирования), то не обязательно ждать, пока набор процедур API будет полностью закончен, чтобы начать разработку внешнего интерфейса. Вместо этого согласуйте использование формата JSON и начинайте писать код в этом формате при помощи Mock-объектов (фиктивных функций). Если вы удачливы, то наверняка видели это раньше, так что вам просто надо копировать предыдущие образцы. На этой стадии вам следует привлечь опытных экспертов к консультированию членов вашей группы и самому поговорить со специалистами, разбирающимися в соответствующих проблемах и способными сообщить вам необходимые детали. Также в этой части процесса нужно осуществить расстановку приоритетов. Что в программе действительно важно, а что факультативно? Как работать над важными элементами с самого начала проекта?

Разработчик программ и руководитель группы (тим-лидер)

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

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

Спросите технического директора: я ненавижу должность технического руководителя группы!

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

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

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

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

Управление проектами

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

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

Это была одна из самых тяжелых ситуаций в моей жизни.

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

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

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

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

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

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

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

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

Не жалейте времени на разъяснения

Один из последних этапов на пути к докторской степени — защита диссертации. Именно здесь вы, кандидат в доктора, представляете результаты своей многолетней исследовательской работы. Вы делаете это перед научным советом, состоящим из экспертов в вашей области. Они оценят ваши результаты и решат, достаточны ли они для присуждения вам научной степени доктора наук (PhD). Много лет назад мне повезло: я получил докторскую степень по математике от одной из самых престижных программ по прикладной математике в США. Одним из членов научного совета, оценивавшим мою работу, был известный математик — специалист в области численного анализа. То, что он сказал мне после моей (успешной) защиты, прошло красной нитью сквозь всю мою рабочую карьеру (не в области математики!). Он сказал тогда: «Ваша диссертация была одной из самых прозрачных и ясных работ, прочитанных мною за многие годы. Благодарю вас!» Разумеется, я был польщен его словами, но одновременно с этим и удивлен. Я предполагал, что этот ученый, математик мирового уровня, будет все знать о моем предмете и просто наблюдать, чем обернется защита моей диссертации. На самом деле, как объяснил он, он действительно смог это сделать, но только благодаря тому, что я потрудился объяснить базовые понятия и мотивацию возникновения моих собственных идей. Я никогда не забывал этот урок. Проработав после этого в области создания программного обеспечения в больших организациях, я не раз смог оценить его слова.

Мы полагаем, что руководство легко схватывает то, что мы делаем как инженеры-программисты. «Эй, парень, ты просто читай код!» Среди программ мы живем каждый день, и ведь они должны быть понятны любому, кто работает в области IT, не так ли? Нет, не так. Технические менеджеры приглашают на работу лучших специалистов (во всяком случае, надеются, что они лучшие), и те решают сложные проблемы. Но менеджеры схватывают далеко не всё. Я всегда удивлялась, насколько благодарны были мне старшие технические руководители, когда я мог объяснить им некоторые основополагающие идеи (например, что собой представляет штуковина под названием «хранилища NoSQL» и что с этим делать) не в угрожающем или снисходительном тоне.

Недавно один старший бизнес-руководитель в нашей организации попросил меня объяснить ему в частном порядке, почему для нас важно перенести «Толстого клиента»7 в архитектуре клиент-сервер на платформы провайдера. На этого руководителя сильно давили, чтобы он разрешил финансирование перехода, но он не понимал, зачем это нужно. Судя по всему, ему было неудобно спрашивать об этом публично. Я провел два очень плодотворных часа, объясняя ему (без PowerPoint!) суть проблемы. Теперь я никогда не боюсь разъяснять базовые принципы и мотивации тех или иных решений и старшим, и младшим сотрудникам организации. Это дает им знания, не принижая их, они учатся доверять моим суждениям и советам, и так мы обеспечиваем в организации необходимые изменения. Не жалеть времени на объяснения — это очень важно.

Майкл Маршалл

Управление проектом

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

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

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

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

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

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

Спросите технического директора: я не хочу становиться техническим руководителем группы

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

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

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

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

Точка принятия решения: остаться инженером или стать менеджером

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

Воображаемая жизнь ведущего инженера-программиста

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

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

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

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

Реальная жизнь ведущего инженера-программиста

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

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

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

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

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

Воображаемая жизнь менеджера

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

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

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

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

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

Реальная жизнь менеджера

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

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

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

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

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

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

Хороший менеджер, плохой менеджер: «царь организационного процесса»

«Царь организационного процесса» уверен, что существует один-единственный организационный процесс и при правильной эксплуатации он поможет решить все проблемы команды. Такие «цари» могут быть одержимы agile-, kanban-, scrum-процессами, «методами бережливого производства» или даже «каскадной методикой». Они точно знают, как эффективно организовать работу системы on call (получение сигналов о сбоях в работе программного обеспечения в режиме реального времени), как нужно организовывать проверку (инспекцию) кода, как и весь процесс релиза готового продукта. Обычно такие люди очень организованны и любят детали. Как правило, они хорошо знают все производственные нормы и правила и неукоснительно следуют им.

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

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

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

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

Интересы отдельных работников и их взаимодействия должны стоять над интересами «процессов и методик».

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

Сотрудничество с клиентом должно иметь преимущество над процедурой переговоров.

Умение реагировать на возникающие изменения должно стоять над неукоснительным следованием плану.

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

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

Как быть хорошим техническим руководителем

Хорошему техническому руководителю нужны разные качества, но вот главные.

Поймите архитектуру системы

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

Будьте командным игроком

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

Руководите группой технических решений

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

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

Правильно общайтесь с командой на понятном ей языке

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

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

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

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

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

Спрашивали ли вы менеджера, чего он ожидает от технического руководителя?

Можете ли вы назвать лучшего технического руководителя из всех, с кем довелось работать? Какие качества делали его хорошим техническим руководителем?

Приходилось ли вам когда-либо работать с неудачным техническим руководителем? Какие его качества вам не нравились?

4

Управление людьми

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

Марк Хедлунд

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

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

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

Поговорим о главных задачах, решающих в организации управления людьми:

получение от подчиненных свежих отчетов;

проведение регулярных личных встреч;

предоставление им оценок и рекомендаций по вопросам карьерного роста, продвижения к поставленным целям, сфер для самосовершенствования, а также заслуженной похвалы;

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

С самого начала выстраивайте отношения с членами команды как с подчиненными

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

Выстраивайте с подчиненными отношения доверия и взаимопонимания

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

Какой вид похвалы вы предпочитаете — публичную или неформальную?

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

В каком виде вы предпочитаете получать обратную связь? В письменном, чтобы иметь время «переварить» ее, или вам нравятся более неформальные устные оценки и рекомендации?

Почему вы решили работать в компании? Что вам здесь нравится?

Как мне узнать, что у вас плохое настроение или вы чем-то расстроены? Если ли моменты, всегда портящие вам настроение? Нужно ли мне о них знать?

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

Есть ли не нравящиеся вам моменты в поведении менеджеров?

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

Есть у вас определенные цели в плане служебного роста? Могу ли я помочь их достичь?

Когда вы вошли в команду, что вас удивило (и хорошее, и плохое)?

Моменты типа: а мои опционы? Вы обещали мне бонус после перевода с прежнего места работы, но я еще его не получил. Почему мы используем SVN (свободную централизованную систему управления версиями), а не Git (распределенную систему управления версиями)? Я не ожидал, что уже сейчас достигну такой производительности!

Помогите подчиненным составить план на 30/60/90 дней

Другой метод опытных менеджеров в работе с подчиненными — помощь в составлении планов на 30/60/90 дней. Он может включать в себя такие большие цели, как более быстрое написание кода или устранение ошибок, а также выпуск релиза продукта. Такие планы особенно важны для новых членов команды, переведенных из других подразделений. Чем старше новичок по опыту и должности, тем активнее он должен участвовать в составлении такого плана. Вы должны побудить его поставить перед собой ясные цели, показывающие, что он готов усваивать необходимые навыки для убыстрения работы. Формулирование целей требует определенной работы и от вас, и от команды, потому что очень редко бывает так, что новичку все становится на новом месте ясным, все хорошо задокументировано и вполне очевидно.

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

Побуждайте новичков к подготовке новой документации

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

Четко доводите до новичков ваш стиль руководства и свои ожидания

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

Получайте от нового работника обратную связь

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

Как общаться с командой

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

Марк Хедлунд

Регулярно проводите личные встречи с членами команды

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

Планирование личных встреч

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

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

Корректировка времени личных встреч

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

Как часто вы контактируете с конкретным работником в течение недели?

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

В каком уровне руководства и советов нуждается данный работник?

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

Часто ли и активно делится данный работник информацией с вами?

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

Каковы ваши личные отношения с данным работником?

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

Насколько стабильно или, наоборот, неустойчиво положение компании?

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

Разные стили проведения личных встреч с подчиненными

Итак, вы распланировали личные встречи с подчиненными. Для чего в реальности нужно их использовать? Я встречалась с разными стилями проведения встреч и могу сказать: их эффективность в равной степени зависит как от менеджера, так и от подчиненного.

Встреча для составления списка необходимых дел

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

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

Встреча для обсуждения в свободной манере

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

Встреча с обратной связью от вас к подчиненному

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

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

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

Отчет о продвижении проектов