7078
правок
Изменения
м
Нет описания правки
{{Conf-Ref}}
Конференция [http://it-conf.ru/ru/content/544.htm 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.
'''Александр Орлов, Слава Панкратов. Восприятие неконструктивной критики'''. Мастер-класс в большом зале на сотню с лишним человек. Через работу в парах, реально. Новые кейсы. Уважаю. Хотя Юра Юрченко сказал, что реальный Заказчик его троллил куда жестче, чем на тренинге, там очень интеллигентно было. Ну, не все ж с такими жесткими заказчиками работали.
{{wl-publish: 2012-11-17 02:57:25 +0400 | MaksTsepkov }}
Конференция [http://it-conf.ru/ru/content/544.htm 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.
'''Александр Орлов, Слава Панкратов. Восприятие неконструктивной критики'''. Мастер-класс в большом зале на сотню с лишним человек. Через работу в парах, реально. Новые кейсы. Уважаю. Хотя Юра Юрченко сказал, что реальный Заказчик его троллил куда жестче, чем на тренинге, там очень интеллигентно было. Ну, не все ж с такими жесткими заказчиками работали.
{{wl-publish: 2012-11-17 02:57:25 +0400 | MaksTsepkov }}