(Update: турне 2009 проекта Happy PM по городам СНГ окончено. Сформировано расписание тренингов на первый квартал 2010 года.)
Я подумал, что было бы неплохо выложить расписание открытых тренингов Happy PM до конца года. Тем более, что большинство их уже спланировано и организаторы на местах ведут работу. Итак 2010 год:
23-24 января, Москва. ”Управление командой” и “Карьера менеджера”
30 января, Харьков. “Карьера менеджера”
7-8 февраля, Новосибирск. ”Управление командой” и “Карьера менеджера”
13-14 февраля, Минск. “Управление командой” и “Карьера менеджера”
13-14 марта, Киев. “Управление командой” и “Карьера менеджера”
15-16 марта, Днепропетровск. “Управление командой” и “Карьера менеджера”
17-18 марта, Одесса. “Управление командой” и “Карьера менеджера”
27-28 марта, Санкт-Петербург. ”Управление командой” и “Карьера менеджера”
Что такое открытые тренинги Happy PM? Это уникальные образовательные мероприятия для руководителей программных проектов и команд (и не только для них, о чем ниже). Без преувеличений, аналогов этим тренингам на пространстве бывшего СССР, не существует. Основные составляющие успеха:
Ниже - подробно о каждом пункте, информация о ведущем и тех, кто уже прошел обучение, а также о стоимости тренингов. Также вы можете ознакомиться с отзывами участников.
Если вы хотите поучаствовать в каком-либо тренинге, пожалуйста, оставьте свою заявку заранее. Как показывает опыт, мест на всех может не хватить.
Any man who reads too much and uses his own brain too little falls into lazy habits of thinking.
Наверняка многие знают старый анекдот про стрельбу студента на военной кафедре. Ну, на всякий случай, воспроизведу:
Приезжает студент, который учится на военной кафедре, на стрельбище. Отстреливается, к нему подходит зав. военной кафедрой:
- Ну что, Петров, два.
- Почему два.
- На, посмотри в бинокль на мишень - ни одной дырки, все в молоко.
Студент берет бинокль, смотрит: «Ну, не знаю, с моей стороны все пули вылетели…»
Отношение к работе в духе «с моей стороны пули вылетели» часто присутствует у молодых специалистов. Которые считают, что они лично могут достигнуть успеха, даже если сам проект, в котором они участвуют, провалится. Но иногда это отношение встречается и у зрелых инженеров.
Вот, например, есть такая активность - верификация дефектов. Стандартная ситуация в проекте: тестировщики дефекты выставляют (например, в Bugzilla), разработчики героически дефекты исправляют (переводят в состояние FIXED). А проверять то, что дефект действительно был разрешен (перевести его в состояние VERIFIED) - это уже можно сделать перед самым релизом.
Что интересно - многих тестировщиков, на самом деле, не так сильно волнует, действительно ли были разрешены те ошибки, которые они нашли. А программистов не так сильно волнует, действительно ли те фиксы, которые они предложили, работают в системе.
То есть, одни дефект выставили (с их стороны пули вылетели), другие фикс положили в пространство кода (с их стороны пули тоже вылетели) - и все. J
Очень редко встречаются тестировщики, которые проверяют, что «их дефект» разрешен, как только тот перевелся в состояние FIXED. Еще реже встречаются программисты, которые пинают тестировщиков, чтобы те проверили, что дефект действительно FIXED.
Так и летают пули по проекту туда-сюда. А бедные менеджеры тушат пожары: «А-а-а, у нас к релизу много непроверенных дефектов. Нужно еще два дня, чтобы их все проверить!..»
Чудесный ролик от гения карандашной анимации Макса Дорофеева - на этот раз об истории Waterfall’а:
Автор объявил конкурс - кто отгадает все музыкальные темы и мелодии, использованные в ролике? (Подсказка: всего их 10, половину даже я знаю
)
В феврале-марте 2010 Вика Придатко выдаст серию из вебинаров по практическому поиску, найму, удержанию и мотивации программистов. Вика известна нашим читателям по выступлению на апрельском тренинге Happв Киеве, по докладу на PM Labs в 2009. А также по тому, что она большой профессионал (в прошлом HR директор компании Global Logic).
11 февраля: бесплатный вебинар “Позитивное управление персоналом”
25 февраля: платный вебинар “Найм от забора и до обеда. Полный цикл поиска и оценки сотрудника”
2 марта: бесплатный вебинар “Внутренний маркетинг. Как воодушевить ваших сотрудников сделать что угодно?”
24 марта: платный вебинар “Найм, мотивация и удержание программистов”
Notice: Вероятнее всего, я там тоже буду. То ли в качестве гостя, то ли в качестве слушателя - Вика мне еще не объяснила.
Notice 2: Форма регистрации на webinary.com.ua иногда взглючивает. Поэтому если неожиднно она не показывает того вебианара, на который хотите записаться, пишите его название в комментариях.
Еще в ноябре мы вместе со Славой Панкратовым написали статью по одной из “Игр в ИТ”. В декабре статью опубликовали в журнале “Профессия - директор”. Теперь публикуем ее здесь:
Александр Орлов
Независимый консультант, автор проекта «Клуб Успешных Менеджеров Программистов», соавтор проекта «Управленческие игры: психология и политика, в которые играют сотрудники, начальники, заказчики и компании»
«Игры» - часть теории транзакционного анализа, выдвинутой выдающимся американским психологом 20-го века Эриком Берном. В своей теории Берн рассматривал межличностные отношений с точки зрения человеческих транзакций или соглашений, сделок. Транзакции, имеющие в себе скрытую цель, он назвал «играми».
Любая игра подразумевает нескольких участников: я, ты, они. Например: я - руководитель, ты - сотрудник, они - остальные сотрудники. Или: я - сотрудник, ты - другой сотрудник, они - начальство. Для начала игры играющий человек должен считать каждого из этих трех участников либо плюсом, либо минусом.
Например, один сотрудник говорит другому: «Это начальство совсем оторвалось от жизни, совсем уже не видит, куда идет проект. А нам, инженерам, расхлебывать.» Это человек исходит из позиции «я+, ты+, они-».
Если же человек говорит: «Ну, конечно, у них все получается и у тебя получается. Вы-то тут уже два года работаете…», то это позиция «я-, ты+, они+».
Целью любой игры является получение ощущений - «купонов», которые могут быть как положительными (золотые купоны), так и отрицательными (коричневые купоны). Золотые купоны человек в будущем сможет обменять на определенные выгоды для себя (например, на повышение зарплаты). А коричневые он сможет использовать, например, чтобы обосновать свой уход: «Меня в этой компании никто не слушает». Также возможны фальшивые золотые купоны - например, человек, испытывает фальшивое чувство торжества над коллегами, но обменять это чувство на повышение он не сможет (потому что руководитель видит, что человек просто строит из себя «супер-звезду»).
Однажды, когда я руководил одной из команд в большом проекте (мы разрабатывали программное обеспечении), у нас случился казус. Инженеры в разных командах реализовали один и тот же модуль. Модуль был нужным, но существовал теперь в двух экземплярах. Обе реализации делали одно и то же, но внутреннее устройство у них немного отличалось.
Перед руководителем проекта встала задача - решить, какой модуль оставить. Обе команды, разработавшие свою версию модуля, такой вариант решения не устраивал: «Это что же,» - говорили они, «может так оказаться, что мы зря писали?..»
Руководитель, однако, считал, что нужно выбрать лучший модуль, а другой выбросить в корзину. Поэтому он попросил обе команды заполнить таблицу с плюсами и минусами обеих реализаций. Думаю, читатель может догадаться, что произошло. Естественно, каждая команда нашла больше плюсов в своей реализации, а больше минусов в чужой. Слова: «Вы понимаете, что мы не зря писали этот модуль?» все чаще звучали с обеих сторон.
Стало понятно, что ситуация становится взрывоопасной. Руководитель решил принять компромиссное решение. Инженерам из разных команд, авторам модулей, предлагалось сесть вместе и сделать совместный модуль, взяв лучшее из обеих реализаций. Поскольку команды находились в разных городах, то совместная работа проводилась по телефону и заняла около двух недель.
Говорит эксперт. Компромисс всегда бывает вынужденным. Он должен быть последним средством. Если два отдела или подразделения не могут решить проблему и приходят с ней к вам, выслушайте обе стороны и, не уподобляясь царю Соломону, выберите одну или другую. На победившего это накладывает огромную ответственность за выполнение работы.
Роберт Таунсенд «СЛОМАЙ СИСТЕМУ! Лекарство от управленческой изжоги»
27-28 марта Гильдия менеджеров программных проектов проведет свой первый тренинг. Тренинг необычен тем, что нацелен на довольно интересную аудиторию - ИТ директоров не-ИТшных компаний. Если вы сами являетесь таковым директором - приходите, думаю, будет очень полезно. если вы работаете в такой компании - присылайте своего директора. Будет полезно и ему, и вам.
Чуть ниже - официальный анонс.
Гильдия Менеджеров Программных Проектов приглашает на уникальный двухдневный курс «Промышленная разработка и эксплуатация ПО: управление и контроль», который пройдет 27-28 марта в Москве в гостинице Мариотт Гранд Отель. Курс был разработан специально для руководителей подразделений и департаментов, ИТ-директоров и вице-президентов по информационным технологиям компаний, не специализирующихся на ИТ, в зону ответственности которых входит управление созданием и эксплуатацией информационных систем для бизнеса.
Курс формирует практически полезную структуру целей и задач промышленного процесса разработки и эксплуатации ПО на всех стадиях жизненного цикла информационных систем.
Специальные модули курса рассматривают сложившиеся в индустрии разработки мифы, которые приводят к провалам проектов, неуправляемости процесса разработки и эксплуатации ПО, культивированию псевдо-творческих настроений, которые на деле способствуют размыванию ответственности при выполнении проектов и дезорганизации производственных и административных подразделений ИТ-департаментов.
Подробнее на сайте Гильдии Менеджеров Программных Проектов

Глава 2: Правила игры
Я не виноват
Когда проект идёт успешно, то вполне понятно, кого надо хвалить: нас! «Я сделал всё, что мог, для этого проекта, а потому результат налицо. Без моего великого вклада проект бы не преуспел даже на малую часть.»
Когда я был студентом, то временно подрабатывал программистом в государственном учреждении. Там я встретился с Дэвидом; одним из наименее способных программистов, которых я когда-либо видел. Когда что-нибудь на проекте шло хорошо, Дэвид был уверен, что это его заслуга. Стоило чему-то пойти не так, он был убеждён в секретном сговоре завистников, желающих унизить его. В конце каждого проекта Дэвид возмущался недостатком похвалы, которую он явно заслуживал. Он ушёл с обидой. Странно, но проекты, над которыми он работал, стали улучшаться. Без сомнения, Дэвид был уверен, что это положительный эффект от его наработок.
Кого же мы можем обвинять в провале проектов? Точно не себя! Это всё те придурки!
Был 1988 год. Я только выпустился из университета и начал работать программистом. Глава компании Ричард созвал митинг всех девелоперов. «Я не доволен количеством багов в нашем софте. Если так будет продолжаться и далее, я уволю всех младших программистов, а менеджеры будут программировать.» Новые программисты, включая меня, сидели в ужасе, а более опытные закатывали глаза.
Когда проект идёт плохо, мы склоняемся к мысли «Кто вообще мог надеяться на удачу в этом месте? Проект был обречён изначально, с этими клоунами в командах и ленивыми неудачниками, отвечающими за критические участки работы!»

Глава 1: Введение
О культурах
Если из всей книги вы усвоите только одну вещь, то пусть ею будет это: культура имеет значение. И большое значение. Культура разработки приложений не то же самое, что методология разработки приложений. Под методологией понимается набор правил, которых надо придерживаться, а культура - это набор укоренившихся устоев, вокруг которых сплотилась группа людей. Методология может говорить людям как себя вести, а культура определеяет человеческую потребность вести себя определённым образом.
Культура определяет эмоциональную реакцию людей на навязываемые правила. Если методология и культура не совпадают, люди инстинктивно чувствуют обеспокоенность, и методология встречает неприязнь. Если менеджер является приверженцем одной культуры, а его/её команда сплотилась вокруг другой, то все будут чувствовать себя не в своей тарелке, и произойдёт болезненное столкновение культур. В отношениях появляется антагонизм и прогресс тормозится.
Конечно, если вы обладаете некоторой властью над кем-то - например как менеджер над своей командой - вы можете заставить их делать то, что вам нужно. Если всё, что вам нужно, это послушание, то никаких проблем. Именно так заключённых в цепях заставляют целый день дробить камни. К сожалению, я очень много раз видел, что этот подход не очень работает в индустрии разработки приложений. И вот почему: Хотя угрозы и принуждение могут заставить людей подчиниться, это не может пробудить в них добровольное сотрудничество. Вы можете кричать, визжать и наказывать сколько угодно, но без добровольного сотрудничества люди никогда не вложат в свою работу ни сердца ни души. В лучшем случае результаты будут так себе.
Если вы хотите исключительных результатов, то нужно принять во внимание культуру.
Следуйте за своими эмоциями
Мы начнём сразу с вопросов с несколькими вариантами ответов, которые помогут исследовать вашу собственную реакцию на несколько разных аспектов разработки приложений. Ваши ответы покажут, насколько сильны ваши эмоции и насколько сильным может быть их влияние на то, какой культуры вы придерживаетесь.
Начиная с этого момента книга Энтони Лаудера “Культуры программных проектов” в русском переводе будет выкладываться главами. Вначале - предисловие.
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
Гильдия менеджеров программных проектов разжилась новым сайтом. Ура! По этому поводу даже родился следующий анонс:
Гильдия менеджеров программных проектов (SPMGuild) - независимое международное сообщество профессионалов в управлении проектами разработки программного обеспечения - объявляет о запуске своего нового сайта.
Новый сайт Гильдии менеджеров программных проектов открыт 3 февраля 2010 года по адресу www.SPMguild.ru
Помимо основных разделов о Целях и Программе Гильдии, а также признанных экспертах, основавших Гильдию и руководящих ее деятельностью, сайт Гильдии содержит новый раздел с анонсами мероприятий, которые Гильдия планирует провести в ближайшее время, а также архив новостей о мероприятиях, которые проведены под эгидой Гильдии в прошлом 2009 году. Отдельный интерес для сообщества представит еще один новый раздел - Библиотека - в котором будут накапливаться наиболее интересные и полезные материалы менеджерской направленности, причем как перепечатки уже известных статей, так и эксклюзивные материалы экспертов Гильдии и других признанных специалистов отрасли.
Как прокомментировал открытие нового сайта один из соучредителей Гильдии Дмитрий Башакин, который руководил проектом по запуску новой версии официального сайта организации: “Переход на новый сайт был нужен нам для того, чтобы реализовать новые идеи по Интернет-представительству Гильдии, которые родились за последние полгода в головах членов нашей организации. Начали мы с простого статического сайта, который помог ознакомить общественность с нашими основными программными документами и привлечь к работе в Гильдии десятки высококвалифицированных специалистов отрасли. Теперь мы выкладываем на наш сайт подробные отчеты о проводимых Гильдией мероприятиях (включая аудио и видео репортажи) и информацию о наших перспективных планах. В стадии активного становления находится раздел, содержащий разнообразную полезную информацию по управлению программными проектами, которая представит несомненный интерес для специалистов нашем по управлению проектами.”
О Гильдии менеджеров программных проектов:
Гильдия основана 19 мая 2009 года в Минске (Белоруссия) на конференции Software Engineering Forum.
Цели Гильдии:
Подробнее о Гильдии:
Последние коментарии