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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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