Моя страница на Круге
Общие ощущения от конференции
В целом (на фоне других конференции) организация очень хорошая. Теперь по порядку
Что понравилось
- много народу
- По сравнению например в ArchLabs. Похоже народ не теряет интерес к этим конференциям
- народ новый
- Обычно на уже на третей подряд конференции — одни и те же лица и доклады про одно и то же. А в этот раз почти все люди новые (только несколько знакомых докладчиков). — Наверное я давно на конференции не ходил…
- WiFi
- Очень хорошо что был. В периодах, где были не интересные(для меня) доклады, удавалось поработать. Основную часть отчета написал на конференции :-), что сэкономило кучу времени. Единственная неприятность, что wifi периодически падал :-((. Обычно это совпадало с попытками Web трансляций кого-нить из Microsoft (например Дона Сайма).
- качество докладов
- В общем очень приличное. Было 2-3 доклада ради которых стоило сходить на конференцию, хотя, конечно, были и проходные доклады.
- очень мало организационных накладок
- В отличии например от SEC(R), доклады проходили по расписанию. Timeline выдерживался. Замен практически не было (Только Дон Смит).
- обед сидя
- Огромный кармический плюс организаторам за большой холл и столы. В кои то веки за обедом (а также на а кофе-брейках и других перерывах) можно было по-человечески посидеть и пообщаться.
- таблички с докладчиками на обеде
- Организаторы придумали фишку — ставить на столы таблички с именем докладчика, что бы посетители могли выбирать с кем сидеть на обеде. Идея наверное хорошая, но реализация получилась так себе (Многие докладчики на таблички забили), а те что не забили, были не очень разговорчивые.
- web трансляция
- Вроде как была неплохая вебтрансляция. Иногда доходило до смешного — сидя в холле с кофе народ смотрел, через wifi что происходит за соседней дверью (сам так делал ^-^).
Что не понравилось
- Электрические розетки
- В связи с появлением wifi, самым критичным ресурсом стало электричество. Розеток было очень мало... подкормить
своего питомца свой laptop можно было только отняв розетку у аппарата подогрева кофе.
- SPAM доклады
- Завели совершенно дурацкую практику докладов во время кофе-брейков (например Qiwi, Softline). Выглядело это как группа заезжих коммивояжеров, тщетно пытающихся привлечь внимание отдыхающих... Вещи рассказывали достаточно банальные и спокойно общаться не давали… В общем, сильно раздражало.
- Выложенное Видео
- Очень с одной строны удобно.. Начал посмотреть видео Стаса (прослушал классическую часть про SVN+Wiki+Bugzills). Неудобно, что не получается дать ссылку на видео и презентации. Так же, на 15 минуте видео оборвалось. А воспроизвести с произвольного места не получается. :-(. Попробовал второй раз в IE — тот же эффект.
- Кондиционеры
- На втором треке были адски злые кондиционеры которые дули прямо в спину.. 3 раза просил организаторов и докладчиков отключить — обещали сделать — так и не сделали. Больше не ходил на второй трек и два дня ел арбидол. Огромный кармический минус организаторам..
- Бубнеж синхронистов
- Качество синхронного перевода, как всегда, не очень высокое (можно например посмотреть видео доклада Питера Хрущки для то, что бы понять качество). Мало того, синхронисты находились в том же помещении, что и докладчик и слушатели, и своим бубнежом отвлекали тех, кому перевод не требовался.
- Fail доклада Дона Смита
- В связи с облаком вулканической пыли благородные Доны (Смит и Сайм) не долетели до конференции... Дона Сайма показывали через Web (Не очень ИМХО удачное решение). А Дона Смита даже не показали. Но наверное неправильно тут в чем-то упрекать организаторов.
- Пивная вечеринка — «Soft Party» — полный отстой
- Пиво в банках, хреновое, и всем не хватило (еды вообще хватало не всем), закуски никакой. Лучше бы не позорились и не анонсировали его и не проводили совсем.
Доклады
1 день
Питер Хрущка (Atlantic Systems Guild). An Agile Mindset
Народ упорно называл его Хрюшка :-). Представляет Atlantic Systems Guild — это сообщество старых пердунов гуру программирования (состав смотри здесь), которые делятся опытом и пишут книги. Из всех я знаю только Toma Demarco.
Очень интересный доклад, в котором он затрагивал актуальную для нас тему: Роли которые управляют Agile-проектом. После доклада еще минут 15 продуктивно общался в холле. Говорил разумно, вообще чувствуется в Питер в теме..
Основные тезисы, которые мне запомнились:
Эволюция методов разработки
Зачем-то привел свою теорию методов разработки.
Началось все со Структурного програмирования (Structured Methods), которые подарили нам такие замечательные вещи как DFD и ER-диаграммы, и вообще научили вначале продумывать архитектуру приложения, а потом уже кодировать.
Потом появилось OOП (Которые нам принесли Буч, Йордан (? почему он) и еще какой-то народ, которые нам дали Объектно-ориентированный анализ и проектирование
а потом достаточно стандартные «бла-бла» про Agile который пришел на смену (Манифест и так далее).
Самое главная мысль в этом месте, что следующий этап не отменяет достижений предыдущего.
В этом смысле Agile не отменяет хороший предварительный дизайн приложения (и вообще идеи «не проектировать на будущее» и «постоянный рефакторинг» — глубоко чужды Питеру).
Роли в Agile
Интересно, как Питер определяет основные роли (Must Have in Agile):
- Product Owner (PO)
- ответственный за требования. PO=Business Analyst=Requirements Engineering.
- Обычно эту роль исполняет:
- Руководитель проекта
- Заказчик
- Маркетинг
- Software Architect (SA)
- Ответственный за решение. Это может быть:
- TechLead
- Boss of the Developers
- Lead Programmer
- Это человека, который:
- разговаривает с заказчиком
- «продает» архитектуру
- наблюдает (Supervise) за разработчиками.
- Основные скиллы:
- Анализ
- Проектирование
- Коммуникации
- Project Manager (PM)
- ответственный за проект. Он же Agile Leader.
- Человек который:
- Следит за тем что все, что нужно сделано (Done).
- Практикует эндшпили (убирает критические проблемы и принимает критические решения, для того, чтобы сдать релиз к сроку).
- Обеспечивает периоды стабильности для команды, которые чередуются периодами, в которых можно менять Scope (Seasons of Change).
- Занимается людьми (Peopleware).
- Мониторит риски проекта.
Питер считает, что никогда нельзя совмещать SA и PO. Естественно, этот вопрос я не мог оставить без внимания и замучал его в перерыве.
Интересно, что Scrum-Master это еще какая-то другая роль, про которую он не сказал, а на прямой вопрос ответил уклончиво.
Agile Requirements
Рассказал Питер и про то, что такое Agile Requirements.
- Рассказал то, что мы называем «Методом набегающей волны» (подробно прорабатываем только те требования, которые собираемся делать в ближайшее время, а остальное прорабатываем в крупном).
- Есть 2 способа снятия требований — поверхностный (snorkeling) и глубокий (scuba diving).
- Все время нужно отслеживать Scope (по аналогии с большим теннисом: Whiteline — граница проекта)
- Формировать требования нужно в партнерстве с заказчиком (co-education)..
Анжей Аршавский (IBM). Програмное обеспечение для разумной планеты
- Очередной «вендорский доклад» от IBM.
- Не пошел слушать (чему очень рад). Вместо этого общался с Питером Хрущка.
- Народ непрерывно уходил с доклада.
- Когда дошло до Jazz-a не выдержал и Игорь Беспальчук (и мы с ним успели обсудить доклад Хрушки).
Дон Сайм(Microsof). F# -функциональное программирование становится трендом
- На F# не пошел… Читал почту, писал отчет..
- Зашел уже в момент, когда Дон отвечал на вопросы. Оказывается, это была телеконференция. Дон вещал удаленно (наверное именно поэтому падал WiFi). Качество звука достаточно приличное. Картинка с изображением докладчика подтормаживала.
Дон Смит (P&P Team Microsoft). Разрешение конфликтов разработки
- Fail — Доклада не было (из-за проблем со связью).
- Вместо него был Дмитрий Сошников программирование игр на платформе XNE.. опять не пошел :-(
Дмитрий Безуглый. Кто такой менеджер продукта и что он может дать разработчику?
Забавный доклад на тему «продуктовая разработка vs. заказная разработка». В общем ничего нового, но есть провокационные и весьма спорные утверждения (наверное это что-то личное от докладчика):
- Сейчас идет движение от заказной разработки к продуктовой (все хотят делать продукт).
- Зарплата разработчиков в продуктовой разработке выше, чем в заказной.
- Вначале нужно поработать в большой Аутсорсинговой компании, а потом уходить в продуктовую.
- В продуктовой компании используют более новые (и рисковые) технологии, что бы обеспечить себе конкурентное преимущество (см график).
s-curve:
- Research & Development в заказной разработке r&D (больше Development-a меньше Research-а), а в продуктовой R&d.
Все это сомнительно и ОЧЕНЬ спорно…
Еще интересные и забавные мысли :
- Заказную разработку сложно продать (ее сравнивают с готовыми продуктами).
- PM — расшифровывается как «Прослойка Между» (теми кому чего-то надо и теми кто уже ничего не хочет).
Сергей Нужненко (Лаборатория Касперского) Техники и подходы к планированию аналитических работ
Ничего не понял. Доклад не структурирован, полон общефилософских категорий и плохо сформулированных идей. В чем основная мысль не понятно. Презентация есть на сайте конференции.
Несвязные тезисы по памяти
- Шнурок — шнурок нельзя затолкать снизу (от разработчика), все движение должно быть от заказчика.
- ошибки аналитика самые дорогие (MikhailZaborov 10:56, 23 апреля 2010 (UTC) тоже мне новость) 2 способа бороться:
- внутренняя приемка
- итеративность
- Аналитик всегда работает с неопределенностью
- тяжело проверить и померить результат работы аналитика
- Каналы общения аналитика со всеми остальными (PM, Заказчик, Разработчкик) должны быть доступными
- Качество моделей, которые строит аналитик состоит из 2ух частей:
- полнота
- непротиворечивость
- MikhailZaborov 10:56, 23 апреля 2010 (UTC)А как же адекватность предметной области и задач?
- проверять качество можно только трассировкой
- Фундамент аналитика:
- должен владеть
- формальной логикой
- принципов классификации
- системным подходом (ЛПР, стратификации, состав, иерархия, структура)
- Модели/категории
- модель сущность-связь
- сущность/явление
- Кроме того, аналитик должен понимать
- контекст (истина относительна).
- понятие границы (объектов не существует).
Второй день
Сурен Самарчан (Innova). Типичный день эффективного лидера
- 95% менеджеров не знают, чем заниматься в течении дня
Не понятно причем тут распорядок дня менеджера. но доклад очень позитивен,
по полочкам разложено, то, что и так (по крайней мере, мне) было понятно.
Готов подписаться почти подо всем сказанным.
То что рассказывал Сурен, несколько отличается от того, что написано в презентации, поэтому привожу здесь тезисы, которые успел записать:
Основные активности руководителя :
1. Усиление команды
- Поиск лучших/увольнение худших/обучение/повышение в сотрудниках уверенности в себе и самокритичности;
- Компания растет быстрее чем люди (пример Dell);
- Непродуктивные люди это не 0, это минус (от них нужно избавляться как можно скорее).
Лидеры команд (и не только) должны обладать следующими качествами:
- У них есть Vision;
- Бесконечный оптимизм;
- Самокритичность.
Используйте любое событие, чтобы обучать людей. Пример — Парный менеджмент (аналог парного программирования):
- следить за менеджером и записывать его косяки;
- решить совместно задачу (размышлять вслух);
- разложить задачу на серию простых шагов.
Сессии критики (руководитель критикует сотрудника, потом коллеги, потом сам себя)
- MikhailZaborov 06:22, 23 апреля 2010 (UTC) Хорошо, если самооценка сотрудника при этом не упадет ниже плинтуса.
Самостоятельность
- Лидер уходит -> команда работает.
- все понятные команде работы должна делать команда.
Энергия
- Лидер передает собственную энергетику команде.
- Харизма — критично важна (человек без харизмы будет убеждать месяцами сделать то, что харизматичный лидер стимулирует за 1 минуту).
- Лидер передает энергетику личным примером.
- Работает больше всех.
- Не устает (не показывает усталость).
- не жалуется, не унывает, не паникует.
- Какой лидер, такая и команда.
- Проактивно относится к инициативе.
- Доступен для сотрудников.
- Искренне ждет результатов от сотрудников.
Атмосфера
Лидер создает атмосферу уверенности которая состоит из:
на 80 %
- Искренность (что думают то и говорят).
- Ответственность (что говорят то и делают).
на 20 %
- Непоколебимые принципы компании.
Кроме того:
- не присваивайте чужих достижений;
- реагируете на деструктивные высказывания;
- чувствуйте гордость за компанию.
Вопросы
- интересуйтесь работой людей;
- люди чувствуют ваше присутствие;
- разберитесь хотя бы с одним вопросом детально;
- записывайте вопрос(задачу) который вы задали и проверяйте что ответ(решение) получено.
Правила игры
- нужно создавать правила игры;
- все правила существуют только в контексте;
- правил которым нужно следовать на 100 % не существуют (очень мало);
- структура управления должна быть максимально плоской.
Преграды
- Нужно видеть большую картинку.
- Все нужно упрощать.
- Не терять энтузиазм по каждой мелочи (будет много неудач).
Думать о будущем
- Даже если пожар, нужно думать о будущем.
Кроме того Сурену были заданы вопросы. В частности обсуждалась мотивация сотрудников
(работа за деньги/ на результат, work/life balance). Примеры и вопросов и ответы на них хорошо описаны у Игоря Беспальчука
Сергей Архипенков. Технология командообразования
Очередной доклад Архипенкова про команды.
Начал за здравие, но в конце начал нести какую-то муть.. и на вопросы отвечал тоже очень странно.
Но народу видимо очень понравилось — Сергея не отпускали 30 минут, и заняли время кофебрейка.
Что такое команда
- общие цели и ценности;
- взаимное доверие;
- неформальные горизонтальные коммуникации;
- коллективная ответственность.
команда и группа — не одно и тоже:
- команде цели нужно ставить только в общем виде (взять Эверест).
Как собирать команду 3 шага
Шаг 1. правильные люди
E=IQ x EQ^2
IQ - Интелект
EQ - Эмоциональный интеллект
EQ = Осознание чего хочет+ Воля воплотить + Эмпатия
- проактивность (чаще всего делают не то, что хочет)
- командный игрок
Шаг 2. Выбрать Лидера
«настоящих буйных мало вот и нету вожаков» (с) Высоцкий
- Навыки управленца
- Лидерство
Лидера нельзя назначить — он должен получить признание:
- как профессионала (Признание)
- как управленца (Доверие)
| Признание |
Доверие |
стиль управления
|
| нет |
нет |
Директивное управлении
|
| да |
нет |
Объяснения
|
| нет |
да |
Участие
|
| да |
да |
Делегирование
|
- MikhailZaborov 07:05, 23 апреля 2010 (UTC) Крайне сомнительная и спорная табличка
- руководитель должен быть частью команды.
- Не ждите от команды вовлеченности больше, чем у лидера.
Шаг 3. Точим пилу
Опять начал про 4П и какую-то муть про управление процессом :-(
Стендовый доклад Дмитрий Лайер (Softline), Борис Вольфсон (Softline) Agile MixFight по правилу Win-Win
Очередной SPAM доклад в время кофе-брейка. Попытка привести аналогии между SCRUM в разработке ПО с принципами игры Регби.
В начале привлекли внимания в виде веселого видеоролика.
Ролик забавный, но мысли там достаточно поверхностные (фрагменты из игры регби чередовались с прыгающими и
кривляющимися у SCRUM доски разработчиками).
Т.е дальше мысли о том что и в Регби и в Agile должен присутствовать кураж не пошло…
Далее последовала очень нудная история о внедрении SCRUM в Softline.
Александр Орлов (Happy-PM.ru) 10 проблем обратной связи
Очень хороший и бодрый доклад про проблемы с обратной связью.. Не могу сказать что список проблем полон, но про то что рассказал все очень хорошо и по делу
Провел аналогию между управление проектами и нелинейными шахматами:
- Конь демотивирован и теперь ходит на 1 клетку.
- Ладья уходит в декрет.
- Ферзь увольняется.
Типовая ситуация с обратная связью в компании
- ее нет
- есть, но такая
- есть, но не туда
- есть, но не про то..
- есть, но не от туда…
- есть, но не та
- … и т. д.
Далее Александр описал 10 (по его мнению типовых) проблем с обратной связью:
- Отсутствие обратной связи разработчикам от пользователей
- Разработчикам важно знать для кого он работает. Нужно понимать что от его действий что-то в мире изменилось (стало больше добра…).
- Нет общения руководителя с сотрудником 1 на 1
- 65 % времени нужно уделять внимание на такое общение. Общение с командой не заменяет общения 1 на 1. Когда сотрудники не получают такого общения — они чувствуют себя брошенными.
- Нет конструктивной (ругань) обратной связи
- Нельзя только хвалить — нужно ругать.
- Менеджеры не говорят спасибо
- тут вроде все понятно.
- Руководитель дает публичную конструктивную обратную связь
- Руководитель рвет подчиненного публично (синдром учительницы). Общеизвестный принцип — хвалить нужно публично, ругать лично.
- Руководитель переходит на личность
- Принцип сэндвича: Похвалил/поругал/похвалил.
- Обсуждается процесс, а не результат
- «Результата нет, а он еще на bash.org сидит». — Не надо бороться с процессом (закрывать сайты, отслеживать посещаемость и т. д.) нужно требовать результат.
- Нет ОС от сотрудников к менеджеру
- Есть несколько вещей удерживающих людей там, где они суперкомпетентны, но им не интересно — это з/п, ипотека, …, и менеджер. Нужно получать обратную связь от сотрудников по поводу того как они относятся к тому, чем они занимаются. В некоторых компаниях вводили процедуру оценки сотрудником задачи (интересно/не интересно/тошнит). Agile эту проблему решает частично (решает, пока сотруднику не надоела вся область).
MikhailZaborov 20:51, 5 мая 2010 (UTC) Наверное было бы интересно и у нас что-то такое попробовать
- Нет ОС снизу вверх
- Большой разрыв. Руководство не слышит ОС от сотрудников с низов. Иногда нужно рвать уровни иерархии. Директор должен периодически общаться с техническими сотрудниками.
- Ретроспективы
- Нужно проводить личные ретроспективы (анализ своей деятельности постфактум).
Интересные цитаты:
- «проблемы менеджера, не в том, что люди смертны, а в том, что люди внезапно смертны»
- «Надеяться, что HR замотивирует ваших сотрудников — тоже самое, что надеяться на то, что соседи воспитают ваших детей».
Олег Ридченко (Intetics). Обучение, развитие и оценка руководителей проектов в IT компании
Достаточно уныло и занудно… Пример механистического отношения к управлению персонала (Ужас!! Ужас!!). Это то куда нам ни в коем случае не нужно свалиться
- процесс обучения и оценки руководителей проектов.
- Intetics (250 человек 2 города Минск и Харьков. 13 руководителей проекта. 3 Года уже работает)
Проблемы
- управление индивидуальной деятельностью сотрудников (синхронизации векторов развития сотрудника и компании):
- повышение мотивации;
- определение ценности;
- повышение ценности сотрудника для компании;
- для РМ:
- нет измеримых критериев оценки;
- не понятно кто оценивает.
Пробовали 360 review. Не получилось:
- потому, что дорого.
- неэффективно (народ относится поверхностно).
Система управления индивидуальной деятельностью
Состоит из 4ех частей (MikhailZaborov 21:00, 5 мая 2010 (UTC) странные какие-то части… ну да ладно):
- Система компетенций.
- Цели компании.
- Персональные цели.
- Оценка руководителей.
+ Система автоматизации всего этого добра на Sharepoint.
Система компетенций
- 17 компетенций (описание навыков и критерии соответствия).
- 2 IT специфичные — остальные общеуправленческие.
- у каждой компетенцию с весом (общая сумма 100).
- значение каждой от 0..1
- Оценки ставит сам руководитель и его начальник.
- Компетенции откуда-то тырили (MikhailZaborov 20:54, 5 мая 2010 (UTC) я попросил прислать — отказали).
Цели компании
Персональные цели
- Персональные области для развитие;
- Составление ПЛР (план личностного развития);
- Составление плана развитие — задача самого РП;
- Руководитель cам анализирует свои проблемные области;
- Cогласует дальнейшие шаги со своим руководителем (тот следит что бы не было никакой лажи).
Стас Фомин (CustIS). Knowledge Management: от Склада к Потоку
Хотел посмотреть выложенное Стасом видео. То что на сайте SofwarePeople отрубается на 15 минуте, а то что Стас выложил показывается в ужасных кубиках :-(
Стас Фомин 09:29, 6 мая 2010 (UTC): нашел где смотреть. Им я уже написал. В вебе мог бы посмотреть
тут или
тут, или поставь себе нормальный кодек пак. XPCodecPack 2.5.1, например)
.
Станислав Давыдов Мастер-класc: Разрешение конфликтов и налаживание обратной связи в командах
В начале была странная игра с разрешением конфликта в группе.
- придумали 5 конфликтных ситуаций (типа менеджеры заставляют программистов тестировать);
- посадили всех в кружки (человек по 10) и сказали: «а теперь решайте конфликт»;
- …
- PROFIT!
- MikhailZaborov 21:03, 5 мая 2010 (UTC) :-(. Все больше убеждаюсь, что такие мастер-классы на конференциях — это какая-то странная попытка развлечь аудиторию.
Далее Станислав предложил методику мотивационных анкет (простая и достаточно интересная):
- выбираются мотивационные факторы (зарплата, технологии, рабочее место, гибкий график и т. д.)
- для каждого фактора ставится 2 оценки (от 1 до 4) — важность и удовлетворенность.
А вот дальше странно:
- Это информация складывается и выкладывается публично.
- команда обсуждает результаты оценки.
- MikhailZaborov 21:03, 5 мая 2010 (UTC) Первые 2 пункта я бы у нас попробовал…
В конце он рассказывал ОЧЕНЬ странный кейс который от с помощью этой методики решал (и до конца так вроде как не решил): «Тупой быдлокодер, пишуший говнокод, пахнущий грязными носками, которого нельзя уволить». В результате методики удалось полечить только проблему носков …
Встречи
Питер Хрущка
Естественно, я не мог оставить без внимания заявление Питера по поводу того, что нельзя совмещать PM и SA. Решил замучать его в перерыве, в результате мы общались во время доклада Анджея Аршавского. Получил от Питера следующие разъяснения:
- Теоретически допустима ситуация, когда руководитель проекта выполняет функции архитектора (руководитель типа «Атлант»). Но только на небольших командах и это совсем не масштабируемо.
- PM должен мыслить в краткосрочных терминах (сдать проект в нужные сроки за нужные деньги).
- SA в долгосрочных (архитектура должна быть устойчивой, надежной и т. д.).
- Бесконечный рефакторинг — это плохо (Стратегия Nothing in Advance работает плохо, как впрочем и любой другой экстремизм).
- Распределение ответственности между ролями выглядит так:
- Архитектуру приложения на самом деле создает и PO и SA. Питер считает, что в любой архитектуре есть бизнесовое ядро (20-30%), в котором нет технических деталей, и которое, в идеале, PO проектирует вместе с заказчиком, а SA его верифицирует и дополняет техническими подробностями. Бывают случаи когда PO не в состоянии спроектировать ядро архитектуры и тогда это приходится делать SA.
Пообсуждали этот вопрос с Игорем Беспальчуком. Поняли, что в таких терминах мы вполне можем с ним договориться (а у нас на эту тему давно идут дискуссии) и весь вопрос заключается в том — насколько сильно PO погружается в технические детали.
