Сайт мероприятия: http://softwarepeople.ru/sp2010/; там все написано…

Конференция проходила в выставочном центре «ИнфоПространство» на Кропоткинской. Я там раньше не был. В общем, все неплохо. Кормили хорошо, только вместо печенек к чаю были странные микро-пирожные. Большой зал оборудован не очень удобно — колонны мешаются. Позже узнал, что залы там все — трансформеры, все стены двигаются, получается нужная в моменте площадь. Но колонны все равно мешались.

Среди раздаточных материалов — в основном реклама. Ну, еще блокнотик, ручка, визитница. Из любопытного в рекламе — Microsoft предлагает по подписке услугу технической консультации на любом этапе проекта, от мозгового штурма и выбора вариантов архитектуры до кодирования и внедрения.

После заполнения анкеты подарили лицензию на Norton Antivirus и специальное («не для продажи») бумажное издание книжки про архитектуру от Microsoft, о которой я как раз недавно писал в блоге.

Народу на конференции было довольно много (если не сравнивать с РИТ’ом, конечно), большинство — молодые люди, 20-30 лет. Впрочем, сама конференция тоже молодая, проводится всего во второй раз.

UPD:На сайте конференции выложили презентации и видео-записи докладов, рекомендую проглядеть, есть действительно любопытные. Видео, правда, только из большого зала (первого трека).

Стас Фомин 16:16, 20 мая 2010 (UTC): Будет видео из всех залов

День 1. 22 апреля

На торжественное открытие я опоздал, застал только последние минуты три, но, по всей видимости, ничего ценного не потерял. Организаторы сообщили, что пара приглашенных гуру (Дон Сайм и Дон Смит) не смогли прилететь из-за извержения вулкана Эйяфьятлайокудль. Собирались организовать видео-трансляцию докладов. Забегая вперед, отмечу, что с Доном Саймом это кое-как получилось, а с Доном Смитом — почему-то никак не получилось, его два доклада отменили.

Вообще, в первый день было довольно скучно, позитивное явление было одно — Питер Хрущка. Поэтому про него расскажу наиболее подробно.

10:00. Питер Хрущка. An Agile Mindset (Гибкое мировоззрение)

Докладчик с забавной фамилией (Питер Хрущка, Peter Hruschka). Организаторы почему-то упорно произносили его фамилию совсем потешно: «Питер Хрюшка». Или, быть может, она так и произносится, просто решили на письме избежать неблагозвучности? Ну, не суть важно. А важно, что Питер — эксперт мирового масштаба, в отрасли с 70-х годов, учредитель Atlantic Systems Guild, международно известной группы экспертов, в которую входят, в частности, Том ДеМарко и Тим Листер. Вторую часть фразы я откуда-то свиснул, в общем, в сети про него есть. По-русски можно почитать тут, а по-английски, и более полно — тут.

Очень позитивный дядька. Мне понравился его английский. Он немец, и, возможно, поэтому все слова тщательно артикулирует, чего мне обычно и не хватает для понимания со слуха, когда говорят американцы.

Немножко рассказал про свою группу экспертов (Atlantic Systems Guild), которая почти как распределенная команда — кто-то живет к востоку от Атлантики, кто-то — к западу. Консультируют они, в общем.

Питер начал доклад с того, что повспоминал, как менялась индустрия разработки ПО с 70х годов 20го века до сегодняшних дней. Выделил три перехлестывающихся периода. Сперва всё «структурировали», потом начали всё «объектно ориентировать», а последнее время с техникой как-то подразобрались, и начали разбираться с людьми, которые это все делают. Это Peopleware и всякий Agile. Эта волна в Штатах началась в конце 80-х (!), а сейчас мы переживаем пик интереса к этой теме, по мнению Питера. Что будет дальше — неизвестно :)

Надо сказать, что Питер не сторонник экстремистских подходов типа буквального следования XP («Единственный стоящий продукт работы — это код!!!»). Более того, он уверяет, что сам Кент Бек — тоже не сторонник :) Во всем нужна мера, а еще важнее — адекватность. Практики и процессы должны быть адекватны ситуации. Если бы Питера попросили добавить еще один пункт к ценностям Agile, он бы добавил «Adequate over extreme».

Основная часть доклада была посвящена рассмотрению трех ключевых ролей, которые, по мнению Питера, должны быть как-то обозначены в любом процессе разработки. Это Product Owner, System Architect и Project Manager. Удивились? :) АГА, Agile не равно SCRUM.

Product Owner — тот, кто занимается требованиями, требованиями и еще раз требованиями. Он знает и понимает задачу бизнеса, требующую решения, и еще умудряется как-то рулить всеми заинтересованными лицами, каждый из которых тянет в свою сторону.

В рассказе про Product Owner’а всплыла пара хороших аналогий с картинками (вообще презентация очень хорошая, лаконичные красочные слайды). Scope (граница проекта) — это как белая линия (white line), очерчивающая игровое поле на теннисном корте. Куда упал мяч? То есть где возникло требование? В рамках проекта или вне их? Это нужно уметь определять, чтобы проект не расползался.

Вторая аналогия (метафора?) — про детальность проработки требований. Сначала — широко, а местами — глубоко. Как снорклинг и дайвинг :) Главное — как можно раньше получить ценность для бизнеса.

Также очень важно при разработке требований представлять себе бизнес-процесс целиком, а не только ту его часть, которая проходит через вашу разрабатываемую систему.

Проекту также необходимо иметь 3..5 целей. При этом эти цели должны быть названы громко и четко, и даже регулярно повторяться, чтобы до всех дошло и не забывалось.

Понятно, что работа с требованиями — это работа, связанная с тесным взаимодействием product owner’а с заказчиком/покупателем/интересантами. Все стороны очень многому могут друг друга научить, и должны это понимать.

В целом, Agile Product Owner — это то же самое, что бизнес-аналитик (Business Analyst), он же Requirements Engineer. Его задачи — цели проекта, границы, управление интересантами, работа с требованиями и бизнес-задачами.

Software Architect — это другая роль. Если product owner отвечает за задачу, то software architect — за ее решение. По Питеру — это мега-важный чувак (сам Питер в настоящее время в этой роли и выступает, как я понял). Аналогия — десятиборье (decathlon) — куча дисциплин, и ни в одной нельзя облажаться. Архитектуру нужно создать, суметь продать, отслеживать ее реализацию, оценивать, объяснить, и т. п.

Питер говорил, что существуют методики оценки качества архитектуры (?). Кроме того, дал ссылочку на свой свободно-распространяемый шаблон описания архитектуры: arc42.com. (Там правда, проблема с английским переводом сейчас.)

По мнению Питера, роль Product Owner’а не следует пытаться совместить с ролью Software Architect’а в одном лице — с большой вероятностью получится плохо. PO хочет решить проблему в моменте, а SA обязан думать и о будущем. Конфликт, шизофрения, Кащенко.

Запомнился также совет по документированию — детальность должна быть минимально необходимой для того, чтобы не пришлось потом реинжинирить чисто из-за того, что что-то было незадокументировано. Лучше иметь меньше документации, но чтобы она была корректна и актуальна. Ну, впрочем, это все понятно.

Project Manager — вау! А это еще кто? А вот есть и такая роль, по мнению Питера, и это не то же самое, что Product Owner. PM должен контролировать движение итерационного колеса ~~жизни-и-смерти~~ требований-и-реализаций, при необходимости это колесо подталкивая.

С «водопадом» это было проще. Планы, сроки, все понятно. С итеративностью и инкрементностью все стало сложнее, PM должен гораздо более тесно работать с остальными участниками. Он отвечает за то, как проект разворачивается во времени, как изменяются длины итераций, когда вбрасываются порции новых требований. Также его забота — обеспечить потенциальную завершенность продукта на каждой итерации. «Done» должно означать «Done». Полную готовность к отгрузке продукта заказчику.

Неудобный зал

На картинке можно посмотреть, как неудобно было в зале с колоннами и многочисленными операторами видеосъемки :(

Книжка

Питер немножко попродвигал книжку, которую они с сотоварищами написали, а издательство «СимволПлюс» недавно выпустило на русском — «Балдеющие от адреналина и зомбированные шаблонами». Это книжка про некие паттерны (и антипаттерны) поведения проектных команд, типичные командные «болезни» и методы их лечения. Думаю, стоит прикупить парочку на контору, наверняка найдутся описания и каких-то наших болячек.

Вопросы Заборова

Миша задавал Питеру ~~Хрюшке~~ Хрущке много вопросов, в конце доклада и в кулуарах, настоятельно рекомендую почитать об этом в его отчете.

11:20. Анджей Аршавский, IBM, «Разумная планета»

Сначала доклад от IBM, как спонсора конференции, вызывал опасения. Думалось, что это будет типичный вендорский доклад о продуктах компании.

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

Рассказывалось это все, причем, довольно монотонно и скучно. На слайдах попадались большие блоки мелкого текста, примерно по которым докладчик и «докладывал».

Забавно, что с сухого академического языка он иногда скатывался к словечкам типа «тулзы», «софт» и т. п.

Тем не менее, в блокноте осталось несколько заметочек про то, что вызвало интерес:

Бизнес IBM: 1/4 — железо, 1/4 — софт, и 1/2 — услуги (как технические, так и бизнесовые);
Имеются тенденции к смещению интереса с просто бизнес-автоматизации к оптимизации (BI и всякая Wikipedia:Стохастическая_оптимизация);
В софтверной части IBM работает порядка 25 000 разработчиков в 78 лабораториях по всему миру. Порадовал термин «популяция разработчиков» :)
С 2003 года IBM начал внедрять методики Agile в проектных командах и, вроде выявилась польза — выросло ROI и снизилось количество людей, требующихся для проектов.

А дальше… Ура! Мое предчувствие мне не изменило, и доклад, начинавшийся с Великого Пафоса, плавно перешел в сторону того, какой есть замечательный набор продуктов IBM Jazz, и как IBM сам с ним живет, хотя почему-то не во всех проектных группах он все-таки используется. Ну, видимо, виноваты исторические причины и особенности некоторых продуктов.

Дослушивать про jazz я не стал, пошел обсуждать с Мишей Заборовым то, что услышали от Питера ~~Хрюшки~~ Хрущки.

12:45. Дон Сайм, Taking Functional Programming into the mainstream

Как я уже говорил, Дон Сайм (Don Syme) прилететь сам не смог из-за вулкана. Но с горем пополам удалось наладить видео-трансляцию через NetMeeting.

Видно и слышно было фигово, но это лучше, чем ничего.

Дон Сайм — автор языка F#. Его блог можно почитать тут.

Сейчас он главный архитектор F# в подразделении Microsoft Research.

F# — это мультипарадигменный язык, с одной стороны, построенный на базе OCaml, а с другой — реализованный на платформе Microsoft .NET, что приближает его к плеяде промышленных языков типа C#. Более того — Microsoft выпустило F# в рамках Visual Studio 2010, что по идее, говорит о полноценной поддержке этого языка. С другой стороны, сообщество F# все равно остается крайне мизерным по сравнению, например, с сообществом C#. Но, опять-таки, с другой стороны, то, что F# построен на платформе .NET, дает:

знакомую платформу и библиотеки классов;
возможность писать под .NET (любые типы проектов и библиотек) на более современном, функциональном (точнее, мультипарадигменном) языке
возможность комбинировать F# и C# в проекте, решая разные задачи на наиболее подходящем инструменте.

Кроме обычного .NET, F# вроде поддерживается и на CompactFramework, и в Silverlight (неудивительно, IL-код ведь одинаковый).

Кроме того, была любопытная ссылка на проект WebSharper, который позволяет писать сайты на F#, генерируя необходимый клиентский JavaScript для исполнения в браузере. То есть, это аналог GWT на F#!

Дон попытался показать на нескольких слайдах явные преимущества F# перед C# в лаконичности и понятности кода. Слоган «Решаем сложные задачи простым кодом!». Код на F# (как и на других функциональных языках), действительно, зачастую более лаконичен. Но не надо путать простоту с лаконичностью. Именно оттого, что функциональные языки оперируют более сложными примитивами, код получается более лаконичным, но, в то же время, читается он все-таки сложнее.

Забавно, что в примерах на C# Дон иногда использовал удлиненные конструкции (то есть реально на C# можно писать чуть короче), и допускал ошибки :) Впрочем, F# все равно оставался сильно лаконичнее, и местами было видно, что таких ошибок в нем допустить просто нельзя.

Из интересного:

Замечательные возможности по интерактивному исполнению F# в Visual Studio 2010. В C# так нельзя.
Механизм цитирования («quotations») позволяющий превратить любую часть программы в данные, которые затем проанализировать (аналог Expressions и LINQ в C# 3.0). Правда, при этом LINQ не такой красивый получается, как в C#.
В F# навороченные механизмы параллельного программирования, но на самом деле они базируются на библиотеке TPL, которая доступна и для C#, и на базе которой в C# 4.0 сделана библиотека параллельных запросов PLINQ.
Многое для F# публикуется в открытых исходных кодах, в частности — сами исходники компилятора.

Что касается использования F# у нас в компании — мне лично (это чисто личное ИМХО) кажется, что пока мы не можем себе позволить писать прикладные проекты на нем — слишком экзотичен, сложно найти кадры и все такое. Но экспериментировать в каких-то ограниченных объемах, наверное, можно. Язык интересный, и из всех функциональных этот, похоже, на сегодняшний момент имеет лучшую поддержку от такого гиганта, как Microsoft.

13:55. Дона Смита отменили

Доклады Дона Смита отменили (оба), поэтому я расширил кофе-брейк, поучаствовал в обсуждении с Асхатом Уразбаевым и Мишей Заборовым предполагаемой поездке в Екатеринбург на конференцию AgileDays. Обсуждали, что мы можем такое-эдакое рассказать, и как это можно назвать.

15:45. Андрей Вербицкий, Хорошая архитектура

Один питерский экскурсовод как-то раз довел меня практически до белого каления своим обращением «господа», которое он умудрялся повторять пару раз на фразу, видимо, на самом деле выражая этим свое негодование насчет глобальной несправедливости всего происходящего с его точки зрения.

Скорее всего, Андрей Вербицкий никогда не работал экскурсоводом в Питере, но почему-то от его доклада у меня в блокноте тоже осталась отметочка «господа». То-ли все-таки тоже частил он с этим странным обращением, то ли это у меня так режет слух. Может, после Питера :) Тем не менее, в целом доклад оставил положительное впечатление, во многом, вероятно, благодаря масштабу проблематики, которую рассматривал автор. Презентация была хорошая, красивая, за редкими исключениями не перегруженная текстом.

Любопытное совпадение, но доклад Андрея также начался с обзора достопримечательностей строительной архитектуры :) Речь шла о давней натянутой аналогии с разработкой ПО и проектированием зданий. Для начала мы пытались понять, что вообще такое хорошая архитектура. Я сразу вспомнил героя и автора книжки «Дзен и искусство ухода за мотоциклом», который долго пытался дать определение качеству, но в итоге был вынужден оставить это понятие неопределенным в виду его принципиальной неопределимости. Андрей давать критерий или определение хорошей архитектуре, к счастью, не собирался, он просто показывал примеры и все соглашались: «Да.. это хорошая архитектура. Да.. это плохая архитектура».

Андрей сформулировал несколько признаков:

хорошая архитектура проста — число деталей сокращено до минимума
используется процессный подход — архитектура поддерживает главные процессы
найден разумный компромисс универсальность/специализация
сделан расчет на изменение среды
предусмотрена интеграция

Признаки понятные, но из той же книжки «Дзен и искусство ухода за мотоциклом» мы знаем, что из одних этих признаков качества синтезировать качество (в данном случае — качественную архитектуру) не удастся. Ну да ладно.

Далее последовал интересный футурологический прогноз. По мнению Андрея, в ближайшие годы ключевое развитие получат следующие направления:

Identity — общепринятые средства идентификации, которые позволят отказаться от кучи логинов и паролей
CRM и SelfCare — в широком смысле, переход на другой уровень взаимодействия компаний и клиентов

Появятся (уже появляются) совершенно новые бизнес-модели и они…. потребуют совершенно новой архитектуры. Как-то так.

Последней темой доклада стало то, что, по мнению Андрея, у нас (в отрасли) очень плохо обстоят дела с обучением архитекторов. Строительных архитекторов учат по альбомам, показывают, где что было сделано хорошо и почему. А у нас, дескать, такого нету. Из зала напомнили, что есть архитектурные паттерны Фаулера. Но, понятно, что этого очень мало, и хочется больше. Кстати, в этом смысле, наш паттерн учетной машины действительно может выйти на голую нишу.

16:30. Microsoft, Облачные вычисления

Дмитрий Мартынов из Microsoft рассказывал об идее облачных вычислений и о реализации этой идеи от Microsoft.

Облачные вычисления можно рассматривать как следующий логический шаг после виртуализации серверов. Даже с виртуальным кластером серверов у вас есть периоды бездействия и периоды максимальной загрузки. Соответственно, оборудование нужно покупать с запаом на пиковую нагрузку, а в остальные часы оно частично простаивает. Идея — ха-ха — покупать ~~машинное время~~ вычислительные мощности «на вес», ровно столько сколько требуется на данный момент. Само железо при этом не покупать и не заботиться о нем — вычисление выступает как сервис.

Платформа облачных вычислений от Microsoft носит название Windows Azure, и позволяет запускать переменное число экземпляров приложений некоторого класса:

Web-приложения под IIS
Web-сервисы под IIS
вроде бы приложения под PHP и вообще все, что доступно через Web, а устанавливается простым копированием, то есть вроде бы Apache работает. Народ в Сети пускает Java-приложения под Jetty.

Azure предоставляет, по сути, два вида ресурсов — вычисление и хранение. С вычислением более-менее все понятно, оно сам по себе типа stateless. Для совместной работы приложений с общими данными нужно использование хранилища. Хранилища бывают двух видов — что-то похожее на MS SQL Server (Azure SQL) и нереляционное (NoSQL) хранилище (Azure Storage), которое зато лучше масштабируется.

Пару слов про Azure Storage — нереляционное хранилище, поддерживает хранение BLOB’ов, хеш-таблиц и очередей. Позволяет поуправлять сегментированием по данным (шардингом), задавая ключик (partition key), который обеспечит совместное хранение связанных данных.

Было показано несколько очень зрелищных фотографий того, как устроены ЦОДы Azur’а внутри. Это такие огромные территории, похожие на склады, где установлены большие металлические контейнеры (типа железнодорожных). К этим контейнерам подключают Интернет, Электричество и Воду. А внутри — сотни плотно упакованных серверов. Плотность упаковки при этом вроде существенно выше, чем в обычных ЦОДах. Контейнеры ставят прям друг на друга, раскладывают по складам каким-то. Картинки — жесть, вспоминается Matrix и SkyNet. Внушает. Видео можно посмотреть тут.

К сожалению, Azure пока недоступен в России. Проблемы, якобы, исключительно в сложностях с законодательством и способами оплаты. Не очень понятно. При этом, если тупо есть кредитка, выпущенная в США или в Европе, то получить доступ можно. Другое дело, что пока в России нет ЦОДов, маршруты до серверов будут довольно дальними.

Интересный кейс. Quest Software предлагает сервис автоматизированного бекапа… в облако. Они создали сервис на базе Azure и, фактически, перепродают купленное оптом у Microsoft пространство хранилища в розницу клиентам в виде сервиса по бекапированию. Как ни странно, при этом клиенты не боятся за сохранность своих данных.

В общем, тренд интересный, его обязательно нужно иметь в виду.

Что касается качества доклада, то тут впечатление осталось двойственное. С одной стороны — все понятно, интересно, по делу, элементы демонстрации и live coding’а (правда, на эмуляторе, а не в настоящем Azure). А с другой стороны — почему-то казалось, что докладчик постоянно находится в защитной позиции и время от времени оправдывается за Microsoft. Из зала задали невинный вопрос про то, как стоимость увеличивается при увеличении количества экземпляров приложений, а докладчик почему-то начал отвечать совсем про другое, «какая вам разница, что там, в этом облаке — Windows или Linux?» Прямо как в том анекдоте: «— Что это ты так поздно? — Кто накурился?! Я накурился?!». Как-то в общем эта защитная позиция сквозила и на докладе и далее, в сессии вопросов и ответов.

Стендовый доклад, Григорий Мелехов, ОСМП Qiwi, «Из исполнителя в руководители. Первые шаги по граблям»

Стендовый доклад — это когда вся конференция пьет кофе, ест плюшки и обменивается опытом в холле, а кто-то один прямо тут же пытается привлечь к себе внимание, пользуясь микрофоном и большим экраном. Мне эта идея не очень нравится, потому что пытаешься разорваться между плюшками и экраном, и в итоге не получаешь удовлетворения ни от одного, ни от другого.

В случае доклада Qiwi плюшки победили, хотя доклад вроде был интересный — «первые шаги новоиспеченного руководителя». Да и в тему конференции, в отличие от F# :)

От доклада в блокноте осталась только запись одного вопроса-ответа докладчику:

Q: Что же главное, чем можно помочь новоиспеченному руководителю?

A: Часто люди, которых поставили на должность руководителя даже не понимают, что они могут делать, чем они могут управлять, какие степени свободы они получают. Нужно это как-то показать.

Сессия вопросов докладчикам

В конце первого дня конференции состоялась т. н. «Сессия вопросов и ответов с ключевыми докладчиками конференции». Конкретно, за столом в большом зале собрались Питер Хрущка, Андрей Мартынов (Microsoft) и Анджей Аршавский (IBM). Эксперт Хрущка сидел между представителями двух гигантов, но при этом выглядел на голову выше и большинство вопросов было адресовано именно ему.

В основном вопросы касались Agile’а и SCRUM’а, которые как спрашивающие, так и отвечающие частенько путали.

Опишу несколько тезисов, которые запомнились:

Мартынов: «Мы считаем что fun — это здорово, но и работать тоже нужно».

Я аж подпрыгнул. Мне казалось, что штука в том, чтобы в работу вносить fun, а не разделять их. Сразу захотелось ему предложить померять коэффициент fun/work и мерять им своих разработчиков.

Мартынов: «Мы считаем, что нет методологии без инструмента».

Я еще раз аж подпрыгнул. Читаю замечательную книжку «Дао Toyota» (Кстати, надо непременно прикупить парочку на компанию), где на опыте Toyota видно, насколько легко можно обойтись без существенных технологических вложений в методологию. Канбан — это тупо деревянный ящик и ламинированные бумажки. Наш Taskboard — это просто пробковая доска. Что еще нужно?

В общем, от Мартынова я подпрыгивал регулярно, сложилось впечатление, что он не понимает, в чем собственно, соль Agile’а.

Аршавский: В разных продуктах IBM до 20 % компонент — повторно используются.

Как-то блекло. Невыразительный он все-таки.

Хрущка: Для любой agile-практики совершенно необходимым является одно условие: responsible people, ответственные люди.

Хрущка: 95 % команд думают, что они — agile. Но лишь 5 % — творят чудеса настоящего agile. При этом не нужно путать agile и cowboy programming :)

А вот этот человек явно понимал, о чем идет речь. В какой-то момент я даже подумал, что стоило бы сходить на его платный семинар.

День 2. 23 апреля

Второй день конференции был гораздо более насыщенным. Уже три полноценных трека, и большую часть дня я провел на одном из них — на «People Management».

10:00. Сурен Самарчан. «Типичный день эффективного лидера»

Доклады Сурена давно известны как очень впечатляющие, вдохновляющие и яркие. В нем действительно виден опытный руководитель из серии «шейперов» (как мне кажется). Именно этим опытом он активно и делится на конференциях.

«Я собеседовал около 1000 человек, претендующих на должность руководителя, и 95 % из них не могут ответить на вопрос, чем они должны заниматься как руководители» — это была первая фраза доклада, определяющая все остальное его содержание. Чем должен заниматься руководитель-лидер?

Далее все изложение было достаточно четко структурировано, велось по слайдам, так что если удастся найти презентацию, то по ней можно получить достаточно полное представление о том, чем же должен заниматься лидер. Я перечислю 10 верхне-уровневых разделов-активностей, которые назвал Сурен, и какие-то свои заметки по ним.

Лидер использует каждую возможность для усиления своей команды

Компании иногда растут быстрее, чем люди. Умные люди это знают, принимают и готовы не брать на себя больше того, что реально могут потянуть (поучительная история про финансового директора Dell, который с ростом компании снижался в должности).

Проблема в том, что менеджеры, выросшие из разработчиков, никогда не видели, как работает профессиональный менеджер.

Только практическое обучение эффективно

Каждое событие можно рассматривать как момент для обучения команды

Работать в паре полезно не только разработчику, но и менеджерам

Забавный пример. Все сложности, например, научиться жонглировать — решаются серией простых шагов.

Можно применять сессии критики. Надо бы почитать и попробовать, мне идея нравится

Лидер способствует самостоятельности команды

Нужно понять, как вы делаете то, что делаете хорошо, и постараться передать это команде.

Лидер регулярно заряжает команду позитивной энергией

Верить в светлое будущее :)

Лидер наполняет жизнь сотрудников смыслом
Лидер создает правильную атмосферу

Конкретнее — атмосферу искренности, открытости и ответственности
Нужно просто начинать с себя
Говорить то, о чем все думают, но молчат
Лучше давать маленькие обещания, но выполнять их

Нельзя спускать на тормозах деструктивные высказывания

Лидер регулярно проверяет идеи и действия сотрудников

Руководитель задает вопросы, команда продумывает действия
После решения нужно проверять наличие изменения

Лидер регулярно принимает сложные решение в условиях неопределенности
Лидер создает и поддерживает правила игры
Лидер уничтожает все преграды на пути гипер-продуктивности
Лидер думает о будущем

Даже если вокруг пожар — думать о будущем!

В конце доклада был задан очень важный вопрос. Примерно так:

Q: А что, если сотруднику важнее побыть с семьей, с детьми? Он уходит домой строго по часам.

A: Это здорово, он молодец, если знает, чего хочет. У меня есть такой знакомый и мы с ним в отличных отношениях. Но к себе на работу я его никогда не возьму — у нас работают люди с другими ценностями.

Очень важно, на мой взгляд, правильно осознавать собственные ценности и соотносить их с ценностями компании. А компании очень правильно четко декларировать свои ценности и не колебаться в том, в каких случаях к ним апеллировать, а в каких — нет.

В общем, доклад Сурена, был, как всегда ярким, запоминающимся, хотя словами — вроде обычные вещи говорил. Видимо, в его личных лидерских качествах действительно немаловажную роль играет харизма. В то же время некоторые методы управления («Если вдруг команда зарывается — ну, попробуйте дать им заведомо невыполнимую задачу») мне представляются небесспорными.

10:45. Сергей Архипенков. «Технология командообразования»

Архипенков — отечественный аксакал в отрасли разработки ПО, говорит, что 30 лет уж как. Вырос из разработчиков, что, в общем-то чувствуется. Работал где-то в ЦУПе, и еще где-то. Сейчас занимается все-таки уже руководством большими проектами, причем именно с уклоном в технологии — как технические, так и проектные/командные, а не в сторону управления проектом как таковым. Человек в общении очень приятный, и порасспрашивать его хотелось.

Доклад назвался «технология командообразования», и вроде было заявлено, и предполагалось, что эту самую технологию автор предаст слушателям. На мой взгляд это не очень-то получилось (если вообще можно такую технологию передать).

Команда, по Архипенкову, характеризуется следующими признаками:

общие цели и ценности
доверие и взаимопомощь
развитые коммуникации
коллективная ответственность

По Архипенкову (я дальше буду пропускать это вводное), команда эффективна там, где пути решения задачи неизвестны. Отсюда он делает вывод, что, например, на машиностроительном производстве команды не нужны, и все отлично работает с рабочими-роботами, как на конвеере Форда.

Я не смог удержаться, и, сев за обедом за стол к Архипенкову, рассказал ему про свое впечатление от книжки «Дао Toyota» — о том, как разительно конвеер Ford отличается от конвеера Toyota, где работают самые настоящие команды, и откуда, собственно, растут корни многочисленных agile-практик.

Итак, по Архипенкову, для создания команды нужно три вещи:

Вещь 1. Правильные люди

«Эффективные люди». Это не только люди с высоким IQ, но и с высокой способностью к кооперации. Архипенков выражает это формулой:

E = IQ * EQ²,

где EQ — т. н. Эмоциональный интеллект: самосознание, самоконтроль, эмпатия, навыки отношений.

Архипенков немного иначе трактует EQ и еще включает туда же волю и мотивацию. Я бы эти ингредиенты поместил в отдельный член произведения, но ему, видимо, очень нравится формула в таком виде :)

Утверждает, что IQ фиксируется к 14 годам, а EQ потенциально может развиваться всю жизнь.

В целом вещи, о которых он говорит, очень понятны и действительно важны. «Правильные» люди умеют работать в команде, ответственны, проактивны и прочее бла-бла-бла. Об этом всем можно прочитать, например, тут. Кстати, хорошая книжка, можно купить на контору экземплярчик

Проблема, которую мне хочется отметить, заключается в том, что все эти сложные слова (например, «ответственность» или «доверие») люди понимают существенно по-разному. И понимание это очень сильно меняется с течением времени. А поэтому можно услышать и прочитать тысячу раз все эти бла-бла-бла, но при этом совершенно не так понимать ответственность и доверие, как твой сосед. И как передать это понимание — большой вопрос.

Вещь 2. Лидерство

Выделяем в две отдельные деятельности лидерство и управление, как две стороны медали. Управление — это анализ текущей ситуации и синтез решений. Лидерство — это определение стратегии, достижение успеха, люди.

Лидер не может быть просто назначен, в отличие от управленца — лидер признан, ему оказывается доверие. Рисуется общеизвестная картинка с квадрантами стилей управления, от директивного управления до делегирования. Я ее пару раз точно видел на конференции.

Высшая категория лидерства — только задавать наводящие вопросы, и за счет этого приводить к нужному решению.

Вещь 3. Точим пилу

Тут почему-то у меня очень рваные, плохо связанные фрагменты. Впрочем, может, именно так, плохо связаны были и подтемы презентации.

Был нарисован график производительности команды на разных стадиях ее становления:

Forming → Storming → Norming → Performing.

После performing типа производительность падает, потому что всем становится скучно. Значит, говорит Архипенков, нужно сделать Reforming и перемешать команду. График делает изящный изгиб снова вверх, формируя зубец пилы :)

Для управления работой у менеджера есть 4 «П»: продукт, процесс, проект и персонал. Причем обычно на коротком интервале менять он может реально только процесс.

Философия ShuHaRi. Многие ее поминают всуе на конференциях. Сперва ты что-то изучаешь, делаешь по инструкциям, потом ты начинаешь ломать традиции, делаешь по-своему, и, наконец, ты начинаешь действовать органично, спонтанно, неосознанно, максимально эффективно, но не зная, как ты это делаешь.

Менеджер должен быть как садовник. Выставить одно растение под солнце, а другое — в тень. Поливать вовремя и правильным количеством воды, закрывать от ветра, вкладывать душу.

Про кросс-функциональность и специализацию — хороший пассаж. В футбольной команде есть специализация — вратари, защитники, нападающие всякие… Но если вдруг около ворот случается опасная ситуация и вратарь вдруг падает, защитник не стоит и не смотрит на него: «Да, облажался наш вратарь!» Любой постарается перехватить мяч, и пусть они не могут играть руками — они сделают все, чтобы перехватить его ногами! Любой из них!

Вся информация в проекте должна быть открыта — это способствует эффективному принятию правильных решений.

Конфликт — это нормально, его нужно решать. Но он не должен переходить на личности. Рассказывал, как и они, бывает, засиживаются до позднего вечера, обсуждая какой-то вопрос, и даже ругаются друг на друга матом, но это все — без перехода на личности :)

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

Слушать было приятно, пользы было мало. Сейчас Архипенков занят в каком-то довольно масштабном проекте (~1000 ч*мес) для какого-то госучреждения. Поспрашивал на обеде:

какой-то документооборот
Java + Oracle
ADF, в ограничения которого уже уперлись, но продолжают грызть ~~кактус~~
тесты на пустой базе данных, скорость пока не пугает

Стендовый доклад. «Agile MixFight»

Еще один «спам-доклад». Начался здорово — показывали фрагменты из регби. Действительно, вдохновляет :) Команда работает как один, единый организм, участвуют все, так как пас можно отдавать только назад. Тут также повторяется хорошее замечание, сделанное Архипенковым — с одной стороны у игроков есть кросс-функциональность, с другой — специализация. Одни регбийцы — быстрые и легкие, другие — массивные и медленные. Все понимают роли друг друга, но при необходимости всегда готовы подменить друг друга в меру собственных сил и возможностей. Тогда это команда. Не нужно путать кросс-функциональность с обезличенностью и одинаковостью. Кросс-функциональность — это, скорее, следствие того, что коллектив работает как команда. Если цель видна (и важна!) всем, то естественным средством ее скорейшего достижения будет частичная кросс-функциональность.

После регби парни начали что-то говорить, но это было уже совсем не так зажигательно. Ну, и вообще, эти стенд-доклады как-то не вызывали интереса, и выглядели неуклюже.

12:00. Владислав Балин. «Природа рисков в разработке ПО»

Владислав Балин — довольно известный в сети человек. Он фигурирует на форумах RSDN и пишет блог [1] под ником Gaperton. Сколько помню, он выделялся в форумах умом, опытом, и резкостью, граничащей с хамством (последнее нередко встречается как следствие ума и опыта). Мы с ним как-то здорово ~~посра~~поругались по поводу SCRUM’а, который у нас тогда в компании только-только появился, я его тогда толком не понимал, но выступал апологетом, а Влад его тоже не понимал, и выступал яростным критиком :) Примерно так обычно и происходят все holy war’ы.

Вообще, блог очень интересный, Влад долгое время работал в компании CQG, а в последние годы занимается больше управлением проектами, и, в силу характера, тяготеет больше к классическому директивному управлению, с четко выделенной персональной ответственностью. В коллективную — не верит до сих пор (хм… а верю ли я?). Блог рекомендую почитать, хотя там местами есть нецензурные выражения, а местами — странные нецензурные рассказики, которые автор, похоже, считает дико смешными. Есть и технические статьи.

Вернемся к теме доклада. «Природа рисков в разработке ПО». Мне хотелось посмотреть на Gaperton’а живьем. Я чуть-чуть запоздал, но вроде ничего сверх-важного не пропустил. Доклад короткий, четкий, ясный. (Влад любит все разложить по полочкам и показать, что это просто почти до очевидности, просто почему-то раньше этого никто не сказал).

Презентация есть, ее можно посмотреть тут.

Далее — тезисы доклада.

Разработка — это, вообще говоря, решение разнообразных технических проблем/задач. Проект — организовать решение этих проблем правильным образом имеющимися ресурсами. Про каждую из проблем/задач заранее можно спросить эксперта, попросить назвать нижнюю и верхнюю границу трудоемкости. От «точно не меньше» до «стопудово меньше».

Классифицируем проблемы, стоящие перед разработчиками, таким образом:

Принципиальные: Верхняя граница неопределена, бесконечность. «А фиг его знает, как вообще это делать» — говорит Эксперт.
Непонятные: Решение точно есть, но верхняя граница сильно увеличена. «Может, справимся за день, но может получиться так, что провозимся месяц» — говорит Эксперт.
Понятные: Примерно понятная задача, разброс границ невелик. «Ну, от двух до трех недель» — говорит Эксперт.

Классифицируем типы ошибок, которые можно сделать на разных этапах, а также рассмотрим, от чего зависит вероятность их возникновения:

Ошибки в требованиях
Ошибки в архитектуре
Ошибки в дизайне
Ошибки в реализации

Архитектура по Балину — базовые технологии и принципы структурирования. Качество архитектуры зависит от квалификации архитектора и заранее очень сложно его оценить. Цена ошибки велика, но повлиять в проекте на риск того, что архитектура окажется неудачной, обычно невозможно.

Ошибки в требованиях также, как известно, очень дорогие. Но риск ошибки в них последнее время успешно удается снизить с помощью итерационных подходов к разработке.

На самом деле остальные риски — дизайна и реализации — не столь существенны, а главное — в большей степени зависят от нас, от управления проектом. Ключ к снижению этих рисков — правильный план работ. Как же его составить?

Обычно функции системы можно легко расклассифицировать по простейшему принципу — на обязательные и желательные. Обязательные — это те, без которых система вообще никому не будет полезна, продукт не купят и т. д. Желательные — это все остальные. Можно применять более сложные разбиения, но начать можно и с такого простого.

По закону Мерфи, обязательные функции системы обычно наиболее непонятные :) Ну, разве что вам повезет. Но обычно — это проблемы из класса принципиальных и непонятных (см. выше).

Зря говорят, что инженеры не чувствуют рисков. Очень даже чувствуют! Отлично чувствуют, и… и обычно начинают работу с наиболее понятных им задач. Для них ближайший риск — это столкнуться с непонятной задачей. Они испытывают при этом дискомфорт, и именно поэтому интуитивно берутся сперва за понятные. Отлично все чувствуют!

Беда в том, что менеджеру нужен совсем другой приоритет!

Рисуем квадранты понятности и важности задач:

1  непонятные,    | 4  непонятные, 
   обязательные   |    желательные
------------------+------------------
2  понятные,      | 3  понятные, 
   обязательные   |    желательные

Инженеры инстинктивно начнут делать работу начиная с квадрантов 2 и 3, но это совсем не то, что нужно менеджеру для снижения рисков проекта! Менеджеру нужно в первую очередь разобраться с квадрантом 1! Проект, в котором 1 и 2 сделаны, может быть успешным, даже если к 3 не приступали.

В этом смысле появляется вполне естественный конфликт интересов между инженером и менеджером проекта. И этот конфликт нужно решать очень жестко — оставлять инженеру выбор в области желательных задач, но твердо требовать решения обязательных. Это может быть стрессом для инженера, но иначе — риск для проекта!

Важный момент в квадранте 1 — что делать с принципиальными проблемами, которые непонятно, как решать, и сколько времени это займет? Их нужно превращать в непринципиальные! Путем разборок, декомпозиций и НИРов. Таким образом, нужно максимально сокращать количество обязательных и при это непонятных и принципиальных проблем, превращая их в понятные обязательные квадранта 2.

Если требуется НИР, то время на него следует жестко ограничить, и результатом которого должно быть какое-то решение о том, что же делать дальше. Пример — в результате НИР, включающих исследование тенденций самолетостроения, в качестве результата получается техническое задание на следующее поколение зенитно-ракетных комплексов.

В конце поговорили о том, что архитектура нужна, что она по-любому должна закладываться в начале проекта и инкрементальной быть, скорее всего, не может — изменяться по ходу дела могут только достаточно низкоуровневые вопросы дизайна. Влад рассказал историю про архитектуры видео-конверторов, которая ему очень нравится, и которая есть в его блоге.

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

12:45. Константин Кондратюк. «Использование MBO»

коротко

MBO (Management By Objectives) — это принцип управления через постановку индивидуальных целей. Человек рассказывал, как это должно работать и почему это может не работать в России и каких-то других странах. Это определяется менталитетом людей — кто-то нацелен на результат, а кто-то — как бы и не очень. Кто-то настроен на процесс, а кто-то — вообще на общение, ему не до работы :) Мысль автора — давайте смотреть на это с открытыми глазами, если у нас такие люди и такая организация, где достижение результатов не в ценностях, то MBO там работать не будет, а превратится в фарс — ну так и не надо пробовать (или придется поменять всю организацию).

Обед и искуственная очередь

Обед в оба дня был одинаковый и одинаково организован. Что меня особенно удивило — так это организация очередей к еде. Она тоже была одинаковой в оба дня конференции. Поясню.

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

Народ самоорганизовался таким образом. Выстраивались две длиннющие очереди, которые медленно двигались вдоль стола от тарелок к чаю, мимо блюд. Слева — одна очередь, справа — другая. Очереди двигались медленно — все, кто сзади, ждали, пока очередной человек спереди выберет себе салатик, закусочку, горячее, гарнир и т. д. Ну то есть все это делали друг за другом. Люди накладывали себе еду на тарелки достаточно медленно.

Что же было замечательного в этой очереди? А то, что в результате оказывалось, что, хотя в хвосте очереди плотность народу была очень высокой, голова очереди была очень разреженной. Фактически, около многих блюд вообще не стояло никого! В то время как многие люди покорно толклись друг за другом в хвосте очереди.

Я, вообще, очень не люблю лезть вперед очереди. И обычно так не делаю, потому что мне кажется, что я этим кому-то делаю хуже, ведь кто-то из-за меня пройдет позже!

Но тут я впервые два дня подряд наблюдал такую забавную самоорганизующуюся очередь, при которой можно было, никому не помешав и никого не задержав, получить свой кусочек гораздо быстрее, и не отстаивая 20 минут.

Я подходил к плотной, почти не двигающейся толпе возле тарелок, и, нисколько не задерживая почти неподвижную очередь, вытягивал со стола тарелку и приборы. После этого я шел к голове очереди, где народ был очень разрежен, и, тоже никому не мешая и никого не задерживая, подходил к свободно стоящему блюду и накладывал себе порцию! Если около блюда стоял человек, достаточно было подождать тридцать секунд, и он отходил, при этом на его место НЕ подходил следующий, так как голова очереди была разрежена — следующий человек в это время выбирал себе блюдо на три метра левее! На трех метрах никого не было, а очередь толпилась еще сильно левее.

Очередь на этот обед тратила время сама на себя! Это было потрясающе занимательно!

Понятно, что сильно ускорить прохождение очереди можно было бы, увеличив параллельность ресурсов (еды) — четыре параллельных ковеера вместо двух. Но это, очевидно, дороже. Скорее всего, аналогичного эффекта можно было бы добиться, если просто расставить блюда по-другому — не в одну линию, а на отдельно стоящих круглых столиках. Это бы не провоцировало бы людей выстраиваться в неэффективную цепочку, где взаимосвязи предыдущий-следующий совершенно искуственны (человек А не может положить себе салат, потому что человек B еще не положил себе колбасу — эта зависимость искуственна!).

Станислав Калканов. «Управление знаниями организации»

коротко

Довольно скучный доклад про то, как в Luxoft'е строили систему управления знаниями. Сначала на Sharepoint'е построили, но там жестковато все оказалось и тяжеловато. Потом сами стали появляться wiki-системы и поставили Confluence (тем более, что в компании используется JIRA). И все стало здорово. Sharepoint оставили для каких-то более формальных документов.

Олег Ридченко. «Обучение, развитие и оценка руководителей проектов»

коротко

Какой-то странный доклад про то, как оценивают руководителей и ставят им цели по развитию в одной компании. Там трехуровневая структура управления и почему-то директора толком не знают, чем занимаются руководители среднего звена, и, видимо, не особо-то хотят знать. Поэтому каждый руководитель обвешивается парой десятков анкет-компетенций, взвешивается, измеряется, и ~~признается негодным~~ оценивается, причем чуть-ли не в виде одного значения, в сравнении с руководителем-коллегой! Жесть, в общем. Компетенции, конечно, сами по себе интересны, но их описание (кстати, как и у нас) - не раскрывается, это считается know how кадрового отдела.

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

коротко

Молодой человек с несходящей с лица улыбкой проводил мастер-класс по разрешению конфликтов. Мастер-класс был странненький, поделились интересными случаями конфликтов, пообсуждали в группах, после чего Стас рассказал о своем опыте использования одного метода. Метод заключается в следующем:

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

Конечно же, самая большая сложность в третьем пункте — как заставить людей разговаривать о том, о чем в группе все привыкли не разговаривать, и как при этом не дестабилизировать ситуацию? Или наоборот — дестабилизировать — это нормально и не надо этого бояться? Вопросы схожи с тем, которые можно задать относительно практики критических сессий, о которых много говорит Сурен Самарчан. Впрочем, Сурен вот не боится их применять :)

Учиться разговаривать действительно нужно, к этому пониманию мы и сами в команде долго приходили, но, по-моему толком еще не научились. Лично мое мнение — очень-очень нужно избавляться от таких вещей, когда «об этом здесь не говорят». Это и есть искренность и открытость сплоченной команды, о которой много пишут, но мало представляют.

В тему мне вспомнилось выступление Джима МакКарти (Jim McCarthy) на конференции SDBP пару лет назад (я писал отчет), где он рассказывал о «Core Protocols» — протоколе для межличностном общении в команде. С удивлением обнаружил, что до сих пор нету перевода на русский (или я не нашел?).

Резюме

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

Репликация: База Знаний «Заказных Информ Систем» → «Software People 2010: отчет Игоря Беспальчука»

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