Не давайте завышенных обещаний по проектам, связанным с программированием. Не обещайте своей команде интересных проектов по ПО «позже», поскольку планы по продукции на «позже» еще не написаны. Ваши обещания породят у людей надежды, а потом они сменятся разочарованием. Если проект важный, то составьте его расписание на данный конкретный момент или максимально близко к нему. Если проект несрочный, можете отложить его на потом. Но помните, что когда «потом» наступит, к тому времени у вас будет много других приоритетов в отношении других продуктов. Если сейчас вы не уделите время тому, чтобы четко сформулировать ценность данной работы, она будет отодвинута в сторону в пользу проектов с более явной ценностью.
Уделяйте 20% рабочего времени команды поддержанию необходимого технологического уровня. Выделите достаточно времени на рефакторинг (перепроектирование или переработку кода), устранение серьезных ошибок, улучшение процесса программирования, осуществление чистки программ и оказание текущей поддержки пользователям. Учитывайте это при каждом планировании. К сожалению, 20% может быть недостаточно для больших проектов, поэтому иногда по ходу исполнения может потребоваться больше времени для переписывания элементов кода или программ либо других улучшений в ПО. Но без этих 20% времени вы можете не достигнуть запланированных результатов и столкнуться с неприятной работой по чистке программного обеспечения.
Добейтесь для себя ясного понимания, насколько важен в действительности тот или иной программный проект. Проекты, связанные с разработкой новых продуктов или бизнес-проектов, как правило, бывают оправданы тем, что от них ожидается создание для компании новой ценности. Однако с чисто инженерными проектами большие ожидания обычно не связаны. Когда к вам приходит программист, желающий заняться конкретным инженерным проектом, при оценке воспользуйтесь следующими критериями.
Насколько объемен данный проект?
Насколько он важен?
Сможете ли вы ясно объяснить ценность этого проекта любому спрашивающему человеку?
Что даст команде успешное исполнение данного проекта?
Ценность этих вопросов в том, что вы подходите к техническим проектам так же, как и к инициативам по новой продукции. Эти проекты имеют своих приверженцев, свои цели, свое расписание, и управляются они так же, как и другие большие мероприятия организации. Это нелегкий процесс, потому что часто в тех случаях, когда вы знаете, что какой-то проект важен, вы не знаете, как сформулировать оценку так, чтобы бизнес-подразделения это поняли. Это особенно нелегко с учетом сложной природы инженерных проектов и трудностей измерения эффективности в программировании. Поэтому вы часто вынуждены объяснять технические детали партнерам из нетехнического блока, а они могут не понимать, какую цель вы преследуете и почему. Здесь я советую тщательно подбирать данные, необходимые для подкрепления вашей позиции, и доводить до партнеров, что даст реализация проекта. Представьте себе систему, редко претерпевающую изменения. По итогам данного проекта она кардинально не улучшится. А вы предлагаете работу определенного объема с этой системой. Очень возможно, что проект и не стоит ваших усилий. К сожалению, на практике всегда не хватает времени на исследовательское программирование, чистку устаревшего или неподдерживаемого кода и улучшение качества программирования, хотя их хотела бы осуществить ваша команда. Поэтому правильное понимание действительной важности того или иного проекта позволит сосредоточиться на чем-то действительно важном и сэкономить время для других необходимых дел.
Но все же вернемся к теме неопределенности в планировании. Проекты претерпевают изменения. Команды могут даже расформировываться или реорганизовываться непонятным или неприятным для вас способом. Лучшее, что при этом вы как менеджер можете сделать, — помочь коллегам зачистить висящие концы, стабилизировать текущие проекты и организованно приступить к новой работе. Здесь вы вполне можете и даже должны при необходимости дать задний ход. Вам следует обеспечить условия, чтобы люди завершили текущую работу. Кроме того, вам следует настаивать на включении инженерных вопросов на ранних стадиях планирования новой работы, чтобы люди почувствовали интерес к новым проектам. Вы сами должны тщательно проанализировать причины возникших изменений, и если даже вы не полностью с ними согласны, выполните свою часть работы, разъясняя причины команде, помогая ей понять новые цели. Чем спокойнее вы будете себя вести в процессе перемен и чем убедительнее сможете продемонстрировать (или даже изобразить) энтузиазм в отношении нового направления развития команды, тем легче окажется переходный период для всех ее членов.
Когда на вас накатывает волна, вы можете либо поддаться ей, либо научиться скользить по ней. Цепляйтесь всеми десятью пальцами ног за доску для сёрфинга и держитесь на волне.
Поддерживать свой технический уровень
Очень часто я слышу от менеджеров один и тот же вопрос: «Как поддерживать свой технический и инженерный уровень?» Мы знаем, что без развития технических навыков мы рискуем потерять связь с профессией и отстать от времени. Однако что дает вам техническая компетентность? Чтобы дать ответ, для начала проясним вашу техническую зону ответственности.
Контролируйте необходимый технический уровень при создании ПО
Чтобы программирование шло вперед, нужна постоянная техническая работа: задействование новых языков и платформ программирования, создание новой инфраструктуры и новых свойств разрабатываемого ПО. Однако на совершенствование этих систем могут быть направлены ограниченные ресурсы и время, так что в вашу задачу входит обеспечить направление усилий команд в нужные места. Вы должны контролировать эту работу, совмещая технические проекты и планируемые улучшения с будущим нового продукта или потребностями покупателей. Если вы научитесь целостному подходу к оценке портфеля проектов, то сможете увидеть, в каких областях находятся главные потребности или возможности, и соответствующим образом распределять усилия команд.
Задавайте компетентные вопросы
Вы не обязаны в деталях знать все технические вопросы. Отвечая за поддержание командами необходимого технического уровня, вы не должны лично вести исследовательскую работу по идентификации обеспечивающих его областей работы. Вы должны руководить, умея задавать компетентные вопросы. Что представляют собой текущие проекты, какие сюрпризы они преподнесли и какие узкие места в них образовались? Что думает команда относительно будущего разрабатываемых систем? Какие команды просят об увеличении штата инженеров-программистов и почему? Какие команды работают в недостаточном темпе, но не хотят привлекать дополнительный персонал для улучшения работы? Почему та или иная команда настаивает на осуществлении конкретного проекта именно сейчас? Вы должны в достаточной степени понимать существо работы команд, чтобы улавливать пустые усилия и оценивать предлагаемые меры по совершенствованию работы.
Анализируйте и разъясняйте командам необходимость компромиссов между техническими аспектами и бизнес-интересами компании
