Отчет о PM Labs 2010

1. Дмитриев Сергей — Ретроспективы. Настраиваем наш процесс разработки.
   • Живой неформальный доклад, очень понравилось, как докладчик работает с аудиторией. При этом — подача информации понятная и структурная. Многое из этого попробую взять в работу — тем более что то, как проводятся ретроспективы у нас в компании меня, мягко говоря, не устраивает. Что лично для меня было ключевого в докладе — промежуточные ретроспективы по итогам фаз или спринтов проекта. Обычно слышала или читала только про ретроспективы по итогам релизов. И второе — при обсуждении проблем, выявленных на ретроспективы — не обсуждать второстепенное (а то у нас обычно считается, что надо обсудить все наболевшее) — а тут как с бэклогом — надо выявить самое наболевшее + решаемое — и с ним работать. Плюс к этому, не переходить сразу от проблемы к поискам путей решений, а попытаться выявить корневую причину проблемы — это может в корне изменить подход к решению. А наши люди тоже свойственны сразу кидаться в бой.
2.  Бережной Сергей — Разработка ПО как сервис. Фокусируемся на Заказчике
   •  Ожидала от доклада большего. Насколько я поняла из последующего обсуждения к коридоре, не только я. Возможно, просто доклад рассчитан на другую целевую аудиторию — на начинающих менеджеров, только-только оторвавшихся от решения технологических проблем и сфокусированных исключительно на технологичности представляемых решений. Для любого более-менее зрелого менеджера, да который, к тому же, общается с заказчиком не из IT сферы все вещи, о которых говорилось в докладе — в некотором роде азбучные истины. Ниже в посте у меня еще будут лирические отступления на тему данного доклада.
3. Георгий Ковалев — Внедрение практики управления проектами в Лаборатории Касперского
   • Мне понравилось. Мы у себя тоже пытаемся что-то сделать как с процессами компании, так и проектным управлением — поэтому было очень интересно послушать про смежный опыт. Работа проделана огромная — и результаты — и пути их достижения — интересные. Жаль, что не было Александра Самбука — он заболел — поэтому не было общей картинки «Проектное управление — Процессы компании — Продукты компании», Георгий рассказывал только про свой кусок — проектное управление. Интересен сам подход к проекту — начался просто потому, что так захотело начальство, ROI не меряют и это даже не стояло в задачах — только сейчас они приходят к тому, что есть возможность получать некие метрики и начать считать ROI. Подход к обучению — учат «по факту» — т.е. не как многие «у нас вот тут скоро будет переход к проектному управлению — давайте поучимся» — а именно в рамках внедрения проектного управления и даже более, инструментариев для его ведения — учат людей пользоваться инструментами — и попутно дают общие навыки. Как борятся с тем, что регламенты никто не читает — вместо регламентов рисуют комиксы.
4. Башакин Дмитрий — Ситуационное управление – опыт практического использования в ИТ-проектах
   • Абсолютно новый для меня материал — никогда ничего на тему не читала и не слышала. В целом, конечно, как и любая модель — попытка впихнуть невпихуемое — но интересно. Потому как если не пытаться впихнуть — то работа превратится в хаос. Митя рассказывал живо и интересно — но материала явно больше, чем времени — отведенного на его подачу — поэтому он явно гнал лошадей. Подумаю на тему посещения соответствующего тренинга — но уже явно не в этом году. По этому докладу тоже будет лирическое отступление ниже
5. Стив Макконнелл — Как сделать эффективным процесс разработки ПО?
   • Самое большое разочарование. Интересно — человек русских считает идиотами — или он вообще зазнался — и всех считает идиотами? Потому что доклад — полная халтура — все те данные и цифры — которые приводились — можно найти на любом перекрестке в интернете. И когда ему об этом в мягкой форме намекнул один из слушателей — он еще и обиделся. В докладе не было ни одной свежей мысли — да вообще мысли не было — он просто пересказал слайды с цифрами. Когда пытались задавать какие-то вопросы более конкретные — фактически уходил от ответа. Вывод — для — организаторов конференции — может — не гоняться за дешевизной и «звезд» не приглашать? Потому как когда идет замануха на звезд — а потом эти звезды несут пургу — то впечатление куда худшее, чем если бы звезд не было совсем. Ну или как-то надо делать «ревью» того, что эти звезды собираются доложить, объяснить им, что у русских есть интернет и они даже его читают — и книжки они тоже умеют читать, как ни странно. Перевод — лично мне только мешал. Переводчица явно не владела технической терминологией — со всеми вытекающими. Имхо, стоит попробовать разориться на аппаратуру для синхронного перевода — тем, кому надо перевод — будут слушать его, а остальным хоть этот перевод не будет мешать — и сам доклад пойдет живее.

Лирическое отступление

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

1. Сергей Бережной в качестве примера сфокусированности не на заказчике, а на себе — привел пример банка, который отказал ему в перевыпуске карты с изменением срока ее действия. Народ тут же кинулся обсуждать — какие в Украине дурацкие банки — и что быть такого не может. Пример неудачный, имхо, с двух позиций.
   • Во-первых, что действительно — ситуация спорная. И что можно было бы подумать о примере, который не допускает неоднозначных трактовок. Я предложила в качестве замены банку — любое подразделение служб ЖКХ — тот же ЖЭК — и все сразу согласились с тем, что все, что там делается, даже не пахнет сфокусированностью на заказчике. 
   • Во-вторых — случай с банком заставил меня задуматься — а так ли и не прав был банк, отказав. И не был ли его отказ мотивирован именно сфокусированностью на заказчике. Ведь для банка один из основных компонентов сервиса — безопасность. И одним из основных средств обеспечения безопасности — является следование процедурам и регламентам. И любой выход за рамки регламентов — ставит под угрозу безопасность — причем не только этого клиента — но всех. И объяснить это клиенту в доступной форме — в общем-то — нереально — и получается что для данного конкретного клиента мы нарушаем принцип сфокусированности на нем, сохраняя при этом глобальную сфокусированность на заказчике. Это такой, как мне кажется, важный момент в проблеме «фокуса».
2. Митя Башакин, когда рассказывал про модель Кена Бланшара и приводил примеры уровней развития (Неопытный энтузиаст — Разочарованнй новичок — Осторожный эксперт — Профессионал) — в качестве примера рассказывал, как он учил кататься на велике свою дочь. И тоже народ сразу начал обсуждать сам процесс обучения езды на велике, что мальчики учатся так-то, девочки так-то, и что было бы, если бы сперва она каталась на 3-х или 4-х колесном велике — короче, народ зацепился за краевые условия. Я тоже думала — а чем можно пример заменить — и тоже придумала вариант.
   • Во-первых велосипед в проекции на IT — не есть хорошо. Велосипед — это такое нечто очень физическое — сродни тому, что мы учим забивать гвозди или что-то такое — фактически — процесс обучения сводится к получению неких сугубо физических навыков. Поэтому стадии как руководства так и прохода человека по стадиям несколько иные. То есть пример может и визуально понятен — но на IT ложится плохо — ведь мы не учим разработчиков долбить по клавиатуре свободным 10-пальцевым методам, пользоваться код-комплишеном и так далее. Мы пытаемся их учить думать и находить решения. Как мне кажется. 🙂 И аудитория сразу спроецировала велосипед на IT и поняла — что не все гладко — поэтому уехали мы на этом велосипеде немного в сторону.
   • И стала я думать, а что такого более-менее понятного всем можно придумать — того, что было бы связано именно с мыслительной деятельностью. То есть того, где мы как-бы учим — но это нам кажется — мы не можем в реальности держать этот велосипед — как бы нам этого не хотелось. В нашем случае человек реально с самого начала едет сам — мы только соломку стелим. Ну и надумала из той же детской области. Ведь когда мы учим ребенка писать (не читать, читать — это просто и интересно — а писать — это нудно, надо выводить идиотские прописи — и так далее) — мы не можем писать за него. Водить его рукой — нет — это не поможет, его мышцы не окрепнут  — крючочки не станут ровнее. Он должен пройти через все эти крюки-закорюки сам — и любой родитель скажет — сколько это слез и истерик. И тут мы реально имеем все стадии развития и огромную проблему в выборе стиля руководства. Как мне кажется, во всяком случае. Тут тему можно даже развить — ребенок хочет писать слова (разработчик горит желанием проектировать архитектуру) — а должен выводить крючочки (сидит на багфиксе или пишет простые классы, которые потом по 5 раз ему возвращаются с ревью). 🙂
   • Перечитала — тоже, в общем-то крючочки не сильно лучше велосипеда — физическое же действие. Можно попробовать вместо крючочков объяснение задачки — подходов к решению, упрощению — мы с мужем потратили довольно долго времени, объясняя сыну, что чем складывать, умножать/делить или вычитать числа в лоб (особенно большие) — надо посмотреть, может, раскрыть скобки или порядок действий можно изменить так, что это будет сделать гораздо проще и быстрее. И видеть это — реально нельзя научить физически — тут надо что-то чтобы в мозгу перещелкнуло — а где у него кнопка — мы не знаем. 🙂
   • В общем да, найти пример, который наглядно иллюстрирует теорию, да еще и хорошо ложится в предметную область целевой аудитории — нетривиально.