Клуб Успешных Менеджеров Программистов
-
Культуры программных проектов: глава 8
Posted on March 17th, 2010 1 commentКультуры программных проектов
Автор: Энтони Лаудер
Перевод: Альберт Мустафин
Глава 8: Изменение Корпоративной Культуры
Тяжёлые Изменения
Компании могут изменить свою культуру. Я видел, как это происходило. Но, несмотря на заявления некоторых, не так легко изменить корпоративную культуру. Это означает изменение доминирующей метафоры компании, а это означает изменение не только поведения; это ещё и изменение взглядов и даже ценностей. Для этого организация должна хотеть, быть готова и способна подвергнуться существенным преобразованиям. Это требует серьёзной решимости и часто влечёт долгое и болезненное привыкание.Многие компание просто не готовы или не хотят или неспособны пережить всё то, что подразумевает под собой изменение культуры. Многие говорят, что хотят изменить культуру, но на поверку оказывается, что они хотят результатов без усилий. Им хочется побыстречку сделать лишь кое-что. В лучшем случае, они добиваются небольших местных результатов, но это часто происходит против основной линии компании, а потому результаты почти всегда разочаровывают. А со временем они возвращаются туда, откуда начали.
Мне позвонил исполнительный директор одного очень известного доткома. Назовём его Питер. Он был в городе и хотел позвать меня на обед. За мексиканским стейком с красным вином Питер сказал мне, что он нервничает. «Энтони, наш главный конкурент захватил весь наш бизнес за последние два года. Мы теперь лишь пытаемся угнаться, а не лидируем. Чем больше мы стараемся, тем больше отстаём. Что они делают такого, что мы не делаем?»
Я хорошо знал конкурента. Я провёт некоторое время, исследуя их способ работы, а потому мог ответить Питеру сразу: «Они используют метолику Lean», - начал я, и стал объяснять более подробно. Питер остановил меня через минуту: «Замечательно. Мы тоже хотим этим заняться. Мы хотим быть быстрее всех и исключить растраты. Но мы не можем делать это так, как ты описываешь. Мы должны сохранить все хорошие практики, которые мы уже используем.»
Через несколько дней он связал меня с Дэйвом, своим коллегой. «Мы сделаем это!» воскликнул Дэйв, «Но нужно быть практичными. Мы не можем подорвать дисциплину. Мы не будем делать ‘официальный Lean’. Вместо этого мы будем более агрессивными по отношению к крайним срокам.»
До меня дошло, что Питер и Дэйв боятся изменений. Я же больше боялся, что они вообще не собираются ничего менять. Всё-таки конкурент выбивал из них дух. Инстинктивный страх Питера и Дэйва почти наверняка проистекал из их глубоко укоренившейся метафоры конвейерной линии. Они свято верили в определённый процесс со строгим контролем со стороны руководства, который они считали абсолютно правильным. А ослабление дисциплины рассматривалось как начало хаоса, опасного для компании. Прежде чем начинать изменения, Питеру и Дэйву нужно было самим поверить в них, а это означало бв принятие того факта, что изменения будут сложными, болезненными и, да, пугающими.
Я часто объясняю клиентам, что культура, подкреплённая нежеланием пройти через болезненные изменения, как резинка. Вы можете растягивать её, пока она не порвётся от натяжения, или вы можете сдаться, отпустить её и смотреть, как она возвращается к первоначальной форме.
Дёрганья просто не дадут тех результатов, которые нужны компаниям. Изменение корпоративной культуры с одной метафоры на другую - это огромное преобразование. Как любое большое изменение, оно не произойдёт случайно и не будет лёгким. Для этого необходимо спланированное усилие. Пока я видел успех лишь там, где присутствовало желание людей в организации - от верхов до низов - изменить культуру во что бы то ни стало.
-
Культуры программных проектов: глава 6
Posted on March 3rd, 2010 1 commentКультуры программных проектов
Автор: Энтони Лаудер
Перевод: Альберт Мустафин
Глава 6: Менеджеры - это…
Авторитет Руководства
Мы уже видели, что у проектов больше шансов на успех, если команда объединена вокруг культуры, основанной на общих метафорах. Эти метафоры подсказывают как вести себя в штатных ситуациях и как заполнять пробелы правил при незнакомых обстоятельствах. И даже если команда сплотилась вокруг общих взглядов, руководство может захотеть их изменить.Менеджер - это некто, имеющий власть над командой. Менеджер может использовать эту власть, чтобы навязать свои собственные взгляды, которым команда инстинктивно сопротивляется. Вместе со своими взглядами менеджер одновременно навязывает и метафоры, породившие эти взгляды, а также соответствующую культуру. В результате происходит столкновение культур, приводящее к беспокойству команды и сильному её желанию обойти требования менеджера и продолжать следовать своим собственным метафорам, чтобы уменьшить беспокойство и увеличить шансы на успех проекта. С другой стороны, менеджер скорее всего будет рассматривать такое поведение как угрозу проекту и подрыв его авторитета. Менеджер тоже начнёт беспокоиться и давить на команду.
Моя команда была нанята бывшим бухгалтером, ставшим теперь старшим менеджером. Нам было поручено сесть с экспертами отдела кадров, чтобы понять их бизнес модель и написать новое программное обеспечение, поддерживающее её.
Через три месяца мы делали презентацию прогресса, и нас спросили “Когда уже будет готово?” Один из членов команды ответил “От вас зависит, когда вы решите, что приложение достаточно хорошо, чтобы отдать заказчику. А тем временем мы будем продолжать его улучшение сколько угодно долго.” Работа продолжалась месяц за месяцем. Команда выпускала новые версии приложения, но менеджер не хотел отдавать его заказчику, пока оно не будет совсем “готово”.
-
Культуры программных проектов: глава 5
Posted on February 24th, 2010 1 comment
Глава 5: Команды - это…Что Такое Команда?
До сих пор мы говорили о взглядах, ценностях и метафорах. Мы видели, что можно убедить кого-то изменить их взгляды, но ценности и метафоры сидят куда глубже, на эмоциональном уровне. Всё это имеет значение, поскольку касается не только людей, но и отношений между ними, выполняемой работы и того, как они измеряют свой и чужой успех. То есть, ценности, взгляды и метафоры являются сердцем команд и командной работы.
Разумеется, все говорят о пользе команд и командной работы. Мы постоянно слышим, что командная работа - это хорошо. А потому, неудивительно, что компании рекламируют и афишируют её для “командных игроков”. Всё было бы хорошо, если бы это означало, что компании нанимают и развивают людей, хорошо работаюших вместе. Но из своего опыта могу сказать, что “командные игроки” - это эвфемизм для людей, которые будут выполнять приказы, спускаемые им сверху боссом. В этом случае фраза “командные игроки” означает послушание и не имеет ничего общего с командами и командной работой.
Разумеется, можно собрать группу людей и попросит их работать как одна команда, но эти люди не будут работать как команда, до тех пор пока они не станут командой. А для этого им нужно объединиться, сработаться и расцвести.
Как Команды Объединяются?
Команда начинается с немногим большего, чем несколько человек, озабоченных их собственными интересами. Чтобы объединиться как команда, должно присутствовать взаимное понимание и уважение того факта, что эти люди теперь заодно.
Как я мог убедиться, никто не может навязать это чувство единения команде, члены команды должны сами увидеть это друг в друге, а для этого им нужна возможность узнать друг друга и найти что-то общее, что поможет им отличать себя от окружающих. Если члены команды разделены и не имеют возможности развить чувство взаимной принадлежности, у них никогда не будет единства, и команда никогда не станет одним целым. Также я видел, что намеренный роспуск команд в конце проекта и возвращение их членов в “запас” разрушает любое единение команды, которое могло начать формироваться.
Один мой коллега Нил Крейвен сидел в большом офисе открытого типа, окружённый людьми, с которыми он никогда не работал. Такой тип офиса позволял экономить на аренде и иметь всех сотрудников на виду. Это никак не было связано с командами. Компания ратовала за “виртуальные команды”, в которых временные группы людей назначались на проекты на основании почти случайной их доступности из огромного географически разделённого списка сотрудников компании.
Компания проталкивала идеи выгод командной работы, но, как сказал Нил, люди были изолированы и одиноки. Очень часто члены команд никогда друг друга не видели в лицо и никогда не работали вместе по окончании проекта. Не было ощущения принадлежности и ничего, что бы объединяло команду, кроме кратковременного назначения на проект, которым управлял обычный менеджер проектов.
Как Срабатываются Команды?
Как только у команды появляется ощущение взаимного единения, им нужно научиться работать вместе как команда. Благонамеренные усилия руководства часто терпят неудачу в попытке симулировать это. Типичные тим-билдинги привносят некую радость в коллектив, но редко имеют длительный эффект. Мотивационные постеры обычно рассматриваются как банальные декорации.
Команда образуется не под внешним воздействием, а лишь когда команда строит себя сама. Команда может сплотиться вокруг общих интересов, которыми могут быть правила, по которым договорились работать члены команды. Конечно же, поначалу может наблюдаться борьба конфликтующих взглядов, пока один из них не возьмёт верх. Основатель команды, или доминируюший член команды, может даже навязать свои собственные взгляды в команде, особенно если у него есть авторитет, но позже эти взгляды подвергнутся тесту.
В детстве я играл в ковбоев и индейцев с другими мальчишками, жившими по соседству. Мы разыгрывали великие битвы, о которых читали в приключенческих книгах. У одного мальчика, Генерала Кастера, было много игрушечных пистолетов, и он давал их другим поиграться.
В Битве Маленького Большого Рога Генерал Кастер отказался умирать. Он заявил, что одет в волшебные доспехи, отражающие пули. Когда остальные дети запротестовали, Генерал Кастер забрал все свои пистолеты и отправился домой, тем самым закончив игру.
Генерал Кастер играл по правилам, отличным от правил других мальчиков. Это не давало нам воспроизводить битвы подобающим образом. Вскоре нам это надоело и мы договорились сделать свои собственные пистолеты из палок и резинок. Генералу Кастеру пришлось играть по нашим правилам или не играть вообще.
Когда команда выработала общие взгляды, она может начинать работать над связями, помогающими команде сплотиться. Я видел несколько команд без общих взглядов, в которых почти отсутствовала связь между членами команды. Это не давало им объединиться, а потому командам не хватало внутренней силы, чтобы прожить достаточно долго.
У одной крупной компании, производящей финансовое программное обеспечение, было несколько команд в разных странах. Руководство беспокоила изолированность команд, они хотели, чтобы лидеры команд встречались раз в месяц для обмена опытом. Поскольку я был лидером одной из таких команд, мена пригласили на эти встречи.
Первая встреча была интересной - все слетелись из разных уголков мира и представляли свои проекты другим. Мы узнали, что проекты сильно различаются. Каждый проект требовал совершенно уникального набора взглядов на то, как измерять успех. Один проект считал за успех захват доли развивающегося рынка. Другой - продление высоко оплачиваемого контракта на оказание консультационных услуг одному клиенту на довольно длительный срок. Третий - поставка нового продукта, финансируемого сразу несколькими банками.
Ко второй встрече стало понятно, что хоть мы все и работали в одной компании, у нас было мало общего, что позволило бы нам иметь одинаковые взгляды.
Третьей встречи не было. Мы все вернулись к своим проектам и редко когда-либо ещё виделись.
Сработаться очень важно, так как это заставляет людей заботиться не только о своём будущем, но и о будущем команды. Когда сработавшаяся команда обнаруживает угрозу, члены команды приходят в состояние повышенной готовности. И, чтобы выйти из этого состояния, они делают всё возможное для выживания команды.
Если же угроза исходит изнутри самой команды, то я видел случаи избавления от членов команды, угрожавших сработанности коллектива.
Я как-то возглавлял команду, разрабатывавшую систему упрабления базами данных, в ОбъектВаре. Одой из объединяющих команду ценностей было предположение, что если относиться к людям с доверием, то они оправдают его добросовестным трудом. У Майкла (одного из сотрудников), очевидно, были другие ценности, включая веру в то, что ошибки приемлемы, если последствия незначительны. Это создавало некоторые конфликты в команде, но Майкл отмахивался от критики, как от слишком эмоциональной реакции других людей.
Однажды, Майкл пропустил важную встречу, что оставило довольно неприятное впечатление о всей команде. Я нашёл Майкла дома, но он предъявил какое-то обобщённое оправдание, где умудрился обвинить двух других членов команды. Быстрая проверка выявила невиновность тех двух. Команда обсудила этот случай и проголосовала за то, чтобы исключить Майкла из команды. Его ценности были разрушительны для команды, а его поведение подрывало те устои, вокруг которых сработался коллектив. Майкл был исключён из команды, а потом и уволен из компании.
Итак, в сработавшемся коллективе трения возникают очень редко, а работа идёт гладко. Однако, введите в коллектив кого-то, кто не принимает ваших ценностей, и получите кота в стае голубей.
У одного из моих клиентов была команда, которая годами успешно работала. Однако, руководство беспокоилось, что команда увязнет в старых привычках, а потому решило сделать вливание. Они наняли Жака, чьё резюме было исключительно впечатляющим. У Жака было много классных идей, которые обещали встряхнуть ситуацию и научить команду работать по-новому.
Но его встряска оказалась больше похожей на землетрясение. Жак принёс с собой менталитет жёсткого командования и контроля, что шло вразрез со взглядами команды, которая в основном полагалась на сотрудничество и консенсус.
Жак не мог понять, почему команда такая недисциплинированная, и сильно расстраивался от того, что они постоянно съезжали с колеи. Чем больше команда сопротивлялась, тем сильнее Жак пытался контролировать их. Команда не понимала, почему Жак такой тиран, и почему он пытается навязать им то, что уводило их от нормальной совместной работы.
Столкновение взглядов проявилось на результатах: проекты замедлились, мотивация упала, никто не был счастлив. Жак обвинял в этом команду, а команда обвиняла его.
Со временем, команда просто отказалась работать с Жаком. Жака уволили, и проекты стали улучшаться.
С другой стороны, я видел, как команда защищала себя так, что даже целиком покинула организацию!
Компания по разработке приложений, с которой я сотрудничал, взращивала высоко эффективную команду программистов, чья продукция помогала процветанию компании. Тем не менее, после нескольких успешных лет, пара дорогих ошибок отдела продаж привела компанию к финансовому кризису. Страх сокращений повис в воздухе. Некоторые из программистов стали искать работу в других компаниях, что стало угрожать целостности команды. Я был шокирован тем, что произошло: члены команды собрались для обсуждения кризисной ситуации, после чего все вместе уволились. Целая команда перешла работать в другую команду. Им пришлось это сделать для выживания команды.
Как Команда Расцветает?
Как только команда сплотилась, благодаря общности взглядов, и сработалась как коллектив, ей нужно пережить несколько успехов в своей среде, что бы расцвести в полном объёме. Это означает защиту себя от внешних угроз.
Довольно очевидный, но часто недооценённый факт, что у команды не просто отношения с её менеджером. Все, кто вне команды, - это часть среды, в которой существует команда. Эта среда может быть дружелюбной или враждебной по отношению к команде, или и то и другое. Чтобы среда была дружелюбной, команда должна быть полезной для среды, иначе, команда не будет представлять ценности и даже может рассматриваться как угроза для среды, а потому может оказаться под сильным давлением.
Таким образом, выживание команды зависит от удовлетворения нужд среды своей повседневной работой. Если члены команды видят, что мировоззрение команды усиливает их эффективность в повседневной работе и улучшает отношения команды со средой, то такое мировоззрение будет только усиливаться внутри команды. Повторяющийся успех ведёт к тому, что взгляды команды перерастают в их ценности, а они усиливают внутреннюю интеграцию команды, закрепляют место команды в среде и защищают команду от внешних покушений на её целостность.
Если ценности оказываются неэффективными и ослабляют внешние связи, команда будет чувствовать угрозу. В результате команде придётся пересмотреть свои ценности, и, если угроза достаточно реальна, то принять новые взгляды (ведущие к новым ценностям), которые уменьшат беспокойство команды и увеличат продуктивность команды.
При смене взглядов на более подходящие для среды команда избавляется от внешних угроз. Обратной стороной медали является то, что новые взгляды могут начать угрожать внутренним связям команды. Члены команды могут иметь разногласия относительно того, какими должны быть новые взгляды, и могут иметь разное отношение к доминирующим взглядам. Это угрожает сплочённости команды и может привести к расколу.
Хоть и редко, но мне довелось видеть, как команды, работавшие слаженно долгое время, преодолевают такие угрозы. Ответ, по крайней мере в командах, где я работал, состоит в том, что у команд есть наработанные механизмы для ситуаций, выходящих за рамки их взглядов. А именно, сработавшиеся команды становятся экспертами в заполнении недостатков правил точно так же как и отдельные эксперты: они призывают на помощь метод развития метафор.
Метафоры, разделяемые коллективом, образуют базу его культуры. В таком случае, процветание команды означает, что команда смогла выработать культуру, чьи основные метафоры помогают команде адаптироваться и выжить в меняющейся среде.
Как только команда выработала культуру, помогающую выжить долгий срок, главной угрозой такой команде становится давление извне, заставляющее их отказаться от своей культуры в пользу другой. Инстинктивной реакцией команды будет сопротивление, которое можно сломить, лишь уменьшив их беспокойство до того уровня, на котором они согласятся сменить культуру.
-
Культуры программных проектов: глава 4
Posted on February 17th, 2010 1 commentГлава 4: Заводская Культура
Метафора о Заводском Конвейере
Управление проектами разработки приложений может быть довольно пугающим бизнесом. Всё что угодно может пойти не так. Слишком много проектов превысили бюджет, не уложились в сроки или произвели нечто низкого качества, что никому особо и не нужно. Это делает менеджеров проектов дёргаными.Другие индустрии сталкивались с похожими проблемами в прошлом и выработали способы их преодоления. В частности, массовое производство было примером, предложив конвейерные линии в качестве наиболее рационального подхода к обеспечению регулярных, предсказуемых, своевременных поставок согласно оговорённой цене и качеству.
Принципы массового производства на конвейерных лентах были переняты и другими индустриями, где их изложили как основные принципы профессионального управления проектами, и они доказали свою высокую эффективность на деле.
Соответственно, не стоит удивляться, что многие люди, вовлечённые в разработку приложений, соблазнились Заводской Культурой и её доминирующей метафорой о Конвейерной Ленте и пользовались ею для приручения своих диких проектов.
Шоколадная Фабрика
Представьте себе чистую ухоженную фабрику, надёжно и рационально производящую коробки с шоколадными конфетами, наполненными апельсиновой начинкой. Обратите внимание на конвейер с конфетами, лежащими на его ленте в разных стадиях звершённости. Посмотрите на станки, расположенные в различных местах вдоль конвейера, и на рабочих возле них.
Теперь запустите конвейер как кино. Добавьте цвет, запахи и звуки, если получится. Заметьте, что получается, когда оператор первого станка нажимает кнопку и опускает рычаг. Станок создаёт пустые шоколадные раковины и выкладывает их на конвейерной ленте. Шоколадные раковины едут по ленте и останавливаются возле следующего станка. Оператор этого станка поворачивает рукоятку, и каждая шоколадная ракушка наполняется в точности необходимым количеством апельсиновой начинки. Шоколадки едут дальше по конвейеру и останавливаются по мановению руки оператора следующего станка, который кладёт орех на макушку каждой конфеты. Затем они едут дальше. Оператор нажимает на педаль, и последний станок ковейера берёт по десять конфет одновременно, кладёт их ровными рядами в коробки и составляет коробки в штабеля для транспортировки.
Теперь представьте, что вы менеджер такого заводского производства. Уявите себя проходящим вдоль конвейера с блакнотом в руках. Вы чувствуете удовлетворение от того, как гладко, слаженно и циклично работает конвейер. Час за часом, день за днём. Всё работает как часы.
Оппа! Внимание! Один из станков конвейера сломался. Полуготовые конфеты скапливаются на ленте. Рабочие паникуют: жидкий шоколад, апельсиновая начинка и шоколадные раковины разливаются по конвейерной ленте на заводской пол. Ваше сердцебиение ускоряется. Вы чувствуете начало паники. Это ваша ответственность! Вы должны разобраться с поломкой! Что вы собираетесь делать? Ну же, нам нужно решение! Немедленно!
-
Культуры программных проектов: глава 3
Posted on February 10th, 2010 4 commentsГлава 3: Культурные Метафоры
Очаровательные значения
(от переводчика: вместо слова «значения» лучше всего подходит слово «смысл», но для правильности перевода пришлось бы полностью перефразировать несколько абзацев текста.)
Судя по многочисленным исследованиям, оказывается, что мы используем метафоры постоянно. Они настолько распространены, что мы даже не осознаём, что используем их.
Небольшая замечательная книга «Метафоры, по которым мы живём», написанная Lakoff и Johnson, показывает, как ещё с младенчества мы учим основные пространственные метафоры вроде вверх - это хорошо, вниз - это плохо. Мы держимся за них, исследуем и расширяем всю нашу жизнь: «Пора повысить уровень жизни!»; «Его шансы на повышение всё ниже и ниже!» Позже мы узнаём о других метафорах, где идеи получают направление: «Я вижу, куда вы направляетесь с этим!»; «Я просто не пойму, откуда взялся этот парень!». Потом о том, что время - это деньги: «Таким способом ты сэкономишь много времени»; «Мы инвестировали месяца в этот проект». И потом мы проводим остаток жизни, создавая новые более богатые метафоры, переплетённые самыми разными способами. Эти метафоры формируют наше мышление и мировоззрение, позволяя нам исследовать идеи и делиться ими с другими.
Основной принцип метафор состоит в том, что черты, присущие одному предмету, переносятся на другой. Эти черты называются значениями (смыслом) метафор. Исследование этих значений помогает нам понять что-то незнакомое в терминах чего-то, что мы уже хорошо понимаем.
-
Культуры программных проектов: глава 2
Posted on February 4th, 2010 2 comments
Глава 2: Правила игры
Я не виноват
Когда проект идёт успешно, то вполне понятно, кого надо хвалить: нас! «Я сделал всё, что мог, для этого проекта, а потому результат налицо. Без моего великого вклада проект бы не преуспел даже на малую часть.»
Когда я был студентом, то временно подрабатывал программистом в государственном учреждении. Там я встретился с Дэвидом; одним из наименее способных программистов, которых я когда-либо видел. Когда что-нибудь на проекте шло хорошо, Дэвид был уверен, что это его заслуга. Стоило чему-то пойти не так, он был убеждён в секретном сговоре завистников, желающих унизить его. В конце каждого проекта Дэвид возмущался недостатком похвалы, которую он явно заслуживал. Он ушёл с обидой. Странно, но проекты, над которыми он работал, стали улучшаться. Без сомнения, Дэвид был уверен, что это положительный эффект от его наработок.
Кого же мы можем обвинять в провале проектов? Точно не себя! Это всё те придурки!
Был 1988 год. Я только выпустился из университета и начал работать программистом. Глава компании Ричард созвал митинг всех девелоперов. «Я не доволен количеством багов в нашем софте. Если так будет продолжаться и далее, я уволю всех младших программистов, а менеджеры будут программировать.» Новые программисты, включая меня, сидели в ужасе, а более опытные закатывали глаза.
Когда проект идёт плохо, мы склоняемся к мысли «Кто вообще мог надеяться на удачу в этом месте? Проект был обречён изначально, с этими клоунами в командах и ленивыми неудачниками, отвечающими за критические участки работы!»
-
Культуры программных проектов: глава 1
Posted on February 4th, 2010 1 comment
Глава 1: Введение
О культурах
Если из всей книги вы усвоите только одну вещь, то пусть ею будет это: культура имеет значение. И большое значение. Культура разработки приложений не то же самое, что методология разработки приложений. Под методологией понимается набор правил, которых надо придерживаться, а культура - это набор укоренившихся устоев, вокруг которых сплотилась группа людей. Методология может говорить людям как себя вести, а культура определеяет человеческую потребность вести себя определённым образом.
Культура определяет эмоциональную реакцию людей на навязываемые правила. Если методология и культура не совпадают, люди инстинктивно чувствуют обеспокоенность, и методология встречает неприязнь. Если менеджер является приверженцем одной культуры, а его/её команда сплотилась вокруг другой, то все будут чувствовать себя не в своей тарелке, и произойдёт болезненное столкновение культур. В отношениях появляется антагонизм и прогресс тормозится.
Конечно, если вы обладаете некоторой властью над кем-то - например как менеджер над своей командой - вы можете заставить их делать то, что вам нужно. Если всё, что вам нужно, это послушание, то никаких проблем. Именно так заключённых в цепях заставляют целый день дробить камни. К сожалению, я очень много раз видел, что этот подход не очень работает в индустрии разработки приложений. И вот почему: Хотя угрозы и принуждение могут заставить людей подчиниться, это не может пробудить в них добровольное сотрудничество. Вы можете кричать, визжать и наказывать сколько угодно, но без добровольного сотрудничества люди никогда не вложат в свою работу ни сердца ни души. В лучшем случае результаты будут так себе.
Если вы хотите исключительных результатов, то нужно принять во внимание культуру.
Следуйте за своими эмоциями
Мы начнём сразу с вопросов с несколькими вариантами ответов, которые помогут исследовать вашу собственную реакцию на несколько разных аспектов разработки приложений. Ваши ответы покажут, насколько сильны ваши эмоции и насколько сильным может быть их влияние на то, какой культуры вы придерживаетесь.
-
Культуры программных проектов: предисловие
Posted on February 4th, 2010 1 comment
Начиная с этого момента книга Энтони Лаудера “Культуры программных проектов” в русском переводе будет выкладываться главами. Вначале - предисловие.Software Project Cultures
Anthony Lauder (translated by Albert Mustafin)
2008
Предисловие
Почему я написал эту книгу?
Я взялся за написание этой книги почти 10 лет назад, потому что коллеги, клиенты и друзья просили меня об этом. Общим у этих людей было ощущение наводнения различными методологиями разработки приложений, каждая из которых прокламирует свои собственные «правила» управления проектами и разработки.
Люди пытались понять, что имеет смысл на практике, а что просто хорошо выглядит на бумаге. Мне говорили, что трудно представить общую картину; детали захлёстывают с головой. Поэтому я начал писать книгу, предназначенную именно для таких людей. Она рассмотрит широкий диапазон методологий разработки приложений и объяснит, как они связаны между собой и чем различаются.
После нескольких месяцев глумления над клавиатурой я выпустил несколько глав и был шокирован, когда несколько рецензентов из тех людей, кто побудил меня написать эту книгу, сказали: «Интересно. Но какая тут практическая польза?»
Моё эго было малость подавлено, поэтому я перестал писать. Тем не менее вопрос практической пользы никуда не делся. Он всё время крутился у меня в голове.
В течение нескольких следующих лет консалтинга я стал замечать, что и другие люди задают похожие вопросы:
- Почему наш начальник заставляет нас следовать методологии, которая очевидно нам не подходит?
- Почему программисты не делают того, что им говорят?
- Почему я не могу внедрить у нас в компании методологию АБВ?
Постепенно до меня дошло, что людям не нужно говорить как они должны работать, они хотели понять, почему разные люди делают работу по-разному.
Они спрашивали меня не столько о методологиях, сколько о том, как методологии срабатывают или дают осечку в конкретных культурах разработки приложений. И не только это, но и:
- Если это наша культура, то что нужно сделать, чтобы изменить её?
Чем эта книга отличается от других?
Эта разница между методологиями и культурами кажется важной. Никто о ней не писал, но люди спрашивали об этом. На рынке явно существовала пустая ниша, которая убедила меня вернуться к написанию этой книги.
Эта книга показывает, как осведомлённость о культурах разработки приложений может отделить успех от провала в реальных проектах. Вместо лишнего теоретизирования книга на жизненных примерах углубится в то, какие бывают культуры разработки приложений, откуда они происходят и какое влияние оказывают. Три доминирующие культуры будут определены и разобраны в деталях наряду с четвёртой культурой, которая сейчас совсем мало используется, а потому вынесена в приложения.
Мы посмотрим на историю каждой из трёх доминантных культур, их базовые предпосылки и методики разработки приложений, соответствующие этим культурам.
Вооружившись углубленным осознанием культур книга исследует довольно интересный вопрос - как очень успешные компании изменили свои культуры. Также мы увидим, что для закрепления культурных изменений нужно больше, чем навязывание новой методологии в командах. Культура разработки приложений должна постепенно проталкиваться по культурной лестнице, изменяя один уровень за другим.
Feedback
The most important part of this book is you. You and other readers will know far better than I possibly
can how relevant the ideas here are to your daily work. Do let me have your feedback. I am sure I can learn far more from you, than you could ever learn from me. Together, we can make future editions of this book more valuable to its audience.
Thank you
Anthony Lauder
-
Культуры программных проектов: часть 11
Posted on February 1st, 2010 2 comments
(все выложенные на текущий момент части - здесь)Опытные: Статистические Значения
Итак, начинающие стараются вложить свою веру в предписанные правила других людей. Вера, разумеется, без доказательств. Начинающим нужна уверенность, а не доказательства, а потому они следуют правилам без вопросов, работают ли правила на практике. Возможно, это пройдёт для начинающих, но не для опытных людей.
Опытным нужно немного больше, чем вера. Им нужны доказательства. Если какое-то правило хорошо звучит, то опытный человек может взять его на вооружение как надо-проверить-на-деле правило, но проверка покажет, подтвердить или отвергнуть это правило. Постоянно несрабатывающие правила постепенно будут отвергнуты насовсем. А те, что подтверждаются на опыте, станут регулярно используемыми.
В результате постоянных испытаний опытные люди всё меньше полагаются на предписанные правила и больше на проверенные «законы». Они составляют свой собственный свод статистических значений, помогающий им решать, что работает, что нет и при каких обстоятельствах.
В книге Тома Демарко и Тимоти Листера Peopleware есть история забастовки под названием работай-по-правилам. В ней рабочие букввально следовали формально навязанным правилам (процедурным руководствам), и, разумеется, прогресс сильно застопорился. Знание, когда правилам следовать, а когда нет, очень важно для эффективной работы. Вот, где опыт играет главную роль.
Статистические значения ближе к сердцу, чем заимствованные правила, потому что они являются нашими собственными детищами, рождёнными потом наших трудов. Они становятся тем, о чём мы старательно печёмся. Мы используем их не только для управления нашими действиями, но и для определения успешности себя и других.
Так же как начинающие чувствуют эмоциональную несовметимость с методологиями, которые конфликтуют с заимствованными ими правилами, так и опытные сотрудники могут чувствовать сильную эмоциональную неприязнь по отношению к методологии, которая не соответствует их собственным статистическим значениям. Когда мы сталкиваемся с чем-то, что подходит под нашу статистику, то испытываем приятное чувство, закрепляющее нашу уверенность в наших данных. И наоборот, когда что-то противоречит нашей статистике, у нас появляется некомфортное ощущение неприязни. Увиденное или услышанное кажется нам неправильным, а потому раздражает нас.
Конечно, вполне возможно, что опытные люди смогут составить из своих статистических данных методологию, пригодную для других, но это рискованное предприятие, так как начинающим не хватит опыта, чтобы воспринимать это не только как правила для слепого соблюдения. Эффективность статистических значений зависит не столько от абсолютного повиновения, сколько от здравомыслия и уверенности, основанных на личном опыте. Главная разница состоит в том, что предписанные правила - это нечто, что вы считаете правильным, а статистические данные - это то, что вы знаете как правильное глубоко внутри, потому что оно было не раз доказано на практике. Они отображают опыт, полученный на передовых, который и отличает опытных от начинающих.
Продолжение следует …
-
Культуры программных проектов: часть 10
Posted on January 28th, 2010 No comments
(все выложенные на текущий момент части - здесь)Тем не менее, приверженность конкретной предписанной методологии не гарантирует уверенности. Часто разражаются споры о том, что на практике означают конкретные правила. Что имеется ввиду в некоторых запутанных инструкциях? Если два правила конфликтуют, то какому отдать предпочтение? Можно ли изменить или даже отбросить какое-нибудь правило, если оно не подходит конкретным обстоятельствам, но продолжать считать себя сторонниками той же методологии? Частенько я замечал, что такие разговоры перерастают в горячие споры вокруг довольно простых вещей.
На одной конференции я встретил тимлида. Его команда использовала RUP и его унифицированный язык моделирования UML. Они использовали коллаборационные диаграмы UML как часть своей работы над дизайном, но заспорили о том, не являются ли последовательные UML диграмы лучше. Они беспокоились, правильный ли путь они выбрали, и спросили меня, не надо ли им переключиться.
Вместо того, чтобы начать подробное обсуждение небольших различий двух типов диаграмм, я спросил, а работает ли для них RUP вообще. Тимлид признался, что создание всяких диаграмм на самом деле замедляет проекты, а потому лучшие из его программистов старались использовать инструменты, которые генерировали диаграмы автоматически прямо из приложения, когда оно уже было написано.
Покопавшись в ситуации мы поняли, что главная выгода, почерпнутая из RUP, состояла в том, что ребята научились мыслить объектно-ориентировано, и тимлид был уверен, что это улучшило дизайн их приложений. Все остальные требования RUP были второстепенными на этом фоне, а его беспокойства о переключении с одного типа диаграмм на другой мало повлияют на результаты проекта.
Эта потребность в уверенности, хоть и оправдывает, скрывает более существенную проблему, с которой в конце концов сталкиваются начинающие. Они ожидают, что методология ответит на каждый вопрос, с каким они столкнутся. Когда это не срабатывает на практике, новички начинают сильно нервничать. Они вложили большую веру в выбраную методологию, потому что они верят, что её авторы знают больше их самих. Обнаружение дыр в предписаниях бросает тень сомнения на методологию и её авторов и подрывает веру новичков.
В прошлом я пытался объяснить начинающим программистам, что нет ничего зазорного в том, чтобы искать в методологии руководства, даже на довольно детализированном уровне, но нельзя ожидать, что она будет ответом на все вопросы. Игра «разработка приложений» существенно сложнее монополии, шахмат и футбола. В ответ на это я обычно вижу кивок головы, но я уверен, что люди редко воспринимали мою теорию. Чаще меня спрашивали: «Ну, и какую же методологию мы тогда должны использовать?» Начинающим трудно отбросить комфорт абсолютной уверенности.
Многие методологи очень восприимчивы к таким дырам, и, когда им их показывают, они стараются заполнить их в следующих версиях книг с правилами. В результате предписанные правила становятся ещё более сложными, а методологии со временем становятся более догматичными. Разумеется, это делает методологии менее субъективными, что может помочь разрешить некоторые споры, но создаёт опасность того, что методология станет менее гибкой и слишком громоздкой для применения. Кроме того, невозможно заткнуть все дыры, а потому, стремление к совершенству просто бесконечно.
В конце девяностых я провёл некоторое время с Дереком Колманом, одним из авторов популярной в то время методологии Fusion. Он признался, что текущая версия была на сотни страниц длиннее оригинала и содержала столько заковыристых правил, что он уже сам не мог увидеть лес за деревьями, а потому был захлёстнут сложностью собственной методологии. Дерек сильно беспокоился, что методология Fusion разваливалась под собственным весом, и решил не развивать её дальше.
Продолжение следует …
Предисловие
Loading ...
Последние коментарии