Блог:Максима Цепкова — различия между версиями

В пятницу был на первой конференции аналитиков AnalystDays в Минске. Конференция определенно удалась. Было более 250 участников, 4 трека и многие из них очень интересны, а залы — переполнены. Так что я думаю, что за первой конференцией последуют другие, конференция AnalystDays продолжит работу.

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

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

Начну я с докладов Ани Рид и Вали Ломаевой из нашей компании, CUSTIS. В обоих основной темой является DDD (domain driven design), но под совершенно разными углами зрения. Аня — HR и она рассказывала, как связаны практики DDD и развитие аналитика, включая набор персонала, начальное погружение в проект и процесс дальнейшего развития. Аня очень волновалась, потому что когда HR рассказывает аналитикам о методике их профессиональной деятельности — можно ожидать всяких сюрпризов. В общем-то волнение ее отчасти подвело — доделывая презентацию перед самым докладом она переписала на комп конференции не последнюю версию, но обнаружила это только в середине доклада. Несмотря на это, в целом доклад, на мой взгляд, удался и вызвал интерес. А Валя рассказывала об опыте применения DDD для работы с требованиями на примере конкретного крупного проекта для Росатома в условиях постоянного и изначально заложенного в проект их активного изменения из-за параллельно выполняющейся доработки законодательной и нормативной базы. Идея — показать, как применяя DDD можно вселить в заказчика уверенность, что разрабатываемая система удовлетворит их требованиям, даже в условиях, когда эти требования с определенностью неясны, а имеются только общие представления или многие варианты решений и бизнес-процессов, которые лишь предстоит согласовать. Если я Вас заинтересовал — смотрите видео.

Дальше хочется отметить доклад Пола Тернера The impact of Systems Thinking on the Business Analyst role. Пол говорил о ментальных моделях и о мышлении. О тех изменениях, которые меняют верхнеуровневую картину системы и потому подлежат особому контролю. О малых решениях из локальной оптимизации, за которые приходится платить большую цену, потому что они ломают цельность. К сожалению, на мой взгляд, в докладе не хватает более конкретных примеров, потому что на уровне слов и общеизвестных историй про слепых, осматривающих слона это понятно, а в практике, тем не менее, возникают проблемы. Однако, я по своему опыту знаю, как сложно такие реальные примеры делать — потому что для понимания они часто требуют большого контекста из конкретного проекта, а его у аудитории, естественно, нет

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

А после обеда Пол Тернер и Адриан Рид проводили большой мастер-класс Practical Techniques for early use in BA cycle на 4 слота. У меня получилось быть маленьком кусочке и надеюсь, что посмотрю запись полностью. Они рассказывали большое количество техник, по которым группы последовательно шли по разным проектам, выполняя задания. Среди них: PESTLE analysis; five forces analysis; MOST; Resource audit; SWOT analysis; kind business problem — actualy, risk, opportunity; способы визуальной работы над решением проблем — rich picture, mind map, fishbow; работа со stakeholder в зависимости от их роли… И это — сильно неполный список.

Дальше пойдем по порядку докладов.

Вадим Мустяца, Deeplace. Живые вики как оперативные базы знаний. Рассказ был основан на опыте внедрения на конкретном большом проекте вики как системы ведения материалов. При этом докладчик пришел на проект, которому было уже два года, и получил на входе файловое хранилище документов различного качества и слабой систематизации, и задачу — закрыть аналитику и сделать еще 160 отчетов. Он поставил использование rizzoma.com, которая тогда была еще google wave. В докладе Вадим не просто рассказал об использовании, он сопоставил вики с общим контентом верхнего уровня — онтологию представления знаний. А вот сопоставления с другими вики-системами и практиками их использования — нет. Это определенный недостаток для тех, кто этого контекста не знает — потому что по ряду пунктов будет смещенное знание. Но для итого, кто контекст представляет, такой взгляд показывает неожиданные грани предмета. Как пример такого взгляда — вики как месседжер, что достигается через совместное редактирование.

Оксана Сергеева, EPAM. Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий (мастер-класс). Я заглядывал кусочками, зал мастер-класса был переполнен. Основная мысль была очень правильная — процесс управления должен быть адекватен потребностям конкретного проекта, и процессы могут быть сильно различны, в то время как на практике об этом задумываются редко, менеджеры предпочитают использовать знакомые процессы. Но вот позиционирование практики в теорию — оно забавно: «возьмем итеративный процесс, например RUP». Ему противостоит Agile, о котором сказано «наверное, доморощенный», и без деталей «каждый проект что-то свое придумывал». С моей точки зрения, это — еще одно свидетельство того, что практики — не слишком склонны разбираться в тонкостях теории, применяя слова как мемы, за которыми стоит не определение, а набор ярлыков-ассоциаций. Это явление хорошо известно по массовому сознанию и, собственно, мемы и являются способом управления современным обществом (доклад Дмитрия Пескова на KM Russia-2011), и оно же работает в профессиональной среде.

Юлия Михайлова, EPAM. Записки аналитика: как бежать впереди паровоза и не попасть под него. Хорошая и понятная success story с выводами. Аналитик доказывал нужность и роль — на входе его воспринимали как технического писателя, по опыту предыдущих аналитиков. А проект — большой, с внешним большим заказчиком, у которого некоторые фичи не имеют единого владельца. Контент мне лично понятный, но наверняка очень полезный для людей с меньшим опытом, и не только начинающих.

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

Николай Киреев, ИИТ БГУИР. Практический анализ по RUP (мастер-класс) Сюда я тоже зашел на маленький кусочек, и зал тоже был переполнен. На примере конкретного проекта докладчик рассказывал, как проводить анализ, создавая модель из обычного текстового описания, получаемого из заказчиков. Как правильно классифицировать сущности, отличать важное от неважного в контексте конкретного проекта, избегая, например, излишне подробного атрибутного описания, не соответствующего роли объекта, а это типичная ошибка. Целевой рамкой модели выступала модель с точки зрения RUP и, с моей точки зрения, в этом есть определенный недостаток — потому что RUP-модель сама по себе сложна и многообразно, и требует хорошего владения. Но все равно, конкретные примеры анализа с примерами — они ценны и, думаю, не только для начинающих аналитиков, но и для более опытных.

Денис Гобов, Арт-мастер. Выстраиваем процесс управления требованиями. Перед организацией стояла вполне конкретная задача — выстроить свою систему управления требованиями таким образом, чтобы проходить аудит соответствия CMMI и RMM-6. И они сделали систему управления требованиями на базе Jira, которая это обеспечивала? выдавая нужные отчеты с трассировкой и детализацией. О которой и было рассказано в докладе. Очень полезно для тех. перед кем стоит задача сертификации, но и остальным может быть интересно потому что управление на основе интегральных показателей из системы ведения дел — в любом случае актуальная задача и опыт — полезен.

Денис Бесков, Школа Системного Анализа. Управление требованиями VS Разработка требований. Принципы и инструменты Основная мысль доклада состояла в том, что управление требованиями, в отличие от их разработки, является не аналитической, а менеджерской задачей. Потому что включает вопросы границ проекта, а это бюджет, scope против денег. И вопрос релизов, приоритеты требований — тоже связаны с управленческими согласованиями. Поэтому когда управление требованиями полностью передают аналитикам без соответствующих полномочий, оно не работает. Хотя аналитическая часть работы безусловно присутствует.

Александр Кондаков. Оценивания по CMMI как… источник вдохновения. Неожиданно интересный доклад, что не предвещалось ни названием, ни аннотацией. Он наполнен историями, с которыми автор сталкивался, проводя оценки по CMMI и gap-анализ перед оценкой. О том, почему не делают те или иные практики: некогда, работу делать надо; у нас люди умные — им не надо учиться. О том, какие практик обычно есть и в каком виде. О результатах хорошей оценки, которая обычно стимулирует реальный рост компании, а не просто выдает гору бумаг. А еще — о графике роста профессионала-аналитика и новой интересной позиции CPO, Chief Process Officer, которая появилась недавно.

Екатерина Макаренко, TEAM International. Техники аналитика — CATWOE, H-METHOD, MOSCOW, SQUARE. Начало доклада я пропустил, а зря. Екатерина рассказывала о большом количестве конкретных методов аналитика, которые, собственно, перечислены в названии доклада. Например, MOSCOW, который по ее опыту позволил обеспечить реальную приоретизацию требований в контексте релизов. А SQUARE представляет собой фреймворк для требований по безопасности, который позволяет перевести эти требования в разряд функциональных. Эта часть рассказа была на примере конкретного проекта, который изначально был сделан вообще без требований по безопасности, а потом оказалось что они есть и жесткие, проект — банковский. Что ценно — это не методика, а фреймворк, имеющий шаблоны и поддерживающие средства, что позволяет пользоваться даже новичками, набираясь опыта. А еще в методе есть довольно много практик, которые применимы не только к требованиям по безопасности, а могут использоваться для других видов требований. А еще — был рассказ про способ трейсинга требований и их изменений по функциям, причем в условиях. когда за время развития проекта было использовано несколько вики-систем и систем ведения дел, и там были конкретные приемчики, сильно облегчающие работу. Например, при изменениях не только ссылаться в новом деле на предыдущее, но и цитировать формулировки — чтобы поиск это подхватывал.

На этом — все.

Был на ADD-2012. Посмотрел на передний край разработки. Не на тот, где гиганты презентуют новые решения, и не на высокую науку, а на тот, где практики работают и мыслят о движении вперед. Где рассказывают о своих идеях.

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

Так вот, реально дело обстоит совсем не так. Причина этому - в творческом характере разработки. Я вполне согласен с достаточно старой и известной теорией Jack W.Reeves What is software design (Корешков/Продукт_инженерной_деятельности_(в_разработке_ПО) русский вариант), что разработка ПО соответствует проектированию в других отраслях. А потому все, кто занимаются разработкой - они порождают новые оригинальные идеи, а вовсе не следуют чужими путями. Естественно, при этом идет массовое заимствование, использование чужих идей в своих разработках - но комбинации тоже являются оригинальными. Если смотреть на аналогии вне IT, то ближайшей, на мой взгляд, является рынок бытовой электроники, на котором сотни фирм производят множество мобильников, телевизоров, пылесосов и других разнообразных вещей, каждая из которых спроектирована более или менее уникальным образом, чем-то отличается от других, и потому идеи, которые при ее проектировании были придуманы - могут представлять интерес. А в IT это же можно сказать про каждую разработку, потому что программный продукт - это индивидуальное, а не массовое производство.

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

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

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

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

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

Так вот, если говорить об основных темах и впечатлениях для меня, то это новые языки и NoSQL базы данных. Темы не новые, но они интенсивно развиваются, и это развитие - интересно смотреть. Об этом было много докладов. Если говорить об языках - то это новый язык Kotlin, который делает JetBrains для JVM, это развитие Groove, Scala, Nemerle, отчасти F#. И это только в один день конференции. Интересно, что в рассказе про Kotlin сказали, что новый язык для JVM независимо начали делать JetBrains, RedHat и Eclipse. А на докладе про Groove докладчика спрашивали - стоит ли сейчас начинать его использовать, или лучше дождаться Kotlin.

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

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

Еще есть все более развивающаяся тема принципиально другого подхода к разработке, при которой принципиально учитывается ненадежность железа и его сбои - речь идет о высоконагруженных приложениях, работающих в распределенной среде, в кластерной архитектуре, в которой отдельные узлы статистически могут выйти из строя, и выходят. А еще - они могут падать из-за ошибок программистов разных уровней. На работу именно в такой среде ориентированы как многие NoSQL базы данных, так и архитектуры на основе модели акторов - Erlang, Akka. Что интересно, когда на подобном железе работают и традиционные промышленные базы данных, например, Oracle, то вопросы надежности и замены узлов они берут на себя, обеспечивая дублирование или подобные вещи и выдвигая требования к конфигурации. И программист может работать в парадигме абсолютно надежной среды, о которой позаботятся админы. А вот сейчас от такого подхода начинают отказываться. Такая надежность оказывается несоразмерно дорогой по сравнению с ущербом от потерь. Поэтому разработчику предлагается самому о ней позаботится на верхнем или среднем уровне. Например, заказать дублирование некоторых данных на нескольких узлах. Или для критичных входящих запросов - позаботится о проверке, что запрос был принят и обработан, а не пропал по причине крэша ноды системы, а если нет - запустить еще раз. И эта парадигма начинает распространятся из социальных сетей, где надежность, в общем-то, не слишком важна, в область таких приложений как, например, электронные аукционы. Кстати, разработка в облаке тоже не дает надежности - в датацентры амазона, например, попадают молнии, выводя их из строя вместе с данными, и оказывается, что такие кейсы в модель надежности заложены не были.

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

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

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

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

В общем, это наблюдение подтвердилось и на последующих конференциях. Но на SoftwarePeople-2012 из общения в кулуарах я понял, что есть еще и третий мир. Там программисты работают по 60-80 часов в неделю, прихватывая выходные. И они свято уверены, что так обстоят дела во всех фирмах, так что искать альтернативы нет особого смысла. Еще они обычно считают, что они получают хорошо для своей работы, иногда сравнивая зарплаты с интернетом. О разнице между их фирмой и другими местами, где эту зарплату платят за нормальную рабочую неделю - они не подозревают. Так что на собеседования они не ходят, пока не припрет - потому как при такой рабочей неделе времени на это просто нет. Собственно, на конференции я услышал историю, как кандидат просто заснул на собеседовании, объяснив, что устал сильно - пару недель пришлось работать по 80 часов. Я вспомнил ранее слышанные подобные истории, в том числе от тех, кто пришел к нам работать. Поговорил с нашими HR - они подтвердили, есть соискатели которые несколько недель не могут дойти до собеседования потому как работают с 9 до 21, а иногда и выходные прихватывают. Так что третий мир - он есть. И люди в нем - не подозревают не только о первом мире, но и о втором. Потому что по конференциям не ходят, в интернете особо не сидят - им некогда, они работают.

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

Второй день весенней SQA Days 2012 в Киеве был достойным продолжением первого. Было много достойных докладов, о которых я напишу. Правда, после обеда я три слота пропустил - Susumu Sasabe и Yaron Tsubery, чьи выступления мне очень понравились в субботу отвечали на вопросы и это надо было слушать: доклады можно посмотреть в трансляции, а это - нет.

Слушая Susumu, я осознал принципиальное отличие японского способа мышления от западного (американского и европейского) в представлении процессов. Западный человек представляет процесс как объект, статически - картинка as is. Если его зачем-то надо изменить - ставим цель, рисуем картинку to be. И меняем. Если изменения велики, то ищем траекторию as is ⇒ to be, вырабатываем план и меняем по плану. Японцы же знают, что процесс сам по себе изменчив и всегда держат в голове траектории их изменения. Когда Susumu говорил о разных процессах, а он в своих ответах описывал их несколько, он всегда держал эту траекторию изменения, представлял их. И, собственно, японский подход непрерывного улучшения - он как раз опирается на это представление, работает на сознательный выбор траектории, ведущей к улучшению.

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

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

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

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

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

→ продолжить чтение…

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

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

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

Итак, после вступления - начинаю.

Для начала - два совершенно общих принципа.

1. Следование методологии не может быть оправданием конкретных предпринимаемых действий.
2. При реализации чего-либо правильно опираться на распространенные практики отрасли в этой области и соотносить свои действия с ними.

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

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

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

1. Business value автоматических тестов - сокращение усилий на выпуск продукта надлежащего качества. Следование этому принципу должно быть доказательным и признанным заказчиком.
2. Люди, отвечающие за выпуск продукта - тестировщики (у нас - аналитики и инженеры) и представители заказчика - доверяют автоматическим тестам. Без этого business value не достижимо. Поэтому тестировщики играют роль непосредственных заказчиков для любых автоматических тестов, и именно они - оценивают их целесообразность.
3. Доверие результатам автоматических тестов повышается, если тесты представлют собой белый ящик - последовательность выполняемых действий видна тестировщикам, и они могут в нее вмешиваться. В отрасли является нормой, когда автоматические тесты реализуются на некоторых скриптовых языках в терминах модели. Они понятны тестировщикам, которые часто их разрабатывают и почти всегда - могут доработать и изменить. Тесты на верхнем уровне джолжны быть компактны.
4. В отрасли применяется подход Data-Driven тест, в котором в составе теста отделены входные и проверочные данные. Данные написаны компактным, легко понимаемым и модифицируемым образом. Это позволяет легко создавать множество прогонов одного теста на разных данных, тестируя сложные случаи, например, данные на границе допустимого диапазона или спецсимволы в строках. И это точно доступно тестировщикам и IT-службы представителям заказчика.
5. Тесты выполняются в рамках фреймворка, который собирается на основе одного (или даже нескольких) из большого количества стандартных.
   • Фреймворк обеспечивает взаимодействие с программой на нескольких уровнях - UI, веб-сервисы, процедуры базы данных, интеграция через MQ, файлы или другим образом. При этом тест может предполагать взаимодействие разных видов. А конкретные процедуры интеграции и взаимодействия реализуются на основе стандартных библиотек.
   • Фреймворки также обеспечивают логирование, включая внутренний лог теста на уровне белого ящика, и отчеты разного уровня - для тестировщиков, разработчиков и менеджеров.
   • Фреймворк обеспечивает ведение тестов и данных для них, запуск тестов в ручном режиме или при сборке, подключаясь к серверу непрерывной интеграции. Хорошие фреймворки на основе BDD позволяют связывать тесты с тест-кейсами.
   • Предпочтительны фреймворки с открытым кодом, и их - тоже много. Для тестирования Web-приложений стандартом де-факто является Selenium, который также подключается к большинству фреймворков (взаимодействие с базой данных и интеграция - они вне Selenium). Рассказыввали также Auto IT X и Robot Framework, но приводились и большие списки, включая композитные конструкции. Есть способы тестировать продукты-черные ящики, включая приложения, запускающиеся под Citrix или закрытые flash-апплеты в броузере - ориентируясь на графические картики, и это можно применять вместе с другими методами. Выбирать надо с учетом специфики проекта - интерфейсы, интеграция и прочее.
   • Над фреймворком прорабатывается некоторая надстройка, ориентированная на конкретный проект. Обеспечивает интеграцию, ведение тестов как белого ящика. А иногда - и представление дополнительных отчетов или макроуправление тестами. Средства для всего этого - имеются (НР QTP не любят потому, что он сам - черный ящик).
6. Тестов у проекта - много. И выполняются они - долго. Поэтому они требуют структуризации. И это - нормально.
   • Применяется выделение Build Acceptant Test (BAT). Они выполняются после каждого билда в первую очередь, и остальные запускаются только когда эти - не прошли. Прочие автоматические тесты могут выполняться реже, в том числе - только при регрессионном тестировании.
   • Применяется деление тестов по функциональным областям. Тогда запускаются сначала BAT-тесты, потом тестирование функционала тех областей, которые затронуты разработкой, и лишь потом, если предыдущие этапы завершены - все остальные. С учетом появления времени новых изменений кода.
   • Применяется приоритезация тестов по критичности функционала и рискам, связанным с его утратой. С соответствующей настройкой исполнения тестов.
   • Тестирование через конечный UI тяжело сопровождается и часто медленнее. Поэтому его применяют ограниченно, например, для одного документа, проверяя остальные варианты на уровне прямого взаимодействия через данные. И пренебрегая связанными с этим рисками, полагаясь на дешевое устранение чисто UI-ошибок.
7. Тесты требуют внимания и дизайна.
   • Если пренебрегать тестами и их дизайном - они превращаются в дорогой, слабополезный и несопровождаемый код, становятся обузой.
   • Разумное применение тестов, наоборот, приносит измеримый эффект в виде экономии усилий на разработку проекта в целом и удовлетворенности заказчика качеством.
   • Организация процесса может быть различной, но в любом случае он встраивается в процесс разработки как одна из составляющих и предполагает совместную деятельность и взаимодействие разработчиков, тестировщиков и аналитиков. Границы ответственности между ними также могут быть разными, при том что за конечное business value автоматических тестов отвечают тестировщики - автоматическое тестирование является частью тестирования в целом.
   • Unit-тесты применяются многими как составляющая часть автоматических тестов (часть людей используют это как синонимы, но многие - разделяют). Формальная граница проводится по-разному, но по-любому они встроены в общий процесс как составляющая, организуются и оцениваются соответственно.

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

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

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

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

А сейчас - обзор докладов.

→ продолжить чтение…

Этот пост посвящен теме, которую я давно для себя знал, но доклад Василия Малинова на SoftwarePeople пробудил ассоциативный ряд и я решил об этом написать.

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

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

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

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

Однако, на самом деле стоит посмотреть вокруг, поискать - какие реальные проблемы, задачи или трудности стоящие в рамках производственных процессов вы могли бы решить, если бы достигли этих умений. И, найдя - предложить тем лицам, которые за эти проблемы отвечает: "Я хочу попробовать это, думаю, это решит такие-то твои проблемы, давай попробуем?" Чаще всего ответ будет положительный - если усилия, затраты на "попробуем" будут разумны. Даже если проблема не находится в списке первоочередных, но актуальна: потому что без Вас о ней думает ответственный, а так - будете думать Вы как заинтересованный человек.

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

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

Удачи!

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

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

А сегодня я был на мастер-классе Джеффа Де Люка о Feature Driven Developer (FDD). И с пользой послушал изложение методологии от его автора, который создал ее не теоретически, а обобщая собственный опыт ведения проектов. Опыт от мэтра — это всегда интересно, особенно если он методично изложен. И в целом он окрасил теоретически известную мне методологию практическими аспектами. Часть из которых мы применяем, а другие — точно стоит попробовать использовать и, может быть постепенно возьмем все…

В целом я продолжаю оценивать эту конференцию очень высоко. Спасибо организаторам!

→ продолжить чтение…

Сегодня был первый день конференции SoftwarePeople-2012. Конференция - определенно лучше, чем в прошлом году. Очень много интерактива, общения. Много интересных докладов, и среди них - есть новые имена, а это - важно. Так что в целом - превосходно.

Теперь - подробности. Для начала - об общем тренде, который я явственно зафиксировал на этой конференции. Это - работа как fun, а не как необходимая деятельность. Конечно, об этом я слышал и раньше, но это было где-то в теории, прекрасном будущем. А теперь, похоже, оно входит в жизнь, становится ее частью. Об этом говорили минимум в трех докладах: Дэниэл Льюис "Мотивация — залог успеха", Асхат Уразбаев и Дмитрий Евтеев (Positive Technologies). И, как сказал Асхат "не то, чтобы это мне нравилось, но это входит в жизнь и с этим надо считаться".

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

Теперь про отдельные доклады.

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

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

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

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

Что замечательно - совсем недавно Рома Корешков рассказывал о статье 1992 года на ту же тему - Jack W.Reeves "What is software design. По ссылке - оригинал, а здесь - русский перевод. Через 13 лет Ривз вернулся к тезисам статьи и нашел, что они сохранили справедливость.

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

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

Остальные доклады - коротким списком, что запомнилось

• Асхат Уразбаев "Лидерство в стиле Lean". Говорил о 3 видах развития команд. Первые - идут вверх. Вторые - попробовали, но не сложилось, и тут - понятно, усилия оказались чрезмерными, но прорыва не принесли. А третьи - вышли на некоторый уровень и там колеблются. И таких много. Почему? Потому что у них кончились проблемы, работа пошла "хорошо". Если проблема возникает - они с ней борются. Но вот чтобы идти дальше, надо уже говорить не о проблемах, а о возможностях. Пробовать, экспериментировать. А без этого - не получится. Дальше речь шла о различных способах - что и как можно пробовать, но это - примеры, а не руководства. Но примеры - полезные, так что презентацию я тоже буду смотреть.
• Джефф Де Люка "Почему мы терпим неудачи. Разработка ПО в наши дни". Джеф дал авторское видение современного состояния. Там не было открытий, но это не было и изложение от капитана Очевидность. Это было авторское видение с полутонами и деталями, и от мэтра оно - интересно. Из неожиданного: изменения он видит всегда революционные, через хаос. А я так не хочу.
• Дэниэл Льюис. Мотивация — залог успеха. В докладе был список буллетов - что мотивирует английских разработчиков сегодня. Утверждалось, что не только английских. Размер зарплаты там очень далеко не наверху (но он должен восприниматься как справедливый). В целом - любопытно.
• Вадим Митякин "Путешествие по изведанному. Чем ваша компания является на самом деле". На этот доклад я не попал, пошел на Джефа. А, говорят, он был весьма интересным - о компании из позиции генерального директора, это редко бывает на конференциях.
• Василий Малинов (Oktogo.ru) "Роль продукта в успехе привлечения инвестиций" - об успешном стартапе, интернет-проект по резервированию отелей в России, взгляд на развитие изнутри. Как менялась бизнес-идея при сохранении в целом технологической платформы резервирвоания - они искали нишу рынка. Любопытно.

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

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

Завтра - второй день и, надеюсь, тоже будет интересно.

Последующие дни Atlantic Systems Guild, увы, не принесли ничего нового. Второй день был сильно гнилой, третий - повеселее, но все равно, информация, которую я услышал - это прошлое, она была бы мне интересна в 2005-2007 году. А с тех пор на проблемы были получены ответы, которые естественно, дали крен в другую сторону, это было осознано, и выработаны какие-то практики поиска баланса. Все это в докладах отсутствовало.

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

Подробный отчет - Atlantic Systems Guild 2012

Статья была опубликована на softwarepeople.ru (портал закрыт) и перепечатана на interface.ru
Статья получила развитие Agile в контексте большого менеджмента – тренды развития (SPMconf-2013)

Прошедшая конференция AgileDays-2012 естественным образом сфокусировала мои мысли на теме Agile-практик как таковых, их развития и соотнесения с традиционным менеджментом.

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

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

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

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

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

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

И в 90-х решение было найдено - Agile-технологии. Возникнув первоначально как протест против доведенных до абсурда процедур регламентации в виде XP, они с появлением SCRUM дали легкий и эффективный способ управления IT-проектами, обеспечивающий приемлемое качество и при этом сделавший управление IT-проектами доступным достаточно широкому кругу людей в отрасли без чрезмерных усилий по освоению. И этот способ завоевывал мир де-факто. При этом первоначальная цель XP - вытеснить за рамки IT процедурное администрирование и вообще классических управленцев - также была во многом достигнута за счет внедрения собственной, оригинальной терминологии и практик. В результате IT-шники получили возможность самостоятельно управлять своими проектами или, во всяком случае, обрекли менеджеров на разбор со спецификой отрасли. Хотя сами практики, если разобраться внимательнее, впитали в себя позитивный опыт "обычного" менеджмента который тоже интенсивно развивается.

После успеха де-факто началось признание де-юре. Артефактами этого являются SWEBOK 3 версии (2004) и PMBOK 4 версии (2008) в которых явно упоминаются agile- методологии и сделана оговорка, что структура самого документа повторяет стадии классической (водопадной) модели лишь по совпадению. PMBOK-4 читать особенно забавно - итеративность новые веяния вписаны в книгу явно на живую нитку, точки сшива и провалы целостности, возникшие из-за этого - видны. И этот процесс завершается сейчас понятийной сшивкой с менеджментом вне IT, которая необходима для Agile-управления IT-проектами в мегакорпорациях. Проявления этой сшивки - доклад Dan Rawsthorne. Scrum: the Big Picture на AgileDays-2012, в котором показана реализация в Agile "общепринятой" иерархии уровней Software Development - Product Development - Project Management - Portofolio Management. И доклад Джефа Сазерленда на SECR-2011, в котором правильный SCRUM позиционирован как высшая и последняя стадия CMMI-5.

Если же говорить о широких массах, то IT-шники относятся к управлению так же как к технологиям. Они знают, что серебряных пуль - нет. Они знают, что новые идеи могут давать много полезного, и за ними надо следить. И чтобы их использовать вовсе не обязательно углубляться в теорию - можно применять на практике и без этого. Хотя если интересно - то почему бы не разобраться в теории - это прикольно, полезно и поучительно. Но во всей теории разбираться - никакого времени не хватит. Поэтому новые идеи вспыхивают, оказавшись удачными - распространяются, становятся общеизвестными, в их ограничениях разбираются, после чего они осыпаются в багаже полезнымии практиками. Так же и в технологиях: вспыхивает функциональное программирование, F# и Haskel, обретает последователей, интенсивно развивается, а потом опадает новыми элементами в C# или занимает подобающую, хотя и неожиданную нишу как Erlang. И практики управления и технологии по пути могут обрастать евангелистами и ярыми сторонниками. А сам цикл от прихода до обретения места - стремителен, порядка полутора лет.

Как я уже говорил, оригинал управленческих практик часто приходит извне. Но попав в IT - он сильно изменяется. Например, Канбан в IT обернулся тремя практиками ведения проекта: доска, ограничения на ней, измерение скорости потока. Который сосуществует в сознании с "большим" Канбаном как методом оптимизации процессов. Схема формирования команды - стадии Storming-Forming-Norming-Performing тоже стали более простыми и формальными, скрестившись по пути с IT-командами. Поэтому многие говорят об отсутствии принципиально нового или искажении оригинальных, якобы правильных идей и процессов. Но это неправильно. Потому что реально процессы впитывают специфику IT-разработки. А еще - приобретают нужный уровень легкости и схематичности, который и обеспечивает их успешное применение в проектах.

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

Сегодня был первый день Atlantic Guild. Кажется, я нашел-таки конференцию, которая мне не понравилась. Хотя - это не совсем конференция, это обучение от мэтров. Так вот, выход сопоставим с выходом от обычных конференций. Не то. чтобы мыслей не возникает совсем, но их в сухом остатке - не больше, а местами - меньше. А вот интереса к содержанию - почти нет, увы. Текущее объяснение таково: мэтры - они в отрасли с 80х. Они пережили пришедшее стремительное изменение 2000-х, осознали его. И сейчас - транслируют это осознание другим людям своего уровня. Проблема в том. что в России отрасль сформирована в конце 90-х - в 2000-х. И поэтому тех самых традиций - нет. Люди живут в стремительно изменяющейся отрасли и как-то умеют это делать. Так что когда докладчики говорят. о том, что есть проблема и нечто нужно менять - слушатели уже знают. какие ответы на это даны, в том или ином виде пробовали и знают о следующем шаге - о проблемах, которые порождены этими ответами. А в докладах - только первый шаг. А он - очевиден.

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

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

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

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

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

Пока все.

Закончилась конференция Agile Days-2012. Второй день был определенно не хуже первого. В нескольких докладах я услышал конкретные идеи, которые можно применить на практике, другие - влекли размышления. Так что, если говорить о конференции в целом - она удалась. И по реакции других участников, они почерпнули для себя много нового. Потому что в целом конференция предназначена все-таки для более молодых, ищущих новые пути и осваивающих новые идеи. Это было видно и по реакции зала на доклады, и по активному общению.

Сегодня был доклад Коли Гребнева из нашей компании про эффективные обсуждения. Доклад был в тему, слушали, задавали вопросы, обсуждали. Потому что тема эффективного проведения совещаний, включая те которые входят в SCRUM - ретро, планирование, DSM - она актуальная.

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

→ продолжить чтение…

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

→ продолжить чтение…

Наконец, доделал и опубликовал отчет KM Russia-2011 - конференция по Управлению знаниями.

Посмотрел на этих выходных выступление Сергея Гевлича на KMrussia про Объясняшки. На самом форуме я в это время был в другом зале и пропустил, но по общению второго дня понял, что пропустил зря. Видео всей конференции еще не выложено, но это выступление было опубликовано на youtube, и ссылка дана в группе TopClassInternational на facebook, где идет общение по управлению знаниями.

Реально вдохновился идеей. С точки зрения теории - ничего нового. Давно известно, что наиболее эффективная передача информации - при сочетании каналов видео и аудио, в динамике. Более того, есть известные и популярные рисованные мультики RSA-студии. Что, кстати, видно из вопросов после выступления - автору указывали на книги, где все это тоже написано.

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

Я потом еще посмотрел сайт автора http://xplainto.me и вышел по ссылкам на статью, программа уже доступна для бета-тестирования, но у меня нет iPad. Может, это повод?

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

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

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

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

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

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

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

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

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

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

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

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

→ продолжить чтение…

В субботу 26.11.2011 участвовал и выступал в Питере на конференции SPM Conf 2011 - Software Project Management Conference. Это - новая конференция от SQA labs, которая, думаю, станет первой в серии конференций по софтверными проектами, дополнив ранее стартовавшие линейки конферениций - SQA Days и Application Development Days. Конференцию снимала на видео наша компания, и скоро запись появится на lib.custis.ru, а пока - мои впечатления.

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

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

• Project Manager в SCRUM - как жопа: жопа есть, а слова - нет.
• Аналогия Ежи и Лисы...
• Кнут получился, а пряник - не очень.

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

В целом - все. Надеюсь, эта серия конференций - будет продолжаться.

Сегодня был второй и последний день Бизнес-форума по Управлению знаниями KM Russia-2011. Были мастер-классы, самым впечатляющим из которых безусловно был мастер-класс Рона Янга, больше трех часов. Практически это была расширенная версия его вчерашнего доклада, с конкретными кейсами и подробностями. Замечательный человек. Рон несколько раз задавал работу в группах на 10 минут с ответами на вопросы, а потом - за перерыв подстраивал следующий слот с учетом услышанного. В конце была обратная связь от участников, ему переводили и Рон исписал больше страницы заметок - он тоже учится, проводя такие мероприятия, что очень впечатляет. В апреле, в рамках бизнес-конгресса, обещан его 8-часовой (или 16-часовой?) тренинг.

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

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

А еще, кроме мастер-классов - было живое и активное общение участников. И это - ценная вещь форума, реальный обмен знаниями - потому что участники очень разные. Я, кстати, узнал, что вчера Сергей Гевлич в своем докладе рассказывал про применение ими формы эффективной упаковки знаний в презентациях через рисование и звук, аналогично RSA Animate. И они готовят программу на iPad, которая сделает создание таких презентаций общедоступным. Стас, правда, говорит, что у него такая технология есть...