«Человек в себе»
Другой проблемный член коллектива — «человек в себе». Он утаивает информацию от вас, от членов команды, от менеджера продукта. Он предпочитает работать втайне от других и раскрывать свой проект тогда, когда он закончен и в нем все работает нормально. Вместо того чтобы обсуждать программы с товарищами, такой член команды отменяет их действия или собирает информацию об их ошибках и делает работу за них. Он не любит проходить через процедуру проверки кода и не просит рекомендаций по разработке больших проектов.
Такой сотрудник раздражает всех вокруг. Став менеджером «человека в себе», вы должны подавлять его привычку к утаиванию информации в самом зародыше. Если необходимо, прямо скажите ему, что он не отвечает ожиданиям, возлагаемым на него по работе. Его поведение может быть признаком страха: он может бояться, что его сочтут недостаточно компетентным в работе или попросят выполнять неинтересные задания. Иногда такое поведение может быть признаком того, что человек претендует на более ответственную работу или не уважает своего менеджера. Какой бы ни была причина таких проявлений, данный работник подрывает единство в коллективе, потому что не сотрудничает с остальными его членами; он часто испытывает дискомфорт от необходимости разделения работы с ними, а его страхи могут стать заразительными для других сотрудников.
По возможности воздействуйте на глубинные причины скрытного поведения. Если работник боится критики, то, может быть, в вашем коллективе слишком жесткая корпоративная культура, и на нее следует обратить внимание? Существует ли в вашей команде общее ощущение психологической защищенности? Не относится ли ваша команда к такому члену как к «чужаку» просто из-за того, что у него другой опыт работы или набор навыков? Если команда отторгает кого-то, вам предстоит решить, исправить ли действия команды или перевести его в другой коллектив. Иногда перевод — самое правильное решение. В других случаях лучшим решением будет работа со всей командой в целях внесения изменений в корпоративную культуру и исключения практики отторжения людей.
Человек, не уважающий других
Еще один тип «вредных» работников — те, кто не уважает вас как менеджера или своих коллег. Работа с ними может быть трудной, и здесь вам может понадобиться помощь вашего руководителя. Но если вы сможете справиться с проблемой сами, это свидетельство силы вашего характера. Проще говоря, можно задаться вопросом: если член команды не уважает вас или коллег, зачем он вообще работает в этом коллективе? Спросите его, хочет ли он быть в вашей команде. Если ответ будет положительным, то ясно и спокойно изложите, чего вы от него хотите. Если же он ответит отрицательно, запустите процесс перевода его в другой коллектив или помогите ему покинуть организацию.
И все? Да, и все. Вы не можете работать с человеком, не уважающим вас или вашу команду. Это скажется на спаянности коллектива, поскольку коллеги станут задаваться вопросом, правильно ли человек делает, не уважая вас. Чем скорее вы достанете и примените здесь лейкопластырь, тем лучше.
Дополнительные соображения по проектному менеджменту
В качестве менеджера инженерного профиля вы обязаны помогать команде составлять расписание. По мере того как наверху организации пытаются проработать планы на квартал или год, вы должны оценить, справится ли ваша команда с конкретными отдельными проектами, каково будет их содержание и достаточно ли у вас людей, чтобы выполнить объем работ. Вас могут попросить о поддержке старых систем в дополнение к новым обязательствам или спросят, сколько новых людей вам нужно привлечь, чтобы поддержать новые инициативы. Организация будет ждать неких предварительных оценок, равно как и более детального планирования проектов.
Общий обзор вопросов управления проектами приведен мной в главе 3, где обсуждались вопросы работы технического руководителя группы, но здесь я хочу привести некоторые дополнительные соображения. Будучи руководителем команды, имея возможность поручить некоторые вопросы планирования проектов техническому руководителю группы, вы все же должны будете и сами участвовать в работе. Вам придется решать, какие проекты взять, а от каких отказаться. Очень вероятно, что уже на раннем этапе вас попросят дать приблизительные оценки по срокам проектов, даже по инициированным и запланированным с применением гибких agile-методов.
Чтобы успешно справиться с этой работой, вам нужно хорошо понимать ритм и динамику команды. К счастью, есть некоторые приемы и методы, облегчающие эту задачу.
Важнейшие правила проектного менеджмента
Ниже я привожу некоторые важные для вас правила.
Правила не подменяют agile-методов
Прежде всего хочу пояснить, что не собираюсь загонять вас в традиционные каскадные методики (или «методики водопада») и требовать детально планировать все этапы и детали проекта от начала до конца. Однако перед большинством команд обычно стоят как большие долгосрочные цели, так и небольшие, помогающие достичь важных. Когда речь идет о планировании более мелких составляющих проекта, то для повседневной работы очень эффективны agile-методы, помогающие легче взаимодействовать в разбивке и приблизительной оценке сроков. Менеджер не должен вмешиваться или «присваивать» себе эти части процесса. Вы отвечаете за картину в целом — за достижения, требующие месяцев, а не недель. И здесь должна проявляться ваша активная роль в крупномасштабном планировании.
У каждого инженера-программиста 10 продуктивных недель в квартал
В году 52 недели, то есть примерно 13 недель в квартале. Однако в реальности потери времени команды будут существенными. Отпуска, совещания, период отчетов и заключений, перерывы или сбои в работе, притирка новых работников — все эти вещи отвлекают внимание коллектива. Не ожидайте, что на каждого члена вашей команды в квартал будет приходиться более 10 недель концентрированной работы над основными проектами. Высока вероятность того, что первый квартал (сразу же после новогодних праздников) будет наиболее производительным, а четвертый (подготовка к новогодним праздникам и встреча Нового года) — наименее продуктивным.
Планируйте 20% всего рабочего времени команды на общую работу по поддержанию технологического уровня программирования
Под общей работой по поддержанию технологического уровня программирования я имею в виду тестирование, устранение ошибок в коде и программах, чистку устаревшего и неподдерживаемого кода, изменения языков и программных платформ. В общем, все, чем приходится заниматься команде в повседневной деятельности. Если вы введете это в привычку, вам удастся качественно исправлять типичный неподдерживаемый код — не обновляющийся, но еще используемый для сохранения совместимости с предыдущими версиями системы — и даже вносить в него небольшие изменения. Очистка систем по мере движения вперед облегчает работу, что позволяет команде разрабатывать новые программы. В худшем случае вы сможете использовать резерв в 20%, чтобы компенсировать неизбежные задержки в разработке нового софта. Если же все 100% вы запланируете под работу над новыми продуктами, то будьте готовы к тому, что эта работа неизбежно начнет отставать из-за излишне жестких планов.
