Хабрахабр

Дж. Х. Рейнвотер «Как пасти котов» (часть вторая): все, что предстоит освоить техлиду

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

Расстановка приоритетов

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

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

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

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

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

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

Разрастание проектов

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

Всегда появляется что-то, о чем вы не подумали. Любой процесс продлится дольше, чем вы надеетесь.

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

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

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

Например, если вы приступаете к проекту, вооруженные вот таким документом, впереди вас ждет много стихийных бедствий и нервотрепки:

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

Помимо этих двух причин, Рейнвотер перечисляет еще несколько дополнительных факторов риска, которые выделил Роберт Гласс – автор грустной книги о проектах-катастрофах в IT-сфере:

  • Неадекватное специфицирование задач проекта
  • Применение новой для данной компании технологии
  • Негодная/отсутствующая методология руководства проектом
  • Нехватка ведущих специалистов в группе
  • Срыв договоренностей производителями аппаратного/программного обеспечения

Поиск общего языка

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

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

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

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

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

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

Комплектование стаи

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

Автор предлагает следующие рекомендации по проведению собеседований:

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

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

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

Организация работы сотрудников

Комфортная среда обитания

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

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

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

Рабочие часы

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

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

Распределение и курирование задач

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

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

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

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

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

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

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

Мотивация и поощрение

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть