Говоря о проектах разработки и внедрения программного обеспечения, мы очень часто обсуждаем проектные подходы, профессиональные качества команды, важность правильного взаимодействия между ролями внутри команды и многие другие аспекты. Однако очень часто мы забываем об одном из важнейших аспектов, который в высочайшей степени влияет не только на ход проекта, но и на его результаты. Любой софт делается людьми и для людей, поэтому специалисту крайне важно иметь хотя бы поверхностное представление того, каким образом человеческий фактор влияет на аспекты проектной деятельности. Публикуем для вас серию небольших статей о человеческих факторах в разработке программного обеспечения и открываем ее самой, пожалуй, очевидной статьей — о человеческих факторах в команде проекта.
Современные проектные команды можно разбить на 2 типа:
- демократические команды,
- иерархические.
Говоря о демократических командах, это команды, в которых все равны, в них нет четкой иерархии. Такие команды наиболее актуальные для академической среды, то есть команды студентов на каких-либо проектах будут скорее демократическими, не смотря на то, что в ней может быть выбран лидер, однако часто они встречаются и в отрасли. Огромный плюс таких команд — взаимозаменяемость каждого участника, что означает поддержание определенного уровня суммарных компетенций команды практически в любых, даже самых непредвиденных ситуациях. Такая команда в силу своих характеристик наиболее сочетается с методиками Agile, когда компетенции каждого члена команды практически одинаковы, когда команда работает на результат как единое целое, когда в команде нет руководителя, но есть скорее лидер.
Однако у таких команд, особенно при отсутствии должного администрирования, появляется и огромный минус, а именно коллективная ответственность. Почему это плохо? Потому что когда ответственны все, не ответственен никто. И наиболее это ярко выражается, если команда сталкивается с трудностями. Легко быть коллективно ответственными за успех, но в провалах почти наверняка начнут искать виноватого. Как можно избежать подобных ситуаций, если вы работаете как раз в такой команде или даже являетесь ее лидером? Исходя из нашего опыта, можем предложить несколько вариантов решения подобных проблем:
- Заведите лист, где вы сможете видеть, кто из членов команды ответственен за какую задачу. Это может быть доска в Trello, лист Excel, находящийся в общем доступе, или онлайн доска со стикерами (подобных ресурсов множество).
- Этот совет вытекает из предыдущего: когда человек видит, что он закреплен за определенной задачей, он чувствует личную ответственность за ее результат. Таким образом, при задержке реализации какой-либо задачи или ее невыполнении выясните, почему так вышло и что готов сделать человек, чтобы в дальнейшем подобные ситуации не повторились.
- Стоит определить роли в команде и зоны ответственности. На начальных этапах, возможно, всем проще работать вместе (особенно если это первый проект для каждого участника), однако дальше тим лидеру стоит делить обязанности между членами команды исходя из сильных сторон его сокомандников.
- Если ваша команда демократическая и ваш опыт участия в различных проектах примерно одинаковый, вряд ли попытка превратить такую команду в иерархическую увенчается успехом. Жесткий стиль управления при недостатке авторитета и опыта только снизит мотивацию команды и вызовет раздражение. Вместо этого, постарайтесь сделать упор на дружескую атмосферу в команде, чтобы каждый не стеснялся высказать свое мнение и был услышан.
Иерархическая команда — довольна популярная структура во многих организация, существует явно выраженная структура подчиненности и отчетности, причем зачастую выстроенная в несколько уровней. Аналитик Вася отчитывается перед менеджером команды, менеджер команды перед менеджером проекта, менеджер проекта перед куратором проекта и так далее. Таких слоев и названий ролей может быть самое разное количество.
Как вы думаете, какая черта самая популярная в таких командах?
Правильно, делегирование! Что интересно, делегирование это может представлять угрозу эффективной работе команды с двух разных точек зрения. С одной стороны, делегирование может быть слишком частым, так как при наличии огромной иерархии над исполнителем, довольно трудно понять, какого уровня решения ты, как исполнитель, имеешь власть принимать. С другой стороны, может быть и обратная ситуация. Представьте, что случилась действительно критичная ситуация, о которой необходимо сообщить менеджменту. Тут, к сожалению, срабатывает у людей боязнь оказаться ненужным или, того хуже, показаться виноватым, поэтому информация о проблемах выше не идет.
К тому же, к сожалению, в таких командах все довольно сложно с уровнем ответственности, и здесь имеется в виду ответственность перед компанией в целом. Огромное количество уровней менеджмента заставляет исполнителей наталкиваться на мысль о том, что они мало влияют на текущую ситуацию. Ответственность здесь в большей степени сконцентрирована внутри команды исполнителей друг перед другом.
Что же можно сделать, чтобы работа такой команды была эффективнее?
Мы считаем, что здесь основная задача менеджера проекта заключается в четком разделении и своих полномочий, и полномочий лидера команд. Хорошей идеей будет показать несколько примеров ситуаций, произошедших в ходе предыдущего проекта, которые были неправильно урегулированы, и пояснить, как следует действовать в подобных ситуациях. Конечно, невозможно предсказать всё, однако теперь сотрудники почувствуют себя более подготовленными и уверенными. Если вы являетесь лидером команды или менеджером проекта, на вас лежит ответственность за то, чтобы подчиненные знали, на что им стоит обратить внимание, с какими вопросами к вам обратиться, а главное, не сомневались в том, что им помогут. Да, картина получается идеальная, но мы считаем, что стремиться к ней вполне реально 🙂
Но вот наиболее критичным минусом такой структуры команды является отсутствие у исполнителей понимания «общей картинки» того, что происходит в рамках проекта, что может вести к ошибкам в их действиях.
Почему это наиболее критично?
Потому что в проектах разработки программного обеспечения каждому исполнителю (аналитику или программисту) очень важно иметь общее представление об архитектуре разрабатываемой системы и о том пуле потребностей, которые есть у заказчика. Подобную проблему прочувствовал на себе любой начинающий специалист. Вы устраиваетесь на работу, готовы трудиться и набираться опыта, а вам дают мелкие и, на ваш взгляд, несущественные задачи и не поясняют, на что влияет результат выполнения этой задачи и что будет, если вы с ней не справитесь. Естественно, координаторы и наставники не хотят тратить свое время, которого и так недостаточно, на объяснения и лишнюю возню с младшими сотрудниками. Но мы считаем, что правильное формирование картины в целом у молодых специалистов поможет им в дальнейшем избежать ряда ошибок, ускорит обучение,повысит мотивацию и поможет быстрее влиться в коллектив.
Что можно сделать, если вы и есть такой младший консультант, аналитик или программист?
Не стесняйтесь спрашивать своих наставников, выбирайте удобные моменты для вопросов и старайтесь с помощью наводящих вопросов выяснить то, что вам нужно, и показать, что вам интересно развитие как специалиста и результат проекта в целом. Главное — преодолеть внутренний барьер, который формируется у нас при обучении в школе и университете, где отношение к вопросам зачастую негативное, особенно, к вопросам «зачем» и «почему».
