среда, 22 апреля 2009 г.

Дух группы

Программное обеспечение выражает команду, его создавшую.

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

Основной принцип следующий: если вы не можете понять что у вас происходит в команде, посмотрите на ПО.

Ключ к созданию качественного ПО - постоянное поддержание контакта с "духом команды".

Для более детального изучения этой темы обратитесь к книге "Программируем командный дух".  Вы также можете присоединиться к группе изучения этой книги: Agile Study Group: Программируем командный дух


Подготовленно по книге
"Правила разработки программного обеспечения" Джим Маккатри, Мишель Маккарти

№8 Используйте руководителей проектов


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

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

Прочитав эти строки первый раз, я был возмущен до глубины души. Как не имеет власти? Как не будет писать спецификации? В то время, все мои представления были связаны именно с тем, что руководитель отдела разработки - это человек который говорит каждому члену команды,  что он должен делать и как он это должен делать. Мой девиз был примерно такой: "Если вы считаете что программирование это творческая работа, тогда нам с вами не по пути". Звучит ужасно, неправда ли? Потом случай свел меня с Денисом (Денис Миллер), и я начал читать книги и учится. Кстати пользуясь случаем, хочу сказать ему спасибо (в качестве рекламы ссылка Study Group).  
А что если подумать? Кстати вот отличный ролик, что бы хорошо думалось Снежинка


Управление проектом является технической задачей. Есть два аспекта технического мастерства:
  • технология, используемая при создании проекта
  • технические аспекты лидерства при создании ПО
Руководитель проекта должен владеть многими искуствами. Он должен уметь
  • уговаривать
  • содействовать
  • внушать вдохновление
  • требовать совершенства и эффективной работы
  • должен знать все входы и выходы  для выпуска ПО в срок
  • должен применять лучшие практические методы
  • должен быть представителем команды для руководства
Руководитель проекта является сердцем разработки ПО.


Подготовлено по книге 
"Правила разработки программоного обеспечения" Джим Маккрти, Мишель Маккарти

воскресенье, 19 апреля 2009 г.

№ 7. Используйте команду по особенностям.


Мы обычным образом организуем команду разработчиков - КК, разработчики, технические писатели, руководители проектов. Мы берем представителей из каждой группы и создаем из них команду по особенностям в матричной организации. Они сами уточняют свое назначение. 

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

Наделение полномочиями.

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

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


Ответственность

Большенство лучших идей, возникших в любом человеческом коллективе, тратятся впустую или теряются. Разбазаривание идей происходит потому, что люди не чувствуют себя ответственными.

  • Источник идеи чувствует, что это не его зона ответственности, и поэтому редко формулирует идею конструктивно.
  • если источник высказывает идею, то адресат, которому направлена идея - может реагировать оборонительно, применяя весь арсенал защитных стилей и средств
  • начальные попытки пробудить интерес к идее, обернуты во встроенную агрессию. Адресат четко распознает агрессию, и оборонясь от нее, не замечает "благородный" компонент сообщения. В этот момент источник уступает своему агрессивному началу и отвергает адресата, как недостойного для ведения последующих обсуждений - то есть устанавливает бит ничтожества.

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


Идентификация

Наделение полномочиями и отчетность неминуемо ведут к идентификации.  Люди отождествляются с тем, что они контролируют и на что влияют.

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

Это чертовски приятно, отождествлять себя со своим продуктом. Вы начинаете думать как продукт вашего творчества, вы говорите от его имени. Вы становитесь его адвокатом, его гласом. Вы говорите что вам надо что бы вы еще лучше работали. Каждая ошибка продукта воспринимается как собственная рана, которую необходимо срочно вылечить. И как вы довольны, когда "вы" работаете "как по часам".


Консенсус

Согласие царит в атмосфере команд по особенностям. Так как элементом идентификации является особенность, а не функция, и так как ответственность за особенность общая, то и определенная степень открытости безопасна.

Когда члены команды идентифицированны, у них отсутствуют области для конфликтов личностного характера.  Конфликты рабочего характера воспринимаются как подарок.


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


У большинства людей существует поверхностное мнение о команде. Они считают что, команда - это притворный консенсус и фальшивые одобрительные возгласы.


Функциональные менеджеры.

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

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

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


В идеальном проекте, обычно имеются Создатели и Кураторы. Создатели специализируются в Разработке, Контроле качетва, Маркетинге, Документировании. Кураторы специализируются в понимании группы, создании обстановки, в которой комфортно заниматься творческой работой.

Кураторы, так же как и Создатели, несут ответственность за качество программного продукта. А Создатели, так же как и Кураторы, ответственны за состояние группы.

Единственноая власть идет от знания и понимания, а не от занимаемой должности!

Подготовленно по книге 
"Правила разработки программоного обеспечения" Джим Маккарти. Мишель Маккарти

№6 Соблюдайте пропорции

Распространенная ошибка многих руководителей проектов, заклюяается в том, что они нанимают только разработчиков.


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

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


На двух разработчиков один КК.


Когда речь заходит о пропорциях, важны не фактические числа, а эффективные числа.


Фактическое число может ограничить вероятность достижения равновесия, но не может гарантировать его. Помните, целью является равновесие!


Подготовленно на основе книги
"Правила разработки программного обеспечения"  Джим  Маккарти, Мишель Маккарти

суббота, 18 апреля 2009 г.

№5 Используйте разведчиков

Прежде чем начать новый проект - произведите разведку.


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

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

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

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

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

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


Разведчиков используют только те люди, которые находятся на полном ходу, ы движении, перемещении. Если вы неподвижны - вам разведчики не нужны.

Будете ли вы разрушены натиском технологического прогресса, или сумеете определить его, зависит от вашей приверженности передачи полномочий каждому члену вашей команды.

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

Подготовленно на основе книги
"Правила разработки программного обеспечения" Джим и Мишель Маккарти

пятница, 17 апреля 2009 г.

№4 Не устанавливайте бит НИЧТОЖЕСТВА

- Что самое трудное в разработке ПО?
-  Заставить людей думать.

Большенство людей не любят думать. Хотя сами могут считать по другому. Легче не думать, и вместо этого бит ничтожества. "Этот парень - ничтожество".  После этого на него ни кто не обращает внимания,  его мнение ни кого не интересует, на него все смотрят с высока, ему нельзя доверять, мертвый груз, ничтожество.

Мы часто устанавливает такой бит на кого-нибудь. Мы просто перестаем его замечать, не слышим (слушаем, но не слышим) его, просто игнорируем. И он ходит сам по себе, а потом в один прекрасный момент покидает команду. И мы вроде рады, но бит ничтожества переходит на другого человека, возможно на вас.

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

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


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

Думающие люди способны оценивать новые идеи. Если же они этого не могут - то в силу двух явлений:
  • оборонительная позиция - возникает, если адресат не правильно понимает критическую обратную связь. Критика или лучшие идеи по поводу продукта или процесса его создания преобразуется в критику себя.
  • после того как хорошие идеи человека были сразу или повторно отвергнуты, инициатор сообщения, из-за страха или иных причин, устанавливает бит НИЧТОЖЕСТВО = TRUE на получателе своего ценного сообщения

Как часто вы занимали оборонительную позицию? Сколько раз возникал конфликт? Конфликт возникающий на основе оборонительной позиции - не правильный конфликт, он не ведет к общей цели выпустить качественный продукт во время.  Что происходило после оборонительной позиции - вы все спокойно обдумывали и принимали критику в удобной для вас форме, возможно даже извинялись.
Как часто ваши идеи отвергались? Сколько попыток донести свою идею вы делали, прежде чем выставить бит НИЧТОЖЕСТВО=TRUE? Когда вы перестали удивлятся что ваши идеи через месяц, полгода принимались и воплощались?

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


Использованы материалы из книги
"Правила разработки программного обеспечения" Джим и Мишель Маккарти

четверг, 16 апреля 2009 г.

№3 Создайте технологический план выпуска продукта

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

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

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

Когда план есть, и вы принимали участие в его создании, вы взяли на себя некоторую ответственность за реализацию  -  вы заинтересованны выполнить план, во время и качественно

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

Эх, как часто хотелось сделать все сразу,  реализовать все идеи по текущему функционалу. И что делалось - реализовывалось по максимуму в отведенное время, не смотря на то что не все протестированно, не все полностью проверенно. А почему? Потому что неизвестно было когда в следующий раз представиться возможность поработать с этим ыункционалом, и как следствие - большое количество ошибок и недочетов. Канечно, они все правились, но будь план перед глазами ...

Самое важное - план должен сущетвовать!


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


Использовались материалы из книги
"Правила разработки программного обеспечения"  Джим Маккарти, Мишель Маккарти

среда, 15 апреля 2009 г.

№2 Привлекайте каждую голову в дело


Действительное вовлечение каждого челена команды в творческий процесс является замечательным достижением руководства команды

У каждого члена коллектива есть свои собстенные мысли, независимо от сплоченности команды. В этом заключается проблема.

Человек - существо разумное, постоянно находится в сосянии размышления. И только он! один знает то о чем он думает, необходимо создать в команде атмосферу доверия - и заполучать мысли, не важно какие.

Почти все идеи возникающие у членов вашей команды, длстойны того что бы их услышали.

Идея должна проходить процесс звукового рождения, тогда она не исчезнет  и возможно получит продолжение и разовьется в другой голове

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

Почему люди не рассказывают о том что думают? Они считают
  • ни кто их не услышит
  • кто то должен им указывать что делать
  • из этого ничего хорошего не выйдет и творчество осуждается
  • они не должны отчитываться за свою манеру работать
  • менеджеры рассматривают свои функции как сугубо управленческие

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


Выдержки текста взяты из книги
 "Правила разработки программного обеспечения"  (Джим Маккрти, 
Мишель Маккарти) 2006г

№1 Добивайтесь общего видения

Что такое общее видение? 
Часто встречается термин видение проекта (vision), но термин общее видение встречается довольно редко. 
Так что же это такое?

Далее цитаты из книги
Каждый член команды должен знать: 
  • что будет делать команда
  • как будет выглядеть конечный продукт
  • какова базовая стратегия создания продукта
  • когда команда должна выпустить продукт 

Мне кажется основная суть в том что именно КАЖДЫЙ член команды должен именть общее видение. Руководитель, менеджер его обязаны иметь, должность такая, а вот команда ... 

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

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

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

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

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

Лидер и команда должны быть на одной волне, должны иметь единый вектор движения. Лидер является эмоциональным топливом для команды. Здоровая команда сама будет идти в правильном направлении

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


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

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


        Лидерство и групповое видение начинаются с сопереживания между лидером и командой


Выдержки текста взяты из книги
 "Правила разработки программного обеспечения"  (Джим Маккрти, 
Мишель Маккарти) 2006г