Практически все менеджеры проектов рано или поздно сталкиваются с явлением профессиональной апатии своих сотрудников. Впервые слово “конфигуратор” в подобном контексте использовал Роберт Шекли в своей известной фантастической повести “Необходимая вещь“. По сюжету, главный герой перед стартом космического путешествия вместо приобретения двух с лишним тысяч запасных деталей по контрольному списку – приобрел аппарат, мгновенно создающий любые мыслимые предметы и механизмы по первому же требованию. Но вот беда – лишь в далеких глубинах галактики обнаружилось, что разработчики заложили в машину черезчур много свободы воли, и ее искусственный интеллект отказывался производить более одной копии одного и того же предмета. Ему было скучно повторяться…
Синдром конфигуратора подстерегает всех тех разработчиков, которые достигли заметных результатов в своей профессиональной деятельности, но не достигли достаточного самоконтроля и самодисциплины. В каком-то смысле это напоминает йогу – развивая себя в творчестве, нужно развивать себя и в плане контролирования своих чувств, эмоций, желаний. Конечно, не до состояния зомби, в котором разработчик выполнял бы поставленные задачи как робот, но до тех пор, когда в его сознании сформируется баланс между реальными коммерческими целями компании и абстрактными задачами дальнейшего саморазвития.
Синдром конфигуратора затягивает, как наркотик. Получая задание, требующее исследований и новаторских решений, разработчик уходит далеко вперед от коллектива. С каждым часом, с каждым днем ему будет все сложнее вернуться к рутинной повседневной работе. Это очень опасный шаг, и на него следует решаться только в том случае, если вы уверены в коммерческой пользе ожидаемого результата. Требуйте от разработчика более детальной отчетности, чем обычно, и не забывайте знакомить коллектив с полученными наработками.
Сотрудники, подверженные синдрому конфигуратора, вносят серьезные психологические “помехи” в работу коллектива. Им тяжело выполнять рутинные задачи, они с неохотой берутся за любые изменения, даже если речь идет про изменение к лучшему, даже просмотр старого кода (не говоря об исправлении) вызывает у них “ломку”. Хорошо, если благодаря структуре программного кода изменения вносить легко, но плохо то, что даже хорошо спроектированная система со временем воспринимается все хуже и хуже: разработчики нуждаются в “новой дозе”, мотивируя это тем, что “вот в этот раз мы уж точно напишем идеальную систему”. Результат известен многим руководителям: разработчики так увлекаются проектированием, что многие решения остаются только на бумаге: их не только не успевают, но и вообще не хотят претворять в жизнь…
Команда разработчиков доходит до абсурда: из-за крайнего нежелания переделывать вообще что-либо, сотрудники начинают требовать четко поставленного ТЗ и становятся неспособны к какой-либо аналитической или исследовательской деятельности, которая хоть на долю процента подразумевает выбрасывание части кода (вспомните известное утверждение: “всегда пишите первую версию с учетом того, что ее придется выкинуть в мусорную корзину”). В результате, вместо того чтобы использовать гибкие методики разработки (суть которых – с минимальными трудозатратами реагировать на изменения), разработчики начинают голосовать за четко поставленное ТЗ на годы вперед (что невозможно по определению) и начинают ненавидеть тех, кто вносит любые поправки в процессе разработки…
Синдрома конфигуратора можно частично избежать, если уметь четко ставить задачи (и воспитывать ваших заказчиков), а так же если сами по себе проекты, которые вы разрабатываете, действительно интересны и полезны людям. Но помните, что это лишь снимет симптомы: до истинных причин вам еще предстоит добраться.