Текущая версия на 17:38, 17 июня 2013

Моя страница на Круге

Общие ощущения от конференции

В целом (на фоне других конференции) организация очень хорошая. Теперь по порядку

Что понравилось

много народу

По сравнению например в 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)

 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) я попросил прислать — отказали).

Цели компании

• SCOPE
• Бюджет
• Время

Персональные цели

• Персональные области для развитие;
• Составление ПЛР (план личностного развития);
• Составление плана развитие — задача самого РП;
  • Руководитель cам анализирует свои проблемные области;
  • Cогласует дальнейшие шаги со своим руководителем (тот следит что бы не было никакой лажи).

Стас Фомин (CustIS). Knowledge Management: от Склада к Потоку

Хотел посмотреть выложенное Стасом видео. То что на сайте SofwarePeople отрубается на 15 минуте, а то что Стас выложил показывается в ужасных кубиках :-(

Станислав Давыдов Мастер-клас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 погружается в технические детали.