Искусство управления IT-проектами - Скотт Беркун

Причина почти всех осложнений во взаимоотношениях кроется в конфликтах или недоразумениях вокруг ролей и целей.

Стивен Ковей (Stephen Covey). The 7 Habits of Highly Effective People

В предыдущем перечне проблем общения один из наиболее важных вопросов касался предположений и выяснения их состоятельности. Руководящие роли – самые неоднозначные и наиболее подверженные выстраиванию предположений со стороны других людей. Любой программист или тестер всегда будет переносить свой первый опыт работы с руководителем проекта (плохим или хорошим) на всех своих будущих руководителей. Когда вы приступите к обязанностям руководителя, новая команда спроецирует на вас весь свой предыдущий опыт общения с руководителями проектов, строя самые невероятные предположения о ваших способностях и о вашем предполагаемом вкладе в работу команды. Неважно, насколько хорош, по вашему мнению, ваш прежний послужной список, для плохих предположений места всегда хватит.

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

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

Рис. 9.2. Дискуссии относительно распределения ролей помогают наладить взаимоотношения (это всего лишь пример, ваши списки могут отличаться от этих)

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

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