Быть руководителем технической команды, безусловно, — огромная ответственность. Направляя профессионалов в нужное русло, можно создать по-настоящему гениальные вещи. С тем же успехом их можно уничтожить в зародыше. Об этом наш материал далее.
/ фото Bureau of Land Management CC
Даже самые выдающиеся идеалисты на топовых позициях сталкиваются с нехваткой ресурсов, дедлайнами и боссами, требующими предсказуемых графиков и результатов. В таких условиях фокус смещается с потребностей и настроения подчиненных на сиюминутные задачи. Тем временем успех в IT зависит в первую очередь от людей и идей, а уже после – от технологий. По данным IBM Systems Magazine, 54% неудач IT-проектов связаны с управлением и лишь 3% имеют отношение к техническим проблемам.
С этим согласны даже люди, примерившие на себя роль проект-менеджера. Например, Амр Ноаман Абдель-Хамид (Amr Noaman Abdel-Hamid) в 2003 году занял руководящую должность в IBM благодаря опыту работы в компании и технической подготовке. Однако он сам не считает это решение хорошим, так как в его личной иерархии на первом месте среди необходимых для проект-менеджера качеств стоит способность мотивировать команду.
Кто-то скажет, что высокой оплаты вполне хватит для разжигания энтузиазма. Но в октябре 2012 года известный экономист Дэн Ариэли (Dan Ariely) в рамках TEDTalk заявил, что деньги как исчерпывающий мотиватор для достижения идеальной работоспособности чересчур упрощен. Ариэли наблюдал за группой инженеров одной компании в Сиэтле, которой было предложено реализовать крупный проект. Он был для них не просто работой, но интересной задачей.
После двух лет разработки руководитель внезапно сообщил сотрудникам, что проект отменяется. Несмотря на то что при участниках команды остался прежний уровень оплаты и должности, они впали в уныние. Ариэли обнаружил, что они перестали так же упорно работать, как прежде. К тому же в коллективе начались опоздания, и никто не хотел задерживаться на работе.
Этот пример говорит об одном: хотя щедрая материальная компенсация является необходимой частью рабочего процесса профессионала, только ее недостаточно.
Внутренний огонь разработчиков может погаснуть по воле неверного управленческого решения и не разгореться уже никогда. В сегодняшнем материале мы решили поговорить об управлении проектами и разобрать основные подходы, которые могут повлиять на мотивацию.
Забудьте о планировании
Итак, проект ждет реализации. Хотя еще не разработаны минимальные требования, все же уже пришло время нанять разработчиков. Пусть они пока сидят и догадываются, что вам от них нужно, а вы назовете это гибкой методологией разработки.
Исследование Geneca показало, что только 55% руководителей четко понимают бизнес-цели своих проектов. Другие же принимают решения наугад и заставляют страдать подчиненных, ведь сроки разработки перестают быть хоть сколько-нибудь реалистичными.
На заключительном этапе проекта, когда все проблемы оказались на поверхности, из уст людей, принимающих решения, можно часто услышать: «Нам нужно было больше времени потратить на планирование». Отсутствие плана обязательно выльется в хаос, который не останется без внимания подчиненных. Когда руководитель начинает метаться от одной задачи к другой, менять решения и фокусы на различных аспектах, мотивация резко начнет гаснуть.
Поэтому перед стартом проекта нужно убедиться, что цели четко поставлены и согласованы с основными заинтересованными сторонами. От этого зависит финансовое планирование, общие ожидания и задачи. Чем крупнее проект, тем ценнее становится формальное и ясное изложение информации.
Всех под одну гребенку
На качество работы влияет только компетентность и скорость исполнения, верно? В идеальном мире, пожалуй, это так, но в реальности личные качества сказываются на результате работы.
Да, можно открыть свежий отчет Stack Overflow и составить впечатление о том, каким должен быть разработчик. Здесь можно узнать усредненные данные о возрасте, образовании, опыте и прочую обезличенную информацию. Однако когда дело доходит до работы, все это теряет смысл.
Андреа Гоулет (Andrea Goulet), глава IT-компании Corgibytes, считает, что разработка ПО изобилует стереотипами. Один из них заключается в том, что все разработчики обожают переписывать код с нуля, а не вносить изменения в существующий. На деле же есть два типа профессионалов: «мэйкеры», которые предпочитают работать с «пустым холстом», и «мэндеры», подхватывающие проект на этапе MVP и работают над безопасностью, масштабируемостью, производительностью, корректировкой ошибок и улучшением функций. Это слаженный тандем, на котором строится эффективная командная работа.
Успех проекта и компании полностью зависит от личностных качеств разработчиков. Как считает Андреа, ключ к управлению командой — это мотивация сотрудников в зависимости от их подходов к работе. Мэйкеры схожи с кроликами — они разгоняются на коротких дистанциях. У мэндеров же больше общего с медленными и степенными черепахами. Все это следует учитывать руководителю и вовремя уловить модель работы подчиненного. Нужен прототип — пора обратиться к созидателям. Появилась проблема — разберутся мэндеры. Не стоит пренебрегать изучением характеров. Разработчики не универсальные солдаты, и непонимание этого факта может стоить впустую потраченных ресурсов.
Удобные инструменты не нужны
С какой стати вам вообще заботиться об облегчении жизни разработчика? Разве кто-то пытается упростить работу проект-менеджера? Однако именно проект-менеджеру следует наладить связи и упростить взаимодействие между отделом разработки и другими сотрудниками.
Мостиками между отделами выступают удобные инструменты, которые позволяют людям различных профессий разговаривать на одном языке. Существует множество решений во всех важных для разработки отраслях. Например, Moqups и InVision помогают дизайнерам в совместной работе над макетами, GitHub и Bitbucket позволяют разработчикам координировать совместную работу над кодом. Если вы не позаботитесь об устранении барьеров между участниками команды и выработкой стандартизированного набора инструментов, проблемы будут лишь накапливаться.
Сосредоточьтесь на мелочах
Есть хорошая идея: нанимайте действительно талантливых людей, а затем «душите» их заинтересованность, мотивацию, а вместе с ними и эффективность в тысяче мелочей — заставляйте формировать отчеты после каждой новой строчки кода, вчитывайтесь при этом в каждое предложение. Да, и не забудьте заставить сотрудников запрашивать разрешение на каждую новую строчку кода. И пусть каждое утро на вашем столе будет лежать список запланированных на день дел разработчика с детализацией до минуты.
Такой подход называется микроменеджментом. Цель этой стратегии заключается в том, чтобы свести к минимуму способность талантливых сотрудников работать независимо от руководителя. Он отлично работает, если вы намерены превратить разработчиков в безвольных зомби, и губителен для созидательной обстановки.
Нужно работать, а не учиться
Вас тоже раздражает, что разработчики порой тратят время на изучение новых языков, инструментов и фреймворков? Они хотят участвовать в конференциях и получать доступ к платным курсам, в то время как у вас работа в полном разгаре.
Все бы ничего, но, согласно go2HR, в 40% случаев недостатка обучения сотрудники уходят в течение первого года.
Подчиненные, умеющие абсолютно все и автоматически получающие актуальную информацию во время сна, — утопическая мечта проект-менеджера. В реальности же разработчикам хочется совершенствоваться. И это хорошо по двум причинам: во-первых, тяга к знаниям неплохо характеризует работника как личность, во-вторых, потребности команды могут меняться на разных этапах разработки продукта, и мультифункциональный разработчик придется здесь как нельзя кстати. Важно учитывать снижение эффективности во время обучения, которое компенсируется новыми навыками команды. Профессиональное развитие сотрудников не только приносит пользу самому обучающемуся, но и всей компании.
Консультант во всем разберется
В привлечении третьей экспертной стороны в процесс разработки нет ничего предосудительного. Но у некоторых проект-менеджеров есть дурная привычка отводить внешним консультантам центральную роль, принижая собственных подчиненных.
Как правило, на стороне специалиста извне оказываются подготовка и опыт, на фоне которых достоинства собственных разработчиков меркнут. Зачастую консультант преследует свои интересы и ставит их выше клиентских. Эти люди бывают чрезвычайно убедительными, отчего в английском языке их даже называют dazzlers — ослепляющими.
Случается, что волшебное сияние в действительности не подкреплено прочными знаниями, но обаяние «эксперта» не позволяет руководителю трезво мыслить. В такой ситуации разработчики быстро понимают, что происходит, и теряют мотивацию, ведь их ценность и знания поставлены под сомнение. Слепо доверившись внешнему консультанту, проект-менеджер рискует остаться с ним наедине у разваленного продукта.
Поэтому важно объективно оценивать компетенцию привлеченной стороны, строго разграничивать зоны ответственности и ставить конкретные KPI.
Заказчик всегда прав
Как и в случае с внешним консультантом, речь здесь идет о вопросе приоритетов. Разработчики сохранят мотивацию, если будут чувствовать, что их руководитель с ними на одной стороне.
Проект-менеджеры должны обеспечивать реализацию проекта. Иногда это подразумевает под собой отказ во внесении лишних функций и правок. Если руководитель соглашается на все, не задумываясь о том, как с новыми и необоснованными задачами будут справляться его подчиненные, вера в лидера команды рассеется, и на ее место придет разочарование.
Нужно больше совещаний
Если вы поймали себя на мысли, что на часах уже двенадцать, а вы со своей командой вот уже час обсуждаете итоги предыдущей встречи, что-то явно идет не так.
Как однажды сказал известный экономист Джон Кеннет Гэлбрейт, «встречи необходимы, когда вы не хотите ничего делать». Применительно к разработке это не совсем справедливо, ведь здесь весь фокус заключается в грамотной координации. В самих обсуждениях нет ничего плохого. Они укрепляют коллектив, позволяют всем членам команды понимать, на каком этапе проекта вы находитесь. Но, как и с микроменеджментом, здесь важно не перегнуть палку.
Слишком большое количество встреч по незначительным поводам — плохой знак для сотрудников. Фрэнк Келли (Frank Kelly), тимлид в Nokia, считает, что в идеале разработчики должны быть в состоянии самостоятельно наладить связь друг с другом, а встречи не должны носить принудительный характер.
В опросе Industry Week от 2012 года руководители признались, что не менее 30% времени, проведенного на собраниях, потрачено впустую. Поэтому важно выработать для своей команды единый регламент встреч. Например, вы должны договориться о максимальной продолжительности совещания или о том, что обсуждения начинаются, даже если кто-то опаздывает. Приглашайте меньше людей на одну встречу — эффективность снижается с увеличением числа участников. Контролируйте обсуждения, договоритесь не использовать гаджеты, оглашайте повестку митапа заранее, чтобы все участники подготовились. Самое важное — не «мучайте» подчиненных обсуждениями по незначительным поводам. Это не только снижает эффективность, но и влияет на настрой команды.
P.S. Парочка ссылок по нашим профильным темам из блога о корпоративном IaaS:
- Размещение бизнес-критичных приложений в облаке IaaS
- Облачные технологии в фотограмметрии и сельском хозяйстве
- Аварийное восстановление как услуга: преимущества и недостатки
- Плюсы и минусы облачных сервисов в модели IaaS, PaaS, SaaS
- На что обратить внимание при выборе услуги облачного PCI DSS хостинга
Автор: it_man
