От разработчика до руководителя

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

Никогда не медлите с помощью командам

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

Будьте любознательны

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

Формирование ожиданий и обеспечение своевременных результатов

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

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

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

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