Читать книгу: «От разработчика до руководителя»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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