Текущая версия на 19:02, 13 апреля 2011

Отчет Стаса Фомина, все замечания, претензии и прочие комментарии welcomed (можно письмами, можно комментировать в блоге).

Несколько лет назад, озлобленный безумной организацией очередной IT-конференции я разродился длинным и злобным конструктивным постом на тему очевидных правил правильной организации IT-конференций. И эту запись читали многие организаторы конференций (были подтверждающие отзывы), но вот только эта конференция стала близкой к идеалу по организационным вопросам^[1].

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

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

Но это никак не снобизм! Я беру на себя кармическое обязательство просмотреть все опубликованные записи всех выступлений с Software People-2010, и опубликовать ниже отзывы-обзоры и о них. А пока можно почитать отзывы коллег, честно посещавших доклады.

Возможно эту фишку «просекли» и многие другие участники — и залы «Инфопространства» не были так забиты, как на Highload или РИТ. Ну и плюс апрель-месяц был дико перенасыщен конференциями — за неделю до SWP2010 был трехдневный РИТ-2010, а за пару дней до этого, в выходные был TrainingLabs-2010 (звали кстати, но никак не мог пойти, ибо overkill).

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

Более того, докладчиков стимулировали «работать» и на обеде — оказалось, каждому докладчику был выдан персональный стол с табличкой, чтобы жаждущие ответов могли к нему подсесть и получить интеллектуальный или моральный satisfaction.

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

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

Мой доклад

Ибо я установил новый рекорд по подготовке к выступлению на конференции. Готовится (непосредственно выступление) я начал после начала конференции, точнее в ночь первого дня.

Но до этого просто не было времени — куча работы, неделю до этого прерванная посещением РИТ-2010 (где тоже пришлось выступать), плюс я придерживаюсь принципа не инвестировать время в подготовку brilliant презентаций — это Путь Продавца, а пытаюсь потратить все время на что-то интересное и полезное, чтобы об этом было не стыдно рассказать, и более того, чтобы рассказывать то особо не требовалось — чтобы все это можно было показать, предъявить живьем — Evidence рулит, это Путь Инженера и Ученого. И хотя таким образом можно рассказывать только об очень конкретных, технологических темах — т.е. каждый раз нужно предъявлять какие-то новые, интересные достижения, требующие реальной работы^[2], это мне интересно, ибо:

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

Фиг знает, что бы у меня там было — думаю, и 3D-видео, и пение, и цирковое выступление, и стриптиз… много идей у меня. А так приходится жестко отсекать все дорогостоящее, ну и спортивный азарт — там, где люди тратят месяц на десяток унылых слайдов, сделать за несколько часов часовой мультфильм с динамичной инфографикой.

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

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

Ах, да. Для выступления на Software People, у меня был дополнительный challenge — выступить под видео, и что бы при этом сработала трансляция. Для этого я приехал за день до, поговорил с ребятами, обеспечивающими связь и трансляцию.

Это были парни из http://kreml.tv (судя по визиткам, хотя да звучит это немного странно, для специалистов по записи лекций и семинаров), и работали они имхо, более вменяемо, чем, например, Firmbook или COMDI. Например, они не использовали Автоматику с большой буквы^[3] для трансляции слайдов, когда трансляция экрана для кодинга или какой-то живой демонстрации вообще невозможна. Здесь же было грамотно — можно было загрузить заранее заготовленное видео и пустить его трансляцию, была возможность агностик-перехвата RGB-канала от компьютера к экрану, с последующей оцифровкой и сжатием, а оператор управлял расположением говорящей головы докладчика относительно изображения с компьютера.

Еще им в плюс — то, что в вебтрансляции не было Анонимного Чятега со Школотой и Троллями (стандартные трансляции фирмбука и COMDI), а как обратная связь использовался твиттер (а это все-таки не полный градус анонимности, как микродвач на РИТовских трансляциях). Да, некоторые не рекомендуют использовать твиттер для комментирования конференций, наверное одноразовый чат с OpenID-авторизацией был бы экологичнее, но, имхо, это вполне допустимо.

Но когда я приехал в первый день, начались неудачи — помер и отказался включаться ноутбук жены (аккумулятор в нем совсем ёк, а тут похоже, как-то отошел контакт питания и весь вечер отказывался включаться) — в результате протестировать воспроизведение с него чернового видео на конференционную плазму не удалось. Не удалось также протестировать и захват. Видео в AVI-формате (я притащил его в нескольких разрешениях и кодеках), система трансляции есть отказалась (она явно микрософтовская, ибо родной формат для нее был WMV), программа-супер-перекодировщик, которой парни гордились (понимает все форматы!) облажалась тоже, хотя что может быть проще тупого AVI с h264-видео каналом и MP3-аудио?

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

Там уже потестировать не удалось, пришлось вступать в бой с переправы.

В результате — подготовленное мной WMV-видео в HD (1024x576) отлично пошло в трансляцию (с чем не справился суперпупердорогойперекодировщик, сделал ffmpeg), но когда я увидел ноутбук организаторов, я понял, что это нетбук! А проблему с торможением видео на них я уже проходил!

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

Пришлось срочно перейти к плану «Ц», и перейти к трансляции видео с ноутбука жены. Как Гагарин, я махнул рукой, сказал «Поехали!», и с парнями синхронно запустили видео в трансляцию и на экран. И тут начался ад. Во-первых, VLC некорректно воспроизводил некоторые фреймы (регулярно картинка «разваливалась на пиксели» артефакты некорректного сжатия) — с чем это было связано, я так и не выяснил, — то ли глюки VLC, то ли даже этот ноутбук не потянул видео, то ли как-то влияло подключение к плазме и клон-режим (руки так и не дошли выяснить, хотя надо конечно выяснить, дабы не повторилось). Во-вторых, как же я ненавижу VLC! Все что в нем можно сделать неудобно, сделано неудобно! Он не отключал стандартный виндовый скринсейвер при просмотре! В результате, каждую минуту у меня включался скринсейвер, мне приходилось пинать комп, после чего все несколько секунд наблюдали обои рабочего стола («мой сын в два года на море»), потом наблюдать несколько секунд полоску инструментов просмотра VLC — и так более сорока раз. Ну и под конец, чертов VLC, вместо того, чтобы показывать последний «контактно-рекламный кадр», тупо завершает работу («и хуже выдумать не мог»).

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

Правда тут был таки плюс, по сравнению с выступлением на РИТ — там у меня вообще не было возможности смотреть на видео доклада — там ноутбук мне настроили только в режиме «дополнительного экрана». Да и с места, где должен стоять докладчик, на ноутбук вообще было не удобно смотреть (90°), а поворачиваться к плазме (180°, т.е. задом к слушателям) было просто недопустимо. И там я применил дикий цирковой лайфхак — незаметно (никто по опросу не заметил), сжимал в руке одолженный андроид-телефон, с синхронно запущенным видео меньшего разрешения, и подглядывал туда. Здесь хотя бы я мог посматривать на нормальный экран, не теряя зрительного контакта с аудиторией.

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

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

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

Резюмирую — в общем, был фейл (организаторы прислали мне — «…средний балл за Ваш доклад: 4,66»), но не эпик-фейл. Да, трансляцию посмотрела моя жена, ей понравилось. Особенно переданный через «телевизор» привет.

Ну и последняя просьба организаторам — видите, какой у меня стиль работы? Поэтому если будете меня приглашать — приглашайте сильно заранее.

Общение

Общался и с знакомыми докладчиками (почти все уже знакомы), и с участниками, темы были разнообразны (ага, скандалы-слухи-расследования — где разоряются, где увольняют, где бьют батогами…).

Можно встретить очень полезных людей, которые сходу, за минуту, решат твою проблему. Например, главный в Яндексе по нагрузочному тестированию, разобрался с 100% загрузкой CPU моего нетбука, вызываемого интерфейсом Яндекс.Почты. Оказалось — это так грузит «виджет» Яндекс.Онлайна, который, в отличие от веб-интерфейса Google Talk, похоже каждую миллисекунду делает poll с сервера. Решение — вырубить его из интерфейса настройкой. Из серьезных тем, за которых я чувствую свою ответственность — это публикация в open-source тех наших доработок открытых инструментов, благодаря которым они выглядят такими чистыми и шелковистыми.

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

На самом деле, надо начинать выкладывать — просто изначально были разные мысли — как публиковать? Может как раз сделать это используя аутентичную инфраструктуру — развернуть весь этот зоопарк (Bugzilla, Testopia, SVN, ViewVC, SVNSearcher, Mediawiki, FeedOnFeeds…) онлайн, чтобы была эдакая рефлексия — развитие этих проектов шло с использованием их самих?

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

Т.е. наверно, лучше выбрать какую-то крупную, бесплатную и независимую площадку.

Тут у меня были мысли брать площадку с DVCS, чтобы все желающие могли легко делать fork и личные доработки. Возможно даже вести personal branches на самой этой площадке.

Но для этого надо было бы выбрать оптимальную DVCS (из Git, Mercurial и Bazaar, очевидно), а этот выбор для меня затянулся — все три чем-нибудь мне не нравятся (претензии к ним — отдельная тема).

Вероятно надо опять наступить на горло собственному перфекционизму, взять какую-нибудь площадку с историей (например, старый добрый, хоть и рекламный, Sourceforge^[4]), и выкладываться туда частями, по проекту на расширение. Если есть идеи — как и куда правильно выкладывать — пишите, комментируйте.

Доклады других участников

Управление знаниями организации – миф или реальность? Как построить эффективную базу знаний компании

Ведущий

Стас Калканов

Материалы

Аннотация и Слайды на GoogleDocs

Тема была весьма близка к моей, поэтому не зайти было просто нельзя (хотя я заговорился и опоздал к началу). Докладчик, кроме того, что мой тезка, занимается схожими вещами — выбор инструментария и процессов в Luxofte, и в то время, как мы легли на ViewVC (SVN)+Bugzilla+MediaWiki, они пришли к схожей картине, но на близких, хоть и платных инструментах: FishEye (SVN)+JIRA+Confluence + свои доработки. В этот раз, он рассказывал о базе знаний, о схожей истории, как Confluence у них победила Sharepoint.

Я регулярно прошу Стаса делать более конкретные презентации, чтобы было видно как все это выглядит, и вообще, «был ли мальчик»©. Но увы, и в этот раз пришлось довольствоваться буллет-тезисами, один из которых гласил «В презентации сознательно не используются скриншоты, содержащие информацию о структуре и содержимом базы знаний Люксофт». Оно конечно понятно, NDA, «Секрет фирмы» и все такое, но в такой огромной компании должны же быть нейтральные части в базе знаний, которых можно будет показать наружу? В общем, еще раз пользуясь случаем, призываю всех, кто делает доклады об инструментах — показывать их.

Они использовали несколько лет (с 2003 года) SharePoint — сначала как портал и БЗ «команды качества» (EnPedia:SEPG), постепенно взваливая на SharePoint больше задач, доведя его до корпоративного портала и базы знаний, но параллельно (с 2007) опять таки в недрах SEPG они дозрели до вики-системы (Confluence), и постепенно переключили на нее все функции портала и базы знаний, оставив на SharePoint некий минимум, оптимально подходящий для людей, которым любая вики будет слишком сложной.

Причины неудачи SharePoint приводились разные, одна из основных — его waterfall-подход: сначала задать структуру БЗ (иерархию и шаблоны страниц и т.п.), и только потом ее наполнять. А об удовлетворяющей всех структуре договорится со всеми было нереально.

В органическом вики-подходе все была предоставлена свобода и гибкость — и в результате база знаний выросла сама, а структура в разных проектах естественным образом сложилась более-менее одинаковой и (surprise!) похожей на то, что пытались «внедрить сверху» с сопротивлением, через SharePoint.

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

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

Тут я даже как-то в раздумье. Реальная мотивация за знания? Хм. это как-то похоже на денежную микромотивацию, плюс «оценка» — это страшная вещь, не всегда польза от нее (например, для сортировки в поиске), компенсирует возможный демотивирующий и даже деструктивный эффект. Жаль, конечно, что на эту «социалку» не удалось посмотреть живьем (хоть в щелочку).

У нас кстати, есть немного социальных игр вокруг знаний, тоже на платформе вики (например, голосования за семинары), и с этим тоже были некоторые неприятные проблемы (скажем, это было катализатором неких проблем).

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

Peopleware или процесс создания интерактивных компьютерных продуктов с учётом человеческого фактора

• Аннотация

• Артем Кузнецов, http://www.uexpert.ru/

Очень добротное введение в тему юзабилити.

Сбалансированное — там есть:

• и просто юзабилити (условно говоря, труды Раскина и семинар Андрея «Гуманный интерфейс», Стивен Сеов «Проектируем время. Психология восприятия времени в программном обеспечении»);
• и готовые интерфейсные решения (условно Алан Купер об интерфейсе. Основы проектирования взаимодействия);
• и веб-юзабилити (Якоб Нильсен, Стивен Круг);
• мне кажется, что от выступления Андрея на WUD-2009, было взято немало (антропоморфизм, толерантность, терпимость…).

Выступление было удачно замаскировано под мемы конференции — конференция прошла под знаком «Peopleware»:

• и название конференции «Software People»,
• и рекламировали тут новую книгу ДеМарко, автора книги «Peopleware»
• и ключевой докладчик, Питер Хрушка, говорил об эпохах «Hardware»→«Software»→«Peopleware», и хотя Питер имел в виду взаимодействие в командах.

Автор доклада ввел «Peopleware» в название, повторил в докладе метафору эпох «Hardware»→«Software»→«Peopleware», и при этом интерпретировал «Peopleware», как «Заботу о людях», и что вот, оно пришло время юзабилити.

Но это чисто «мотивирующая драматургия» — а информационная часть была вполне достойной, как по форме, так и по содержанию:

• Хорошая презентация в Keynote, читаемая, контрастная, благородные цвета и шрифты, уместная анимация (хотя от перехода «кручение куба» кружится голова).
• Практика использования «персонажей» даже в презентации.
• Не только изложены базовые принципы, но и показаны пара живых кейсов^[5].

Резюме — must see всем, и разработчикам, аналитикам и тестировщикам (тестировщики — при тестировании обязательно обращайте внимание на юзабилити, пусть это не будет Tруѣ-certified-юзабилити аудит, но это будет супервклад)!

Это видео (четыре файла видео, которое он раздавал на конференции, в сумме меньше чем два часа), можно посмотреть параллельно с ненапряжной работой, и так сказать «вкурить основы», не тратя время на несколько толстых книжек.

Доклады, просмотренные в видео

Архитектура ИС. Принципы построения хорошей архитектуры

Докладчик

Андрей Вербицкий

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

Андрей же, заинтриговав волшебной формулой «Современная архитектура ИС стоит на трех китах — Identity, CRM, SelfCare», сразу же ушел в дебри надежных строительных метафор. Цель было пояснить, что архитектура — это компромисс, причем далеко не одномерный и не плоский — даже строительную архитектуру нельзя свести только к технологиям или только к формам, влияет и ландшафт (метафора окружения), и время, и потребители. И все это подтвержается известными разношерстными примерами плохих и хороших архитектурных решений:

Плохие

• Домик над водопадом
• Паромная переправа в Белфасте

Хорошие

• классический русский сруб
• бруклинский мост
• эйфелева башня

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

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

Разумеется, важно достигать компромисса между универсальностью (супер-универсальная-нежизнеспособная система) и специализацией (бодрая, но заточенная под конкретные условия или заказчика система, которую потом, пытаются продавать другим заказчикам^[6]

В качестве эффективных hacks предложен ТРИЗ, и принцип Парето^[7].

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

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

Далее — классический менеджерский треугольник рисков (Scope-Cost-Time), который традиционно рисуют равнобедренным — устарел. Время сейчас всем важнее всего!

Именно в этом успех Agile, где Scope и Cost разменивают на время и выигрывают! Сделайте 80% самого нужного заказчику за 20% времени (Парето, ага) и разбегайтесь взаимоудовлетворенными! Счастье всем даром и пусть никто не уйдет обиженным!©

В области безопасности Андрей пообещал, что логины-пароли уйдут в прошлое, а в светлом будущем всех нас ждет полное, материально-географическое, отделение бизнес-информации (в частности, персональных данных), от технической. Будет единые права доступа, вероятно Single Sign On и все такое.

Это как раз и был первый кит-тренд из формулы — Identity.

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

Следующий кит — CRM (под которым, я думаю, все привыкли понимать Customer Relationship Management, как проблемы, так и продукты-решения), тут с одной стороны означал «персонализацию клиента» (учет разных культур, географий-континентов и т.п.), с другой — почему-то означал возможность задания бизнес-логики (как-то мне неочевидно, почему это сюда).

Ну и третий тренд — SelfCare, по сути — делегация всего на клиента, но в удобной для него форме, чтобы убить опять таки двух зайцев — и сократить свои расходы, и повысить лояльность клиента. Девиз: «Клиент, это тоже равноправный сотрудник, только зарплату получает услугами».

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

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

Ну тут я совсем не согласен. Полно ресурсов по архитектуре! Книги — тот же Фаулер с паттернами всего, плюс как раз на этой конференции всем участникам раздавали бесплатно русский перевод микрософтовского свода архитектурных практик. Интернет ресурсов тоже не мало, от того же Фаулера до целого портала http://infoq.com (статьи, презентации, видеовыступления — архитектурные решения, свежие кейсы — все очень актуальное).

Что касается корпоративной библиотеки архитектур, как «меню» и чего-то такого, «текстового» — то внутри компаний best архитектуры воплащаются не в бумажки (ну и в них немного тоже), а в первую очередь в работающие фреймворки, программные каркасы (свои самоделки или адаптации-интеграции других, свободных или вендорский фреймворков, в общем, живой код, а не мертвый текст! И тогда да, при старте нового проекта в первую очередь примеряются имеющиеся в «гардеробе» компании каркасы, и даже, если ни один из них не подойдет окончательно, часто на их основе строится прототип (потому что это быстро, это Agile, и даже если этот прототип окончательно не приживется, разведка боем даст возможность выяснить настоящую иерархию требований).

Далее начались вопросы зрителей.

• Управление проектами …?
  • — нет, не связано с архитектурой.

• Управление знаниями… где надежный фундамент в IT-архитектуре?
  • Докладчик посетовал на бескультурье.
  • Я же думаю, что это принципиально неверная метафора «идеальный неизменный фундамент» — нет такого. Зашившись на бестпрактику («лучший Cobol!» «Лучшая СУБД — Informix с прогрессивной двухзвенкой!») — и глазом не моргнешь, как окажешься на обочине, с умчавшимися в точку горизонта конкурентами.

• UML… ?
  • Нет, это не архитектура.
  • Угу, это как раз началось выяснение, о какой архитектуре шла речь.

• ТРИЗ… ? Это же вроде разрушение шаблонов?
  • Нет, ТРИЗ это как раз шаблонные алгоритмы. Только другие.

• Может Архитектура это Платформа? (ага, близко к моему пониманию).
  • Нет, платформа это как Шарепоинт или 1С, т.е. это конструктор, это ограниченность. (Фреймворки! Вот что надо было говорить!)

Риски управления рисками

Докладчик

Григорий Печенкин

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

Хвалился водопад, впервые показавший, что разработка≠программирование, и атаковавший риски с позиции учета, покрытия и балансировки. В великом и ужасном PMBOK («кто в книгу эту заглянуть посмеет, того смертельный ужас унесет ©») прописано аж 6 процессов управления рисками. Ну и нарушение заповедей — смертный грех («нет выделенного аналитика → это не риск, это 100% проблема»). Классическая защита тяжелых методологий — «делайте по правилам, иначе наступите на Страшные Грабли» (на своем опыте, типа сначала не было тестировщиков были одни кодеры… ну и дальше понятно). «Сначала надо решить Методологическую Проблему» («лучше день потерять, потом за час добежать» ©) → «когда я осознал проблему, я стал активным участником UML2.ru».

Хвалились книги Майкла Тернера «Основы MSF», и что-то там про RUP.

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

Причем начать управлять рисками и бороться с странными проблемами, часто попадаешь на конфликты. («Нереальные сроки для разработчиков ←→ бонусы сейлзам»).

Много картинок и отсылок к Dilbertу.

Ну и в частности по этому — «идентификация рисков» нужно делать коллективно (иначе будешь «пророком в своем отечестве»). Желательно возбудить мозговым штурмом, хотя это редкость и дорого.

Отдельно — культура компании должна разрешать ошибки. Если это не так — правильный менеджер должен создавать такую зону хотя бы в своей команде (закрывая ее своей грудью). Ошибки, неопределенность, вероятность — неизбежна. Надо учится с этим работать (оценки через Planning Poker — это про это).

Секция рисков связанных с заказчиком — отсылка к докладу «Персональные риски аналитика».

Примечания

1. ↑ Впрочем, идея «конференций на курорте» мне по-прежнему нравится сильно больше
2. ↑ и нельзя, как в гуманитарно-менеджерских областях, переливать из пустого в порожнее психологические аспекты, или бесконечно жонглировать терминами
3. ↑ Людей. Cтандартный подход — специальный человек листает слайды на компьютере-трансляторе, поглядывая на экран докладчика, соответственно лаги могут достигать нескольких минут («листатель» отвлекся на беседу со вторым, особенно если второй другого пола).
4. ↑ Google Code видимо не подойдет — его как-то не любит Виталий, принявший у меня царство над багзильным королевством.
5. ↑ Бедные заказчики юзабилити-аудита, они наверное не знают, что все фиговое, что будет у них найдено, будет регулярно препарироваться на конференциях
6. ↑ Они пытаются надеть квадратное ведро на наши круглые головы! (наши клиенты о конкурирующем решении).
7. ↑ Очевидно имелось в виду не «Парето-оптимальные решения» и «равновесие по Нэшу», а принцип «80/20» в какой-либо форме, означающий неравноценность проблем и возможностей (за 20% ресурсов можно снять 80% требований и т.п.)