2012-11-17: SPMconf-2012 в Минске - день первый
Конференция SPMconf-2012 в Минске - ожидаемо хорошая. Это достаточно сложная конструкция, к хорошему ведь привыкаешь, и оно кажется не столь впечатляющим. Это как с отношениями с клиентами: если ты стабильно оправдываешь его ожидания, то он перестает испытывать тот восторг по этому поводу, который был вначале. Не потому, что стало хуже, а потому что привык. Так вот, с конференциями, которые проводит Влад Орликов - тоже самое, они ожидаемо, привычно хорошие.
На конференции - я выступал, рассказывал о модели командных ролей Белбина. В свое время мне эту книгу посоветовали, я прочел и проникся. Потому что это - качественная экспериментальная работа с командами, наблюдение за ними и выявление соответствия между позициями, которые занимают люди их умственно-психологическими характеристиками, определяемыми по тестам. И этим оно отличается от ряда других моделей, которые основаны больше на некоторой классификации деятельности, после чего заявляется: раз деятельность нужна - пусть ее выполняют. Здесь деятельность поделена и распределена не умозрительно, а на основе научно поставленных экспериментов и наблюдений. И, собственно, мне хотелось рассказать об этом людям, тем более, что модель применима для IT-команд и о ней явно пишет Йордан в "Смертельном марше". Если я вас заинтересовал - смотрите презентацию и доклад, а лучше - первоисточник, книги Белбина "Команды менеджеров. Как объяснить их успех или неудачу" и "Типы ролей в командах менеджеров".
После выступления посмотрел твиттер по своему докладу. Люди пишут заметки, как я на ноуте, только публично, в твите. Может, начать? Хотя резать на короткие сообщения - это очень сложно...
А теперь - обзор докладов первого дня, на которых я был. Начну с тех, которые больше понравились.
Безусловной звездой первого дня, по моему мнению, был Дима Безуглый. Сначала он экспромтом заменил заболевшую Наталью Руколь, прочитав доклад Кто такой менеджер продукта и что он может дать компании-разработчику. Содержание доклада сильно не соответствовало достаточно скучному названию, оно было гораздо шире и описывало роль и ответственность Product Manager и сопутствующие активности, много сопоставляло это с Project Manager'ом. Главное - что в продуктовой разработке классический треугольник Бюджет - Деньги - Сроки - сильно теряет значимость, хотя сами понятия остаются.
Важная мысль о грядущем принципиальном изменении рынка. Времена, когда каждый банк заказывал отдельную систему - давно прошли. Дорого и нерентабельно. Поэтому работу программиста - продает куча народа. Но, рынок мобильных устройств меняет ситуацию, потому что делаешь продукт на 0.5% рынка за 1$ - получаем огромные деньги.
Главный рынок для IT-компании - рынок рабочей силы. Если не найдешь персонал - вылетишь. Раньше разработчики гуляли между заказной (интересно) и внутренней (есть деньги) разработкой, все. А сейчас приходят продуктовые компании. Там хорошо с деньгами и неплохо с интересно. И они ломают рынок кардинально. Единственное, часть продуктовых компаний - они не разрабатывают сами. а заказывают разработку.
А после доклада Дима провел мастер-класс Тонкости проведения не технического интервью технического специалиста. Речь шла об интервью менеджером технического специалиста при приеме на работу. Замечательная смесь практической психологии, психолингвистики, компетенций Спенсера и многого другого в одном докладе. При том, что каждая тема - очень велика. Но Дима дает опорные точки, показвает как работает в комплексе. А если заинтересовало - копайте, изучайте. А еще - рассказывает как правильно нанимать на работу, если планируешь работать с человеком долго. Надо сопрягать базовые ценности - они не изменятся. А скилы - да, они важны, но их можно прокачать. Пересказывать - нереально, читайте, смотрите доклад.
Сергей Архипенков в своем докладе продолжал тему, которая у него звучит в последнее время. Начал он еще во вступительном слове на открытии конференции: "Программирование по ошибке отнесено к инженерной деятельности. У нас нет законов, нельзя доказать правильность. Разработка ПО - гуманитарная дисциплина, поэтому так сложно этим управлять и столько подходов." Я, правда, думаю, что он не прав - потому что так обстоит дело во всех областях, где много проектирования. А программирование - это именно проектирование.
В своем докладе Сергей собрал воедино известные мифы о программировании. В контрастном виде, очередной миф отвергает предыдущий. Правда, мифы - стары, и я лично не знаю, думает ли кто о них всерьез? Но, может, и есть такие динозавры... Но список - любопытен.
- Что разрабатывать просто, миф потому как много фейлов и нет уверенности результата.
- Что сложно. Потому что год поучил Java - и вполне способный программист. Не то, что в космической отрасли.
- Что разработка ПО прохожа на производство. Факт - разработка ПО это только проектирование. Говорит, что статистика по миру по НИР и ОКР примерно соответствует статистике Standish group по успеху программных проектов.
- Разработка ПО - инженерная дисциплина. Факт - гуманитарная. Я: он тут противоречит предыдущему факту. Ну или надо все НИР и НИОКР объявить гуманитарными.
- Говорит, что Коберн (Коуберн?) исследовал корреляцию между успехом проекта и применяемой методологии. Обнаружил, что корреляции нет.
- Миф. Разработку ПО можно ускорить.
- Реально есть формула расчета оптимальной длительности, и сократить можно только на 20% максимум.
- В ответах на вопросы он формулу продиктовал. Длительность проекта в месяцах = 2.5 * корень кубический из трудоемкости в человеко-месяцах.
- Миф. Проблему можно закидать денигами.
- Миф. Проблемы решаются процессом
- Миф. KPI мотивирует
- Миф. Работу программистов нельзя измерить.
- Миф. Незаминимых людей нет. Факт: есть цена замены. Выход нового - 2-12 месяцев. Цена замены порядка годовой зарплаты.
- Миф. Программисты антибюрократичны. Факт - они антиидиотичны.
- Миф о железном треугольнике. Опровергается разработкой Word :)
- Миф: программистами невозможно управлять. Факт - управлять можно, но не как МакДональдсом, а иначе.
Позитив. Правда тоже много известных тезисов.
- Теория W Барри-Боэма. Использовать теорию корпоративных игр с ненулевой суммой. Общение, взаимовыгодный процесс и взаимовыгодный продукт.
- Выбрать правильный продукт - тот что приносит 500% прибыли, а не 10%. Ссылка на Демарко. :) Я: это из серии, что правильный человек сидит на берегу и ждет, когда проплывет труп врага.
- Правильный персонал
- Маслоу в развитии. Первые 4 уровня - дефицитарные потребности, насыщенные на 80% они перестают интересовать. А потом, верхние, самореализация - идут бесконечно.
- Я: впрочем, тут вопрос сложный, есть противоречащие факты. Поэтому приходится объявлять тех, кто после удовлетворения не хочет самореализоваться недочеловеками. Но это сильно противоречит гуманистическим реалиям современного общества.
- Формула E=IQ*EQ*EQ и баян про IQ и EQ
- Эшби, Введение в кибернетику 1959. Для хорошего управления число состояний управляющего объекта должно быть не меньше количества состояний объекта управления. Я: следствие: население (государства), рассматриваемое как объект правления имеет очсень малое количество состояний.
- Цикл Наблюдать - Общаться - Анализировать - Синтезировать - Пробовать - Обобщать Я: сомнительно, если честно, что цикл такой.
Татьяна Белова. Как привести дела в порядок: применение методики GTD для менеджера проекта. Татьяна делилась своим практическим опытом использования GTD - она это делает уже два года, и именно этим доклад ценен. В докладе много вещей, знакомых из книги, но именно практический опыт - главное. И его я тезисно перечислю.
- Многие обламываются на внедрении сразу - не могут свести много своих списков в один. Не надо сразу. Главное - освободить голову от жужжания дел, а то, что в ежедневнике - не жужжит, его можно позднее перенести, работая пока на нескольких списках. Чтобы выписать все дела из головы, достаточно пары часов. Результат вас удивит - у нее получилось около 100 пунктов.
- Потом - сортировка на списки по Аллену и перенес в средство, где будем вести (если выписывали отдельно).
- А дальше - приучаем себя на регулярной основе совершать действия со списками.
- Раз в день, 10-20 минут, просмотреть список и выгрузить лишнее из головы. Она этим занимается в метро, по пути на работу и с работы. Еще иногда внутри дня выгрузку делает.
- Еженедельно - список отложенных и когда-нибудь. Вдруг пора переносить.
- Еще - приучила себя ловить идеи. Задачи - о них напомнят.
- Следующий этап, ТОЛЬКО когда предыдущий пройден, списки - ведутся и с ними работаешь. Тогда делаешь приоритеты, Напоминалки, делить списки по контекстам. У нее контексты конкретного человека - "заодно спросить, уточнить".
Грабли
- Есть грабли - начинаешь беспокоиться о системе дел. Постоянно. Это неправильно.
- Излишняя фокусировка на инструменте. Он должен быть удобным, но не должен брать много мыслей.
- Сложная система связей
- Внедрить сразу
- Два списка Рабочее/Личное
- Невнятная формулировка. Ловушка для тех. кто использует outlook - кидают письмо и не пишут. что по нему надо сделать. Надо писать, не не делают.
В докладе был краткий список инструментов. Она использует Remember The Milk. Плюс задачи из писем в течении дня - в Outlook. Но по концу дня - все переносится в Remember The Milk, послать можно Fwd письма.
Для идей использует EverNote, туда валится все, что хочет запомнить, но оно не является делом. Использует голосовые заметки - с телефона, когда засыпаешь. И фотки - когда увидел в книге - фотку, не переписываешь. Еще - голос с распознаванием, по-русски тоже работает. И можно сохранять документы и web-контекст.
Помимо прочего фиксация дел обеспечивает, что "если вы чего-то не делаете - вы точно знаете, что именно вы не делаете".
Алексей Кривицкий. Новейшая история менеджмента. От эры стагнации к периоду ренессанса. Доклад-объяснение для программистов, откуда вообще берутся менеджеры и почему, а не другие программисты управляют компаниями. Даже если компания выросла из маленькой, созданной программистами. Такая история развития, понятная, но упрощенная, местами сильно. С кейсами управленческих перегибов: "Есть проблема - назначим менеджера по ее решению, или отдел создадим". С афоризмами: "Даже если вы разрабатываете по agile, вам надо разрабатывать софт".
Любопытная моделька по видам управления.
- Поппендик: у каждого работника должно быть два менеджера: Профессор (do things right) и Предприниматель (do rights things).
- Product Owner = Product Manager. do rights things.
- do things right - команда, а для качества возникают менторы по ролевым специализациям (программирование, тестирование)
- А scrum master - это третье, сотрудничество, фасилитатор. Do things fast.
- Нужен баланс между всеми составляющими менеджмента. Если перекос к Предпринимателю - дерьмовый процесс и продукт, если к Профессору - хорошо делаем ненужное. И так далее.
Получился хороший рассказ как работает scrum of scrum и делится ответственность.
Интересно, что специализации менеджеров соответствуют корневым проблемам, как их выделяет Дениэль Пинк в книге Драйв или Мотивация 3.0.
- знание цели - PO
- автономность - SM
- мастерство - Mentor
Ирина Виноградова, Владимир Ли. Планируем релиз играючи. Игры не получилось, речь шла о средстве визуализации на Excel для планирования релизов, написанном под ту митодику, которая применяется в Касперском (оценка фич в разрезе ролей). Средство - хорошее и правильное, но игры - все-таки нет. А форма доклада - хорошая, местами как диалог между Product Manager и Project Manager + Team.
Александр Орлов, Слава Панкратов. Восприятие неконструктивной критики. Мастер-класс в большом зале на сотню с лишним человек. Через работу в парах, реально. Новые кейсы. Уважаю. Хотя Юра Юрченко сказал, что реальный Заказчик его троллил куда жестче, чем на тренинге, там очень интеллигентно было. Ну, не все ж с такими жесткими заказчиками работали.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.