Как пасти котов. Наставление для программистов, руководящих другими программистами

Надеюсь, что вы запуганы чуть меньше, чем изображенный на рисунке программист. Мы, технари, сталкиваясь с необходимостью взаимодействия с группами разработчиков, с которыми в обычных условиях не общаемся, чувствуем себя не слишком уверенно. Будьте готовы к тому, что «обычный» круг общения начнет расширяться. Далеко не все совещания, которые вам предстоит провести, предполагают присутствие исключительно подчиненных программистов. На них, скорее всего, будут приходить сотрудники нетехнического профиля, равно как и специалисты в тех технических дисциплинах, в которых вы не слишком смыслите. Определенного внимания к себе будут требовать сотрудники, ответственные за формулировку бизнес-требований, люди из отделов поддержки и тестирования, специалисты по проверке качества, финансовые сотрудники и многие другие.

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

Всегда обрисовывайте ваш отдел в идиллических тонах. Никогда не сваливайте вину за срыв сроков на своих подчиненных. Такую позицию очень не любят, и подобными действиями вы только подогреваете нашу и без того пожароопасную индустрию, в которой программисты при оценке своих попыток соблюдения контрольных сроков проявляют себя убежденными идеалистами. Мы можем сколь угодно пребывать в уверенности, что программирование есть искусство (а это действительно так). При этом не стоит забывать, что ваш начальник мыслит по-другому; по его мнению, программирование есть наука с присущей этому понятию предсказуемостью. Выслушивая похвалы, считайте, что вам повезло, но реагируйте на них скромно и достойно; делайте акцент на том, что если бы не ваша команда, никаких достижений не было бы в помине. Хотите высказать сотруднику свои претензии – ради бога, но только в приватной обстановке.

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

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

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

Еще несколько слов о требованиях. Будучи программистом, вы, естественно, любите разрабатывать программные продукты. Отталкиваясь от идеи, вы преобразуете ее в виртуальную реальность. Согласитесь, есть некое волшебство в создании выверенного пользовательского интерфейса, который, к тому же, грамотно состыкован с прикладной частью. Скорее всего, лучшим из всех созданных вами программных продуктов был тот, относительного которого вы четко представляли себе бизнес-требования. Думаю также, что как программист вы получили от разработки этого приложения больше всего приятных минут. Постарайтесь донести это чувство до группы описания продукта, и по мере сбора требований очерчивайте ее сотрудникам пределы возможного. За счет своих технических способностей вы сможете на корню избавляться от всех неудачных идей; навыки же сотрудников группы описания продукта в области бизнеса помогут вам генерировать новые идеи. Учитесь организовывать сотрудничество технологии и бизнеса; при этом не забывайте, что доминирующую роль в этом союзе играет именно бизнес. Вряд ли вам как технарю это понравится, но такова реальность, и подход, о котором я говорю, себя окупает.

Ретроспективные совещания

Будем надеяться, что поминки проектов вам проводить не придется. Совещания, тип которых обозначен в заголовке, не должны представлять собой арену для выражения недовольства; на самом деле это лишь формальный способ обучения на собственном опыте. Как писал Норман Кит (Norman Keith):

«Степень эффективности и успеха ретроспективных совещаний обусловливается безопасностью сотрудников. Под безопасностью я имею в виду защищенность сотрудников от критики в рамках их группы. Лишь при таком условии они смогут обсуждать собственные результаты и даже признаваться в том, что поставленных целей можно было достичь по-другому, более оптимальными способами – иначе говоря, учиться анализировать выполненные проекты. Безопасность необходимо культивировать и поддерживать. Несмотря на то, что, по большому счету, безопасность выражает ответственность всех участников ретроспективного совещания, его руководитель призван создавать условия для безопасности, следить за ее поддержанием и контролировать это ощущение. Чтобы сотрудник чувствовал себя в безопасности, он должен быть уверен, что за проявленную честность он не получит по ушам (например, не нарвется на отрицательную оценку во время следующего критического обзора). В ходе ретроспективного совещания не обойтись без постоянного и должным образом поощряемого взаимодоверия» [57] .

57

Norman L. Kerth, Project Retrospectives (New York: Dorset House Publishing, 2001), p. 7.

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

В ходе ретроспективного совещания, помимо прочего, полезно определиться с ответами на нижеследующие вопросы.

• Насколько четко была сформулирована спецификация продукта? Другой вариант того же вопроса: не случилось ли так, что в силу многократного пересмотра спецификации этап проектирования пришлось отложить на слишком долгий срок?

• Нашлось ли у вас время на макетирование проектного решения или же вы сразу приступили к кодированию?

• Трудно ли было расширять существующую архитектуру новыми функциями?

• Внес ли руководитель проекта весомый вклад в его успешную реализацию? Как можно оценить его организованность, компетентность и готовность к участию в проекте?

• Если бы вам представилась возможность написать тот же код снова, сделали бы вы что-нибудь по-другому?

• Находились ли в вашем распоряжении все программные инструменты, необходимые для решения поставленных задач?

• Как вы думаете, какие составляющие процесса разработки имеет смысл изменить?

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

Телеконференции

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

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