Содержание

1 Общие ощущения от конференции
- 1.1 Что понравилось
- 1.2 Что не понравилось
2 Доклады
- 2.1 1 день
- 2.2 Второй день
3 Встречи
- 3.1 Питер Хрущка

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

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

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

много народу: По сравнению например в 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 и [[RuPedia:ER-модель_данных|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 — расшифровывается как «Прослойка Между» (теми кому чего-то надо и теми кто уже ничего не хочет).

ссылка на презентацию

Сергей Нужненко (Лаборатория Касперского) Техники и подходы к планированию аналитических работ

Ничего не понял. Доклад не структурирован, полон общефилософских категорий и плохо сформулированных идей. В чем основная мысль не понятно. Презентация есть на сайте конференции.

Несвязные тезисы по памяти

Шнурок — шнурок нельзя затолкать снизу (от разработчика), все движение должно быть от заказчика.
ошибки аналитика самые дорогие (Mikle Zaborov 10:56, 23 апреля 2010 (UTC) тоже мне новость) 2 способа бороться:
- внутренняя приемка
- итеративность
Аналитик всегда работает с неопределенностью
тяжело проверить и померить результат работы аналитика
Каналы общения аналитика со всеми остальными (PM, Заказчик, Разработчкик) должны быть доступными
Качество моделей, которые строит аналитик состоит из 2ух частей:
- полнота
- непротиворечивость
- Mikle Zaborov 10:56, 23 апреля 2010 (UTC)А как же адекватность предметной области и задач?
проверять качество можно только трассировкой
Фундамент аналитика:
- должен владеть
  - формальной логикой
  - принципов классификации
- системным подходом (ЛПР, стратификации, состав, иерархия, структура)
- Модели/категории
  - модель сущность-связь
  - сущность/явление
- Кроме того, аналитик должен понимать
  - контекст (истина относительна).
  - понятие границы (объектов не существует).

Второй день

Сурен Самарчан (Innova). Типичный день эффективного лидера

95% менеджеров не знают, чем заниматься в течении дня

Не понятно причем тут распорядок дня менеджера. но доклад очень позитивен, по полочкам разложено, то, что и так (по крайней мере, мне) было понятно. Готов подписаться почти подо всем сказанным. То что рассказывал Сурен, несколько отличается от того, что написано в презентации, поэтому привожу здесь тезисы, которые успел записать:

Основные активности руководителя :

1. Усиление команды

Поиск лучших/увольнение худших/обучение/повышение в сотрудниках уверенности в себе и самокритичности;
Компания растет быстрее чем люди (пример Dell);
Непродуктивные люди это не 0, это минус (от них нужно избавляться как можно скорее).

Лидеры команд (и не только) должны обладать следующими качествами:

У них есть Vision;
Бесконечный оптимизм;
Самокритичность.

Используйте любое событие, чтобы обучать людей. Пример — Парный менеджмент (аналог парного программирования):

следить за менеджером и записывать его косяки;
решить совместно задачу (размышлять вслух);
разложить задачу на серию простых шагов.

Сессии критики (руководитель критикует сотрудника, потом коллеги, потом сам себя)

Mikle Zaborov 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. Выбрать Лидера

«настоящих буйных мало вот и нету вожаков» (с) Высоцкий

Навыки управленца
Лидерство

Садовник

Лидера нельзя назначить — он должен получить признание:

как профессионала (Признание)
как управленца (Доверие)

Признание	Доверие	стиль управления
нет	нет	Директивное управлении
да	нет	Объяснения
нет	да	Участие
да	да	Делегирование

Mikle Zaborov 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 эту проблему решает частично (решает, пока сотруднику не надоела вся область).

Mikle Zaborov 20:51, 5 мая 2010 (UTC) Наверное было бы интересно и у нас что-то такое попробовать

Нет ОС снизу вверх: Большой разрыв. Руководство не слышит ОС от сотрудников с низов. Иногда нужно рвать уровни иерархии. Директор должен периодически общаться с техническими сотрудниками.
Ретроспективы: Нужно проводить личные ретроспективы (анализ своей деятельности постфактум).

Интересные цитаты:

«проблемы менеджера, не в том, что люди смертны, а в том, что люди внезапно смертны»
«Надеяться, что HR замотивирует ваших сотрудников — тоже самое, что надеяться на то, что соседи воспитают ваших детей».

Олег Ридченко (Intetics). Обучение, развитие и оценка руководителей проектов в IT компании

Достаточно уныло и занудно… Пример механистического отношения к управлению персонала (Ужас!! Ужас!!). Это то куда нам ни в коем случае не нужно свалиться

процесс обучения и оценки руководителей проектов.
Intetics (250 человек 2 города Минск и Харьков. 13 руководителей проекта. 3 Года уже работает)

Проблемы

управление индивидуальной деятельностью сотрудников (синхронизации векторов развития сотрудника и компании):
- повышение мотивации;
- определение ценности;
- повышение ценности сотрудника для компании;
для РМ:
- нет измеримых критериев оценки;
- не понятно кто оценивает.

Пробовали 360 review. Не получилось:

потому, что дорого.
неэффективно (народ относится поверхностно).

Система управления индивидуальной деятельностью

Состоит из 4ех частей (Mikle Zaborov 21:00, 5 мая 2010 (UTC) странные какие-то части… ну да ладно):

Система компетенций.
Цели компании.
Персональные цели.
Оценка руководителей.

+ Система автоматизации всего этого добра на Sharepoint.

Система компетенций

17 компетенций (описание навыков и критерии соответствия).
2 IT специфичные — остальные общеуправленческие.
у каждой компетенцию с весом (общая сумма 100).
значение каждой от 0..1
Оценки ставит сам руководитель и его начальник.
Компетенции откуда-то тырили (Mikle Zaborov 20:54, 5 мая 2010 (UTC) я попросил прислать — отказали).

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

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

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

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

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

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

Стас Фомин 09:29, 6 мая 2010 (UTC): нашел где смотреть. Им я уже написал. В вебе мог бы посмотреть тут или тут, или поставь себе нормальный кодек пак. XPCodecPack 2.5.1, например)

.

Станислав Давыдов Мастер-класc: Разрешение конфликтов и налаживание обратной связи в командах

В начале была странная игра с разрешением конфликта в группе.

придумали 5 конфликтных ситуаций (типа менеджеры заставляют программистов тестировать);
посадили всех в кружки (человек по 10) и сказали: «а теперь решайте конфликт»;
…
PROFIT!

Mikle Zaborov 21:03, 5 мая 2010 (UTC) :-(. Все больше убеждаюсь, что такие мастер-классы на конференциях — это какая-то странная попытка развлечь аудиторию.

Далее Станислав предложил методику мотивационных анкет (простая и достаточно интересная):

выбираются мотивационные факторы (зарплата, технологии, рабочее место, гибкий график и т. д.)
для каждого фактора ставится 2 оценки (от 1 до 4) — важность и удовлетворенность.

А вот дальше странно:

Это информация складывается и выкладывается публично.
команда обсуждает результаты оценки.

Mikle Zaborov 21:03, 5 мая 2010 (UTC) Первые 2 пункта я бы у нас попробовал…

В конце он рассказывал ОЧЕНЬ странный кейс который от с помощью этой методики решал (и до конца так вроде как не решил): «Тупой быдлокодер, пишуший говнокод, пахнущий грязными носками, которого нельзя уволить». В результате методики удалось полечить только проблему носков …

Встречи

Питер Хрущка

Естественно, я не мог оставить без внимания заявление Питера по поводу того, что нельзя совмещать PM и SA. Решил замучать его в перерыве, в результате мы общались во время доклада Анджея Аршавского. Получил от Питера следующие разъяснения:

Теоретически допустима ситуация, когда руководитель проекта выполняет функции архитектора (руководитель типа «Атлант»). Но только на небольших командах и это совсем не масштабируемо.
PM должен мыслить в краткосрочных терминах (сдать проект в нужные сроки за нужные деньги).
SA в долгосрочных (архитектура должна быть устойчивой, надежной и т. д.).
Бесконечный рефакторинг — это плохо (Стратегия Nothing in Advance работает плохо, как впрочем и любой другой экстремизм).
Распределение ответственности между ролями выглядит так:

Архитектуру приложения на самом деле создает и PO и SA. Питер считает, что в любой архитектуре есть бизнесовое ядро (20-30%), в котором нет технических деталей, и которое, в идеале, PO проектирует вместе с заказчиком, а SA его верифицирует и дополняет техническими подробностями. Бывают случаи когда PO не в состоянии спроектировать ядро архитектуры и тогда это приходится делать SA.

Пообсуждали этот вопрос с Игорем Беспальчуком. Поняли, что в таких терминах мы вполне можем с ним договориться (а у нас на эту тему давно идут дискуссии) и весь вопрос заключается в том — насколько сильно PO погружается в технические детали.

Репликация: База Знаний «Заказных Информ Систем» → «SoftwarePeople-2010:Отчет Заборова М.А.»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Персональные инструменты

Просмотры

SoftwarePeople-2010:Отчет Заборова М.А.

Материал из CustisWiki