Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами
Помимо прочего, во время встреч с сотрудниками «один на один» вы получаете возможность отслеживать работу над проектом и препятствия, с которыми подчиненные сталкиваются в своей деятельности. Этот процесс можно формализовать. К примеру, можете завести стандартный опросник и попросить сотрудников группы раз в неделю заполнять его. Информация, содержащаяся в анкетах, позволит вам выявлять трудности и своевременно направлять усилия на их преодоление. При просмотре анкеты конкретного сотрудника пригласите его к себе в кабинет и обсудите варианты разрешения возникших проблем. Решать проблемы по мере их появления, на ранних этапах значительно эффективнее, чем биться с проектом, разъедаемым проблемами, не выявленными вовремя.
Совещания с другими группами
Итак, вы получили новую должность. Теперь вам предстоит существенно расширить границы своего общения. На эту тему есть иллюстрация Скотта Адамса (Scott Adams) – обратите внимание на позицию руководителя (рис. 5.2).
Рис. 5.2. Программист, только что узнавший о повышенииИллюстрация из Dilbert воспроизводится с разрешения United Feature Syndicate. Inc.
Надеюсь, что вы запуганы чуть меньше, чем изображенный на рисунке программист. Мы, технари, сталкиваясь с необходимостью взаимодействия с группами разработчиков, с которыми в обычных условиях не общаемся, чувствуем себя не слишком уверенно. Будьте готовы к тому, что «обычный» круг общения начнет расширяться. Далеко не все совещания, которые вам предстоит провести, предполагают присутствие исключительно подчиненных программистов. На них, скорее всего, будут приходить сотрудники нетехнического профиля, равно как и специалисты в тех технических дисциплинах, в которых вы не слишком смыслите. Определенного внимания к себе будут требовать сотрудники, ответственные за формулировку бизнес-требований, люди из отделов поддержки и тестирования, специалисты по проверке качества, финансовые сотрудники и многие другие.
Как вести себя на таких совещаниях? На некоторые из них придется приходить в официальном наряде – поэтому пополните свой гардероб хотя бы одним хорошим костюмом. Помните, люди не вашего круга ожидают, что вы покажете себя немного странноватым; постарайтесь, впрочем, держать эту наигранную придурковатость в рамках стереотипа творческой личности и сделайте так, чтобы люди, привыкшие считать доходы и далекие от логических выражений, воспринимали вас адекватно.
Всегда обрисовывайте ваш отдел в идиллических тонах. Никогда не сваливайте вину за срыв сроков на своих подчиненных. Такую позицию очень не любят, и подобными действиями вы только подогреваете нашу и без того пожароопасную индустрию, в которой программисты при оценке своих попыток соблюдения контрольных сроков проявляют себя убежденными идеалистами. Мы можем сколь угодно пребывать в уверенности, что программирование есть искусство (а это действительно так). При этом не стоит забывать, что ваш начальник мыслит по-другому; по его мнению, программирование есть наука с присущей этому понятию предсказуемостью. Выслушивая похвалы, считайте, что вам повезло, но реагируйте на них скромно и достойно; делайте акцент на том, что если бы не ваша команда, никаких достижений не было бы в помине. Хотите высказать сотруднику свои претензии – ради бога, но только в приватной обстановке.
Никогда не сваливайте вину за срыв сроков на своих подчиненных. Такую позицию очень не любят, и подобными действиями вы только подогреваете нашу и без того пожароопасную индустрию, в которой программисты при оценке своих попыток соблюдения контрольных сроков проявляют себя убежденными идеалистами.
Успешное взаимодействие с остальными подразделениями компании заставит сотрудников уважать вас. Уважению не будет предела, если вы позволите им не присутствовать на длительных и иногда утомительных совещаниях, которых вам самому никак не избежать.
Одна из основных ваших задач в процессе взаимодействия с другими группами заключается в том, чтобы обеспечить своевременное получение бизнес-требований в как можно более завершенном состоянии. Разбухание области действия, как известно, начинается со скверно определенных требований. Ситуация ухудшается, когда программисты, столкнувшись с плохим описанием продукта, начинают фантазировать, и с этого момента разрастание области действия уже практически невозможно контролировать. Этапу описания продукта следует уделять не меньше времени, чем этапам проектирования и программирования. Такие временные затраты окупаются – дело в том, что, чем более комплексной информацией вы обладаете по части коммерческих приоритетов компании, тем лучше себе представляете, какой продукт ей необходим для того, чтобы занять достойную позицию на рынке.
Еще несколько слов о требованиях. Будучи программистом, вы, естественно, любите разрабатывать программные продукты. Отталкиваясь от идеи, вы преобразуете ее в виртуальную реальность. Согласитесь, есть некое волшебство в создании выверенного пользовательского интерфейса, который, к тому же, грамотно состыкован с прикладной частью. Скорее всего, лучшим из всех созданных вами программных продуктов был тот, относительного которого вы четко представляли себе бизнес-требования. Думаю также, что как программист вы получили от разработки этого приложения больше всего приятных минут. Постарайтесь донести это чувство до группы описания продукта, и по мере сбора требований очерчивайте ее сотрудникам пределы возможного. За счет своих технических способностей вы сможете на корню избавляться от всех неудачных идей; навыки же сотрудников группы описания продукта в области бизнеса помогут вам генерировать новые идеи. Учитесь организовывать сотрудничество технологии и бизнеса; при этом не забывайте, что доминирующую роль в этом союзе играет именно бизнес. Вряд ли вам как технарю это понравится, но такова реальность, и подход, о котором я говорю, себя окупает.
Ретроспективные совещания
Будем надеяться, что поминки проектов вам проводить не придется. Совещания, тип которых обозначен в заголовке, не должны представлять собой арену для выражения недовольства; на самом деле это лишь формальный способ обучения на собственном опыте. Как писал Норман Кит (Norman Keith):
«Степень эффективности и успеха ретроспективных совещаний обусловливается безопасностью сотрудников. Под безопасностью я имею в виду защищенность сотрудников от критики в рамках их группы. Лишь при таком условии они смогут обсуждать собственные результаты и даже признаваться в том, что поставленных целей можно было достичь по-другому, более оптимальными способами – иначе говоря, учиться анализировать выполненные проекты. Безопасность необходимо культивировать и поддерживать. Несмотря на то, что, по большому счету, безопасность выражает ответственность всех участников ретроспективного совещания, его руководитель призван создавать условия для безопасности, следить за ее поддержанием и контролировать это ощущение. Чтобы сотрудник чувствовал себя в безопасности, он должен быть уверен, что за проявленную честность он не получит по ушам (например, не нарвется на отрицательную оценку во время следующего критического обзора). В ходе ретроспективного совещания не обойтись без постоянного и должным образом поощряемого взаимодоверия»[57].
Проведя ретроспективное совещание в «безопасном» формате, вы получаете хорошие шансы почерпнуть довольно существенные сведения относительно недавно завершенного проекта. Эти знания, в свою очередь, позволят вам усовершенствовать процесс разработки. Необходимость соблюдения на ретроспективных совещаниях ощущения безопасности связана с тем, что иногда сотрудникам на них приходится отвечать на неприятные вопросы.
В ходе ретроспективного совещания, помимо прочего, полезно определиться с ответами на нижеследующие вопросы.
• Насколько четко была сформулирована спецификация продукта? Другой вариант того же вопроса: не случилось ли так, что в силу многократного пересмотра спецификации этап проектирования пришлось отложить на слишком долгий срок?
• Нашлось ли у вас время на макетирование проектного решения или же вы сразу приступили к кодированию?
• Трудно ли было расширять существующую архитектуру новыми функциями?
• Внес ли руководитель проекта весомый вклад в его успешную реализацию? Как можно оценить его организованность, компетентность и готовность к участию в проекте?
• Если бы вам представилась возможность написать тот же код снова, сделали бы вы что-нибудь по-другому?
• Находились ли в вашем распоряжении все программные инструменты, необходимые для решения поставленных задач?
