Викилоги

Участвуя в различных наших конференциях и смотря их материалы часто думаешь о том, как бы конференция выглядела в идеале. Тут три части: подготовка конференции, формирование секций и докладов, собственно проведение и, возможно более важное - последействие, фиксация результатов конференции. Почему результаты могут быть важнее? Потому что они - долгоиграющая составляющая. А еще, хотя общение - безусловно ценно, результаты при хорошей публикации - доступны широкому кругу лиц. Однако, на на большинстве конференций "спасение утопающих - дело рук самих утопающих": докладчики сами публикуют свои доклады или выкладывают презентации, благо это несложно, и тем дело кончается. Хотя необходимо отметить, что есть продвинутые конференции, например, ЛАФ-2010 или ADD-2010, на которых заботятся о фиксации результатов докладов.

Это была преамбула. Теперь предмет поста. Блуждая, точнее, целенаправленно изучая проторы инета на предмет изучения IT-отрасли на западе наткнулся на весьма интересную конференцию WICSA (Working IEEE/IFIP Conference on Software Architecture). Интересна она тем, что помимо сайтов конференции поддерживается wiki, в которую собираются материалы конференции. И не только статьи участников, каждая сессия - продумывается на предмет целей и вопросов, результаты круглых столов и обсуждений - кратко фиксируются. Пример такой фиксации можно посмотреть здесь по конференции, и здесь по отдельной сессии, и в других статьях. Заметим, что в публикациях - статьи, связный текст, а не презентации. Это определяется форматом конференции, который, в отличии от наших - весьма жесткий, докладчику дается 10 минут на презентацию своей работы. Это, кстати, характерно и для других зарубежных конференций. Зато регламент сессии предусматривает, помимо презентаций докладов, еще дискуссии в группах по этим докладам, с фиксацией результатов.

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

P.S. Кстати, сами материалы тоже интересны, читайте. Я, когда подробнее посмотрю - напишу.

В блоге Левенчука появился очень качественный обзор Стандарты представления требований.

Мне этот обзор позволил достаточно четко сформулировать мысль, откуда берет истоки подход через требования. Он берет начало в тех военных системах, для которых характерно две важных особенности. А именно, заказчиков не слишком интересуют деньги и сроки. Деньги - потому что они чужие. И вообще, если стране надо - что их считать. А сроки - потому что их устанавливает партия и правительство, и - ты же не хочешь чтобы тебя обвинили в саботаже. На западе со сроками было несколько по-другому, но суть не особо меняется. Военные не слишком готовы двигаться по требованиям к системе по этим причинам.

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

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

Я тут интенсивно почитал Левенчука — ЖЖ и вокруг, касательно новых стандартов и онтологии знаний, и у меня сложился ряд мыслей по этому поводу.

Во-первых, что есть сам процесс стандартизации вокруг методологий — ISO 24744 (metamodel for development methodologies). Это методологи (западные) в очередной раз резвятся. Они разочаровались в объектно-ориентированном подходе и объектно-ориентированных моделях и вместо этого придумали новую концепцию — онтологического моделирования. Объекты их разочаровали тем, что они не могут провести границу между атрибутом класса и другим классом, с которым есть отношения. А еще — атрибуты плохо отражают динамику изменений и вообще жизнь объекта. Поэтому в новой концепции нет атрибутов, равно как и самих объектов, а есть «факты».

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

Вся эта история и текущее состояние прилично освещена. Стандарт непрерывно переписывается, в новых частях — реализуются новые идеи, плохо совместимые со старыми, при этом старые части — не модернизируются, в результате, например, есть две слегка не совпадающие системы базовых типов, примеры не соответствуют описаниям и много другого знакомого и веселого. А еще — в принципе это все должно сопрягаться с ISO 24774 (life cycle management/process description) и ISO 15926 (data integration), но нормального сопряжения нет.

Что касается полезности стандарта — она сравнима с полезностью стандарта XML, или SWIFT или EdiFact. Причем тренд идет именно в эту сторону — описывается внешний формат представления, а семантику накладываешь ты сам, соответственно, всяк желающий представить свои знания в стандарте сможет для начала описать свою форму — произвольную — форму представления, а потом ей следовать. Конечно, стандартизаторы рассчитывают, что будут библиотеки стандартных форм, и никому не надо будет придумывать свою. Но я думаю, что будет как с EdiFact: Гера рассказывал, что для передачи любых документов, например, накладных там есть приличное множество форм, и если ты с каким-то поставщиком хотите обмениваться, то вы, во-первых, должны между собой договориться о конкретной форме, а дальше — каждый должен запросить своего провайдера, и это есть лишнее звено, поэтому на практике этим не пользуются… Левенчук это тоже высказывает, только по-другому, оптимистичнее. Кстати, есть другой пример — SWIFT — тоже множество форматов передачи различной финансовой информации, только когда мы делали работу с ним для Собина, выяснилось, что почему-то используется формат, где содержательных полей не хватает, поэтому многое пишется в структурированном текстовом комментарии, а вовсе не в полях.

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

На самом деле, способ однозначной фиксации — есть. Это — реализация в информационной системе. Если в информационной системе есть понятие «товарная группа» и у товара обязательна ссылка на группу, то все пользователи точно знают, какая группа у конкретного товара. При этом они могут возмущаться неправильным назначениям групп для конкретных товаров, но это уже — второй вопрос. Если они влиятельны, они могут или добиться изменения значения, и товар перейдет в другую группу, или потребовать завести еще один атрибут «товарная группа-2» и назначить его по другому, и тогда у товара будет сразу две группы. Аналогично, если система считает исполнение плана и бонусы по нему, то мы точно знаем, на сколько каждый менеджер исполнил свой план. Опять-таки можно говорить про несправедливость или дебилизм системы, факт измерения плана не изменится. Это, кстати, очень важная роль информационной системы, мне в свое время это на примерах показывал Гера и я проникся.

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

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

На просторах инета (и кто бы мог подумать - в msdn) найдена статья по сравнительному анализу различных методов выработки архитектуры - Zachman, TOGAF, FEA, Gartner. Весьма интересно. Во вводной части там отсутствуют слова, но они есть в английском оригинале. Если совсем кратко, то суть в следующем.

1. Zachman framework - на самом деле, это таксономия, то есть классификация области архитектуры предприятия на 30 клеточек (5x6), к которым надо относить артефакты, и утверждается, что в идеале все клеточки должны быть заполнены, а каждый артефакт должен быть в одной клеточке.
2. TOGAF - это стандарт на процедуру, процесс порождения архитектуры. При этом он не гарантирует качественной архитектуры в результате.
3. FEA - порождение бюрократических попыток стандартизовать структуру автоматизации для агенств и подразделений правительства США. В целом - оказалось практически мертворожденным.
4. Gartner Methodology - скорее похож на набор успешных практик, нежели на методологию или стандарт.

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

Зато - выскажу мысли, которые возникли, когда метод, процедуру делают стандартом. Ведь TOGAF, например - именно стандарт от OMG для процесса получения архитектуры. Он, правда, не гарантирует правильность и качество архитектуры. На SECR-2010 мэтр от OMG вещал про важность стандартов и начал от пожара в Балтиморе, когда выяснилось, что шланги разных пожарных машин нельзя состыковать, чтобы получить длинный шланг. Такие стандарты безусловно важны. Но когда стандартизуют процесс, то получают совсем другое - получают правила, регламентную процедуру тужения пожара. А это уже перебор. Безусловно, в тушении пожара существуют правила, которым надо следовать - какие вещества чем тушить и тому подобное. Наверняка существуют также хорошие практики, которые полезно знать. Но все это никоим образом не образует стандарта или регламентной процедуры, место стандартов тут - ограничено, в области шлангов, которые должны сопрягаться...

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

Я тут по наводке Майка Кудряшева (для тех, кто знает) обнаружил такую весьма перспективную штуку - ArchiMate. Это произведение OMG, предназначенное для описания систем в виде диаграмм с единой нотацией. В описании выделяется три уровня - бизнес, приложение и технологии, и дихотомия структуры против поведения. Есть еще две другие оси: внешний и внутренний взгляд на систему и индивидуальное против комплексного, но это менее ясно. Для всего этого сделана единая нотация диаграмм, в некотором смысле - весь UML в одном флаконе, ну - почти весь. Есть примеры использования, которые теперь принято называть best practice. Под это еще подложен язык моделирования, как же без него :) и стандарт-спецификация, но это уже не так интересно, как и в случае с UML. А вот смешанных диаграмм мне лично - не хватало. Понятно, что я все равно рисовал, используя разные символы на одной диаграмме, но теперь это можно будет делать, используя новую прогрессивную нотацию - это стандарт 2008 года :) В общем, рекомендую взять на вооружение.

P.S. Для рисования - есть шаблоны Visio

Наконец, дописал отчет по SECR-2010

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

Первое — в том, что информационная система — она не заменит сотрудника и не будет с ним конкурировать. Если взять нового сотрудника, то одно из двух: или он будет негодным и тебе с ним мучиться, или окажется способным, и тогда это — конкурент. А еще при очередной компании сокращения тебя обойдут, ибо ты по-прежнему незаменим. Конечно, информационная система уменьшает эту незаменимость, но, во-первых, это меньший риск чем другой сотрудник, а во-вторых — она же не должна быть совершенной. у нее наверняка найдутся недостатки. В целом информационная система безопасна с этой точки зрения.

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

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

Рутина на работе и борьба с ней — это популярная тема. Тут родились некоторые мысли. Бороться с рутиной, на самом деле — не надо. Ее надо удерживать в заданных границах и это — должно быть естественной частью жизни и работы. В любой работе есть рутинная составляющая и даже люди творческие оценивали ее от 60 до 90 процентов. В ходе работы рутинная составляющая имеет тенденцию увеличиваться — просто потому, что по мере развития творческие задачи становятся рутинными. На эту тему — надо рефлексировать — и поддерживать долю творчества. Через расширение области деятельности, через знакомство с миром вокруг. Конференции и профессиональные тусовки — средство для этого. Можно книги читать или нехарактерные проекты делать — это кому что нравится.

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

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

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

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

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

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

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

Я, наконец, написал отчет о конференции по Управлению знаниями - размещаю KM Russia-2010 - конференция по Управлению знаниями. На самом деле, то, что я его делал с задержкой - даже полезно - я еще раз перечитал заметки и местами - что-то для себя осознал. В целом, повторюсь, это та область, в которой сейчас надо заниматься. Управление знаниями нацеленно на то, чтобы интеллект группы людей соответствовал не худшему, как в толпе, а лучшему, подтягивая остальных до этого уровня.

Некоторое время назад Лена Сомина подсунула мне книгу Поварнин Искусство спора (UPD: Либрусек заблокирован, есть еще здесь). Отмечу, что картинка на обложке по ссылке совершенно не соответствует духу книги. А книга достаточно подробно классифицирует как методы и приемы ведения спора, так и сами споры по их целям и форме. И написана в начале 20 века, когда споры считались важной частью жизни и велись разнообразно - в узком кругу и публично, устно и письменно. И само слово понималось гораздо шире, чем сейчас - понятие спора включало в себя любые обсуждения с высказыванием разных точек зрения. С тех пор обществе, конечно, шагнуло вперед и публичные споры обогатились еще одним видом - постановочные споры, которые ставят целью убедить публику в некоторой главной мысли, которая остается за кадром, или просто дать разрядку зрителям, и именно такие споры превалируют на нашем ТВ. Но это - суррогат, а что касается собственно обсуждений, то книга остается актуальной и полезной.

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

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

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

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

Из докладов второго дня мне запомнились

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

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

А в целом - для меня как для аналитика конференция была профессионально очень полезной.

Какая-то осень очень быстрая. Позапрошлую неделю назад был SECR, а сегодня я на новой конференции по Управлению знаниями. Подробный отчет по SECR по своим заметкам сделать не успел, планировал в выходные напрячься, но получил комок земли в глаз из-под копыт лошади и работать на компе не получилось Поэтому выкладываю что есть SECR-2010 и делюсь впечатлениями первого дня новой конференции.

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

Теперь о конференции. В целом аудитория - очень пестрая. Много науки, HR, маркетинга, нефтянки - что объясняется организаторами и докладчиками - СОМАР (это маркетинг), докладчики от школы бизнеса СПбГУ, и от Лукойла, включая вице-президента. Тема управления знаниями сейчас востребована, говорят всем госкомпаниям вменили в обязанности завести соответствующий штат и заняться управлением своими знаниями :) Ну и тема - на слуху, а в России площадок для обсуждения - нет. Правда у части публики был один актуальный вопрос - как бы сделать так, чтобы менеджмент поверил в управление знаниями и велел им заниматься. Интересно, что один из гуру (Ник Милтон) дал на этот риторический вопрос вполне практический ответ. Хотя, если честно, мне именно такая постановка вопроса напоминает стенания про то, что дети сейчас не читают, и рассуждения о методиках, как бы их к чтению приучить. Я даже испугался, что конференция будет в основном про это. Но нет, были и практические хорошие доклады, интересные тем, у кого дети читают.

Организация - 2 дня, один зал, доклады объединены в 3-часовые блоки, 3 блока в день и это - кошмар. Потому что внутри блока - сидишь, даже размяться нельзя. Но это техника. Теперь про содержание - доклады.

Сегодня было много, пять штук, докладов западных гуру. Из них два - лично, остальные - по web-трансляции. В числе личных докладов - Ник Милтон из Knoco, который работал над постановкой процессов управления знаниями в BP. Кстати, участник из ТНК-BP подтвержил, что эти практики от материнской компании получены и применяются, но до конференции он считал. что они - составная часть управления проектами, и только сейчас узнал, что оказывается это управление знаниями :) Доклады гуру про управление знаниями, на мой взгляд, излагали известное. Правда, во многом потому, что я прочел книжку Учитесь летать. А ее не все читали. Кроме того, послушать гуру, даже когда они излагают известные основы - интересно, это всегда авторский взгляд и детали.

Кроме них - были интересные доклады наших бизнесменов-практиков - Сазанович, Ширяев, Матохин. И интересные доклады из Гавриловой и Андреевой СПбГУ. Гаврилова много рассказывала про методы извлечения знаний, она пришла из программной инженирии, где занималась извлечением знаний для наполнения экспертных систем и в докладе было много подробностей именно на эту тему, в частности - про организацию интервью. В целом только два доклада за день вызвали у меня разочарование. Что - очень неплохой уровень.

Завтра будет продолжение и тоже краткое резюме. А когда-нибудь попозже - большой отзыв про все доклады.

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

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

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

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

Примерно так.

Итак, продолжаю писать свои впечатления про SECR. Начну с конца. На закрытии организаторы себя хвалили за проделанную работу. За то, что пригласили Страуструпа и других зарубежных звезд. А также - за отбор докладов, по их оценкам, уровень докладов на этой конференции - самый высокий, по сравнению с предыдущими. Я на предыдущих не был, поэтому мне хотелось бы услышать мнение тех, кто был на них по этому поводу. Пишите комменты, или расскажите в отчетах Но, в любом случае, хвалить себя, несмотря на звучавшую на круглом столе критику и именно по отбору докладов - это отрыв от реальности.

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

Что касается остального позитива сегодня, то было несколько запомнившихся докладов, в порядке слушания.

• Олег Ридченко (Intetics Co.) “Mind the Gap” – что делать с растущими ожиданиями клиента. О том, что ожидания клиента - они непрерывно растут. И если это не принимать во внимание, то при постоянной мощности их, через некоторое время, перестаешь оправдывать. А чтобы этого не было, надо работать с клиентом и представлять свои достижения. Было прилично подробностей, о них отдельно. Но в целом Володя, по-моему, рассказывает про это дело лучше.
• Мина Бустром (SunGard Front Arena) - о том, как в адаптировали классическую водопадную MDA-методологию к Agile, организовывая работу по проекту интеграции. Именно к Agile, опираясь на его принципы. У них вполне получилось. Очень энергичный и хорошо построенный доклад. Мне понравилось.
• Сергей Архипенков об управлении разработкой, и вообще о гуманистическом отношении к программистам. Кстати, после доклада поспрашивал у него про их организацию управления на проекте из 50 человек, поделенным на команды по функциональным модулям (в принципе, похоже на СМ). У них team lead - главный, он и управляет и за архитектуру внутри компонента отвечает, аналитику и реализацию внутри ведет команда. Тестировщики - вынесены в отдельную команду и тестят еженедельные минорные релизы всех команд, основные релизы раз в два месяца. Руководит этим управляющая команда из team lead'ов + архитектор + руководитель всего проекта (это он). Деление на компоненты и архитектура верхнего уровня - у архитектора. В целом - похоже, по-моему, на то, что у нас, только без agile.
• Илья Сегалович (Yandex) - о технологиях и вообще организации разработки в компании. В общем-то. мог бы рассказать больше. Было очень быстро, и довольно интересно - что вынесено на уровень компании, что на откуп в командах, как устроены процессы верхнего уровня. Чего-то принципиально нового я не услышал, но подробнее - напишу.

Еще не могу не написать про доклад Бьярна Страуструпа. Организаторы подложили большую свинью докладчикам, которых поставили параллельно. Потому что там никого не было - в комнату С я заглянул, один докладчик и один человек в зале, в комнате B собирали стулья. Конечно, эти доклады меня лично не вдохновляли, но это можно сказать о многих докладах конференции. А Страуструп вполне хорошо, хотя весьма монотонно и скучновато рассказывал про предмет - C++ и его новый стандарт. Доклад был профессионален - достаточно качественно, сбалансировано по частям, занял отведенное время, а не больше. Это тот случай, когда ожидания, в целом, оправдываются. И это радует.

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

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

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

Часть программного комитета четко выдерживает "научность" конференции, и явно это формулировала. Не жестко, но тем не менее по уровню научной статьи - обзор аналогов, позиционирование в отрасли, заключения. На самом деле, тут ничего страшного нет - если бы они это заявили, то почти любому докладу научность в этом объеме придается за час-другой. И в принципе, это делает статью лучше - если за уши не притягивать. Только они не заявили, а вместо этого - выложили требования к оформлению, на которые, говорят, никто не смотрел. Только научность - это палка о двух концах. В общем-то ее придать можно чему угодно и она совершенно не говорит о качестве доклада. Что я лично сегодня и наблюдал. Хотя из зала некоторые участники полагали научность правильным направлением. Кстати, в самом программном комитете по поводу научности единого мнения нет. Николай Пунтиков, который будет руководить комитетом в следующем году, не считает ее правильным направлением развития. Основная идея у них - это неспециализированное общение программистов. Кстати, было предложение одного из импортных участников сделать еще отдельный трек отвергнутых докладов. В общем, замечания, претензии и идеи организаторам были высказаны, будем надеется, что в следующем году будет лучше.

А для желающих посмотреть на Страуструпа: в пятницу в 16:30 будет его доклад C++0x, а потом - специально организованная сессия автографов.

Во вторник был и выступал на SECR-банки. На два зала - 25-30 слушателей при 18 докладах :) Но - были доклады про проекты по inhouse разработке, и это - любопытно, проблемы и задачи которые люди решают и каким образом. Что сильно запомнилось:

• Леонид Феликсон рассказывал про SOA вместо Томас Ерла. По-русски. С упором на концепции. "Теперь программисты не стремятся писать код, кроме некоторых испытывающих от этого кайф. Вместо этого они берут готовый код и комбинируют его для получения нужного функционала. И идея SOA - в том, чтобы было легко это сделать." Это пересказ, а не цитата, но смысл передан. У меня это вызвало ассоциации с идеей постиндустриального общества, в котором реальное производство переносится в Китай и другие подобные страны, а в развитых - остаются услуги.
• Андрей Калмыков из Deutshe Bank рассказывал про переход от оплаты за часы на fixprice. Идея не в том. чтобы сэкономить, а в том, чтобы бизнес узнал цену своих хотелок. У бизнеса часто глаза на лоб лезут от цены, за такие деньги им это совсем не нужно. Во многом, конечно, потому что заказывают они стратегическим вендорам, но это уже второй вопрос. Ну и россыпью еще интересное было. Например, что если надо думать при разработке, или даже при тестировании - это в Россию, а если работа тупая - к индусам, в три раза дешевле. Зато они пытаются готовые проекты, сданные с документацией передать индусам на сопровождение чтобы экономить.

Были и еще интересные доклады, подробная аннотация будет. Но был и отстой.

В среду был на основном SECR. Народу много, доклады, в целом, приличные, вернее, в каждое время был минимум один приличный доклад, а иногда - парочка. Из запомнившегося - доклад аутсорсеров Fujitsu в России (Таланов, Крехов, Махмутов) - ребята делают систему, которая позволит автоматически исполнять change request'ы заказчика, сформулированные на естественном английском языке, с аудитом аналитика, выдавая готовый код (sic!!). Пока у них демо на модельных примерах, в этом году запланирован выход в продакшн и они оценивают, что смогут до 25-60% запросов на изменение своих приложений обрабатывать автоматически. Потому как тупые запросы. А сложные - да, к программистам, как сейчас. Их, конечно, начали клевать теоретики - какой смысл делать автомат, если он не все обрабатывает и прочее, но если у них получится - это ж замечательно.

Завтра продолжим...

Я дописал отчет о ADD-2010 в достаточно подробном виде.

На выходных дописал отчет о Летнем Аналитическом Фестивале, где я выступал и общался на прошлых выходных ЛАФ-2010. К сожалению, дописать отчет на неделе не получалось - не давала остальная работа, а дальше откладывать неправильно - забываешь. Вот и пришлось дописывать в субботу.

P.S. Вы не думайте, я именно дописывал, где-то 2/3, а может и 3/4 были написаны раньше :)

Я хочу написать про книжку по управлению знаниями "Учитесь летать" (Крис Коллисон, Джефф Парселл).

В пятницу я совершенно случайно оказался у стойки секретарей в тот момент, когда они получали комплект купленных книг и взял одну полистать. А когда она мне понравилась, то внаглую утащил один экземпляр почитать. И за выходные прочитал 2/3, а сейчас - до конца. Что говорит о качестве книги (и о ее объеме :)) - я достаточно редко глотаю профессиональные книги такими темпами. Книга - замечательная, и в своем личном рейтинге я бы сопоставил ее с такими книгами, как UML Файлера или SCRUM Книберга. Потому что она написана практиками и излагает практические вещи, а не глубокую теорию. И эти практические вещи можно пробовать применять - в разном порядке и объеме. Общая идея - главное начать, а дальше - оно пойдет. И, собственно, именно это мне импонирует. Конечно, несколько режет глаз несколько несдержано-рекламный характер изложения, но если отнести его просто на индивидуальный стиль авторов, то особой проблемы он не составляет. Есть же люди, восторженно относящиеся к своей работе и ее результатам, и это не страшно :)

Теперь о содержании. Книга написана на примере очень большой компании - BP (British Petrolium) и это, естественно, накладывает свой отпечаток. Но это не страшно, а, наоборот, стимулирует применять предлагаемые практики осознано, а не механически. Сами же практики безусловно полезны и применимы. Более того, часть из них по-сути встроены в процедуры SCRUM, например, процедура разбора полетов при "обучении в процессе" - это типичная ретроспектива, и шаблон проведения (как я его слышал на какой-то из сессий от Бибичева) - тот же самый. Думаю, все выросло из одних корней. Однако, книга ценна тем, что там много акцентов и деталей по проведению всех этих процедур. С моей точки зрения, многие из описанных практик можно применять в нашей компании, и часть из них не требует создания каких-то специальных условий, хотя другие - требуют некоторого предварительного вложения сил. Но не технического - тут усилиями Стаса у нас есть все возможности, а организационных. И умственных, то есть определенной перестройки сознания.

Кстати, если говорить о технических составляющих, то книга написана очень давно (2001) по материалам еще более старым (1997-1999). Солидная часть технического обеспечения, касающаяся интернет-технологий вышла за рамки корпоративных решений на просторы общих сетей. И если технологии форумов и сообществ, думаю, развивались параллельно и обогащались, то социальные сети типа "Мой круг", думаю, зародились именно внутри корпораций и уже оттуда пошли как общедоступные проекты. Впрочем, я могу ошибаться, этот предмет я не слишком знаю. В любом случае, надо следует делать поправку на накопленный со времени написания книги опыт.

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

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

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