Продолжаем делиться выдержками из руководства по выживанию для начинающих техлидов от Дж. Х. Рейнвотера. В первой серии мы рассказывали, с какими породами разработчиков руководителю обычно приходится работать; теперь попытаемся понять, что делать со всем этим зоопарком. Организационную деятельность в технической команде можно условно поделить на две части – более-менее родные вещи (вроде обзоров кода и управления архитектурой) и все то, к чему жизнь программиста не готовила – то есть управление людьми и процессами. Разберемся сначала с незнакомым.
Расстановка приоритетов
Первое, что обычно сбивает с ног свежеиспеченного руководителя – это лавина самой разнообразной информации. Такое положение дел вполне логично: тот, кто стоит во главе команде, менее замкнут в ее рамках и задействован в большем количестве процессов, но легче от этого не становится. В итоге, технический лидер нередко начинает распыляться – считая своей обязанностью реагировать на каждый сигнал, он хватается за все сразу, перепрыгивает с одной задачи на другую и упускает то, что больше всего требует внимания.
Выход здесь один – фильтровать этот поток информации, отделяя то, что имеет прямое отношение к основной задаче (выпустить код, отвечающий коммерческим требованиям, с оговоренный срок), и отправляя основное в бэклог. Но на первых порах критерии такой сортировки могут быть не очевидны. Новичкам кажется важным абсолютно все.
Усложняет дело еще и то, что многие раздражители возбуждают эмоции, которые мешают здраво оценить важность и срочность проблемы. Поступающие сигналы могут вызывать интерес (в коде обнаружилась занятная аномалия), вину (проектировщик напоминает, что уже много раз просил как-нибудь внедрить функцию, которую он хочет реализовать), опаску (пользователь выражает недовольство обновлением).
Чтобы успешнее систематизировать все запросы и сведенья, автор предлагает в использовать для их обработки следующую матрицу:
- Как новые данные отражаются на области действия проекта, на проектном решении, на конечном сроке сдачи проекта?
- Надежен ли источник информации? Если нет, то можно ли его проигнорировать?
- Следует ли реагировать на поступление информации незамедлительно или можно немного подождать?
- Где и как сохранить информацию с тем, чтобы при необходимости к ней можно было бы оперативно обратиться?
- Каков срок действия информации? Когда она становится неактуальной?
- Как данная информация соотносится с тем, что уже известно о проекте?
Как можно заметить, эта матрица помогает отделить зерна от плевел в нескольких отношениях: избавиться от откровенно бесполезной или ненадежной информации, отодвинуть то, что еще можно отодвигать, оценить важность сведений строго для текущего проекта. Однако вопросы о сроках и способах хранения намекают на то, что неактуальную в данный момент информацию не следует отметать как неактуальную в принципе – это другая крайность, которая в долгосрочной перспективе приведет команду к застою. Подробнее об этом мы будем говорить чуть позже, при обсуждении понятий «руководство» и «лидерство».
Разрастание проектов
Следующая болевая точка – оценка объемов и сроков работы. Опять же, какое-то время «плавать» в этой области для начинающего техлида практически неизбежно – нужен опыт, чтобы суметь обозреть все составляющие проекта разом, ничего не упуская, и с первой попытки выставить для каждого типа работ, включая малознакомые, адекватные сроки. Но даже наработанный опыт не спасает от определенной погрешности, и свести ее к нулю не представляется возможным. Предельной точности в планировании работы препятствуют два закона, которые метко сформулировал Хэмфри:
Любой процесс продлится дольше, чем вы надеетесь. Всегда появляется что-то, о чем вы не подумали.
Исходя из всего этого, автор призывает относиться к проблеме философски. Скорее всего, в первом приближении вы не сможете учесть какие-то менее очевидные функции или непредсказуемые осложнения, и они потребуют дополнительного ресурса, который вы не закладывали. К таким неожиданностям нужно быть готовым и готовить команду – учить людей быстро перестраиваться, чтобы «залатать дыры», оставлять им про запас немного времени на непредвиденные обстоятельства. Чего нельзя делать ни в коем случае – это рассматривать естественное разрастание как ЧП и искать виноватых, особенно в других отделах (а это всегда выглядит особенно соблазнительно). Так вы только посеете вражду между командами и ничего не сделаете для решения проблемы.
Тем не менее, не стоит ударяться и в полный фатализм: разрастание проекта все-таки является следствием недоработок в планировании. Совсем от них избавиться не удастся, но снижать концентрацию можно и нужно.
Если переложить законы Хэмфри на программистские реалии, становится понятно, что планирование проседает по двум причинам: недостаточный анализ подробностей и излишне оптимистические оценки длительности конструирования программных продуктов. Оптимизм у руководителей обычно отшибает естественным путем: несколько раз сорвав сроки, вы волей-неволей начнете перестраховываться. Что же касается детальности, этот навык тоже приходит с опытом, но составить общее представление о том, как должна выглядеть дорожная карта, стоит с самого начала.
Например, если вы приступаете к проекту, вооруженные вот таким документом, впереди вас ждет много стихийных бедствий и нервотрепки:
Если же дорожная карта больше похожа на образец, приведенный ниже, шансы счастливого исхода заметно повышаются:
Помимо этих двух причин, Рейнвотер перечисляет еще несколько дополнительных факторов риска, которые выделил Роберт Гласс – автор грустной книги о проектах-катастрофах в IT-сфере:
- Неадекватное специфицирование задач проекта
- Применение новой для данной компании технологии
- Негодная/отсутствующая методология руководства проектом
- Нехватка ведущих специалистов в группе
- Срыв договоренностей производителями аппаратного/программного обеспечения
Поиск общего языка
Вы, возможно, подумаете, что речь здесь пойдет о навыках общения коммуникативных талантах – но нет, смысл заголовка куда буквальней. В разных компаниях команды программистов формируются на разных основаниях. Если вам повезет, возможно, в вашем ведении будут люди, работающие с вашим родным стеком технологий. Но сплошь и рядом попадаются и смешанные команды, где разные сотрудники владеют разными языками. Такая смешанность в разы усложняет руководителю жизнь.
Одна из обязанностей лида – курировать всю деятельность команды, следить, чтобы весь код, который выходит в мир, был рабочим, качественным и без чрезмерной сложности. Если вы не знакомы с инструментарием, который используют при разработке ваши подчиненные, то руки у вас связаны. Вы не можете самостоятельно проводить обзоры кода, узнаете о серьезных ошибках только на этапе тестирования, что сбивает весь ритм работы, да и, говоря грубо, вас намного проще водить за нос.
Что делать в этой ситуации? В общем и целом, есть два пути. Если набор языков и технологий не слишком велик и переменчив, вы можете не пожалеть времени и попытаться освоить их хотя бы на базовом уровне. Это, пожалуй, оптимальный выход из положения – так вам не придется ни от кого зависеть, информацию вы будете получать напрямую, а значит, удастся избежать «глухого телефона» при обсуждении функциональности, требований и сроков.
Если же освоить нужные языки самому не представляется возможным, значит, вам придется искать способы делегировать эту обязанность. Формируйте ядро помощников, которые смогут предоставлять вам объективную и честную обратную связь по каждой незнакомой технологии (если ей владеет только один работник, этот метод, естественно, не сработает).
Углублять свои знания в вопросах, связанных с технологиями и инструментами, полезно еще и по другой причине – только так можно стать техническим лидером в полном смысле этого слова. В своей терминологической системе автор разводит понятия «менеджер» и «лидер». Менеджер – это тот, кто занимается организацией работы, решает повседневные проблемы и следит за тем, чтобы текущие задачи выполнялись вовремя и как следует. Лидер же – это стратег, который мыслит за пределами контрольных сроков, задает для своей команды общее направление движения, поднимает планки, переосмысляет и оптимизирует процессы. Само собой, в команде разработчиков такое визионерство требует хорошего знакомства с рынком технологий. В фоновом режиме технический лидер постоянно прикидывает, что в текущем инструментарии устарело и требует замены, отслеживает новинки и при этом имеет достаточно широкий кругозор, чтобы оценить их реальные достоинства (и не впасть в синдром Трюкача).
В первой части статьи мы говорили о том, что руководителю не стоит беспокоиться о том, что он выпадет из работы с технологиями – и для тех, кто метит в лидеры это действительно так. Но здесь имеет смысл еще раз повторить предупреждение оттуда же: не надейтесь при этом уклониться от обязанностей менеджера. Руководство предполагает балансирование между этими двумя ролями, которые иногда вступают в конфликт, но остаются почти в равной степени (менеджмент несколько уступает) необходимыми для выживания команды. Оттачивать организационные навыки в ваших интересах – чем меньше времени будет съедать рутина, тем быстрее вы будете расти как технический эксперт. Если пусть повседневные задачи на самотек, воцарится хаос, в котором уже не будет места никакой стратегии.
Комплектование стаи
Теперь переходим ко второму блоку проблем – пресловутой работе с людьми. Начнем с самого начала: прежде чем говорить о том, как управлять человеческим ресурсом, нужно разобраться, откуда его брать. Даже если вам досталась сложившаяся команда, рано или поздно встанет вопрос о наборе сотрудников. Ранее мы разбирали типы программистов и указывали на тех, за кем стоит гнаться в первую очередь. Теперь нужно понять, как действовать, чтобы выявить в кандидатах нужные качества и не разочароваться в своем выборе.
Автор предлагает следующие рекомендации по проведению собеседований:
- Дайте кандидату тестовое задание. Поставьте перед потенциальным сотрудником задачу, которую он должен будет либо решить сразу, либо взять на дом и решить к установленному сроку.
- Обязательно проведите устную проверку навыков кандидата – так вы сможете оценить и его знания, и способность ясно мыслить в стрессовой ситуации.
- Максимально подробно распишите обязанности искомого сотрудника, все задачи, которые ему предстоит выполнять, и отдайте этот список кандидату для ознакомления. Так разговор сразу станет предметнее и, как правило, откровеннее.
- Не ограничивайтесь одной встречей. Будет очень хорошо, если кандидат пообщается не только с вами, но и с вышеупомянутым «ядром» — вашими помощниками, заместителями, ведущими разработчиками в команде. Но устраивать смотрины со всем коллективом не стоит, это уже перебор.
- Проверка личных качеств, типологические тесты и тому подобное – возможный, но необязательный этап. Прибегайте к нему, только если кандидат не против и у вас есть надежные инструменты оценки.
Говоря о найме, нельзя не упомянуть и оборотную сторону – увольнение работников, которые тянут команду вниз. Здесь Рейнвотер занимает довольно жесткую позицию и советует без колебаний избавляться от тех, кто показал себя некомпетентным или проблемным. Лучшая позиция – политика одного предупреждения: она дает человеку возможность исправиться, но не позволяет злоупотреблять этим правом. Если сотрудник попал в «черный список» и вы провели с ним беседу, курировать его дальнейшие успехи нужно с особой тщательностью. Это требует дополнительных усилий, поэтому давать третий шанс – уже неоправданная расточительность.
Кроме того, от нерадивости члена команды страдает обычно не только абстрактное «общее дело», но и вполне конкретные люди, которым приходится исправлять его ошибки или мириться с тем, что он портит результаты их работы. Излишняя снисходительность, таким образом, оплачивается за их счет и вряд ли укрепит ваши лидерские позиции.
Организация работы сотрудников
Комфортная среда обитания
Этому аспекту в книге уделяется очень много внимания. Добиваться от своих сотрудников максимальной продуктивности – прямая обязанность лида, но высокая продуктивность требует высокой концентрации, а концентрация невозможна, если программиста со всех сторон окружают раздражители. Поэтому руководитель должен сделать все, что в его силах, чтобы обеспечить команде хорошие условия работы.
Конкретные рекомендации по проектированию офиса, которые дает Рейнвотер, местами звучат несколько идиллически (например, по отдельному кабинету на брата), а местами – как отголоски далекого и тяжелого прошлого (у каждого разработчика должен быть собственный компьютер). Но общий принцип по-прежнему остается разумным и применимым: для того чтобы программисты достигали в своей деятельности успехов, у них должна быть возможность, с одной стороны, некоторое время поработать в коллективе, с другой — пораскинуть мозгами в одиночестве. Для первого нужны места сборов, оборудованные соответствующим образом: кабинеты для совещаний с проекторами, команды для отдыха (в идеале) с пресловутыми теннисными столами или игровыми приставками. Для второго требуется организовать доступное пространство так, чтобы людям как можно меньше приходилось отвлекаться на шум, мелькание, запахи и другие отвлекающие факторы. Если условия оставляют желать лучшего, позволяйте сотрудникам, особенно ценным и надежным, работать из дома.
К обязательному минимуму удобств относится также и современная, качественная техника, которую разработчик может, в пределах разумного, настраивать по собственному усмотрению. Если машины слабые и устаревшие, говорить о технологических прорывах, да и просто спокойной, бесперебойной работе не приходится. Для тестирования программ должны выделяться особые устройства, воспроизводящие стандартные пользовательские характеристики.
Рабочие часы
Ворох обязанностей техлида, который мы обрисовали, наводит на мысль о том, что продолжительность его рабочего дня должна чуть ли не удвоиться. Но и здесь нужно соблюдать осторожность. Проблема заключается в том, что своим рабочим режимом руководитель сам того не желая задает тон всему отделу. Если вы сидите допоздна, работники будут предполагать, что нечто подобное ожидается от них тоже. В итоге, переработки могут войти в плоть и кровь вашей локальной культуры – а это чревато неприятностями.
Во-первых, далеко не все будут довольны таким положением дел. В первую очередь переработки ударят по тем, кто отягощен дополнительными обязательствами, например, семейными. Если таких людей окажется много, обстановка в команде сложится напряженная. Ну а во-вторых, автор, как и многие после него, указывает на то, что лишние рабочие часы скорее вредят производительности – и из-за усталости, и из-из снижения мотивации. Разумнее требовать от работников эффективной работы в урочное время, чем насаждать привычки, которые приведут к выгоранию.
Распределение и курирование задач
Будем откровенны: даже идеальные условия и щадящий график сами по себе не сподвигнут людей на самоорганизацию и прилежную работу. Среди прочего начальник нужен, чтобы распределять работу и следить за тем, чтобы она выполнялась. Какую-то часть вашего времени должен занимать контроль – кстати, это тоже способствует концентрации.
Автор советует не слишком дробить «отчетные периоды» для подчиненных, не душить их постоянным наблюдением с ежедневным запросом результатов. Разумнее определять список задач для каждого на неделю и оценивать проделанный объем работы за тот же период. В особо горячие периоды списки придется корректировать даже на этом небольшом промежутке из-за возникающих срочных дел и изменений в приоритетах. Руководитель должен держать все эти изменения в голове (а в современных реалиях – и вносить их в соответствующие системы учета).
Если лидер приходит в «чужую» команду с уже сложившимся рабочим ритмом, стоит попросить каждого работника самому подобным образом расписать свои обычные задачи. Такая документация может вскрыть массу интересного – не только, кто и чем занимается и как осуществлялось руководство раньше, но и что люди вообще думают о своих обязанностях.
Что касается содержания этих списков, разумеется, во многом оно будет определяться навыками сотрудниками и требованиями компании. Но при всем при этом в книге продвигается мысль о том, что нужно по мере возможностей ротировать задачи – разработчик не должен делать одно и то же из недели в неделю. На то есть несколько причин. Во-первых, это помогает поддерживать здоровый климат в команде: никаких обид из-за того, что кому-то постоянно достаются самые неприятные или, наоборот, самые интересные вещи, меньше ощущения рутины и монотонности в работе. Во-вторых, программистам необходимо оставаться в хорошей интеллектуальной форме – разнообразие задач будет этому способствовать. Наконец, с подобным чередованием понадобится минимум усилий для формирования скамейки запасных.
Скамейке запасных Рейнвотер придает большое значение. Основная мысль здесь в том, что в случае болезни, отпуска, увольнения, безвременной кончины любого из разработчиков, в команде должны найтись люди, которые сумеют выполнять его функции – хотя бы на тот период, пока не наймут замену. Это не только гарантирует бесперебойную работу отдела, но и позволяет избежать некоторых других проблем (например, острой зависимости компании от Волшебников). Соответственно, следует поддерживать интерес сотрудников к актуальным технологиям, всячески поощрять сотрудничество и участие в «чужих» проектах.
Кстати говоря, от фактора падающего кирпича не огражден и сам начальник. Поэтому, как только немного освоитесь, начинайте задумываться о том, кого бы сделали своим преемником. Это не только перестраховка, но и хорошее упражнение для делегирования задач – при подготовке преемника вам невольно придется задумываться о том, какую работу проще и безопаснее всего доверить другим. Во время авралов это знание окажется очень полезным.
И последнее: до сих пор речь шла в основном об интересах команды и начальства, но не стоит терять из виду тот факт, что мы все-таки работаем с людьми. Личные предпочтения и особенности сотрудников должны по возможности учитываться. Не стоит ожидать особой мобильности от того, кто с трудом переключается с одного на другое, не стоит из соображений справедливости отправлять Тормоза на задачу, с которой он боится не справиться и так далее. Здесь мы снова упираемся в тезис о том, что нужно внимательно наблюдать за своими сотрудниками и хорошо их знать.
Мотивация и поощрение
Но хватит о кнутах, поговорим о более приятном – тех пряниках, которые программисты должны получать от работы. Рейнвотер называет следующие разновидности пряников (в порядке приоритетности): зарплата, карьерное продвижение, доброе слово и, наконец, абстрактные корпоративные регалии.
В том что касается оплаты труда, вышедшие из разработки руководители не слишком склонны к прижимистости, но часто впадают в противоположную крайность и завышают ожидания сотрудников. Принимая решения насчет ставок, держите в голове следующие факторы: производительность, опыт, результативность, своевременность исполнения задач, текущая средняя ставка, конъюнктура рынка и корпоративные стандарты. Распространенная ошибка – повышать зарплату авансом, рассчитывая, что это стимулирует работников выкладываться на полную катушку. На деле, люди относятся к повышениям иначе – как к норме, которую они уже заслужили.
Если в компании действует премиальная система, убедитесь, что установлены реально достижимые показатели, на основании которых можно объективно награждать сотрудников. Иначе премия превратится в их глазах либо в некую фикцию, которая существует только в теории, либо в фиксированную надбавку.
Продвижение сотрудников – сложная тема. Сложность состоит, в первую очередь, в том, что во многих компаниях повышение в должности неразрывно связано с управлением людьми (возможно, вы и сами попали на руководящий пост потому, что уперлись в «потолок»). Не всем это нужно и подходит. Идеальные условия для роста – это развернутая иерархия чисто технических работников, позволяющая разграничивать разные уровни ответственности и компетентности и соответствующим образом их оплачивать. Если такого нет, вам предстоит особенно внимательно присматриваться к сотрудникам, чтобы понять, справятся ли они с новым набором обязанностей.
Похвала предыдущих двух пунктов не заменит, однако остается важным инструментом мотивации. Разработчики – по большей части, коты-эксгибиционисты, им нравится видеть, что их вклад, какой бы он ни был в реальности, замечают и ценят. Но и перегибать палку не стоит: похвала должна быть своевременной, искренней и предметной. Банальности в духе «Мы все хорошо поработали над этим проектом» будут восприняты как корпоративное пустословие и скорее оттолкнут, чем вдохновят. Хвалить лучше на людях (а критиковать – с глазу на глаз) – это хорошо влияет на общую атмосферу.
Автор: DigitalEcosystems
