Управляем катастрофой
До сих пор мы только констатировали объективно существующие трудности и проблемы, которые связаны с разработкой программных проектов. Читатель давно уже в праве ожидать от нас ответа на вопрос «что делать?». Короткий ответ – управлять людьми, которые вовлечены в проект. И круг таких людей достаточно широк. Оставшаяся часть статьи будет посвящена управлению программными проектами, а если точнее, то работе менеджера проекта 14 по управлению людьми, как внутри проекта, так и вне него. Начнем по порядку.
Над входом в храм Аполлона в Дельфах написано «Познай себя». Начинайте проект с себя. Вы – менеджер проекта. Если это ваш первый проект, то поздравляю вас с приобщением к благородной профессии. «Управление благородно по своей сути. Менеджмент ничего не имеет общего с деятельностью бюрократа, сидящего наверху. Менеджер делает самую необходимую в компании работу. Благодаря нему становится возможным выполнение самых грандиозных проектов. Нет более почетной работы, чем та, которую делает настоящий менеджер» [].
Но даже, если у вас сверхвысокий IQ , это не поможет вам в управлении людьми. Чтобы управлять людьми, нужны совсем другие качества. Менеджер должен обладать сверхвысоким EQ – коэффициентом эмоционального интеллекта ( Emotional Intelligence ). Вот три компонента эмоционального интеллекта:
? Понять свои собственные чувства.
? Научиться управлять ими.
? Научиться распознавать эмоции других и управлять ими.
Загляните в себя, есть ли у вас необходимые качества. В силу аутистической природы программирования хороший программист, как правило, этими качествами не обладает. Из хороших программистов выходят, как правило, плохие менеджеры проектов. Аутисты предпочитают не общаться с другими людьми и не испытывать потребности в таком общении, они не интересуются другими людьми, стремятся быть в одиночестве. Недостаточный EQ и шизоидные наклонности могут привести к параноидальному стилю управления: чрезмерной бдительности, подозрительности, озабоченности скрытыми мотивами, повышенной тревожности [].
Такие руководители считают подчиненных некомпетентными симулянтами, которые не любят свою работу и стремятся избежать ее, если у них есть такая возможность. Руководители подобного типа практикуют строгий контроль через активное личное наблюдение, формальные правила и ограничения. Ведут себя агрессивно, в особенности с теми подчиненными, которые высказывают свое мнение. «Кнут и пряник»15
для них единственные инструменты мотивации подчиненных. Эти инструменты, может быть, полезны, когда мы управляем стадом баранов, но для управления командой эйнштейнов категорически не годятся. Эйнштейны очень быстро разбегаются, если, конечно, их не огородить колючей проволокой 16. Мы еще вернемся к вопросу мотивации эйнштейнов.
Если у вас недостаточный EQ , не отчаивайтесь. В отличие от IQ , который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни.
Призыв 1. Повышайте свой эмоциональный интеллект, если вы хотите руководить успешными программными проектами.
Поймите свои собственные мотивы. Ответьте себе на вопрос, почему вы беретесь именно за этот проект 17. Помните, что вам предстоит поставить на кон свою репутацию и вложить в проект душу. «Вполнакала проекты не делаются» - очень точная формулировка И. Ставинского []. Поэтому нужно четко понимать, в чем будет ваш выигрыш в случае успешного завершения проекта.
Призыв 2. Поймите свои личные цели, достижение которых связано с успешным завершением проекта.
Эти цели не обязательно должны быть материальными: повышение оклада или должности. Это могут быть идеальные цели: познать новое, сделать то, что до вас никто не делал, обеспечить существенные конкурентные преимущества вашей компании или, наконец, осчастливить все человечество. Главное, чтобы для вас лично эта цель была значимой настолько, чтобы стремление к ее достижению могло бы поддерживать в вас состояние постоянного горения от начала до завершения проекта.
Как мы отмечали ранее, главная цель управления проектом - вызвать у заказчика чувство удовлетворения.
Степень удовлетворенности – субъективная величина, которая является отношением субъективной оценки достижений к субъективной же оценке ожиданий или потребностей. Отсюда следует:
Призыв 3. Продавайте свой проект от начала до завершения работ.
Понимание этого правила пришло ко мне достаточно давно 18, но формулировку его я заимствовал у Тома Питерса []. Продавать проект следует в первую очередь заказчику. Если, после заключения договора на разработку ПО, вы планируете следующую встречу с заказчиком на приемо-сдаточных испытаниях, то вы прямой дорогой идете к катастрофе. Вы должны работать над тем, чтобы заказчик постоянно испытывал чувство удовлетворения от начала проекта до его завершения. Этого можно добиться, если вы разрабатываете проект итерационно: чуть-чуть спроектировали, чуть-чуть закодировали, чуть-чуть протестировали и продали этот результат заказчику. Продали - это означает - убедили (снова психология) заказчика, что вы представили ему нечто большее, чем то, на что он мог бы рассчитывать на текущем этапе проекта. Если во время приемо-сдаточных испытаний критика заказчиком того, что вы произвели, это, скорее всего, признак неизбежной катастрофы, то замечания на ранних итерациях это весомое свидетельство движения вашего проекта к успеху. С радостью принимайте их и тщательно анализируйте 19. Даже если вы не будете уверены в их положительном влиянии (вы ведь можете что-то не знать о бизнесе заказчика), оперативно совершенствуйте свой проект и вновь представляйте результаты заказчику. Тем самым заказчик становится соучастником вашего проекта и соавтором будущего результата. А какой же родитель не любит ребенка, которого он сам растил и воспитывал. Это обратная связь, которая необходима любой системе управления, если вы хотите, чтобы она обладала устойчивостью. Это гарантия того, что на приемо-сдаточных испытаниях заказчик будет ожидать ровно то, что вы ему представите. Управляйте ожиданиями заказчика и формируйте у него адекватную оценку представленного вами результата.
Заказчик далеко не единственный человек, которому вы должны постоянно продавать свой проект. Заказчика окружают люди, которые могут существенно влиять на формирование его мнения. Например, будущие пользователи вашей программы. Вы просто обязаны продавать ваш проект и им. Так же полезно продать проект экспертам в той области ИТ, к которой относится ваш проект. Заручитесь их поддержкой, она особенно пригодится вам, если заказчик не является специалистом в ИТ.
Очень важно продавать проект вашему руководству, если заказчик проекта со стороны. Руководство должно быть постоянно уверено, что проект завершится в срок и в полном объеме. Сделайте проект прозрачным, пусть руководство видит все, от плана проекта до исходного кода программ и скриптов. Руководство, конечно, не поймет, как продвигается ваш проект, но избавится от присущей ему фобии, что от него что-то скрывают. Разработайте для руководства небольшой и ясный набор индикаторов (об индикаторах проекта чуть позже), который будет отражать продвижение проекта к цели, и регулярно представляйте отчет по их изменению, чтобы руководство могло следить за прогрессом проекта.
И если уж речь зашла о руководстве, то уместно привести здесь еще одно правило.
Призыв 4. Не позволяйте руководству принимать других решений в вашем проекте, кроме двух: остановить проект или сменить менеджера.
По всем остальным вопросам в проекте принимать решения должен менеджер, а руководство вправе лишь высказывать свои рекомендации. Если это не так, то вы идете к катастрофе. Джоель Спольски [] так описывает последствия вмешательства руководства: «…Руководители разных уровней с удовольствием запускали руки в каждый стряпающийся пирог, раздавая указания направо и налево в стиле, который я стал называть порулил и убегай. «Порулил и убегай» потому, что начальники появлялись на горизонте вероломно, отдавали глупые распоряжения как именно все, черт побери, должно быть сделано, без какого-либо предварительного размышления, и покидали комнату, оставляя всех собирать осколки».
Если вам не удалось оградить проект от подобных вмешательств, вам, скорее всего, придется собирать осколки до его завершения.
А теперь о самом главном в управлении программным проектом – управлении проектной командой. Управлять людьми – значит побуждать их к правильным действиям. А побуждать их можно, только управляя мотивами. Согласно теории мотивации для того, чтобы человек совершил какое либо действие он должен испытывать некую потребность и предполагать, что, выполнив это действие, он в той или иной степени эту потребность удовлетворит. Поэтому управление мотивами осуществляется, как правило, в двух направлениях: 1) формирование правильных потребностей; 2) формирование правильной оценки степени их удовлетворения 20.
Я отношу себя к сторонникам гуманистического направления в теориях мотивации и исхожу в своей практической деятельности из структуры потребностей, которую описывает пирамида А. Маслоу. Мои многолетние наблюдения показывают, что потребности нижнего уровня пирамиды (физиологические и безопасности) для программистов, как, впрочем, и для других работников интеллектуального труда, играют несущественную роль. Это означает, что если эти потребности удовлетворены процентов на 50-70, то их дальнейшее удовлетворение слабо мотивирует работу программиста. Для программистов гораздо большее значение имеет удовлетворение потребностей принадлежности, самоуважения и самоактуализации. Причем, чем выше квалификация программиста, тем на более высоком уровне пирамиды Маслоу находятся мотивирующие его потребности. Попробуйте уговорить суперпрограммиста перейти на техническое сопровождение системы, даже если вы пообещаете ему в два раза большую зарплату. А вот уговорить его перейти на проект в области сверхновых технологий вполне возможно, даже при некоторой потере в доходах.
Об этом же пишет Э. Йордан []: «Деньги, выгода, комфорт и тому подобное являются факторами «гигиены» - их отсутствие вызывает неудовлетворенность, однако они не могут заставить людей полюбить свою работу и дать им необходимые внутренние стимулы.
Что действительно может дать такие стимулы, так это ощущение значительности достигнутых результатов, гордость за хорошо выполненную работу, более высокая ответственность, продвижение по службе и профессиональный рост - все то, что обогащает работу». Об этом же более 30-ти лет назад писал Вейнберг []: «Творчески работающему программисту присуща глубокая внутренняя мотивация». На мой взгляд, это еще одно следствие аутистической природы программирования.
Призыв 5. Имейте ясное представление о мотивах каждого участника проекта, чтобы эффективно управлять проектной командой.
Как я уже отмечал ранее, потребности каждого программиста зависят от его возраста, опыта и квалификации. Позволю себе привести свою экспертную оценку распределения мотивирующих потребностей для профессиональных программистов.
Потребности |
Профессионализм |
||
Начинающий |
Опытный |
Профессионал |
|
Материальные (зарплата, условия труда, социальный пакет и проч.) |
50% |
20% |
|
Безопасности (стабильность компании, востребованность технологии проекта на рынке труда, возможность повысить квалификацию) |
20% |
||
Принадлежности (возможность учиться у более опытных коллег, опыт участия в успешном проекте, признание в коллективе) |
40% |
20% |
10% |
Самоуважения (развиваться, делать что-либо лучше других, повышение в должности, самостоятельность и ответственность в работе) |
10% |
30% |
40% |
Самоактуализации (амбициозность целей проекта – сделать то, что никто не делал или не смог сделать) |
10% |
50% |
|
Команда успешного проекта это команда победителей. Успешный проект должен сделать победителем всех его участников [].
Призыв 6. Рассматривайте работу команды над проектом как корпоративную игру, в которой каждый участник, стремится к достижению своих личных целей, продвигая проект к успеху.
Управление командой начинается с ее формирования.
Призыв 7. При наборе персонала убедитесь, что человек сможет сделать то, что нужно в вашем проекте и хочет то, что вы сможете ему дать.
Вроде все просто, однако, это не так. Сможет это не только знает и умеет, но еще и захочет 21. А часто бывает ситуация, что не знает и не умеет, например, если технология совершенно новая, но хочет. И этого стремления, как правило, бывает достаточно, чтобы освоить новую технологию и успешно решить поставленную задачу. Главный вывод, который отсюда следует это то, что на серьезный проект, надо набирать разных программистов. И начинающих, и звезд. Если вы берете в проект суперпрограммиста, то должны быть уверенным, что вы сможете эффективно использовать его квалификацию и найдете достойную задачу, которая его заинтересует.
В настоящее время нет каких-либо формальных методик определения квалификации программиста. Мой опыт показывает достаточно значимую корреляцию хороших способностей к программированию и сверхвысокого значения IQ . Высокий балл диплома и престижное математическое или техническое образование свидетельствует об общих способностях кандидата успешно осваивать новый материал. Диплом о престижном высшем образовании немаловажен для хорошего программиста, хотя и не является необходимым условием 22. При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволит вам создать эффективную программистскую команду. О практике проведения интервью могу рекомендовать работы [, ], в которых изложены подходы, во многом совпадающие с моим опытом.
Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации.
Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса - кустарным творением программистов - когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает
для пользователя.
Призыв 8. Не загружайте программистов несвойственной для них работой. Включайте в проектную команду, бизнес-аналитиков, эргономистов, художников-дизайнеров, документалистов. Разделение труда - залог перехода от кустарного производства к более эффективному промышленному производству.
Теперь, когда цели определены, команда собрана, пора приступать непосредственно к созданию программной системы. Поскольку, разработка ПО, как мы отмечали выше, корпоративная игра, то первое, что мы должны сделать, это договориться о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды в проекте. Повторим вслед за автором []: «Каждому проекту своя технология». И чем больше и ответственней проект тем «тяжелей» должна быть технология. Технология может меняться вместе с развитием и ростом проекта, но на каждом этапе она должна быть определена и описана . Бессмысленно спрашивать с программиста ответа за то, что ему не поручено 23.
Призыв 9. Договоритесь о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды.
Регламенты и стандарты требуются еще и для того, чтобы все участники проекта разговаривали на одном языке, а ваш проект не превратился в проект строительства Вавилонской башни.
Иначе, например, если не определено или не исполняется соглашение по правилам кодирования, программисты быстро перестанут понимать друг друга.
Главная задача менеджера - обеспечить максимально эффективное использование знаний и способностей каждого участника проекта для решения проектных задач. Набранная вами группа специалистов это еще далеко не та команда, которая способна быстро и качественно достигать поставленные цели, умеющая самостоятельно принимать нестандартные и эффективные решения. В силу аутистической природы программирования набранная вами группа это собрание индивидуалистов-эйнштейнов, которые, как правило, самодостаточны и не нуждаются ни в руководстве, ни в общении. Для того, чтобы из группы получилась команда, необходима общность представлений участников о нормах поведения в коллективе и ожиданиях от каждого из его участников. Каждый участник команды должен понимать, какое трудовое поведение приемлемо, а какое порицается, каковы должны быть отношения в группе, стиль и методы работы. У меня выработалось определенное представление о правильных нормах поведения, которые я настойчиво внедряю в своих проектах. На мой взгляд, программист может считать себя профессионалом только тогда, когда:
Основные усилия по мотивации участников проектной команды я направляю на то чтобы стимулировать правильное поведение.
Призыв 10. Постоянно работайте над строительством команды, мотивируйте правильное поведение участников проекта.
Очень важно, чтобы каждый член проектной команды знал, или хотя бы имел при желании возможность узнать о проекте не меньше, чем его менеджер. И не стоит ничего скрывать, ни проблем с заказчиком, ни разногласий с руководством. Трудно ожидать самостоятельные, нестандартные и эффективные решения от человека, у которого «шорами» ограничено видение проблемы.
Ошибкой являются попытки управления проектом на микро-уровне: мотивирование достижения формальных индивидуальных показателей, например, реализация программистом функциональных требований, количество написанных им строк исходного кода или плотность выявленных ошибок. В творческой деятельности формальные подходы не работают 24. Де Марко [] по поводу одной из своих коллег говорил: «я слабо представляю, какой вклад она вносит в мой проект, но за 12 лет ее работы в компании все проекты, в которых она участвовала, заканчивались успехом». За ответом направляю к его книге.
Основным инструментом управления у менеджера является план работ. Как мы уже отмечали ранее, работа по проекту должна вестись итерационно, а каждая итерация должна наращивать функциональность, которая определена требованиями к системе. Наиболее приемлемое время итерации от 2 до 6 недель. Именно на этот срок должно осуществляться детальное планирование. Поскольку в реализацию попадают только хорошо проработанные системные требования, то можно добиться достаточно высокой точности плана. Трудоемкость элементарных работ детального плана должна составлять от 4 до 20 часов при расчете на среднего программиста. Каждая итерация должна заканчиваться коллективным анализом «Lessons Learned»: удалось ли достичь поставленных целей, какие проблемы пришлось решать, как реорганизовать технологические процессы для более эффективной работы, - и детальным планированием следующей итерации.
Макро-показателей, по которым менеджер должен осуществлять мониторинг проекта, не так уж и много:
? Процент реализованных функциональных требований от общего числа.
? Объем затраченных на разработку человеко-часов.
? Количество строк исходного кода.
? Количество ошибок выявленных и закрытых.
Динамика этих показателей в сравнении с плановыми значениями позволяет вам и вашему руководству формально судить об успешности продвижения проекта. Если эти показатели существенно (более, чем на 10-15%) отличаются от прогнозируемых, то это свидетельствует о возможных проблемах проекта. Например, если количество кода превышает ожидания, то это может быть следствием ошибок в оценке трудоемкости (придется пересматривать планы, поскольку, скорее всего, увеличится срок проекта) или недостатков архитектуры и слабого повторного использования кода. Меньшее по сравнению с ожиданиями количество выявленных ошибок может свидетельствовать о недостатках в тестировании.
Программисты это, как правило, очень трудолюбивые люди (порой до фанатизма), с глубокой внутренней мотивацией к программистской работе. Как правило, я не вмешиваюсь в работу конкретного программиста, если срок выполнения поставленной задачи не превышен в 2-3 раза по сравнению с оценками в детальном плане. Так я определил для себя допуск на разброс траекторий на молекулярном уровне. Это оправдано, поскольку некоторые задачи решаются в разы быстрее, и на макро-уровне проект продвигается в соответствии с планом. Но если на микро- уровне возникают существенные отклонения от плана, это служит поводом для анализа причин неэффективной работы программиста.
Для эффективной работы программисту необходимо и достаточно выполнение четырех условий:
? Понимание целей работы.
? Желание ее сделать.
? Умение ее делать.
? Возможность ее сделать.
Неадекватное понимание целей конкретного проекта может привести к проблемам. Большинству опытных программистов свойственно стремление решить свою задачу не просто хорошо, а как можно лучше.
Они стремятся сделать задачу для самого общего случая, оптимально по памяти и быстродействию, используя самые последние достижения информационных технологий, закладывая в архитектуру возможность дальнейших расширений. Доводя свою программу до совершенства, программист способен затратить гораздо больше времени, чем реально требуется на задачу. Это стремление всегда вступает в конфликт с коммерческой стороной профессионального программирования, как способа получения доходов. С точки зрения заказчика, качественная программа это та, которая удовлетворяет заявленным требованиям. Не более того 25.
Призыв 11. Нацеливайте программистов на правильное решение задачи максимально быстрым способом.
Опыт свидетельствует, что более чем в 90% случаев ее не придется переделывать. Если работа вашей подпрограммы занимает только 1% общего времени выполнения, то, затратив сколько угодно времени на оптимизацию ее алгоритма, вы не добьетесь улучшения системных характеристик более чем на 1%. Такой выигрыш вряд ли стоит того, чтобы тратить время на оптимизацию. Со всеми остальными программистским наворотами дело обычно обстоит так же.
О мотивации программистов я уже говорил, поэтому добавлю лишь одно правило.
Призыв 12. Не пытайтесь получить от программиста больше того, что он хочет вам дать.
Ключевое слово здесь «хочет», заметьте, не «может», а именно «хочет» 26. Задача не будет выполнена за любое отведенное на нее время, если у программиста нет мотивов для ее решения. Или сумейте мотивировать программиста на выполнение задания, или передайте ее другому участнику проекта. Другого пути нет.
Еще раз напомню, что доминирующие потребности программистов находятся в верхней части пирамиды Маслоу, поэтому пинать и пугать их - занятие совершенно бесперспективное. Для начинающих программистов хорошим стимулом является само участие в успешном проекте (может быть в первом в их жизни), возможность учиться ремеслу у более опытных и искушенных коллег. Для опытных программистов хорошим стимулом может служить новизна и востребованность на рынке труда технологий, используемых в проекте (потребность безопасности).
Для них также существенны сложность и самостоятельность (потребность самоуважения) в решении поставленных задач. Как правило, я стремлюсь ставить задачи примерно в 1,5 раза сложнее, чем те которые данный программист решал ранее. Для опытного программиста каждая новая задача должна предоставлять дополнительную возможность доказать свой профессионализм. Сложнее дело обстоит с суперпрограммистами. Их основным мотивом, как правило, служит самоактуализация, поэтому они стремятся решать задачи, которые до них еще никто не делал. Оптимальное их место в проекте – системная архитектура и реализация архитектурно значимых компонентов системы (скелета системы). При правильной мотивации оставшаяся часть их потребностей принадлежности и самоуважения реализуется через обучение коллег и передачу им своего опыта. На эту деятельность следует планировать до 50% времени суперпрограммиста. Суперпрограммист в проекте должен играть роль технического лидера, который ведет за собой остальных участников под лозунгом: «Делай как я!». Он всегда должен быть готов продемонстрировать, как можно решить любую задачу в проекте.
Третье условие эффективной работы программиста – умение делать порученную работу. Как правило, начинающие программисты мало что умеют. Их главный метод программирования – копирование чужих образцов (Copy/Paste). Это естественный путь обучения ремеслу. Вспомним художников, которые учатся, копируя полотна великих мастеров. Важно, чтобы образцы для подражания были достойными. Поэтому целесообразно поручать задачу паре программистов, в которой один из них выступает наставником, а другой подмастерьем, перенимающим опыт.
У меня нет личного опыта парного программирования, которое рекомендует xProgramming, когда одну программу пишут по очереди. Но есть накопленная с годами уверенность, что ревизия кода более опытным коллегой на предмет «изобретения велосипеда» просто необходима. Кстати «изобретение велосипеда» любимое занятие не только среди начинающих, но и среди уже достаточно опытных программистов, у которых всегда возникает потребность переписать все по-своему.
Этому, как правило, есть две причины. Первая - недооценка сложности поставленной задачи. Вторая - недостаток времени для изучения достижений технологий, используемых в проекте.
Дополнительно, парная ответственность за исходный код страхует ваш проект от негативных последствий неожиданного ухода одного из специалистов 27.
Призыв 13. Планируйте время на самообучение участников проектной команды и обучение менее опытных программистов более опытными наставниками.
Время на это все равно тратится. Но если времени на обучения не достаточно, то будьте готовы к тому, что бездумное применение технологии Copy/Paste будет приводить к размножению ошибок в вашем проекте в геометрической прогрессии, и что масса времени будет тратиться на изобретение очередного велосипеда. Все это неизбежно приведет к снижению общей эффективности работ по проекту.
И о последнем условии эффективной работы – программисту должна быть предоставлена возможность сделать порученную работу. Здесь речь идет не о тривиальном наличии компьютера и инструментов разработки 28. И не о наличие отдельного кабинета, о котором пишет Де Марко 29. В творческой деятельности обязательным элементом ответственности является свобода выбора пути решения стоящей проблемы. Свобода не только необходимое условие творчества, но и важный мотивирующий фактор. Даже если вы уверены в существовании более правильного решения, вы не в праве настаивать на нем, вы можете высказать свое мнение только в виде рекомендации. Предоставьте членам проектной команды право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет. Впрочем, вы ведь тоже можете ошибаться.
Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов свободы. Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники.
Работать больше, это совсем не значит - работать продуктивнее. Скорее наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переработкам. «Хорошо управляемое предприятие - это спокойное место. Зато «фабрика, отличающаяся "кипучей" деятельностью и "трудовым героизмом" работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой». Это не я сказал, это говорит управленец «в законе» [].
Если программист адекватно мотивирован для того, чтобы выполнить порученную работу, то он будет стремиться сделать ее максимально быстро и с необходимым качеством. Многие программисты, особенно молодые, по собственной инициативе готовы тратить на решение задачи по 12-16 часов в сутки. Это неправильно, эффективность работы резко снижается, и при злоупотреблении сверхурочной работой программист уподобляется мухе, бьющейся головой о стекло, вместо того чтобы методично искать правильное решение 30.
Еще одно распространенное заблуждение менеджеров: оптимизм программистов. Я не имею в виду начинающих программистов, я говорю об опытных. На мой взгляд, заниженные оценки сроков решения поставленной задачи, как правило, являются следствием морального давления менеджеров. Программисту в силу своего аутистического нежелания общаться с другими людьми, легче согласиться с навязываемыми руководством сроками, чем объяснять начальству, почему оно не право.
Отношение менеджера и членов успешной проектной команды должны строится не на принципах подчинения, а на принципах партнерства. Партнерство не может быть без доверия. Если в проектной команде нет доверия, это путь к катастрофе.
Призыв 14. Не мешайте программистам. Доверяйте им. Обеспечивайте им свободу творчества. Предоставляйте им право на ошибку. Не оказывайте на них давление.
Повторюсь, управляйте проектом на макро-уровне. Не бойтесь, если одна молекула временно летит медленнее, чем остальные, или не совсем в ту сторону. Главное, чтобы это не было системой, чтобы среднее движение всех молекул было направлено к цели и осуществлялось с необходимой скоростью.
Важнейшим неформальным макро- показателем состояния проекта являются коммуникации, их качество и количество. Если угодно, то по моей экспертной оценке коммуникации, включая наставничество и консультации, в успешном проекте занимают 30-50% рабочего времени. Только благодаря эффективным коммуникациям можно достигнуть синергетического эффекта, который отличает команду от просто группы. Мне неоднократно приходилось убеждаться, что освоение новой информационной технологии парой программистов, которые осуществляют интенсивный обмен знаниями, происходит минимум в 3 раза быстрее, чем в случае, когда ту же работу выполняет один программист. Недостаточное количество коммуникаций свидетельствует, как правило, об отсутствии команды, каждый углублен в свою задачу и не интересуется, что делают его коллеги. В результате будет сделано не то, что нужно, а то, что будет сделано, вряд ли удастся интегрировать в единую систему. Если через день после получения недельного задания у программиста не возникло уточняющих вопросов, жди беды. Скорее всего, он с головой ушел в «проектирование дома, забыв уточнить, для чего он предназначен» []. Учитывая шизоидную несклонность программистов к общению, менеджеру требуется прилагать значительные усилия для того, чтобы мотивировать необходимый уровень коммуникаций.
Эффективность коммуникаций напрямую связана с доброжелательностью межличностных отношений. Не стоит ожидать плодотворного обмена информацией, если участники проекта поставлены в условия конкуренции или разделены барьерами должностной иерархии. Доброжелательность это не отсутствие споров и дискуссий, а нацеленность в спорах и дискуссиях на поиск консенсуса (интегрированного решения проблемы, которое объединяет лучшие стороны всех предложений), а не на выяснение межличностных отношений.
Меня давно перестали напрягать обсуждения в рабочее время членами проектной команды вопросов, не связанных непосредственно с проектом. Я рассматриваю их как способ установления открытых и доверительных отношений между коллегами, без которых немыслимы эффективные коммуникации по производственным вопросам.
Кроме того, это способ отвлечься от зацикленности, от длительных и безуспешных попыток решить задачу, способ вытеснить проблему в подсознание. Все, кто занимался творческой деятельностью, понимают необходимость данной фазы в интеллектуальном процессе. В психологии это называют фазой инкубации проблемы.
Для успешного проекта характерно постоянное ощущение его участниками чувства удовлетворения и гордости за результаты своей работы, чувства оптимизма. Только наблюдая и анализируя общение участников проектной команды, можно получить информацию об их удовлетворенности состоянием дел. Нет ничего более гибельного для проекта, чем равнодушие или уныние его участников.
Призыв 15. Наблюдайте за коммуникациями в проекте. Постоянно поддерживайте необходимый уровень энтузиазма в проекте. Мотивируйте участников проекта на установление эффективного неформального общения.
Объективности ради отметим, что слишком интенсивные коммуникации могут свидетельствовать о проблемах в проекте. Например, о слишком большой связанности архитектурных компонентов, разрабатываемых разными людьми. Это так же может свидетельствовать о недостатках нормативной или проектной документации, в которых отсутствуют ответы на повседневные рабочие вопросы, и их приходится искать, отвлекая коллег. Хотя, в силу аутистической природы программистов избыток коммуникаций в проекте встречается достаточно редко.
