Распродажа складских остатков ключей Corel Выбирайте настоящее ПО Microsoft

 

 

 

 

 

 

 

Несколько месяцев назад я получил приглашение выступить в Хартфорде (Коннектикут) в отделении Международного института бизнес-аналитики (IIBA). Группа хотела услышать что-нибудь о лидерстве и о том, как члены группы могут повысить свое мастерство руководителя в своей организации. Мы обсудили несколько возможных вариантов и остановились на презентации о руководстве проектами гибкой разработки. Эта статья кратко описывает эту презентацию и рекомендации, которые я дал группе, включая десять личностных характеристик руководителя, которые, вероятно, наиболее применимы к группам гибкой разработки.

Я вовсе не собираюсь втиснуть суть лидерства в десять простых характеристик. Существуют книги и организации, подробно обсуждающие эти вопросы, включая Сеть руководителей проектов гибкой разработки (APLN).[1] Пока же давайте условимся о том, что лидерство - это нечто, что мы все понимаем, независимо от того, можем мы это формально определить или нет.

Контекст руководства гибкой разработкой

Возможно, в будущем, оглянувшись на развитие технологий разработки программ, мы назовем первое десятилетие 21-го века десятилетием гибкой разработки. За эти годы гибкая разработка прошла путь от немногочисленных консультантов, представляющих на конференциях открытые ими лучшие способы разработки программ, до уровня проведения конференций, полностью посвященных гибкой разработке. Гибкая разработка уже не является сферой интересов небольшой группы ярых сторонников; сейчас ею активно интересуются целые организации, занятых разработкой программного обеспечения, которые охватывают широкий спектр технических и программных областей. Мы до сих пор сталкиваемся с проблемой недопонимания гибкой разработки, но это всегда происходит при переходе новых течений из разряда новшества к всеобщему признанию.[2] Если вы знаете притчу о слепцах и слоне, то можете понять, сколь неуловимой может быть истинная суть самой гибкой разработки и руководства гибкой разработкой.[3]

Все, с кем я говорил, соглашаются с тем, что гибкая разработка программного обеспечения сегодня стала повсеместной. В той или иной форме гибкую разработку освоили как мелкие, так и крупные организации. Эта тема поднимается в самых разных журналах, от ACM"овского Communications до Crosstalk- журнала для проектировщиков программного обеспечения военного назначения. Переход к гибкой разработке стал синонимом улучшения способа разработки программных систем.

Точно так же как термин "гибкая разработка" может пониматься по-разному разными специалистами, так может пониматься по-разному и термин "руководство проектами гибкой разработки". Я рассматриваю его с позиции разработчика программ. Проблема не разрешится, если брать во внимание одно лишь лидерство, поэтому, обсуждая эффективные способы освоения роли руководителя проекта гибкой разработки, мы должны смириться с размытостью этого понятия.

Обычно во время презентаций (вроде той, что я недавно проводил для IIBA) я спрашиваю присутствующих, применяют ли они методы гибкой разработки. Число поднятых рук с каждым годом растет. Затем я спрашиваю тех, кто использует эти методы, как они понимают гибкую разработку. И я удивляюсь не столько разнообразию полученных ответов, сколько тому, что иногда довольно много ответов звучит одинаково. Часть проблемы кроется в злоупотреблении словом "гибкость". Я провел небольшое исследование фраз, относящихся к разработке программ и содержащих это слово. За 30 минут я составил список, который включал гибкую разработку, гибкое проектирование, гибкое моделирование, гибкое тестирование, гибкое управление проектами, гибкое планирование внедрения, гибкое принятие решений, гибкий Scrum, гибкие языки, гибкие базы данных, гибкое программирование, гибкую сборку, гибкую разработку игр, гибкое мышление, гибкое применение, гибкое ИТ… я бы еще добавил сюда "гибкую перегрузку". Очевидно, такое обилие понятий является нашей проблемой.

Поэтому, рассматривая лидерство, я хочу исследовать практические подходы и характеристики, которые наилучшим образом соответствуют характеристикам гибкости, описанным в Манифесте гибкой разработки.[4] Из четырех основных положений Манифеста наиболее прямо к последующей дискуссии относится следующее: цените людей и взаимоотношения выше, чем процессы и инструменты.

Существуют разные стили руководства, равно как и разные стили разработки программ. Краткое исследование термина "руководство" дало список следующих слов, описывающих стиль работы руководителя: бюрократизм, харизма, властность, демократия, невмешательство, ориентация на людей, ориентация на задачи, ориентация на операции, служение, ориентация на трансформацию и ориентация на окружающую среду. Вероятно, руководство, как и гибкость, имеет разное значение для разных людей, в зависимости от их взглядов. Как бы нам все это упорядочить?

Рисунок 1. Некоторые широко известные лидеры

Начну я с того, что назову некоторых известных лидеров в разных областях. Некоторые из них показаны на рисунке 1. Кое-кто из них вам наверняка знаком, например, Уинстон Черчилль, Джон Кеннеди и Адольф Гитлер. Другие лидеры, такие как Ли Якокка и Лу Герстнер, скорее всего известны лишь ограниченному кругу лиц.[5]

Затем мне на ум пришли лидеры в сфере технологий, то есть те, кто, по мнению разработчиков программного обеспечения, оказал сильное влияние на индустрию разработки ПО. Разработчики хотят понять этих людей, подражать им и следовать их идеям. Мой список лидеров в сфере технологий показан на рисунке 2.[6] Не все вошедшие в этот список связаны с программированием. Некоторые из них управляли крупными корпорациями и вполне могли бы появиться на рисунке 1. Я отнес их к лидерам в сфере технологий потому, что они сделали нечто, чем восхищаются разработчики.

Рисунок 2. Лидеры в сфере технологий

Теперь давайте взглянем на разницу между первой и второй группой. Эти отличия не безусловны и о них даже можно было бы поспорить за чашкой кофе, но я собираюсь предложить свою точку зрения.

Характеристики лидеров из первой группы (рисунок 1) представлены ниже. Эти лидеры:

• делают акцент на управлении и организации;
• высоко ценят структуру;
• в основном интересуются "общей картиной";
• ставят стратегию выше тактики;
• являются лидерами по должности. Многие из них были назначены на свои посты или избраны в ходе выборов;
• опираются на мобилизованных последователей. Поступая на работу или вступая в армию, вы соглашаетесь следовать за лидерами, предложенными вам организацией. Выбора у вас нет.

Характеристики второй группы лидеров (рисунок 2) можно описать так:

• основной ценностью они считают знания;
• инновации служат для них и целью, и средством для достижения цели;
• они являются лидерами в силу признания. Большинство членов этой группы достигли руководящих позиций, потому что люди видели в них лидеров и хотели за ними следовать;
• они опираются на добровольных последователей;
• каждый член группы является признанным экспертом в некоторой области.

Таких людей, как Билл Гейтс и Стив Джобс, можно легко отнести к обоим типам лидеров. Я поместил их во вторую группу в связи с местом, которое они занимают в умах программистов за их способность применять инновационное видение технологий к построению своих компаний. Они научились быть хорошими руководителями, но в первую очередь они - лидеры.

Лидерство по должности против лидерства по признанию

Успешные лидеры должны вдохновлять своих последователей. Успешный военачальник достигает этого, внушая войскам веру в то, что они сражаются за правую идею, и вселяя веру в победу. Это происходит в рамках лидерства по должности. Технологические лидеры вдохновляют последователей, заставляя их верить в то, что они могут стать лучше, приняв идеи и методы лидера. Думаю, эта разница является ключом к пониманию того, как стать хорошим технологическим лидером.

Генерал армии или генеральный директор корпорации часто имеют совершенно иной набор ценностей и ответственностей, чем солдаты или сотрудники компании, хотя все они заняты общим делом. Однако в сфере технологий основные ценности технического лидера и отдельного сотрудника более связаны между собой. Поэтому я уверен, что если вы хотите стать техническим лидером, вы, в первую очередь, должны быть техническим специалистом. И если вы хотите занять руководящую позицию в группе гибкой разработки, вам нужно согласовать свои ценности с ценностями группы, а не требовать от группы подравняться по вашим ценностям, которые могут не вполне им соответствовать. Рисунок 3 показывает, сколь различными могут быть основные ценности лидера и последователей, если это "лидер по должности", и насколько они могут быть схожими, если это "лидер по признанию".

Рисунок 3. Степень совпадения ценностей лидера и последователя.

Из этого мысленного упражнения мне совершенно очевидно одно:

Руководство фокусируется на распределении ресурсов, управлении средствами, передаче полномочий, оптимизации прибылей и т.п. Эти стороны деятельности критически важны для любой стремящейся к успеху организации.

Лидерство больше относится к отношениям с людьми, особенно это касается лидерства в сфере технологий! Технические лидеры связаны с теми, кем руководят. Некоторые выдающиеся лидеры справлялись и с лидерством, и с управлением, но в общем случае хорошие руководители и хорошие лидеры образуют две разные группы.

Личностные характеристики лидера и гибкость

В сентябрьском/октябрьском выпуске познавательного коммерческого журнала Bi_ZEd за 2005 год есть статья о личностных характеристиках лидера, написанная Патрицией Бизу (Tricia Bisoux).[7] Вообще таких списков довольно много, но эта статья содержит типичный набор характеристик, соответствующий нашему обсуждению. Ниже я исследую каждую из них и попытаюсь понять, какие из них наиболее применимы к работе с проектами гибкой разработки.

Самоанализ: хорошие лидеры хорошо знают самих себя. В частности, лидеры знают свое положение в организации или системе, а также свои сильные и слабые стороны. Лидеры регулярно размышляют о стиле своей жизни и своих ценностях. Эта характеристика хорошо применима к группам гибкой разработки, поскольку размышление является основным принципом гибкой разработки.[8] Руководитель проекта гибкой разработки ценит размышления и подталкивает членов группы к размышлению и самооценке с целью улучшения своих достоинств. В отличие от этого, если вы работаете с более определенным и основанным на плане процессом, такие размышления не играют критической роли. Когда организации, которые придерживаются подобного плана, ищут пути улучшения, им приходится строго планировать и сам процесс улучшения. Такие организации часто имеют специальную группу проектирования процессов или группу улучшения процессов, которой они и поручают эту задачу.

Не все руководители чувствуют себя комфортно, позволяя "пациентам править в дурдоме". В традиционных организациях каждый человек играет свою роль и не отклоняется от нее, что очень радует руководителей. Совершенно по-другому ведут себя лидеры групп гибкой разработки. Они без дискомфорта могут позволить группе самостоятельно определять способ выполнения работы. Эти лидеры довольны своим положением и могут оставаться собой и вести себя естественно при работе с группой.

Одно из следствий, вытекающих из самоанализа, заключается в умении определять, когда нужно проявлять лидерские качества, а когда - нет. Несколько лет назад на конференции пользователей IBM Rational выступала с пленарным докладом Сюзан Батчер (Susan Butcher), известная погонщица собачьих упряжек, многократный победитель гонок на Айдитароде. Она рассказала о ситуации, когда собаки отказались бежать по намеченному маршруту, так что она в конце концов уступила и позволила им выбрать свой путь. Путь, по которому она собиралась ехать, обрушился, и она скорее всего погибла бы вместе с собаками. Ее слова о выученном тогда уроке до сих пор звучат у меня в голове: "Иногда вы должны править сами, а иногда нужно отдать управление собакам". Несомненно, она должна была осознать саму себя, чтобы сделать это.

Если вы работаете с группой, достаточно ли комфортно вы себя ощущаете, позволяя руководить кому-то другому? Если нет, вам может быть сложно стать лидером группы гибкой разработки.

Личная убежденность: каждый лидер должен иметь личную убежденность. В этом смысле технические лидеры и лидеры проектов гибкой разработки ничем не отличаются от любых других лидеров. Лидер без личной убежденности - просто мошенник, и это сразу бросается в глаза. Сотрудники относятся к лидеру как дети к взрослым - они сразу замечают неискренность.

Личная убежденность не означает, что вы всегда правы. Прежде чем занять какую-то позицию, вы должны поверить в свою правоту, но в то же время вы должны быть достаточно уверены в себе, чтобы позволить другим убедить себя в существовании лучших способов выполнения работы. Если у вас нет личной убежденности и веры в то, что вы делаете (вместе со своей группой), то лучше уйти с дороги и позволить им идти вперед без вас.

Мужество: Cмужеством называется "духовная или моральная способность начать дело и упорно добиваться своей цели, преодолевая опасности, страх или трудности".⁹ Мужество не может существовать без личной убежденности. Лидер должен обладать личными убеждениями и быть достаточно уверенным в себе, чтобы подвергать их сомнению. Мужество является еще одним принципом гибкости, но часто неверно истолковывается.

Практики часто думают, что мужество означает способность ринуться вперед в соответствии с планом, невзирая на последствия. На самом деле мужество - это сила и способность найти правильный путь и следовать ему; в идеальном случае это решение возникает после того, как вы исследуете все альтернативы, осознаете последствия своих действий и убедитесь в том, что они приемлемы для организации, группы и других заинтересованных лиц. Такое знание зачастую вытекает из такта, интеллекта, опыта и здравой оценки в применении к ситуации. Выдающимся технические лидеры бывает свойственно выдающееся мужество.

В организациях, работающих по плану, целью является следование плану любой ценой. Самое худшее, что можно сделать, - это "испортить всю музыку", отступив от плана. Это ведет к ложной или по меньшей мере слишком оптимистичной оценке состояния проекта. Одна организация, в которой мне приходилось работать, должна была сдать продукт к определенной дате. Долгие месяцы руководители проводили еженедельные собрания, на которых каждый отчитывался о состоянии своей группы. Сообщения об отставании от графика ставили на руководителе "черную метку". Если вы сообщали об отставании, то считалось, что вы должны заставить свою группу работать сверхурочно и сделать все возможное для того, чтобы наверстать упущенное. Каждую неделю руководители докладывали, что все идет по плану. За неделю до сдачи один из них заявил, что его группа не успевает и ей нужно еще два месяца на завершение работы.

Что дальше? Ясно, что за неделю двухмесячную работу не сделать. У этой проблемы две стороны. Во-первых, руководителю не хватило мужества сказать правду. Во-вторых, ценности этой организации способствовали сокрытию плохих известий. Если вы собираетесь стать лидером проекта гибкой разработки, вы должны обладать мужеством, говорить правду и позволять говорить правду членам своей группы. Проще говоря, организация должна исповедовать ценности, обеспечивающие существование групп гибкой разработки.

Творческие способности: одной из моих самых любимых характеристик в этом списке являются творческие способности. Я к ним так неравнодушен, поскольку то, что мы часто считаем творческими способностями, не вполне точно передает их суть. Творчество - это не просто способность делать что-то новое и необычное. Это не изобретательность. Ключевым аспектом творчества является способность генерировать идеи, альтернативы и возможности. Творческий лидер помогает группе генерировать эти альтернативы и оценивать их значимость.

Творчество (от слова "творить") создает ценности. Нестандартное мышление - это прекрасно, но результаты такой деятельности должны создавать ценности для группы и организации. Простой поиск новых способов решения проблемы творчеством не назовешь. Творчество - это поиск новых способов решения проблемы, которые более продуктивны и полезны, чем все остальные. Самые творческие личности, с которыми мне приходилось работать, опирались на существующие базовые теории и технологии и находили способы их объединения для решения новых проблем или лучшего решения старых.

Вероятно, многие из вас знакомы с комиксами о Дилберте. Кто, по-вашему, самая творческая личность в этих комиксах? На мой взгляд - Уолли, не как лидер, конечно, а как чисто творческая личность. Он генерирует весьма изобретательные способы уклонения от работы, но Уолли не лидер, поскольку его творчество создает ценности лишь для него самого и не приносит пользу организации. Творческий лидер всегда сосредоточен на принесении пользы организации.

Творчество не является свойством исключительно гибкой разработки. Хорошие лидеры должны проявлять творческие способности в любых ситуациях.

Любопытство: возможно, любопытство, как гласит пословица, "убило кошку", но оно движет вперед технических лидеров. Хорошие группы разработчиков и те, кто ими руководит, буквально наполнены любопытством. Простой работающей реализации решения им недостаточно. Они создают замечательные программные системы, задавая вопросы, которые начинаются со слов "а что, если"? Им нужно знать, как это работает, почему это сделано именно так, а не иначе, и как это можно сделать лучше. И, лишь удовлетворив свое любопытство, они убеждаются в том, что сделали лучшее, что могли в данной ситуации.

Лидер не должен ограничивать любопытство. Истинный талант настоящего лидера заключается в том, чтобы направить любопытство группы так, чтобы она могла распознать момент, когда дальнейшие исследования перестают приносить пользу Хорошие разработчики стремятся создавать замечательные программы, но лишь самые лучшие умеют определить момент, когда продукт уже достаточно хорош. Группы, следующие принципам гибкой разработки, создают программы так, что могут точно сказать, когда продукт достаточно хорош для их клиентов.

Способность вдохновлять: живя в Массачусетсе, я имел возможность наблюдать, как выдающийся лидер вдохновляет группу. Билл Беличик, тренер футбольной команды "Нью-Ингленд Пэтриотс", раз за разом создает команды победителей. Беличика нельзя назвать известным тренером, но и он не ищет славы. Он напряженно трудится, создавая и реализуя планы игры и подготавливая команду к каждому матчу. Он вдохновляет свою команду своей репутацией тренера-победителя. Он обладает опытом и обширным послужным списком, на который может опереться. Он обладает сильным набором личных принципов и убеждений. Когда нужно, он проявляет сострадание и сочувствие к своим игрокам.

Все выдающиеся технические лидеры, как в гибкой разработке, так и в более традиционных областях, похожи на Билла Беличика. Отчасти они достигают лидирующего положения за счет своего прошлого успеха. За их плечами много побед, они имеют твердый набор ценностей. Мне приходилось работать с такими людьми, и именно их я вспоминаю с особой теплотой, когда размышляю о своей карьере. А "заводилы", произносящие зажигательные речи, не укрепляя своей лидерской позиции, быстро забываются.

Способность слушать: любой, что ведет за собой группу людей, должен уметь слушать. Сюзан Батчер прислушалась к упряжке собак, которой управляла, и это спасло жизнь и ей, и собакам. Способность слушать - это мастерство, которому можно научиться, но в первую очередь нужно хотеть слушать. И снова всплывает тема о том, что нужно быть самим собой. Если вы проявляете уважение к группе неискренне, слушая, но не слыша, у вас будут проблемы.

Позвольте объяснить, что я имею в виду под "слушать, но не слышать". "Слушать" - это когда кто-то обращается к вам с речью, и вы понимаете его слова, но это не значит, что вы согласны или собираетесь действовать в соответствии с этими словами, и вы можете не дать человеку ответа. Проще говоря, вы слышите слова, но не обращаете внимания на содержание. В отличие от этого, "слышать" -значит понимать собеседника и реально взаимодействовать с ним. Представьте, что некто предлагает способ изменения некоторого процесса. Если вы выслушали идею и вы хороший слушатель, вы должны высказать свое конструктивное мнение. Идея может оказаться настолько хорошей, что вы захотите, чтобы она получила развитие. Идея может требовать дополнительного осмысления. Если вы думаете, что идея плоха, нужно назвать причину и, возможно, предложить способы ее улучшения. Хорошие лидеры именно так и поступают (особенно в группах гибкой разработки). Они привлекают всю группу и помогают ей овладеть проектом.

Поскольку в группах гибкой разработки высоко ценится личное общение, нужно развить в себе способность слушать. Требование отчета о состоянии дел у человека, сидящего рядом с вами, не поднимет ваш авторитет в группе, особенно в группе гибкой разработки. Участники групп гибкой разработки отыскивают наилучшие способы взаимодействия и постоянно совершенствуются в этом мастерстве, опираясь на собственные умения и на проект, над которым идет работа.

Новаторство: новаторство порождает изменения, а группы гибкой разработки приветствуют изменениям. Фраза "приветствуем изменения" стала визитной карточкой групп, занимающихся экстремальным программированием. Такие группы приветствуют изменения требований, технологии и любых других аспектов проекта в любой точке его жизненного цикла. Если вы не приемлете новаторство, вы, скорее всего, не сможете адаптироваться к изменениям. Новаторство и творчество идут рука об руку, поддерживая друг друга. Хороший лидер вдохновляет группу на новаторство и творчество, фокусируясь на создании ценностей. Если вам нужна линейка для измерения успешности своих результатов, то лучшей вы не найдете. Инновационна ли ваша команда, творит ли она, создает ли ценности?

Новаторство буквально пронизывает группы гибкой разработки. Эффект слияния особенно ярко проявляется тогда, когда лидер обладает всеми или большинством из описанных здесь характеристик. Лидер не замыкает способности к новаторству в себе. Лидер проекта гибкой разработки вдохновляет на новаторство всех членов группы. Технический лидер гибкой разработки подобно талантливому руководителю достигает успеха за счет усилий всей группы, а не в результате отдельных героических поступков.

Стремление к приобретению опыта: противоположностью изменений является застой. Если вы не меняетесь, вы застаиваетесь. Если вы застоялись, вы отстаете. Продуктивно работающая группа постоянно меняет свои методы и стремится к новому знанию.

Опыт - это знания, а не просто трудовой стаж. Опыт лучше всего измерять переменами. Богатый опыт порождает открытость мышления и способность принимать разные точки зрения и культуры. В нашем университете мы стремимся к тому, чтобы студенты за время обучения хотя бы раз съездили за границу в один из наших проектных центров. Опыт, приобретаемый ими во время работы в таких странах, как Таиланд, Венгрия, Марокко или Намибия, воистину бесценен. Они возвращаются в университет совершенно другими, с новым взглядом на жизнь и обучение и на то, что они могут дать обществу.

Каждые несколько лет преподаватели берут академический отпуск для приобретения опыта. Этот опыт они могут получать в промышленности, в другом учебном заведении и вообще где угодно. Они возвращаются в родной институт оживленными, обновленными и подзаряженными. Я часто удивляюсь тому, что другие компании не предоставляют своим сотрудникам академические отпуска. Я уверен, что вложения окупятся сторицей.

Являясь лидером группы, какой опыт вы стремитесь приобрести? Позволяете ли вы своей группе приобрести опыт, который зажег бы в них эмоции? Если нет, может быть, вам пора пересмотреть свой стиль руководства?

Способность к размышлению: на самом деле это возвращает нас назад к самоанализу. Путь к самоанализу лежит через размышление. Все, что делаем мы и наша группа, образует цикл. Но этот цикл - не просто круг. Это спираль, и мы может подниматься по этой спирали вверх к новым лучшим достижениям, или спускаться вниз к поражению. Способность к размышлению является, пожалуй, самой важной характеристикой групп гибкой разработки и их лидеров.

Группы гибкой разработки регулярно размышляют о своей производительности и меняют методы работы. Они могут делать это в любой точке процесса. После каждой итерации группа гибкой разработки оценивает выполнение этой итерации и смотрит, нет ли проблем, требующих устранения. При необходимости они настраивают процесс и не ждут окончания проекта, чтобы произвести "разбор полетов".

Заключение

Перечисленные выше личностные характеристики не обязательно новы и относятся не только к лидерам проектов гибкой разработки. Однако если вы участвуете в проекте гибкой разработки, вам нужно оценить свой стиль и понять, что нужно изменить, чтобы стать лидером такого проекта. Главное, что нужно помнить: речь идет не о гибкости, а об успехе! Гибкость - всего лишь средство. Она не должна становиться целью.

 

Примечания

1. Советуем подробнее ознакомиться с APLN на сайте http://apln.org и в особенности с презентацией Гибкий танцующий слон, которую представила Сью Мак-Кинни (Sue McKinney), вице-президент по трансформации процессов разработки подразделения IBM Software Group.(http://apln.org/steve.ppt).
2. Оригинал статьи: Leadership in an (almost) Agile world.
3. Подробное описание понятия гибкой разработки можно найти в моей мартовской статье от 2007 года: http://www.ibm.com/developerworks/rational/library/mar07/pollice/index.html.
4. История вопроса описана здесь: http://www.wordinfo.info/words/index/info/view_unit/1/?letter=B&spage=3.
5. Познакомьтесь с Манифестом гибкой разработки http://www.agilemanifesto.org/.
6. Здесь также изображены генерал Джордж Паттон, Юлий Цезарь и вождь гуннов Аттила.
7. Изображены (по часовой стрелке, начиная с верхнего левого угла) Билл Гейтс, Гради Буч, Кент Бек, Стив Джобс, Мартин Фаулер, Джеймс Гослинг, Джон Бентли и Билл Джой.
8. Эту статью можно найти здесь: http://www.aacsb.edu/publications/Archives/SepOct05/p40-45.pdf.
9. См.: http://www.agilemanifesto.org/principles.html.
10. 9. Онлайновый словарь Merriam-Webster http://www.merriam-webster.com/.