2009-06-18 Отчет о SEF-2009: (shows)

Материал из CustisWiki

Перейти к: навигация, поиск
Серия из трех постов:

В продолжении темы конференции SEF-2009 (начало в предыдущем посте) тут мы, Стас Фомин и Андрей Бибичев, рассмотрим запомнившиеся доклады. Вернее все те доклады, на которых нам удалось сходить. Часто наш выбор тем совпадал и были мы только два дня из трёх, так что это далеко не все интересные доклады, прочитанные на конференции.

Открытие

К нашему удивлению, открытие конференции не свелось к обычной скуке на тему «как здорово, что все мы здесь сегодня собрались»/ «спасибо нам самим за такую хорошую организацию столь сложного мероприятия», сдобренной пафосной чушью спонсоров и свадебных генералов (в Москве часто на открытие выступают вендоры, а иногда и вообще люди не «в теме» — например, депутаты). Да, на открытии были вполне содержательные доклады с обзором отрасли и её перспектив.

Так, декан экономического факультета БГУ Ковалев М.М., неожиданно для своего почтенного возраста, изложил вполне разумное понимание необходимых стратегий государственного уровня для развития IT в условиях Кризиса™ (забавно, был в курсе модных теорий Хазина) — максимальное налоговое благоприятствование IT-области, строительство «постиндустривальных дорог», т.е. прокладка интернет-магистралей, выход на 0.5% мирового софт-аутсорсинга (по сути борьба за первую десятку мест после «оторвавшихся лидеров» — Индии и Ирландии), с поддержанием «интеллектуальной» ниши/специализации, т.е. репутацию не быдлокодеров, а грамотных программистов и интеграторов, способных на нетривиальные и даже наукоемкие решения, а для этого — «прокачка» образования начиная от школьного, мощный пиар на запад. Цитата — «… надо бы и к этим деньгам поиметь доступ…». Назывались вменяемые цифры, например, об среднегодовом объеме работ $40000 в год на разработчика (на открытии московского SECR-2008 от разработчика «требовали» приносить в контору $1000000 в год). Можно посмотреть видео доклада.

Затем был доклад президента ассоциации РУССОФТ Валентина Макарова, сразу купившего симпатии аудитории путевым наблюдением «… каждый раз радуюсь, только переезжаю границу и сразу видно, что другая страна совсем: все в порядке, красиво, КОРОВЫ…».

Идея организаторам — следующий минский SEF снабдить маскотом «Корова™ с клавиатурой».

Опять весьма конкретные замеры белорусской IT-индустрии по РУССОФТовской методике (объемы, структура, зарплаты), списки ведущих российско-белорусских аутсорсинговых компаний. Отмечен существенный уровень законодательной господдержки: налоговый режим, IT-оффшоры «Парк высоких технологий», «Инфопарк», поддержка образования в сфере ИТ. Выдвигалась идея альянса славянских стран (РФ, РБ, Украины) как «полюса высокотехнологичного аутсорсинга», общий объем которого уже превышает, например, в полтора раза вклад Китая. Есть презентация и видео.

Затем очень кратко и насыщенно  (четкая, корректная инфографика) выступил Александр Юруть — аналитик портала dev.by — белорусский рынок труда программистов в цифрах. Конечно, относительно московских зарплаты выглядят несколько скромно (плюс их, особенно для низких квалификаций, процентов на 20-30% подрезал Кризис™), но если сравнивать с «замкадной» РФ — уровень зарплат в РБ, думаю, не ниже.

Человеческий фактор: про что забывают менеджеры

Александр Орлов (кстати, вот и его отчет о SEF-2009) приоткрыл завесу вокруг любимой своей темы — роли человеческого фактора в управлении проектами по созданию программного обеспечения. Вообще, делать письменный пересказ живой подачи материала — дело неблагодарное, так что лучше посмотрите авторскую презентацию с наложенной звуковой дорожкой. Единственно, мы возьмём на себя труд и избавим читателей от пары лишних запросов в Google — приведем ссылки на упоминающиеся в докладе материалы (из серии «Must Read 4 PM»):

Мастер-класс «Руководство командой разработчиков»

Сергей Архипенков провел  качественный и обстоятельный мастер-класс от технически подкованного и опытного PM-а про нетехнические хитрости в управлении командой разработчиков (есть презентация):

  • В материале активно используются элементы теории индикаторов типов личности Майерс-Бриггс (Myers-Briggs Type Indicator, MBTI) и командных ролей по Белбину, что не так часто встретишь в материалах, касающихся программирования. Заметим, правда, что в нашей компании был даже внутренний семинар на эти, казалось бы, чисто гуманитарные темы.
  • Утверждается, что все мы с вами — флегматики → (интроверты ×логики ×рационалы), зато делимся на сенсориков («конкретное» восприятие) и интуитов (не путать с одноименным онлайн образованием).
  • Еще нас (ваших покорных) до глубины души взволновала формула E = IQ × EQ2, которая моделирует зависимость эффективности (E) сотрудника от его IQ (интеллектуального уровня) и EQ (эмоционального интеллекта) – да, с EQ у нас явные проблемы… Правда сообразительная часть аудитории тут же заметила, что формула применима только при IQ и EQ не меньше единицы, т.е. «нормировка» важна (а эта «нефизичность» формулы нас, как выпускников МФТИ, сильно смущает).
    На выступлении был аншлаг — по какому-то странному недосмотру Сергею был выделен не главный зал, а одна из двух дополнительных аудиторий (хоть весьма и не маленькая, но всё же не такая вместительная, как главный зал), так что народ плотно сидел и стоял в проходах и даже у двери →→→ многие желающие даже не смогли попасть внутрь.

Тем, кто заинтересовался подобным взглядом на проблемы управления флегматичными раздолбаями разработчиками, советуем прочитать книжку Сергея «Руководство командой разработчиков программного обеспечения». 

Круглый стол «Как провалить программный проект. Вредные советы»

Это была интерактивная импровизация известных ПиэМ гуру/тренеров — Сергея Архипенкова и примкнувших к нему Александра Орлова, Асхата Уразбаева, Дениса Петелина и Юрия Шиляева.

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

Там же ПиэМы-ведущие и объявили публично о создании SPM Guild — «Гильдии менеджеров программных проектов» (независимое международное сообщество профессионалов в управлении проектами разработки программного обеспечения).

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

Career Development в EPAM Systems

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

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

В результате, внедрена следующая ролевая модель обучения:

  • Менти (не путать сментами) — обучаемые, обычно сгруппированы в небольшие группы по 2-3 человека, к каждой из групп приданментор.
  • Ментор — собственно «джедай-специалист», рулящий обкаткой приданной ему группы (2-3менти) на реальных проектах, выдающий им задания и проверяющий выполнение. На обучение тратит не больше 20% (?возможно меньше) времени.
  • Кураторfull-time погруженный в обучение специалист, приносящий себя в жертву готовящий и читающий лекции для группы из приблизительно 30менти.А в качестве мотивации на обучение «подованов» — джедаям объявляется ультиматум — «никакого повышения, пока не подготовите себе замену».
    Насколько я понял, пообщавшись потом в кулуарах — это не значит, стать «начальником воспитанных менти», ведь тогда организационная иерархия выродилась бы в «вертикаль власти», это скорее означает повышение грейда и, следовательно, зарплаты.

Собственно направлений обучения не так много — J2EE, .Net, NetWeaver, Тестирование, и после объявления долгожданных конкретных цифр: →→112 групп, 215 менти

    • 49 в .NET направлении
    • 34 в J2EE направлении
    • 39 в SAP NetWeaver направлении
    • 93 в Product Functional Testing направлении

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

CMMI® "для маленькой такой компании". Опыт внедрения и успешного оценивания

Александр Кондаков (его отчет о SEF-2009), уникальный для РФ специалист — сертифицированный SEI оценщик компании по «страшному кодексу» CMMI, рассказал, что на самом деле это не так страшно, ничуть не сложно, и по сути, требует от компании только одного — желания быть сертифицированной, а это вполне доступно не только огромным зарегулированным софт-монстрам, но и небольшим командам. CMMI имеет много гитик/уровней, и наверняка найдется тот, который соответствует вашей компании, а наличие CMMI-сертификата может благоприятно отразится на ваших взаимотношениях с заказчиком. Об этом он рассказал на примере, как ни странно, не российской, а небольшой испанской компании, где собрался десяток сильных программистов со всего мира (ибо хорошие испанские программисты, серьезная редкость, как ииспанские ученые— попробуйте вспомнить хоть одного, разумеется после эпохи Инквизиции, —прим. Стаса), чтобы совмещать работу с пляжным отдыхом. А заказчиком их были европейские военные (ВМС, подлодки), и стиль работы этих парней их несколько беспокоил. Так вот, эти ребята получили оценку CMMI-Dev v1.2, который успокоил заказчика, плюс консалтинг по организации процесса разработки — что пригодилось им самим.

В последующей дискуссии из зала стали выступать на тему что «CMMI до level 3 — это не круто, а у нас именно CMMI 3», но, такое хвастовство размерами уровнями мы порицаем.

Интеграция приложений

Доклад Романа Петрова из Epam Systems выглядел многообещающие — сия задача, актуальная как никогда, ибо мировая маркентингово-ITшная мысль уже лет пять как развернулась от недостижимого идеала Единой Правильной Системы Автоматизации Вашего Бизнеса, к реинкарнированной и реабилитированной идее «лоскутной автоматизации» на базе нового стека стандартов, протоколов и архитектур, только своими названиями полностью исчерпавшего трехбуквенные аббревиатуры. Ну да, имеются в виду концепции Единой Шины и Сервисной Архитектуры, приход которых уже давно предсказывают оракулы вроде Гарднера с его магическими квадратами, а Вендоры (местами, с примкнувшим open-source миром) уже выкатывают кандидатов на роль этих мессий — IBM Websphere ESB и Websphere Message Broker, Sun Glassfish OpenESB, Oracle Enterprise Service Bus, Apache ServiceMix, Apache FUSE,  Mule, …
Единственно — пока нет заслуживающих доверия сообщений об успешных внедрениях в реальном российском бизнесе хорошего масштаба, с сохранением legacy-приложений, с хорошей производительностью и надежностью. Поэтому любое сообщение о реальном внедрении, или даже о процессе разумного (а не политического) выбора, с построением макетов, стендовыми испытаниями, взвешиванием десятка факторов — просто на вес золота.

Вот собственно, что и хотелось услышать, исходя из названия доклада. Однако, докладчик сначала (16 из 20 слайдов), рассказывал, что он понимает под интеграцией (всевозможные графы материальных и информационных потоков), затем очертил встреченную задачу — плохо интегрированный разнородный legacy-софт (вроде даже COBOL был), и следующим слайдом объявил решение — Microsoft BizTalk-сервер. Пока аудитория дивилась (ибо BizTalk далеко не в лидерах этой области, и даже, можно сказать, «не в моде»), докладчик показал следующий слайд, где альтернативными механизмами «интеграции» назывались «M$ SQL Server, M$ SharePoint, Windows Server…». С такой логикой не хватало только «M$ Word и даже M$ Notepad». Аудитория стала интересоваться, каким же образом удалось придти к такому выбору — оказалось никаких попыток развернуть макеты альтернатив и не делалось, а выбор сделан из «экономических соображений», как «наиболее дешевый». Это очень удивительное утверждение, ибо есть ведь и бесплатные, и open-source шины. Кроме того, докладчик, подавал как экономию «бесплатный доступ разработчику на 120 дней» к набору BizTalk-коннекторов. О радость, да. Звучало как «…ни о каком принуждении граждан не могло быть и речи, все были богаты и свободны от забот, и даже самый последний землепашец имел не менее трех рабов…»©.
Ну и окончательно выяснилось, что эта интеграция тоже была окончательная и бесповоротная — все эти интегрируемые legacy-приложения переписали под .NET.
(Радикальное решение проблемы бедности, ага).

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

Мастер-класс «Качество и usability»

Лично у нас доклад Геннадия Драгуна оставил смешанное впечатление: с одной стороны Геннадий старался и тема весьма и весьма животрепещущая, но с другой стороны для мастер-класса материал был слабоват (на наш искушенный и требовательный вкус), не содержал живых примеров и кейсов, аппелировал к достаточно ограниченной области применимости — публичные web-сайты относительно общего назначения, где пользователь бывает либо один раз, либо так редко, что забывает как оно там всё устроено, так что оптимизировать стоит только легкость «познания/вспоминания» интерфейса, но никак не скорость работы с ним.

В частности, большую дискуссию вызвало использование термина Data-Driven-Design:

  • согласно Геннадию, это дизайн пользовательского интерфейса, основанный на реальной статистике «кликов» живых пользователей наproduction-системе (что вслед за чем делали, куда «тыркались» и т.п.) — когда мы (голоса из зала) засомневались, нас отослали к блоговому посту «Goodbye Google»;
  • мы же для себя этот термин всегда понимали как «проектирование (или даже генерацию) пользовательских интерфейсов, опираясь на структуру данных – например, структуру реляционных таблиц» (типичный пример, дизайн №3 из следующего комикса);
  • гугление, которое мы провели постфактум, показало, что термин действительно запутанный, значений у него масса — кроме указанных выше это еще:
    • способ объектно-ориентированного проектирования;
    • а также разделение метаданных, управляющих дизайном (например, CSS), и логики приложения (дабы отделить мух от котлет дизайнеров от программистов);
      однако смысл, в котором этот термин употребил Геннадий — самый сомнительный и натянутый.

В списке литературы, рекомендуемым Геннадием к изучению по теме, мы не  обнаружили книги Джефа Раскина «Humane Interface», что очень жаль, так как вещь действительно стоящая(особенно на фоне «слонов», ЕВПОЧЯ — п рим. Андрея).'

Дальше — больше: уже в Москве выяснилось, что в другой своей презентации Геннадий приводит примеры своих проектов, которые он считает успешными с точки зрения usability, и среди них мы с ужасом и неподдельным раздражением увидели сайт online-заказа билетов s7.ru (Стас, увы, имел опыт заказа билетов на этом сайте).

Так что, если кто организует (или собирается организовывать) мероприятия, посвященный юзабилити, позовите нас — нам есть что сказать!

Мастер-класс Дениса Иванова «Моделирование на UML»

Материал, на наш взгляд, был скомпонован достаточно странно: после общего определения понятия UML (нам это напомнило сцену в Симпсонах, когда Гомеру расшифровывали аббревиатуру «V.I.P.») Денис сразу перешел к разбору достаточно навороченных кейсов из серии «вы спрашивали – мы отвечаем», открыв word-файл с вопросами (то ли с форумов, то ли из личной переписки). Cкурпулезно разбирая ответы, Денис рисовал нагруженные мульти-псевдо-гипер-орграфы (цитата из доклада: «UML-диаграмма — это просто, это всего лишь мульти-псевдо-гипер-орграф») и вдавался в такие тонкости стандарта, которые, наверняка, и его авторы-то не помнят ;-) Нам, и не только нам (см. фото), показалось это слишком скучным, так что мы поспешили «мигрировать» в другой зал — на доклад Сергея Кудряшова — и не пожалели об этом (см. ниже).

Отметим, что мы в своей работе активно используем UML, но в основном для эскизного моделирования, на строгой букве стандарта не зацикливаемся, отдавая себе отчет в том, что это зачастую уже «ненормативный» UML. Короче, к UML мы относимся как к инструменту, а не как к храму/собору — т.е. чисто потребительски и почти не выходя за объем, описанный в карманном бестселлере Мартина Фаулера «UML 2.0» (начинающим юэмелистам можем порекомендовать начать знакомство с предметом именно с неё, а может даже ей и ограничиться).

Организация процесса проектирования приложений в софтверной компании

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

Моменты, особенно запавшие в душу:

  • Keading Time — это час послеобеденного времени, официально отводимый на чтение книг/статей/блогов по специальности, их обсуждение. Название происходит отReading Time, но из-за глюков переключения раскладки в Mac OS первая латинская букваR часто превращалась в русскуюK, а получившаяся игра слов понравилась.
  • Если у сотрудника непомерно выросла самооценка и он хочет повышение з/п, а вы с этим не согласны (считаете самооценку завышенной) — отправьте в качестве «бонуса» этого сотрудника с докладом на профильную конференцию — там ему самооценку быстро и бесплатно «вправят» коллеги из других компаний. Два зайца одним выстрелом!
  • Уровень крутизны специалиста правильно мерить простой шкалой всего из трех пунктов:
    • начинающий;
    • мастер;
    • индивидуальный стиль деятельности (ИСД); причем если сотрудник реально дорос до ИСД, то его надо выгонять организовывать собственную компанию!
  • Еще Сергей советовал всячески поощрять неформальное общение: вечером за кружкой пива или, как предпочитает сам Сергей, утром за чашкой чая (на что Стас несколько громко прошептал  «в постели», чем вызвал смех в окружающей нас части зала).

Типичные проблемы выявления требований и их решение

Александр Байкин рассказал существенно обновленную версию доклада «Гибкое управление требованиями», который ранее был в жаркой дискуссии «обкатан» на нашем семинаре (по ссылке есть видео той версии с обсуждением).

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

Были еще на паре технических докладов, т.е. докладов, рассказывающих на техническом уровне об одной из вендорских технологий (ASP.NET MVC, нагрузочное тестирование, …), но в целом, уникальной/прорывной информации они не содержали, поэтому здесь мы о них подробно повествовать не будем.

Ну и завершим рассказ о конференции, кратким постом о наших докладах.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.