/ фото 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-дайджест: 30 материалов о работе с ПД и высокой производительности.
P.P.S. Парочка ссылок по нашим профильным темам из блога о корпоративном IaaS:
- Размещение бизнес-критичных приложений в облаке IaaS
- Облачные технологии в фотограмметрии и сельском хозяйстве
- Аварийное восстановление как услуга: преимущества и недостатки
- Плюсы и минусы облачных сервисов в модели IaaS, PaaS, SaaS
- На что обратить внимание при выборе услуги облачного PCI DSS хостинга
Комментарии (29)
http2
28.07.2017 12:31+1По данным IBM Systems Magazine, 54% неудач IT-проектов связаны с управлением и лишь 3% имеют отношение к техническим проблемам.
Эти бы слова, да в уши начальству :)
Ну и по остальным пунткам тоже плюс. :)
П.С.
Эта статья — тот редкий случай, когда я с ней согласен, а не язвлю с тупости. :)Dmitry_5
29.07.2017 17:17По хорошему, если начальник хочет кого-то наказать, к нему самому должны применяться еще более жесткие меры. Ведь это его факап.
mikhailt
28.07.2017 12:48+2Есть отличний анализ типов разработчиков в книге ""/«Как пасти котов» Дж. Рейнвотера.
На Хабре был пост о ней https://habrahabr.ru/company/piter/blog/265389/
Книга старая, но всячески рекомендую к прочетнию тем, кто руководит программистами.
Отдельная благодарность за ссылку на статью в IBM Systems Magazine.
К сожалению, даже в ней не написано, почему проваливаются оставшиеся 43% проектов.
ncix
28.07.2017 13:18Есть интересный пример из жизни, очень бы хотелось комментариев:
В режиме стартапа, без четких требований и описаний API был реализован на коленке некий проект, включающий серверный код, клиентское веб-приложение да еще и мобильное приложение с отдельной функциональностью. Все это интегрировано с неким коммерческим веб-сервисом (который тоже в режиме стартапа). Делалось все на энтузиазме небольшой команды. В итоге всё взлетело и стало работать, но код во всех трёх блоках был конечно ужасен. План был таков, что после релиза MVP и пилотирования будут понятны пожелания клиентов из которых можно будет понять планы развития и спроектировать подходящую архитектуру.
После двух месяцев пилотирования оказалось, что бэкэнд, написанный на PHP в самом ужасном стиле в общем-то прекрасно работает и не требует доработок. Тем не менее, мнения участников команды разделились — одни утверждают что именно бэкенд нужно переписать с нуля качественно, т.к. в будущем он может создать проблемы (и это правда). Другие считают, что т.к. в перспективе задач для бэкенда нет, его лучше оставить как есть, сосредоточив ресурсы на фронте и мобильном приложении, к которым уже набрался приличный стек пожеланий клиентов.
GDXRepo
28.07.2017 13:27Личное имхо. Бек — это основа работы сервиса в целом, а также основа для функционирования мобильных приложений. Качество всего сервиса и услуг, которые он предоставляет, основано именно на бекенде. Если вы не планируете оставлять проект на том же уровне, что и сейчас, а хотите в будущем его развивать (а это нормально, любой остановившийся в развитии проект быстро теряет клиентов), — то вам нужен бекенд, который можно будет легко расширять и сопровождать. Поэтому в него стоит вложить время и усилия, причем лучше это сделать именно сейчас, пока нет каких-то тяжелых проблем, срочных задач и так далее, то есть можно относительно спокойно все перепахать, не трогая при этом рабочую версию сервера. А мобильные разработчики вполне себе могут параллельно пилить свои платформы на существующем серваке, им никто не мешает. Если есть нехватка ресурсов — я бы поправил критичные проблемы на фронте (если таковые имеются, т.е. не пожелания, а именно проблемы, мешающие использованию приложения, самые-самые яркие жалобы клиентов), а потом бросил силы на приведение бекенда в состояние «сияет всеми цветами радуги». Потом уже и мобильные подтянуть.
Если коротенько — важно иметь фундамент. Бек — это фундамент для мобильно-ориентированного сервиса. Без фундамента вы в любом случае, рано или поздно, но придете к его модификации, и вот тогда плохо будет всем. И серверным разрабам, и мобильным. И компании в целом, естественно.ncix
28.07.2017 13:32то вам нужен бекенд, который будет легко расширять и сопровождать.
В том и проблема, что на текущем этапе нет задач, требующих доработок бэкенда. Соответственно можно только догадываться о направлении его расширения. А значит тратить ресурсы на гипотезы, а не на факты.
Если есть нехватка ресурсов — я бы поправил критичные проблемы на фронте (если таковые имеются, т.е. не пожелания, а именно проблемы, мешающие использованию приложения, самые-самые яркие жалобы клиентов)
Да, но у потенциальных клиентов есть конкретные пожелания по функциональности фронта и мобильного приложения. Без их реализации они не станут клиентами. А без клиентов cashflow проекта просто не позволит переключиться из режима разработки на энтузиазме в режим нормального экономически выгодного производства.
GDXRepo
28.07.2017 13:44+2Грамотные специалисты по бекенду (и по мобильным аппам тоже) могут превратить код из «помойки» в аккуратное творение, готовое хотя бы к сопровождению, а также к небольшому расширению. Если специалист говорит, что код ужасен (судя по вашему посту выше), но при этом не представляет, как его модифицировать, если нет «конкретных задач», — то, возможно, стоит поискать более квалифицированного специалиста, хотя бы и со стороны, как консультанта (хотя сам не одобряю консультантов, но ситуации разные бывают). Никто не говорит, кстати, что нужно пытаться придумать несуществующие задачи и сделать из бекенда этакого семиголового монстра, который может все и ничего одновременно. Речь всего лишь о том, что нужно отшлифовать, перекрасить и отполировать то, что и так работает, но находится в плачевном состоянии.
Но в целом тут уже вопрос к вам как к руководителю. Нужно расставить приоритеты, выяснить, какие задачи по мобилкам тянут приложение вниз (если таковые имеются), и какую часть имеющихся ресурсов вы готовы направить в фундамент, а какую — в удовлетворение клиентов. Полностью довольными клиенты не будут никогда, всегда есть некий неплохой процент тех, что что-то предлагает или хочет изменить, это нормально. Важно лишь выделить оттуда действительно стоящие вещи.ncix
28.07.2017 13:53Грамотные специалисты по бекенду
А их нет у нас. Есть только начинающие, постепенно растущие.
стоит поискать более квалифицированного специалиста
На энтузиазме? Платить пока нечем. Пробовать искать за долю — значит двигать все доли в команде. Очень непростая задача, есть реальный риск развалить команду.
Полностью довольными клиенты не будут никогда, всегда есть некий неплохой процент тех, что что-то предлагает или хочет изменить, это нормально. Важно лишь выделить оттуда действительно стоящие вещи.
Тут как раз всё очень просто. Есть структурированный список "хотелок", есть количество желающих клиентов по каждому пункту, отсюда легко определить приоритеты.
GDXRepo
28.07.2017 13:57+1Смотрите сами, опять-таки, это вопрос исключительно к вам как к руководству. Бизнес «без оплаты, на энтузиазме» — это всегда двойной риск. Сам стартап — это уже риск, а если у стартапа нет денег — это уже совсем рискованно, потому что все держится именно на энтузиазме. А энтузиазм — штука переменчивая. Как минимум, стоит сосредоточиться на том, чтобы люди не потеряли веру в проект, но и вся ваша клиентура не разбежалась, а также чтобы стартап не уперся в стенку, когда столкнется с необходимостью внести изменения в код, который невозможно модифицировать. Этот баланс крайне сложно соблюдать, и редко это получается на 100%, но в этом и состоит прелесть и одновременно сложность работы руководителя. Думайте, что для вас лучше, куда распределять ресурсы и куда лучше вести компанию. Тут вряд ли мнение со стороны вам чем-то поможет, особенно когда неизвестны никакие внутренние детали процессов, протекающих в компании.
Lamaster
28.07.2017 14:27> https://vk.com/video3981242_168222671?t=47m20s
Задачи всегда есть. Да хоть нагрузочное тестирование, рефакторинг на скорость, на отдачу веб-страниц, логирование, алерты о дауне серваков и тд.Lamaster
28.07.2017 14:31Ошибся с копипастой цитаты:
В том и проблема, что на текущем этапе нет задач, требующих доработок бэкенда
ncix
28.07.2017 14:58Это всё стОит ресурсов, есть ли экономический смысл на текущем этапе?
Ivanko63rus
29.07.2017 09:49+1У вас вопросы, по которым вы должны дать ответ самому себе.
Спрашиваете что делать — удовлетворить клиента или проработать архитектуру. Когда вам предложили доработать архитектуру, вы ответили что у вас сейчас нет ресурса и может не хватить мотивации людей. Вывод думаю очевидный напрашивается.
Прочитав ветку, думаю что нужно монетизировать и работать с клиентами чтобы было чем платить работникам.
После чего можно говорить о бэкенде.
mayorovp
28.07.2017 13:57+2Надо собрать все комментарии разработчиков про бэкенд, систематизировать и сохранить где-нибудь — иначе, когда дело все же дойдет до переписывания бэкенда, никто уже не будет помнить зачем его переписывать-то собрались.
Также имеет смысл заранее продумать архитектуру нового бэкенда, и оценить трудозатраты, результат положить в ту же папочку что и комментарии разработчиков. Такая ситуация, когда уже есть рабочий прототип с набитыми на нем шишками и пока что неограниченное время на проектирование, идеальна для waterfall-разработки, и этим надо воспользоваться.
Непосредственно код нового бэкенда сразу писать не нужно пока старый хорошо работает.
AnneSmith
30.07.2017 10:58-1всегда поражает разница на уровне менталитета:
по-русски это всегда «8 верных способов загубить разработку»
по английски это всегда «Eight Proven Ways to Make Your Project a Success»
Neikist
31.07.2017 13:31AnneSmith
01.08.2017 06:49можно и так назвать, хотя в современном варианте это реализовано как minimum viable product (MVP), по сути те же шаги на пути к успешной реализации проекта с промежуточным тестированием и последующим улучшением
однако, думаю, что создатели военных самолетов бы приняли бы идею MVP в контексте невернувшихся машин за величайшее оскорбление, потому что они действительно делали максимум того, что им было доступно
Wild_ButcheR
02.08.2017 11:59Уже давно понял, что деньги — не единственная мотивация. Сотрудники ведь не роботы, работая над проектом люди вкладывают плоды творчества. Естественно, им обидно от того, что проект закрывают.
GDXRepo
Крайне интересно было почитать. Причем, после прочтения многие вещи становятся понятны, с которыми сталкивался когда-то в ходе работы. И сразу возникает желание всю эту статью распечатать и повесить в каждом офисе)) Жаль, что мало кто из руководства знает хотя бы половину из перечисленных пунктов. Разработчики тоже не идеальны, но в том и фишка, что никто не идеален, но каждый знает, как совместными и правильными усилиями добиться успеха для проекта и компании в целом. Статейку в избранное, спасибо!
it_man
Спасибо, что читаете!