Дж. Ханк Рейнвотер Как пасти котов
Скачать 4.43 Mb.
|
Умение обращаться с представителями разных пород Программисты – это в первую очередь люди. Поэтому в одном человеке могут быть в большей или меньшей степени выражены все перечисленные характеристики. Некоторые из них как будто исключают друг друга, но на самом деле это не так. Все люди сотканы из противоречий, и ваши подчиненные – не исключение. От вас как от человека, осуществляющего руководство этими чудесами природы, требуется понимание, умение мотивировать и, прежде всего, мудрость, которая нарабатывается только с опытом. Мнение о программистах нужно составлять по тем граням их характера, которые ярче других сверкают в свете новых начинаний и ослепляющих вспышек проектов, приближающихся к сдаче. Мнение о программистах нужно составлять по тем граням их характера, которые ярче других сверкают в свете новых начинаний и ослепляющих вспышек проектов, приближающихся к сдаче. Предположим, у вас есть счастливая возможность набрать сотрудников в свой отдел с «чистого листа». Какие породы сочетаются удачнее? По-моему, лучше всего соблюдать баланс между архитекторами и конструктивистами. Эти две породы привносят в процесс создания программных продуктов наиболее востребованные навыки – первые мыслят стратегически, вторые прекрасно ориентируются в деталях. К этому альянсу время от времени имеет смысл подключать художников. К сожалению, скорее всего, подобрать группу из идеальных кандидатов не удастся. Работать вам придется с тем, что есть. Потому успех вашего взаимодействия с людьми, сочетающими в себе вышеупомянутые характеристики, зависит от вашей проницательности, терпения и умения быть для подчиненных наставником – то есть от трех универсальных качеств руководителя. Есть еще один тип личности, на который следует обращать особое внимание. Я имею в виду программистов-ковбоев. Этот тип плохо согласуется с перечисленными породами, а описывать его лучше в соответствии с тем мнением, которое ковбой о себе формирует. Итак, программист-ковбой обычно в совершенстве владеет своим ремеслом, но при этом управлять им практически невозможно. Ковбои глубоко убеждены, что могут работать только над теми проектами, над которыми хотят, делать это на собственных условиях, согласуясь исключительно с собственными планами и обращаясь только к подходящим по их мнению средствам. Такой программист – своеобразный волк-одиночка (или, если придерживаться терминологии этой книги, – кот, который гуляет сам по себе). В зависимости от того, что вам нужно, и вашей готовности терпеть своеобразие их личности, ковбои могут творить либо чудеса, либо хлам. С ковбоями надо держать ухо востро: они ни при каких обстоятельствах не станут частью вашей команды. Прибегать к их услугам стоит либо в безвыходных ситуациях, либо если разрабатываемый проект должен радикально отличаться от всех других, а сопровождать его будут сторонние специалисты. Почему в программистах сочетаются все эти чрезвычайно занимательные личностные характеристики? Мне кажется, связано это с тем, что сам характер деятельности разработчика программного обеспечения привлекает людей совершенно определенного рода. В своем классическом труде «The Mythical Man-Mouth» Фредерик Брукс (Frederick Brooks)10утверждает, что наше ремесло приносит людям удовольствие пяти видов: 1. Радость созидания. 2. Радость созидания полезных для других людей продуктов. 3. Привлекательность процесса упорядочивания головоломных объектов, состоящих из взаимосвязанных динамичных элементов. 4. Радость от постоянного обретения новых знаний и решения нестандартных задач. 5. Интерес к работе с продуктами, созданными исключительно путем приложения интеллектуальных усилий человека, которые, тем не менее, существуют, развиваются и делают совершенно непередаваемые вещи. Все эти факторы кажутся тем людям, которыми вы руководите, чрезвычайно привлекательными. Разобравшись в их мотивации (да и в своей тоже), вы сможете серьезно усилить свои позиции как руководителя. Кошачьи разборки Соревнование по шипению и царапанию Проектное совещание превратилось в словесную схватку между Джоном и Кевином. Мы уже перешли к обсуждению регистрации пользователей в системе, а они все еще спорили насчет низкоуровневых подробностей методик конструирования. Дискуссия застопорилась – ведь, несмотря на отсутствие четкого плана обсуждения, все мы были уверены в том, что поговорить есть о чем. Джон и Кевин спорили без перерыва. Дело в том, что Джон (консультант) и Кевин (опытный сотрудник и талантливый программист) руководствовались совершенно разными мотивами и планами относительно этого совещания. Каждый из них считал своим долгом доказать другому, что он умнее, и вопросы проектирования системы их в тот момент не интересовали. А все потому, что Джона назначили руководителем проекта – он занял должность, на которую очень хотел попасть Кевин. Нашего начальника на совещании не было, и ни одного желающего выступить в роли посредника не нашлось. На следующий день в центре внимания опять оказались Джон и Кевин – они собачились за каждое проектное решение, и все остальные сотрудники отдела предпочитали помалкивать. К концу второго дня мы сумели согласовать значительно меньше вопросов, чем планировались, а то, что нам удалось, оказалось результатом ожесточенной бойни между двумя воинственными котами – Джоном и Кевином. Остальная часть группы чувствовала себя совершенно дезориентированной. Люди начали сомневаться, удастся ли вообще закончить работу над системой. Значительно осложняло ситуацию то обстоятельство, что перед группой поставили задачу сделать систему как можно быстрее, ибо та ее версия, которая в тот момент находилась на рынке, негативно сказывалась на репутации компании. Этой короткой историей я хотел обозначить трудности, связанные с введением в одну команду консультантов и программистов. Особенно их отношения осложняются в отсутствие начальника. Вы могли бы справедливо поставить под сомнение разумность выбора в качестве руководителя проекта консультанта. Кроме того, как видите, за неимением четкого плана и механизма разрешения противоречий на проектном совещании сотрудники просто убивают время, подрывая тем самым принцип «сначала проектирование – потом кодирование». Развитие межличностных отношений в группе разработчиков подтверждает мою мысль о необходимости психологического анализа подчиненных для повышения качества руководства. Конец этой истории довольно печален. Проект закрыли, а проектирование и конструирование продукта поручили группе разработчиков из другого отдела. Пропустившему основные «военные действия» руководителю отдела по возвращении пришлось в течение нескольких дней с большими трудностями объяснять начальству, почему после всех обещаний и заверений, предшествовавших началу работу над проектом, разработчики так и не сдвинулись с мертвой точки. Слава, почет и деньги Любой сотрудник жаждет признания своей деятельности, хочет ощущать весомость своего вклада в общее дело. Быть оцененными по достоинству стремятся и некомпетентные сотрудники – даже несмотря на то, что их вклад в деятельность компании исключительно негативный. Все мы любим поразглагольствовать насчет того, что создание кода для нас – это уже своего рода награда. Но хотелось бы мне знать, сколько мы проработаем, если нам не будут за это платить. Но даже если будут платить, и платить хорошо, мы в любом случае будем требовать признания со стороны наших товарищей и надеяться, что начальник между делом похлопает нас по плечу. Настоящие кошки предпочитают спокойно дремать в углу, не заботясь о том, кто и как на них смотрит; кошки-программисты в этом отношении, напротив, проявляют некоторый эксгибиционизм. Ярким подтверждением того, что и программистам нужно признание, служит практика встраивания в код своеобразных «пасхальных яиц» (хотя сегодня она считается несколько вульгарной). Вас, начальника, они воспринимают как зрителя, сидящего в переднем ряду, и, конечно же, ожидают аплодисментов. Причем ожидают все – даже те, над которыми впору начинать читать молитву11. Расхваливать своих сотрудников – это, конечно, замечательно, но иной раз стоит на секунду остановиться и поразмыслить, отрабатывают ли они те деньги, которые получают. Ведь это входит в вашу задачу как руководителя. Если хотите похвалить человека, сделайте это на виду у всех. Если считаете нужным покритиковать его, не выносите свои оценки на суд публики. Дело не просто в вежливости – эти правила поведения важны в том смысле, что как похвала, так и порицание одного человека на самом деле оказывают грандиозное влияние на всю группу. Поверьте мне, публичное унижение не способствует повышению продуктивности работы группы. Напротив, похвала, высказанная при всех, причем искренне и по заслугам, способна творить чудеса. Не надо кричать о том, что ребята прекрасно поработали, выходя из комнаты для совещаний. Выберите такое время, когда слова благодарности окажут наибольшее воздействие. Четко определитесь с тем, за что вы хвалите человека, и обязательно сделайте так, чтобы сотрудники группы это знали. Расхваливать своих сотрудников – это, конечно, замечательно, но иной раз стоит на секунду остановиться и поразмыслить, отрабатывают ли они те деньги, которые получают. И еще немного о поощрении. Кто знает – может быть, у вас у самого такой начальник, который никогда вам слова доброго не скажет. Тогда и вам будет не до комплиментов подчиненным. Роль лидера предполагает стремление к успеху подчиненной вам группы. Когда группа добивается успеха, вы ее хвалите. Кто же хвалит вас? Иногда никто, хотя время от времени вы сами хотите получить от начальника хлопок по плечу. Роль руководителя, которая предусматривает приложение некоторых усилий для улучшения репутации подчиненных, превратится в сущий ад, стоит вам попытаться искать почестей для самого себя. Не стоит забывать, что любой руководитель должен оценивать свои успехи исключительно по тому, насколько эффективно работают его подчиненные. Если вы выдвинулись в руководители из программистов, задача усложняется, поскольку теперь вам придется принять ответственность за профессиональную судьбу ваших друзей. Но не позволяйте дружбе мешать делам. Лучше используйте ее как средство достижения общей цели. Я вас уверяю, что если вы, в конечном итоге, все вместе добьетесь успеха, ни один из ваших подчиненных не осмелится утверждать, что вы манипулируете дружескими отношениями. Мотивирование деньгами Кажется, я уже поднимал денежный вопрос? Лучше было бы его как-то обойти, поскольку, как сказано в Библии, «…ответом всему – монеты»12. Согласно последнему статистическому исследованию, почасовая ставка программистов составляет от 30 до 150 долларов, причем большинство из них находится где-то посередине этого спектра. Как определить, стоит ли платить вашим сотрудникам именно столько, сколько вы им платите? Среди факторов, которые нужно учесть, – производительность, опыт, результативность, своевременность исполнения задач, текущая средняя ставка, экономическая конъюнктура и корпоративные стандарты, касающиеся оплаты труда сотрудников в области высоких технологий. Подбирая новых сотрудников и повышая оплату старым, вы должны быть справедливым и бережливым одновременно. Справедливым и бережливым. Хм, это довольно трудно – можно поддаться соблазну разбрасываться деньгами, как будто они растут на деревьях, опрометчиво полагая, что оплата повышает производительность. На самом деле здесь стоит хорошенько подумать, ведь сегодняшняя роскошь есть завтрашняя потребность. Деньги, подобно власти, оказывают на человека самое что ни на есть деструктивное влияние. И не заставляйте меня цитировать еще одно известное высказывание из Нового Завета13. Так все-таки, возвращаясь к теме, как соблюсти баланс в вопросах денежных выплат? Представим себе весы правосудия. На одну чашу положим справедливость, на другую – бережливость. Вес чаши справедливости равен опыту и производительности программиста. Вес чаши бережливости состоит из стандартных коммерческих хитростей, таких как соблюдение баланса доходов и расходов и статистика средней заработной платы программиста. Принимая решение о денежных выплатах, имейте в виду эту аллегорию – она очень действенна. Но ведь это все теория. А что на практике? Именно из-за несоответствия теории и практики денежный вопрос в деятельности руководителя становится одним из самых сложных. Вам известны принципы, следуя которым вы теоретически должны принимать решения относительно вознаграждения персонала. С другой стороны, существенные коррективы в планирование вносят экономические аспекты – в частности, текущая коммерческая конъюнктура и корпоративная политика. В некоторых компаниях, помимо оклада, сотрудники получают бонусы, которые выписываются в соответствии с личными заслугами каждого. Этот стимул действует лишь тогда, когда сотрудники оказываются в состоянии выполнять то, за что они теоретически заслуживают дополнительного вознаграждения. В принципе, можно ввести практику выплаты ежеквартальных бонусов, но, по моему опыту, это не самый лучший выход – однажды начав их выплачивать, вы обязательно столкнетесь с тем, что сотрудники будут на них надеяться. Касательно денежного вопроса вам лучше проконсультироваться со своим начальником – скорее всего, вместе вы сможете разработать оптимальный для своей команды план. Если решения о вознаграждении принимаете только вы, действуйте так, как считаете нужным, и не забывайте правило справедливости и бережливости. Уровень мышления14 Ну что, вам интересно? Вы заинтригованы тем, что будет дальше? Думаю, что нет. Скорее всего, вы пребываете в полной уверенности, что дальше я разражусь мириадами советов о том, каких действий лучше избегать, а на каких делать упор, и все эти сведения будут представлены в виде маркированных списков. Действительно, в последующих главах таких списков будет немало, но в данный момент я хочу обратить внимание на то, как важно в вашей новой роли думать. Поэтому с перечислением рекомендуемых и не рекомендуемых приемов руководства пока что повременим. Возможно, необходимость думать – это самая сложная обязанность менеджера. Тем не менее это абсолютно необходимое условие нашего успеха. Как пишет в книге «Dynamics of Software Development» Джим Маккарти (Jim McCarthy): «Основная задача руководителей процесса разработки программных средств состоит в том, чтобы аккумулировать как можно больше интеллектуальных ресурсов и направить их на создание конечного продукта»15. Стоя в душе – думайте. Катаясь на велосипеде, прогуливаясь по парку, выделывая невообразимые трюки на роликах – думайте. Сталкиваясь с дилеммами, которые обусловлены принятыми проектными решениями, – думайте. Думать значительно полезнее, чем смотреть телевизор или бесцельно бродить по Сети, – пусть даже там 500 каналов, но на самом деле на них ничего не происходит, и то, что они как будто избавляют человека от необходимости мыслить, совершенно не здорово. Думайте напряженно, до изнеможения, а когда не останется сил – начинайте заново. Результат вас удивит. Ну а теперь подумаем о том, как справляться с некоторыми типичными ситуациями. Предположим, в вашем подчинении кот породы минималист, но при этом весьма профессиональный. Вы хотите поручить ему модернизацию продукта, который писал кто-то другой, но доработать который в контексте текущих коммерческих задач совершенно необходимо. Взглянув мельком на код, который вы собираетесь вменить ему в обязанность, он говорит: «Нет, это слишком сложно – код нужно переписать». Естественно, речь идет о коде, который писался два года и который уже сейчас приносит компании неплохие деньги. Ситуация осложняется тем, что человек, который этот код написал, у вас больше не работает и поэтому физически не может помочь новому сотруднику в нем разобраться. Итак, у вас два выхода. Первый: пасть под давлением минималиста, сделав его самым счастливым человеком, но загубив последний шанс сдать проект в срок. Второй: направить его на путь изучения существующей архитектуры и дать ему впоследствии возможность внести в нее весомый вклад. Поиграйте с его пристрастием к четкой архитектуре – попросите документировать существующий код с тем, чтобы в будущем, если позволит время, он смог бы переписать некоторые объекты, сделать их более удобными. Если он профессионал, не сомневайтесь – он обязательно разберется в том, что написал его предшественник. Не стесняйтесь использовать в своих целях дух соревновательности. С точки зрения минималиста все, что написал не он, – полная туфта. На самом деле вполне возможно, что он боится, будто не сможет разобраться в существующем коде, и просто не хочет в этом признаться. Всегда ищите скрытые мотивы, которыми руководствуются все без исключения представители рода человеческого. Поймите: программисты, не готовые признать, что их компетенции не хватит для решения поставленной задачи, очень любят выискивать своему бездействию высокоинтеллектуальные оправдания. Как поступить с архитектором, который уверен, что созданные им объектные решения превосходят все созданное ранее, а вы, тем не менее, усматриваете в них некие слабые стороны? Не надо ему ничего говорить про врожденные недостатки решений – ничего не добьетесь, зато наживете себе врага. Лучше попросите его объяснить предполагаемый механизм функционирования всех динамичных элементов и построить несколько прототипов, или тестовых программ, которые смогли бы наглядно продемонстрировать действие заложенных в решении функций. Если он создаст эти прототипы и никаких проблем не возникнет, значит, возможно, вы были неправы, и изъянов в найденном решении нет. Если архитектура кажется вам слишком громоздкой и монолитной, попросите разбить ее на компоненты. Если окажется, что они прекрасно друг с другом работают, значит, архитектор вполне адекватно представляет себе, что он хочет. Если объекты излишне взаимосвязаны и взаимозависимы, это свидетельствует о пристрастии архитектора к усложнению, которое способно существенно удорожить сопровождение продукта. Что отличает высокопрофессионального архитектора? То, что он способен создать конструкцию, которую сможет обслуживать и расширять любой его последователь. Такая конструкция не рассыплется при первой же модернизации кода. На код при работе с архитектором нужно смотреть его глазами – даже если он слеп на один глаз и не видит другим. Есть твердое правило: прежде чем пытаться утвердить то или иное решение, используя свое положение руководителя, обязательно выслушайте человека и попробуйте его понять. Какие еще рекомендации я мог бы дать по поводу такого рода ситуаций межличностного общения? Есть твердое правило: прежде чем пытаться утвердить то или иное решение, используя свое положение руководителя, обязательно выслушайте человека и попробуйте его понять. В том, что касается конфронтации, программисты ничем не отличаются от остальных людей – они хотят, чтобы их выслушали. Как пишет в своей книге «The 7 Habits of Highly Effective People» Стивен Кави (Stephen Covey), «сначала старайтесь понять… и только после этого – быть понятым». Поиск консенсуса при принятии технических решений есть не что иное, как вид искусства, основывающийся на готовности выслушивать чужие идеи. Для того чтобы выстроить такую основу для взаимодействия с сотрудниками, требуется терпение, и проявлять его необходимо – хотя иногда нам кажется, что времени нет даже на конструирование, а насчет методов все вроде бы согласны. Вы можете так считать, но это не отменяет постановку задачи по достижению консенсуса16. О том, как достичь консенсуса, мы еще поговорим в главе 5, которая посвящена проведению проектных совещаний. Возможно, вы удивитесь, когда узнаете, что консенсус нельзя строить на основе компромисса. И еще один пример, иллюстрирующий принцип «услышь, прежде чем судить». Некоторые языки программирования – и, в частности, Visual Basic (VB) – не предусматривают полноценных конструкторов объектов. Недавно я столкнулся с тем, как один художник с помощью события инициализации класса VB пытался организовать обращения к набору объекта со стороны (родительского) класса-потребителя17. Если объект VB не удается конкретизировать, перехватить ошибку становится очень трудно. Когда я спросил этого деятеля, почему для обработки подверженной ошибкам операции он выбрал упомянутое событие, в ответ он сообщил, что его решение изящно, понятно и не требует от вызывающего объекта подготовки обращения к интерфейсу. Я, естественно, посчитал, что надежная обработка ошибок значительно важнее любых попыток вылизать текст. Но промолчал. Ознакомившись с его аргументацией, я объяснил ему, с какими трудностями может столкнуться такой объект, и подкрепил свои соображения наглядным примером в коде. Если бы я сразу сказал что-нибудь вроде «это не есть правильно – разберись!», то не смог бы образумить его своим примером, и он так бы не понял, чего от него хотят. Повторюсь: если дать человеку возможность высказать его точку зрения, он в ответ проявит понимание к вашей позиции. |
Похожие:
 | Деятельности и смежных отраслях (Вопросы правоприменения в области оценочной деятельности) 52 Котов А. Г. Ширина окна усреднения как инструмент повышения качества оценки | | Реферат Творчество народного художника России Володе приходилось вначале помогать старшим пасти свиней, потом заниматься этим самостоятельно. Нелегко было с учебой в школе.... |
 | В. М. Котов, С. П. Круковский, М. Ю. Попович, А. М. Сахаров, А. А. Ярош, В. Н. Ярош Цель: создание творческой и психолого-педагогической среды для развития инновационного педагога, осуществляющего деятельность по... | | Лекция 31 Основные направления развития региональной экономики как... Информация о выполнении плана первоочередных действий по реализации национальной образовательной инициативы «Наша новая школа» в... |
| Программа по формированию навыков безопасного поведения на дорогах... Полину Сергеевну Пряхину как учителя, много лет проработавшего в школе, как классного руководителя, как нашу односельчанку, как маму... | | Программа по формированию навыков безопасного поведения на дорогах... Аудирование как врд и как умение (общая характеристика данного врд). Аудирование как цель и как средство обучения |
| Решение кафедры ... | | Программа по формированию навыков безопасного поведения на дорогах... Самое главное – урок рассматривается сегодня не только как деятельность учителя, т е как форма обучения, но и как деятельность ученика,... |
| Состав предприятия как имущественного комплекса А предприятие как субъект права в свою очередь не может выступать предметом купли-продажи. Отсюда использование словосочетания продажа... | | Как сделать современным и интересным урок русского языка? Как привлечь к чтению современного школьника, равнодушного к переживаниям Татьяны Лариной, Наташи Ростовой, Пьера Безухова? Как приблизить... |
| Уроках иностранного языка в средней школе. Вопросы для самостоятельной подготовки Говорение как врд и как умение (общая характеристика данного врд, сравнительная характеристика монологической и диалогической речи,... | | Образ великого Пушкина в творчестве поэтов Х1х-хх веков Онегине", для кого-то – тема долга и чести, как в "Выстреле", ревности, как в "Цыганах", исторической правды, как в "Борисе Годунове",... |
| Руководство Мирного Воина в повседневной жизни Даже если человек подметает улицы, он должен делать это так, как рисовал Микеланджело, как сочинял Бетховен, как писал Шекспир | | В. Н. Садовников Ницше уверен, что "высшее воспитание" и множество противоречат друг другу. Высшее воспитание подобает лишь исключениям и это не что... |
| Программа по формированию навыков безопасного поведения на дорогах... Вот, я посылаю вас, как овец среди волков: итак будьте мудры, как змии, и просты, как голуби | | Тема Культура речи как образовательная Значение языка в жизни общества. Понятие лингвистической экологии. Речевая культура как показатель общей культуры личности. Язык... |
