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

Дж. Ханк Рейнвотер, программист старой закалки, относится к числу людей, которые знают все топкие места в роли технического лидера наперечет, потому что сами в них плавали. Его книга «Как пасти котов» подкупает своей предметностью: здесь описываются конкретные, хорошо всем знакомые ситуации, разбираются по косточкам разные составляющие и условия работы команды, даже приводятся авторские технологические решения (к сожалению, уже устаревшие). В небольшом цикле статей мы планируем осветить все, что нам показалось наиболее полезным и актуальным в книге – от типологии сотрудников до рекомендаций по общению с другими командами.

Начать стоит с резонного вопроса: почему, собственно, коты? Сам автор в качестве пояснения ссылается на цитату Элен Алман, которая проводит эту аналогию в своей книге Close to the Machine:

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

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

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

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

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

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

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

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

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

Распространенные породы

Архитектор

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

Конструктивист

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

Художник

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

Инженер

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

Ученый

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

Лихач

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

Редкие породы

Волшебник

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

Минималист

Пишет на удивление функциональный код очень скромных объемов. Все стройно выглядит, четко выстроено и недвусмысленно сообщает о своем назначении. Эта порода очень капризна в выборе задач и проектов; минималист будет больше других бороться за право устанавливать область приложения своих способностей. Слабое место – сопровождение. Изо всех сил сопротивляется необходимости вносить правки в свой код (не говоря уж о чужом) – ему просто неинтересно возиться с частностями, когда основное уже сделано.

Аналогист

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

Трюкач

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

Дворняги

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

Разгильдяй

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

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

Тормоз

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

Любитель

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

Профан

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

Эклектик

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

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

Итак, мы перечислили те породы, с которыми автору доводилось встречаться чаще всего. К этой классификации, однако, следует дать несколько примечаний:

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

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

Пример №1

Ситуация: у вас есть объемная кодовая, которую нужно модернизировать под текущие потребности компании, и разработчик-минималист, который видит ее впервые в жизни. Разработчик заявляет, что код нужно переписывать с нуля – все чересчур сложно, но вы на это пойти не можете: на продукт уже затрачено немало ресурса. Что делать?

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

Пример №2

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

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

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