Блог:Максима Цепкова

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

С каждым разом на конференции все больше народа. Эта конференция проходила в Park Inn Прибалтийская и собрала больше 600 человек. Реально гигантские залы, и полные. С задних мест докладчик - где-то вдали, на горизонте, особенно в большом зале - поэтому стоят плазмы, идет трансляция и экрана и докладчика. Думаю, следующая конференция будет еще более многолюдная. Она состоится во Львове, будет 3 дня вместо обычных двух и там будет день западных спикеров.

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

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

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

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

Питер Друкер "Энциклопедия менеджмента". Как написано в предисловии автора, творчески собрана из его книг за 60 лет с участием его самого и представляет введение в теорию управления. Получилось емкое и концентрированное изложения, касающегося менеджеров и вообще работников умственного труда (оказывается, это - его термин, 1969). Но еще - получился обзор развития общества, начиная с середины 19 века (а местами и раньше), и до конца 20 века (книга издана в 2001, работы 1999 учтены). При этом материалы рассыпаны по тексту, что дает взгляд с разных сторон. А еще - свидетельствует о цельной картине у автора, который легко начинает с верхнего уровня и погружается в детали под уместным в конкретном месте углом зрения. И это - превосходно, потому что подобные картины - большая редкость.

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

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

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

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

Да, про agile - это, естественно, в мировых масштабах, а не про нашу компанию, и даже не про Россию - в России как раз было не так, поскольку в отрасль в 90-х во многом приходили из советской науки, а там нормально управляли интеллектуальными проектами.

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

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

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

Сам я выступал на конференции, рассказывал об опыте применения Domain Driven Design. Прямое отражение модели в код на основе шаблонов Domain Model и Rich Objects, о котором говорят авторы подхода, вызывает в больших многолетних проектах определенные проблемы, и для их решения мы разрабатываем в проектах набор более сложных правил отражения, который назвали Технологическими рельсами. Доклад вызвал интерес, были вопросы. И еще из нашей компании выступал Коля Гребнев, рассказывал о создании самоорганизующихся процессов в командах. Его доклад тоже слушали с интересом.

А теперь о докладах подробнее. Надо учитывать, что я был далеко не на всех докладах. Я пропустил Кириленко потому что мой доклад стоял параллельно. Не был на Орлопанках, слушая параллельный трек - там были наши ребята и, я думаю, они донесут ценное, что там было. Еще был большой трек Microsoft ALM, о котором я знаю из других источников и трек мобильной разработки, которая (пока?) вне сферы моих профессиональных интересов, туда я зашел только на Дмитрия Мартынова из Google чтобы почувствовать тренды. А еще во второй день мне пришлось уехать в 15 часов, увы.

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

Перед конференцией SoftwarePeople прошли два мастер-класса Эдварда Йордана CIO’s at Work и IT Project Estimating. Я был на обоих. Первый из них был довольно дорогой - организаторы хотели камерности, и им эту удалось, я бы сказал даже более чем. Свою роль сыграла не слишком понятная программа мастер-класса: сама книга есть только на английском, а анонсе обещано обобщение опыта CIO различных крупных компаний. На втором же было более 50 человек.

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

Мастер-класс был на хорошем английском, даже записывая, я продолжаю воспринимать то, что он говорит, а это - ценно. В электронных материалах - много линков. Сами материалы - это оглавление рассказа, каждый пункт был раскрыт и иллюстрирован историями, которые хорошо рассказаны. Йордан знает опыт в отрасли - середины 60-х. Технологии - меняются, а люди - не очень. Книга CIO’s at Work, на основе которой построен мастер-класс - реальные интервью, 16 штук. Я ее полистал, и по-моему не слишком интересно. А в мастер-классе - обобщение этого опыта. А я дальше немного расскажу об интересных для меня моментах, дополнив своим видением. Естественно, передать полностью не получится, даже опубликовав презентацию - потому что оглавление не передает содержание текста, и по нему вы можете лишь оценить - знаете ли вы об этих вопросах вообще, а никак не соотнести свое знание с позицией автора.

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

С освоением технологий явно лучше, чем с освоением менеджерских аспектов. И те тренды ориентации на людей как ключевого фактора для успеха проектов, и которые, говорят, зародились в далеких 60-х в космической отрасли штатов, были, казалось бы, освоены IT-отраслью в изложении Peopleware Тома ДеМарко, а в последнее время воплотились в Agile-Lean процессы - остаются лишь баззвордом.

Был представлен список приоритетов CIO. Из него видно, что преимущественно они заняты текучкой, операционной работой. А стратегия - увы, даже не в верхней половине списка. Еще интересно сравнить списки приоритетов 2010 и 2011 года. Список 2010 года содержит вполне понятные цели и задачи - по поддержке основного бизнеса со стороны IT, по эффективности самой IT-работы. И довольно мало мемов, которые "должны волновать всех" (Cloud, broadband и connectivity), и это - не есть хорошо для жрецов соответствующих мемов. В списке 2011 содержательные пункты сгруппированы в 1-2 группы со своими баззвордами, и за счет этого освобождено место для мемов. В 2012 число мемов еще увеличивается - portal, mobile... Все это хорошо согласуется с еще одним трендом современного общества - переходом от содержательных понятий к мемам.

Поговорили также о мемах и баззвордах, не вошедших в список приоритетов, некоторые из которых обозвали tools, например, virtualization или social media :) К сожалению, форма представления в виде списков так же несет отпечаток консервативности. Здесь более уместны семантические сети или другие визуальные формы, потому что приоритеты и другие понятия перекрываются и связаны. Увы, этого не было.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, сама конференция - многолюдная. 667 участников, 54 доклада. Реально переполненные залы. Были косяки, но ко второму дню организаторы учли уроки, и, главное, организовали трансляцию из второго зала в холл, что позволило желающим слушать доклад хотя бы из-за двери. Как они шутили "fast fail у нас был - значит дальше будет хорошо".

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

А теперь - о трендах и обзор докладов, на которых я был.

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

Вчера и сегодня был на тренинге Джефа Паттона. Он рассказывал о том, откуда и каким образом получается самый важный артефакт SCRUM - Product Backlog, который является источником для всего остального. В описаниях процесса SCRUM об этом говорят реально мало, хотя практики известны. Джеф представил цельную конструкцию подходов к формированию продукта и его релизов, с фокусами ответственности и особым упором ценность продукта и user experience.

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

А еще тренинг включал в себя обучение эффективным формам коллективной работы - collaboration. И, как сказал Джеф, "Collaboration - это не разговоры и обсуждения. Это - совместная работа, и желательно - молча."

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

А я дальше не поленюсь и кратко раскрою содержание тренинга. К сожалению, кусок второго дня я пропустил, так что есть лакуны. Да. часть про SCRUM как сбалансированный процесс и agile как систему ценностей я опущу, потому что полагаю ее знакомой. Она не заняла много времени, но задала контекст для дальнейшего.

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

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

Сегодня, 21.03, прошла очередная встреча Клуба директоров по разработке, посвященная эффективности внедрения ALM. На встрече получилось заглянуть в ведение проектов крупными компаниями разработчиками - KasperskyLab, который сейчас активно внедряет TFS, ABBYY, которая использует ALM на основе систем собственной разработки на пока на TFS переходить не собирается, и других разработческих компаниях. С другой стороны, был обмен мнениями и опытом по проблемам ALM в inhouse-разработке - в банках Райффайзен и ВТБ24, в ВымпелКоме, и других. И именно этим было интересно мероприятие. Понятно, что определенная маркетинговая составляющая, касающаяся TFS тоже имеется, поскольку встречи организует Microsoft. Однако прежде всего это площадка для общения и обмена практическим опытом. К тому же то, что Kaspersky выбрал именно TFS - тоже показатель уровня решения.

В пятницу был на Enterprise Developers Conference, которую проводил CareerLab. Конференция была весьма нетипичная, участники преимущественно представляли inhouse разработку. Впечатления от конференции очень позитивные, на ней было несколько неожиданных докладов. Местами получилось заглянуть во внутреннюю кухню корпоративной разработки, которую не так часто представляют на конференциях, а еще - посмотреть на развитие тренда ALM-средств, которые предоставляет Microsoft не в виде презентаций самих средств (хотя это тоже было), а на опыте их внедрения в крупных разработческих компаниях.

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

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

Конференция http://www.modelsward.org/ - International Conference on Model-Driven Engineering and Software Development - закончилась. Впечатления первого дня - здесь. Но второй день - изменил впечатления первого дня о преимущественно недоработанных прототипах или рассуждениях общего уровня от специалистов. Это просто первый день оказался так скомпонован. А во втором - пошли вполне себе нормальные доклады про модели, кодогенерацию по ним конечных приложений, а также верификацию и тестирование моделей, которые в этом случае реально нужны. И это продолжилось на третий день.

Кроме того, в конце второго дня была poster session. Она реально отличалась от стендовых докладов у нас на конференциях, аналогов я не видел и опыт можно использовать. Суть в том, что у автора есть плакат с достаточно подробным изложением идеи, а дальше - ты с ним можешь общаться, задавать вопросы. Этот формат хорошо подходит для представления новых идей и продуктов, которые в докладе объяснять не очень хорошо, потому что нужен интерактив и рефлексия по восприятию. А в таком формате - самое оно. Еще это хорошо подходит для представления идей, заложенных в большие фреймворки и inhouse разработку. В докладе этого не сделать - надо передавать много контекста, либо поднимать уровень абстракции так что получается рекламный доклад. А в этом формате основные идеи - пишешь на плакате, их видят. А в интерактиве собеседник расспрашивает о тех аспектах, которые именно его интересуют. Что интересно, на этой сессии были так же докладчики, которые делали доклад на основных сессиях - то же плакат с кратким изложением презентации, и дальше - общение. И это позволяет более подробно пообщаться с ними. У нас это во многом заменяет общение с докладчиком после его доклада, но, во-первых, ты теряешь следующий доклад, а, во-вторых, вопросы часто должны созреть. И за 1 час такой сессии пообщаться с 5-6 докладчиками - вполне успеваешь. В общем, надо брать на вооружение.

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

Из конференции я вынес для себя, что генерация по моделям сейчас является эффективным инструментом и ее надо осваивать. Собственно, отдельные фрагменты у нас используются, но как разовые вещи. Что характеризует ситуацию? Моделеров и генераторов реально множество. Видел сравнение из 20-30 наименований. При этом утверждается, что они работают над моделью с совместимым XMI-описанием, то есть можно использовать совместно: для бизнес-логики один, для интерфейса - другой, а диаграмму классов (например) можно свободно переносить. Наверняка есть open source разработки, от университетов - точно, их представляли. Они ограниченные по функционалу и могут быть сырые, зато в текстах, можно развивать и вносить вклад. Главное - не тотальная генерация конечного приложения, а только его однородной части. Да, казалось бы, с ней особых проблем нет - берешь и формально реализуешь. Но дальше каждое изменение - согласованные правки в 5+ местах - а это уже дорого, играет человеческий фактор. В общем, буду сюда активно смотреть.

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

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

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

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

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

На этом все. Обзора доклада не будет - все равно подробных публикаций материалов нет. В заключении поделюсь цитатой от Oscar Pastor (University Valencia, keynote): CASE tool should help designer to solve problem instead of adding new problem - how to use it properly! Очень характерно.

Я еще 3 дня в Барселоне, буду гулять по городу. Впечатления и фотки, кому интересно - в личном блоге.

Конференция http://www.modelsward.org/ - International Conference on Model-Driven Engineering and Software Development. О моделях, поэтому и поехал посмотреть.

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

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

В целом, сегодняшние доклады можно разделить на две категории. Первые - это от профессионалов в которых уровень абстракции поднят настолько высоко, что остались общие тренды и рассуждения - которые мне и так известны. Надо сказать, что профессионалы часто работают в крупном inhouse - GM, Tata, NEC и другие - поэтому подробности им передать действительно трудно. А второе - это доклады о достаточно частных проблемах, решенных на модельных примерах, которые, тем не менее, позиционируются как какие-то достижения. Как пример - сегодня было несколько докладов о сравнении моделей. Понятно, что если вы работаете с моделью коллективно и храните их в системе контроля версий, то практически тема важная, а хороших средств - нет. Но ничего сильно нового тут нет. Есть такой Erwin, который очень давно сравнивал модель в нем со структурой БД. Сейчас это многие средства умеют. Так что для доклада - это не тема, по-моему.

На этом на сегодня все.

Пост http://a-str.livejournal.com/524554.html говорит об обучении творчеству, и автор имеет ввиду писателей, художников и другие аналогичные профессии. Но все это очень применимо к проектированию программ. Редко кому из нас удается встретить учителя, и поэтому мы - преимущественно самоучки. И проблема легкой выбраковки - реальна. В проект вкладываешь много своего умения, он - дорог, и критика слушается очень тяжело...

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

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

Правда, требует упаковывать свои мысли в 140 символов и для меня лично - это часто сложно. Даже отдельная мысль укладываетя не всегда, надо 200-250 символов, чтобы отметить нюансы и акценты. Но вообще для меня это - интересный опыт. На SPMconf я поймал мысль, что реплики по поводу выступления хочется бросить в твиттер. Или процитировать (но это-то как раз многие делают). Но - не успеваешь, вернее, это отвлекает внимание от восприятия доклада, а это - жалко. Особенно, когда мысль не влезает на десяток символов - их-то точно можно ужать. Но, думаю, это - тренируемый и полезный навык, так что буду практиковаться. Во всяком случае. на круглом столе у меня получалось :)

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

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

Игорь Любин, News360. Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестирования!

Великолепный доклад о проактивной позиция тестировщика.

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

1. Тестирование начинается с прихода в компанию. Вопросы на интервью.
   • Определить цели
   • Задать как можно вопросов о проекте
   • Узнать какие проблемы надо решить.
2. Горячие точки. Поговорить с ключевыми участниками, составить список горячих точек
3. Фишки. Пообщаться с командой, собирать идеи.
4. SMART-анализ целей (горячие точки, фишки). Выписать цели, выбрать цели на месяц.
5. Добиться прозрачности. TOP-5 задач на неделю. Таблица Задача, исполнитель, срок, комментарий.
6. День золотого духа. Влиться в проект. Стать junior-тестировщиком на 1 день.
7. feedback. Взять обработку отзывов от пользователей в свои руки.
8. Разделение обязанностей. Мотивация: выявить склонности тестировщиков и предложить им задачи по специализации.
9. Функциональные карты. Сделать тест-анализ по модели Объект-Действие-Параметр-Значение. Выявить основной функционал. Оценить покрытие.
10. Особенности платформы. Усилить покрытие.
11. Чит-листы (не чек-листы). Готовые проверки, их масса в сети - и не надо придумывать самим.
12. sitechko.ru. Там много готовых листов. Руководитель Наталья Руколь.
13. Понятие критического бага. Составить критерии, согласовать.
14. Критерии выпуска версии. Процесс тестирования на выпуске. Когда надо выпускать. Набор чеклистов.
15. Build Verification Tests. Составить, прогонять регулярно.
16. Волны тестирования. Соорганизоваться, продумать итерации тестирования.
17. Стратегия тестирования. Сделать документ на 1 (одну) страницу. Поддерживать его.
18. Шаблон баг-репорта. Сделать. Научить всех пользоваться.
19. Анти "Протестируйте". Организовать процесс передачи версии в тестирование. Антипаттерн: разработчик собирает билд, пишет "протестируйте" - тестировщик день нечто делал, пишет "протестировано" - получается "выпущено" и огребаешь баги. Нужны новости версии и понимание, что трогали.
20. Ежедневные статус-репорты. Ежедневно. А еженедельно - сообщать об успехах.
21. Post morten. После выпуска версии - провести анализ, выявить сильные и слабые стороны.
22. Минтуки встреч. Вести протоколы-минутки, рассылать участникам и другим заинтересованным.
23. Полчаса на автоматизацию. Выделять каждый день. Пусть одному человеку из команды. За это время - пишется один тест. И за мессяц - их уже 20.
24. Все в teamcity (или аналог). Включить запуск автотестов на регулярной основе. А не хранить их где-то локально.
25. Инженерные практики. Быть QA. Поговорить с разработчиками о качестве, об используемых практиках.
26. Roadmap тестирования. Выписать даты выпуска версий, нарисовать карту.
27. Трындеть. Никогда не кушать в одиночку. Ежедневно общаться с разными коллегами.
28. Сплотить команду. Поддерживать ритуалы в команде.
29. Начинаем рабочий день. Никогда с утра не открывайте почту! Первый час - для другого. Для разумного планирования и общения.

Михаил Субоч, ЭПАМ Системз. Построение Keyword-driven фреймворков. Это был доклад об архитектуре тестового фреймворка, воплощенного во фреймворке TAF Core. Фреймворк был создан в EPAM и выложен в open source под LGPL. Но рассказ был именно об общих принципах.

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

1. Данные
2. Логика
3. Шаги
4. Утилиты
5. объекты (ui-локаторы, таблицы БД, web-сервисы)

В презентации есть конкретная схема: Ядро, инструменты, агент для распараллеливания и запуска. И так далее.

И в конце - были общие рекомендации.

• Быстрая смерть - программирование в Excel вместо шага проверки. Нарушение разделения.
• Незапускаемые тесты бесполезны.
• Ломаем утром, строим ночью. Утром - техническая реализация, вторая половина - дизайн. И лучше эти активности не смешивать - разное мышление
• Составление сложных шагов из базовых. CreateProduct и другие подпрограммы. Чтобы вспомогательные шаги, обвязку - убирать из теста. Например, просто Login всюду, кроме автотеста формы логина. И это должно быть доступно тестировщику, а девелопер - пусть ревьюит.
• Важна независимость от технологии. TAF Core - был до Selenium. Но может с ним интегрироваться, равно как с телериком. Низкий порог входа.

Максим Гриневич, Colvir Software Solutions. Промышленный подход к автоматизации тестирования или Keyword-driven testing в жизни. Рассказ был о внутреннем устройстве тестовых сценариев для тестирования большой банковской системы. Как я понял, это касается той же самой системы, о которой накануне говорил Алексей Надененко, впрочем, я могу ошибаться.

Тесты устроены так.

• Разработчики - предоставляют стандартные операции, действия и проверки, которые представляют шаги тестирования, реализуемые как банковские keyword
• На их основе тестировщики реализуют сценарии тестирования.
• Необходимо видеть, что именно делает автотест. По шагам. Для Заказчика и руководства. При этом то, что написано должно соответствовать. И это - важное требование у них. Хотя часто автотесты воспринимают как черный ящик.
• Тестовые сценарии - в xml. Версионность и прочее.
• Для работы используют ALTOVA. Отображение и редактирование в формах. При этом - несколько видов просмотра, из которых можно редактировать ограниченную информацию.
• Верхние узлы - дают пошаговую инструкцию тестирования, и руководители ее смотрят через xml/web
• При прогоне - лежат конкретные значения. Но подставляются они - отдельно.
• По xml - генерируется исполняемый сценарий. Его не правят, при изменении - меняют исходный xml
• Тестовый план или цепочка сценариев тестирования. На вход ему готовят данные. Первый из них - готовит данные - выводит документы в нужное состояние и прочее. Пускается параллельно. Распараллеливание надо учитывать сразу, тогда оно не составляет проблем.
• Ошибки теста бывают трех видов: Данных, Автотеста и Приложения. И с этим надо разбираться.
• Начальный въезд в xml - два дня, и уже может писать, пусть ошибаясь.
• Программисты планируют устроить перегенерацию на лету, или интерпретацию - чтобы исключить хранение сгенеренных автотестов.
• Будут расширять набор стандартных операций. Пока половина автотестов через операцию "другое", но они над этим работают.
• Хочется связать автотесты с функциональностью, чтобы понимать что прогонять. Сложно, потому как структура приложения непроста.
• Текущее приложение - desktop, будет версия под web.
• Вопрос про версии. Ответ: все очень сложно, у них около 30 клиентов, каждому из которых дано право вносить в код.

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

Ирина Тузикова, Grid Dynamics. Простой взгляд на автоматизацию или Как не изобретать велосипед. Доклад о комплекте инструментов Web-тестировщика и особенностях установки и настройки их. Казалось бы, в чем проблема? Но тут - как с администрированием: у одних админов все настроено и тикает, а другие - непрерывно лечат. Так вот, были моменты, которые надо настроить сразу, чтобы не лечить потом. Может быть и очевидные, но наверняка на эти грабли наступает куча народа. В докладе упомянуты были Java, Maven, IDEA, Selenium, Thuсydides, Броузер и Web-драйвер к броузеру.

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

И остальные доклады.

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

Кстати, у Дорофеева на SPMconf была аналогичная модель, касавшаяся прогнозирования сроков завершения обработки. Тоже с обратным потоком дел от программистов в бэклог как одним из факторов. Но - посложнее (и изложена более живо).

Сергей Талалаев, Exigen Services. Oracle-based тестирование. Теория и практика. Это вовсе не про БД-Oracle. Это оракул, предсказания. Основанные на мнениях экспертов - людей, мнения которых близки к истине.

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

Так вот, Excel в данном проекте - и есть ото самый оракул.

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

Виталий Шульга, EPAM Systems. Особенности автоматизации с помощью скриншотов на платформе .NET. Дальнейшее развитие темы автоматизации тестирования приложения, запускаемого под Citrix, для которого недоступна внутренняя структура объектов и потому надо опознавать элементы по их изображению. На прошлой SQA days рассказывали об успешном использовании Sikuli для этих целей. Но дальше они захотели интегрировать эти тесты с другими своими тестами, которые для WPF-приложений. Sikuli - это Java, стыковки с .Net не получалось. Они пару недель помучились, а потом за день написали мини-движок, который умеет опознавать картинки и дергать примитивный WinAPI для мыши и клавиатуры - и дальше можно писать тесты, основанные на скриншотах, однородно с другими на платформе .Net. Там пришлось помучиться с эффективной реализацией алгоритма опознания изображения - сначала сравниваются 5 точек, раскиданных по картинке, и только когда совпали - идем дальше. А первая версия с простым сравнением - была очень долгой.

Конференция SQAdays-12 в Минске - очень удачно. Много хороших и дельных докладов. Более 500 участников и много общения. Постоянный кофе и перекус в фойе также способствует общению. А вечером - затянувшееся afterparty. И все эти замечательные штуки - традиционны для SQA Days.

Общие темы, которые были в большом количестве докладов.

• Архитектура конструкции для автоматических тестов. Наиболее полно - в докладе Лянгузова, но у других тоже звучала. Отделение тестов от данных и так далее.
• Разделение уровней тестирования: UI - бизнес-логика комплексно (API сервисов) - unit-тесты отдельных частей. Выстраивание пирамиды.
• Доклады о распространенных ошибках и проблемах. Да, это все - известные грабли. Но почему-то по ним любят ходить.
• Об организации тестирования, сотрудничестве разработчиков и тестировщиков, которое необходимо.

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

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

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

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

Телеграфные записи основных моментов, остальное - смотрите презентацию и видео.

• Библиотеки. Важно поставлять тех же версий, что и в проме. У них Мавен.
• Фреймворк. Обеспечивает отчеты. Определяет формат тестов, это надо учитывать при выборе. Обеспечивает запуск тестов. Обычно начинают с Junit, а так - Fitness и Cucumber совместно.
• У Fitness тесты - Fixture, в других - есть аналоги. Это привязка тестов к исполняемому коду.
• Тестовые данные. От тестов отделяются. Повторное использование, структурирование и систематизация.
• Окружения. Запуск тестов в разной среде - FF и IE
• Конфигуратор. В приложении обычно статические настройки. Но их не всегда достаточно. Например, при запуске тестов под виртуалками с динамическими ip-адресами может быть нужно разбираться с сертификатами и подхватывать эти адреса.
• Важно, чтобы вся внешняя среда ушла из fixture
• Менеджер данных. Тесты не должны говорить "дай мне данные из этого файла, они должны говорить "дай мне данные такого типа в таком количестве". У них совсем умный менеджер не получился, но они туда идут.
• Еще важно контролировать связи между разными компонентами, архитектура зависимостей показана.
• Пример-1. Структура каталогов. Для Java-компонентов. Это - отражение логической архитектуры в структуру реализации, и со своими дополнениями.
• Вопрос уровня тестирования. Можно работать на UI, можно на бизнес-логике. Тест нового пользователя. Запрос пользователя, которого нет - создание - проверка, что есть. Вообще говоря, этот тест можно пускать на UI, можно на веб-сервисах, можно глубже. И в идеале мы должны иметь возможность переключения уровней. В принципе, это не очень сложно - если заранее подумать. Тут что важно - если есть не UI-вход. Потому что UI не может подсунуть неправильные значения - ограничения сверху. А тестировать сервисы - надо.
• Признак нехороше архитектуры - появляются папочки "разное" или классы, которые некуда приткнуть. Я: очень правильно!

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

Типичные причины провалов.

1. Запись тестов (recording). Еще 5 лет назад была книга, что это не работает. Но до сих пор продают и покупают именно это.
   • Перестает работать на чуть более сложных проектах, чем демо
   • Невозможно поддерживать по изменениям. Представьте, что recording продают бухгалтеру.
   • Простой выход - не используйте
   • Чуть более сложный: обеспечьте, чтобы работало для вашего приложения. Это доработка. И смиритесь, что когда поменялось - надо перезаписать тест, не пытаемся читать и модифицировать. И под это - заточите методику.
2. UI-автоматизация теста - медленная.
   • Потому что поднять с нуля через интерфейс - тяжело. По данным. Плюс - мы работаем через посредника.
   • Решение: Нормально пишите код. Не используйте sleep для синхронизации
   • Решение: Запускайте тесты параллельно. И сразу стройте архитектуру для этого. Включая разделение данных.
   • Фокусируйтесь на других видов автоматизации тестирования. Комплексно. UI-тесты - верхушка, а под ними - уровень бизнес-логики, API, там больше тестов. Под ними - unit-тесты (здесь: по логическим фрагментам).
3. А еще - UI-тестирование нестабильно. 2-3% fail-тестов просто потому что асинхронно.
   • Тоже не тестируйте все через UI. Я: из зала - неправда. Да, потому что там тоже может быть асинхронность
   • А еще - перезапускать после падения, и анализировать только повторные падения.
4. Слишком дорого разрабатывать и поддерживать.
   • Потому что выполняются медленно, а тестировщик - просто ждет
   • Потому что неверно выбран инструмент. Разработка тестов - тоже разработка ПО. И надо применять технологию.
   • Потому что недостаточно знаний у команды. Для хороших тестов - нужно сотрудничество разработчиков и тестировщиков, по-отдельности получается хреново.
     • Простой механизм от разработчиков, чтобы тест понимал, что все отрисовано
     • Чтобы найти кнопку попросите разработчиков добавить id, а не ищите полчаса как обойти.
   • Используйте хороший фреймворк
   • Отделите фреймворк от скриптов
5. Автоматизация не используется. И, блин это проблема
   • Мы не доверяем автоматическим результатам, лучше проверим руками. - Надо учить работать по-другому, работа с людьми. Интегрировать автотесты с ручными, в общей системе. Userfriendly: ручные писали в Excelб а тут будет какой-то xml. И запуск одной кнопкой.
   • Слишком долго и сложно анализировать автотесты. Это реально, и надо продумывать. Пример: (а) автотест упал - прогнали вручную - внесли дефект на систему при повторении, или на автотест, если ручной прошел.

Подводя итоги

• Выберите правильный фреймворк. Это - разработка
• Внимательно отнеситесь к организацию процесса и разделению обязанностей
• Налаживайте коммуникацию между командами.

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

Про инструменты.

• Не нужно наворачивать, потому что с базами знаний должны работать все сотрудники компании. А не только продвинутые.
• Расширяемость. Потому что область использования будет расти, а инструмент - не сменишь.
• Поддерживаемость. За инструментом надо будет следить, делать расширения и прочее. И тут вопрос тяжести решения.

Рекомендации напоследок.

• Сделайте обязательным использование базы знаний. Чтобы в ней все было, искать в одном месте.
• Автоматизировать рутину. Ее все ненавидят. Например, поиск устаревших статей. Рейтинги. Поиск. Аудит - отчеты что плохо. У нас тут хорошо. Пример: как только в Project-сервере меняют проект сотрудника, он получает письмо со ссылками на статьи, и он - должен ознакомиться, это тоже контролируют.

По инструментам - они используют микс. Часть - требует заказчик. Используют медиавики. Где-то sharepoint.

Любовь Аверина, Ново-Плей. Пример эффективного управления тест-кейсами при помощи Google docs. Основная идея доклада в том, что Google Docs таблицы представляют собой коллективно и совместно используемый Excel. В таблицах - удобно вести тест-кейсы, но вот совместно работать с Excel-файлами тяжело. А google docs - позволил эффективно работать. И докладчица подробно показывала, как у них это сделано. К сожалению, не видя экрана (а он далеко) это посмотреть не получалось. Но я надеюсь на презентацию.

Елена Андреева, Grid Dynamics. Грабли автоматизации. Учимся на чужих ошибках. Либез по правильной организации кода. Популярные грабли. Коротко и по делу. И, вроде всем известно и очевидно. Но мусорные куски закомментированного кода при этом встречаются повсеместно. И у разработчиков тоже. Плюс - тестовые фенечки, например, логи вместо системного вывода. Великолепная фраза "Результаты проверяйте просто, иначе в проверках - будут ошибки".

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

Проблема в том, что в compile-time не достаточно информации. Например, cast object к конкретному типу. В общем случае - ошибка, но в конкретной программе архитектура может гарантировать, что на вход идут только объекты нужных типов. И чтобы преодолеть это - используют дополнительную разметку, и специальные тулы, которые, опираясь на эту разметку проверяют правильность. И таким образом можно гарантировать, что строка-номер кредитной карты по всей программе имеет правильный формат, который на входе из простой строки - будет проверен. Или поделить все строки, используемые для динамического sql на те, которые заведомо корректные, и те, где нужен контроль sql injection, и обеспечить, чтобы этот контроль был проведен до исполнения. Получаются Pluggable types, дополняющие систему типов. Как средство упоминали Checkit framework.

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

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

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

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

Еще интересно про обработку ошибок. Есть onerror, но он не ловит на загрузке страницы. А еще - вопрос хостов. Для хостов можно делать доверенные узлы - если есть доступ. Второй метод - плагин JSErrorCollector, ловит ошибки браузера. И со списком можно взаимодействовать. Но только FF.

Илья Кацев, Яндекс. Проект Роботестер Робот как тупой юзер. Умный юзер - пусть будет тестировщик. Но тупая часть работы у него уходит. Краулер - ходит по сайту. По мотивам поиска, только внутри страниц, смотреть состояния и действия. Тут важно, что страницы очень динамические, содержимое сильно меняется. И надо заполнять формы и активировать. И там еще java-script логика, активизация кнопок. В целом интересно.

Наталья Руколь, Лаборатория качества и Андрей Мясников, Undev.ru. Диалектика созидания: курс на сотрудничество. Последний доклад дня, шоу с интерактивом. Четыре миниатюры взаимодействия тест-менеджера Наташи и тестировщика Андрея. Все идеи понятные, но сценки все равно классные, особенно вечером.

Миниатюра где "все не так" и разборка с мест - что именно не так. А потом - разбор ошибок. И рекомендации по исправлению.

1. Собеседование
2. Первый рабочий день
3. Испытательный срок
4. Рутина. В последней сценке менеджер окончательно демотивировал тестировщика, а потом - уволил.

Записывать не было смысла, так - отдельные фразы.

• Нет глупых вопросов, есть глупые люди, которые не задают вопросов.
• Нечеткое задание "познакомься с продуктом"...
• Если свободного времени нет сейчас, то его не будет и потом.
• Менеджер - не чайник, потому что его нельзя выключить.
• Соответствие слова и дела.
• Завел больше всех багов - к кулеру без очереди :)

А теперь - про остальные доклады, на которых я был.

Александр Андрущенко VIAcode. Тестирование производительности системы мониторинга на платформе Microsoft SCOM 2012. Доклад о том, что система мониторинга не должна напрочь перегрузить систему, вырубив приложение. Проблема в том, что мониторинг подключают далеко не сразу. Система уже написана и работает. И в этих случаях подключение мониторинга может быть чревато. Поэтому нагрузку самой системы мониторинга - тоже надо мерить и учитывать.

Михаил Матвеев, T-Systems. От ручного тестирования к автоматическому: опыт внедрения в крупном проекте. Была конкретная задача - перейти от ручного тестирования к автоматическому, без дополнительных требований к квалификации того, кто разрабатывает сценарии тестов. Ручные тест кейсы вели в Itorg. Для автоматических выбрали два продукта (от экрана далеко, поэтому не записал, но презентация - будет), один из которых обеспечивает визуальное конструирование тестов из набора шагов, а второй - генерит по этому некоторый исполняемый скрипт. Успешно.

Ольга Киселева, HFLabs. В моем коде багов НЕТ! Странный доклад. Про автотесты, которые делают большим количеством копи-пастов, и их надо вычитывать. И тесты, которые проверяют count, а не содержалку и так далее, слова правильные, но не структурировано. С другой стороны, проблемы-то воспроизводятся во многих случаях. В общем доклад про множественные проблемы плохоорганизованной разработки (тут - тестирования), и о частных решениях, которые надо обеспечивать через человеческий фактов (надо подумать, постараться...). Наверное, так бывает, но решения все-таки нужны более промышленные, процессные по-моему.

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

А речь шла про очень большие системы и функциональные тесты в них. Которые сильно зависят от данных, и потому выстраиваются в цепочки, в каждой из которых 300-400 тестов. Про использование bankwords - предметно-ориентированные (банк) ключевых слов. Про отслеживание зависимостей цепочек для распаралеливания выполнения - чтобы уложить регресс в 6 часов вместо 12 (или больше, могу ошибаться). Про схемы обмена данными, на которых как раз основана зависимость тестов. Но все это, увы, без конкретики - как именно они поддерживают схемы обмена данными, как ведутся цепочки и так далее. На общем уровне.

Владимир Примаков. Мастер Тест План / Тестовая Стратегия К сожалению, доклад оказался методологической инструкцией в буллетах. Без кейсов, обучение истине от скучного лектора. Жаль.

Татьяна Зинченко, Inter Technology Group. MindMap - в мире интеллектуального тестирования. К сожалению, доклад не удался - потому что не получилось поставить тулу, которая рисует mindmap вживую, потребовалось обновить Java, что затянулось на неопределенное время. А доклад был про mindmap как средство работы для тесткейсов. Лично я - это слышал и, по-моему, именно от Татьяны. С другой стороны, на каждой конференции - много новых людей и они-то не слышали :) Зато я быстро нашел сервис http://drichard.org/mindmaps чтобы рисовать через web. Сохраняет в Json, на сайте написано, что может в googledocs но не работает.

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

Была большая лекция Стива (Stephen Mann) про командную работу, во многих аспектах.

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

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

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

Кстати, дам некоторую врезку о тех самых деталях вариантах, которые упущены. Это полезно и мне самому - я их вспомню.

• Команды, ведомые лидером - не единственный вариант. Второй эффективный вариант - команды, руководимые опытным координатором. Просто он - существенно сложнее и требовательнее к составу. Согласно исследованиям Белбина, они обладают примерно равной эффективностью, и оба широко распространены. Собственно, эти варианты были сформулированы Белбиным в ходе своих исследованиях. Прочитать об этом можно в его книгах "Команды менеджеров Как объяснить их успех или неудачу" (это - первая, с нее стоит начинать) и "Типы ролей в командах менеджеров" (это - дальнейшее развитие). А две недели назад на SPM-conf-2012 я делал доклад с кратким изложением основных аспектов - что можно вложить в 40 минут. На сайте есть презентация, и скоро (в течении месяца, думаю) появится видео.
• Работать при развитии человека, конечно, надо с сильными сторонами, и надо подбирать ему позицию с адекватным кругом обязанностей. Однако, при этом организационное разделение обязанностей - штука весьма устойчивая, и важно, чтобы человек закрывал большинство аспектов определенной позиции. И если слабые стороны в этом мешают, то их надо подтягивать. Иногда можно сместить разделение обязанностей по позициям, но суть в том, что обязанности одной позиции часто сильно связаны между собой, и их перераспределение может сильно уменьшить эффективность. Можно, конечно, все организационное деление на позиции переиграть под способности конкретных людей, но это - сложная работа, потому что требует учесть много аспектов. Как в футболе - есть несколько типовых способов разделения обязанностей между игроками команды, роль игрока определяется его способностями, но слабые стороны для роли - надо подтягивать. А сделать полностью оригинальный рисунок взаимодействия могут только очень сильные тренеры.
• По Мотивации - есть разные люди. Теория мотивации Герчикова делит людей на пять категорий, в зависимости от типа их мотивации. И с разными людьми надо работать по-разному. Подробнее о теории почитать здесь, а здесь - пост практика на ту же тему (с продолжением). И это - не единственная теория. На ADD-2010 Антон Овчинников рассказывал о применении упрощенной модели Юнга для правильного донесения до сотрудников конструкции оплаты персонала.
• С формированием культуры компании проблема заключается в достаточно быстрой смене персонала в современных условиях. В основном человек работает на одном месте год, два, реже три. Привить культуру за это время - очень сложно. А дефицит кадров - не позволяет отбирать людей с учетом культуры. Плюс надо учитывать, что чрезмерная однородность - она ослабляет команду. Отчасти, ответ был дан - через формирования общей культуры в рамках сообщества, из которого набирается основной состав команды.

На этом про команды закончим.

Что касается собственно методов управления знаниями, то участники разбились на команды и придумывали совместные проекты для регионов. При этом были достаточно интересные методички по ведению коллективного обсуждения в целом и по методам мозгового штурма и 5 почему. А в группах были маркетологи из СОМАР, которые знакомы с практическим применением этих методов по своим мероприятием. И практически это было весьма эффективно, такое знакомство управление знаниями через практическое применение. Кстати. стоит отметить оригинальную интерпретацию метода Мозгового штурма, дополненную сокращенной ролевой моделью Белбина (7 ролей из 9, без Реализатора и Души компании, которые не нужны в коротких сессиях). Выглядит любопытно.

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

Так что второй день был очень креативным и практически-нацеленным. А конференция в целом - прошла хорошо и лично мне дала новые знания о работе со знаниями :) Фотки - смотрите в ЖЖ, благо блогеров было много.

Сегодня в третий раз был на KM Russia-2012. В этом году мероприятие проходило в весьма любопытном формате, и концептуально и по исполнению. Если предыдущие два года это весьма напоминало обычные конференции с докладами спикеров и интерактивными мастер-классами, то в этот раз организаторы поставили весьма необычную и амбициозную цель - свести вместе бизнес, власть и блоггеров вокруг рамочной темы управления знаниями, и попытаться заложить предпосылки конструктивного сотрудничества. Надо сказать, что с профессиональной точки зрения эти цели - далеки от моей работы, однако на форуме ожидались эксперты мирового уровня, и в частности Рон Янг, а также выступления от крупных корпораций, применяющих у нас практики управления знаниями - IBM, JTI, Сбербанк, РЖД, что для меня - интересно. И ожидания тут оправдались. А еще - было просто любопытно, что выйдет из столь разнородной тусовки.

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

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

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

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

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

Еще было интересно узнать, как продвигаются проекты в Сбербанке и корпоративном институте РЖД, и других, о которых я слышал в прошлом году.

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

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

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

Завтра - продолжение.

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

А еще - был приятный для меня сюрприз, мой доклад о командах Белбина вошел в тройку сильнейших вместе с докладом Николая Фролова "Gamification" и докладом Максима Дорофеева.

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

• Инструменты для GTD из доклада Татьяны Беловой. Саму методику я представляю и легкую ее версию в целом использую. Просто у меня не так много дел, и на оперативном уровне точно обходится простым текстовым списком. Но разнообразных активностей становится больше и, возможно, уже стоит перейти на более серьезные конструкции, например, Remember The Milk. А еще - подумать об использовании EverNote для фиксации идей и материалов, мысль о том, что идею можно просто продиктовать на телефон, и она запишется, да еще с распознаванием представляется заманчивой - в метро, вечером.
• Модель для видах обучения в зависимости от контекста, прозвучавшую у Дмитрия Башакина. Я понял, что стоит оценивать и позиционировать взаимодействие с другими, в котором есть аспекты обучения, передачи знаний относительно этой модели. Без этого способы могут переключаться, а это сильно снижает эффективность.
• А еще - знания и модели, полученные из докладов Максима Дорофеева и Дмитрия Безуглого останутся у меня в памяти и в деятельности по связанным темам будут использованы. Но это не к исполнению, а просто как накопление базового уровня картины мира.
• Еще я взял на заметку опыт hack days. У нас в компании были в эту сторону идеи, но не столь оформленные, и до практического применения дело не дошло. Организовывать я лично - не готов, но поспособствовать при случае - это да.
• Доклад Марии Бондаренко привел к мысли о сознательной работе в квадранте эмоций "Восхищение" - делать неожиданные вещи заказчику. На внедрении и обучении ГБК эта практика была, Алена держала фокус: мы делали разные недорогие, но важные заказчику вещи как реакция на замечания на обучение. Но есть подозрение, что как практика - она утеряна. Стоит ее пошевелить, наверное. И подумать о том, как вписать это в процесс в рамках проекта СУПП. В принципе, ответ есть - через список хороших практик относительно этапа проекта. Они не обязательны к использованию, но, подобно спискам GTD, "если ты что-то не делаешь, то хотя бы поступаешь так сознательно".

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

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

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

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

А теперь - обзор докладов.

Начну я с замечательного, превосходного доклада Максим Дорофеев. Гигиена количественного управления.

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

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

1. Определяем цель. Цель должна быть одна, а не много - иначе ты в ситуации Буриданова осла.
2. Строим или находим модель объекта управления. Модель явления обычно содержит множество показателей, но Цель позволяет нам отделить важное от неважного, и ограничится малым числом понятных параметров.
3. Отделяем общее от особенного. Вариация показателей может быть системной, обусловленной общими причинами, и тогда надо работать с процессом управления или самим объектом. А может быть результатом влияния некоторого особенного фактора, вызывавшего провал или успех. Отличить это сложно, но есть модели. Карты Шухарта (6 сигма), критерий Бэрра, и правила Нельсона для тренда. Есть еще, но этих - хватает. А интересующиеся могут читать ГОСТ 50779.42 или ISO 8258 (если я верно списал номера).

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

Этот процесс был показан на двух конкретных примерах

1. Мониторинг срока в разработки. Цель - успеть к сроку. Модель - наблюдение за бэклогом в итеративном инкрементальном адаптивном процессе разработки. Модель была замечательно визуально нарисована! А еще - по ней есть программка, выдающая предсказание срока при загрузке среднего и среднего квадратичного отклонения по измеряемым величинам.
2. Обеспечение максимальной производительности. Модель - на основе производительности по ролям, опять-таки в итеративном инкрементальном адаптивном процессе разработки.

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

И в заключении - шедевры, записанные за докладчиком. Можно также посмотреть твиттер - народ активно постил.

• Я надеюсь, что к концу доклада кто-то поймет, что все делал неправильно. Потому что, по моему опыту, почти все все делают неправильно.
• Цифры - это то что любят менеджеры. Люди, мотивация, креатив - сложно. Зато цифры - они говорят "сколько заплатить премию Коле". А это, по наблюдениям, главный вопрос менеджмента.
• Менеджеры верят, что если недовольным премией сотрудникам показать формулу расчета, то они поверят в справедливость и смирятся.
• Менеджеры любят цифры, только цифры их ненавидят.
• Буриданов осел. Много целей для проекта - то же. Не стесняйтесь ставить ОДНУ цель.
• АвтоВАЗ. Богаче комплектация - больше приключений! Кстати, их настоящий слоган.
• Ставьте цель. Например, скорость. Да, будут ныть про качество. Но реально я не видел ни одного удачного способа сделать быстро, принеся в жертву качество. Потому что чтобы быстро сделать проект - там надо мало багов и прочее.
• Менеджеры обожают графики больше, чем порнуху программисты.
• Картинка. Человек с завязанными глазами идет по граблям - общая причина. А если одна грабля с топором - там особая причина.
• Люди-снежинки. Руки из жопы. Дорофеев вместе с сыном - автор этой метафоры. Он - рисовал, сын - увидел и назвал.
• Если к людям относиться как к идиотам, они оправдывают ожидания.
• IT - единственная область, где с костылями мы только быстрее.

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

Алексей Харюков. Hack Days в рамках компании. Результаты эксперимента. Практический доклад. Как они устроили в компании Hack Days в мае и результаты превзошли ожидания. И они повторили в ноябре. Рамка: команде надо за краткое время (2 дня) выдать идею и с нуля сделать прототип. Они делали в выходные. Результат презентуем за 10 минут, голосование тайное по номинациям: Навороченность, Завершенность, Оригинальность, Лучшие презентации, Открытие HackDays, Best of the Best.

Участники: в первом 27 чел. 8 команд из 100, во втором - 40 чел 12 команд из 120 сотрудников из разных городов. Во втором участвовали дистанционно из штатов, невзирая на часовые пояса. Идею - подхватили. Сильно меняются представления о том, что можно сделать за два дня. А еще - были сделано два проект, которые будут пускать в промышленную разработку.

Понравилось и содержание доклада, и манера изложения и представления.

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

Но именно из этого доклада я вынес модель соответствия уровней обучаемого стилям обучения

• Уровни: Начинающий энтузиаст - Разочарованный новичок - Способный, но осторожный исполнитель - Профессионал.
• Стили обучения: Директивный - Наставничающий - Поддерживающий - Делегирующий

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

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

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

Рекомендовала книги

• Джозеф Пайн "Экономика впечатлений."
• К.Сьюэлл "Клиенты на всю жизнь".

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

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

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

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

Только вот, по-моему, что реальный мир - это не игра ни разу. Поэтому мы имеем частное проявление старой идеи: пусть менеджеры как-нибудь экранируют реальный мир, чтобы программистам был фан. Было - через agile, сейчас - через gamification. И движение с двух сторон: программисты хотят фан, а менеджеры в очередной раз надеются на серебряную пулю, которая позволит простым образом заставлять программистов работать как одержимые. Я думаю, что ничего не получится - серебряной пули не существует. Но конкретные полезные средства и практики - безусловно появятся.

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

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

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

Павел Обод. Бизнес мышление у сотрудников IT сферы. Докладчик - увлеченный новым. Энтузиаст-новичок. Он сам это прошел и открыл, и несет в массы. При этом он - владелец небольшой компании. И честно признает, что у себя использует 15% рассказанного, но хочет - больше. А рассказ был про витамины Адизеса. И их мапинг на IT-роли в команде. И про непрерывное улучшение процесса. Про вебинары как инструмент.

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

Было некоторое количество забавных тезисов.

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

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

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

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

Владимир Горшунов. Смешиваем Scrum и Канбан Докладчик тролил аудиторию, а аудитория - наезжала на докладчика. Что оживляло, но особого интереса для меня - не добавляла. Потому что автор говорил о некотором виртуальном и жестком SCRUM, о котором думали, а на самом деле он не столь догматичен и его надо адаптировать под реалии, плюс местами упростить в сторону Канбан. Как пример такой псевдопроблемы: "Как заставить SCRUM работать, когда T&M а не Fixed - у нас же при этом нет Product Backlog". Я: T&M - это ж почти идеал. В общем, то на нынешнем этапе развития agile-практик мысль - очевидная. Но пока - не для всех, ибо лучшие практики развиваются быстрее, чем многие люди это воспринимают.

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

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

На этом - все.

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

На конференции - я выступал, рассказывал о модели командных ролей Белбина. В свое время мне эту книгу посоветовали, я прочел и проникся. Потому что это - качественная экспериментальная работа с командами, наблюдение за ними и выявление соответствия между позициями, которые занимают люди их умственно-психологическими характеристиками, определяемыми по тестам. И этим оно отличается от ряда других моделей, которые основаны больше на некоторой классификации деятельности, после чего заявляется: раз деятельность нужна - пусть ее выполняют. Здесь деятельность поделена и распределена не умозрительно, а на основе научно поставленных экспериментов и наблюдений. И, собственно, мне хотелось рассказать об этом людям, тем более, что модель применима для IT-команд и о ней явно пишет Йордан в "Смертельном марше". Если я вас заинтересовал - смотрите презентацию и доклад, а лучше - первоисточник, книги Белбина "Команды менеджеров. Как объяснить их успех или неудачу" и "Типы ролей в командах менеджеров".

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

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

Безусловной звездой первого дня, по моему мнению, был Дима Безуглый. Сначала он экспромтом заменил заболевшую Наталью Руколь, прочитав доклад Кто такой менеджер продукта и что он может дать компании-разработчику. Содержание доклада сильно не соответствовало достаточно скучному названию, оно было гораздо шире и описывало роль и ответственность Product Manager и сопутствующие активности, много сопоставляло это с Project Manager'ом. Главное - что в продуктовой разработке классический треугольник Бюджет - Деньги - Сроки - сильно теряет значимость, хотя сами понятия остаются.

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

Главный рынок для IT-компании - рынок рабочей силы. Если не найдешь персонал - вылетишь. Раньше разработчики гуляли между заказной (интересно) и внутренней (есть деньги) разработкой, все. А сейчас приходят продуктовые компании. Там хорошо с деньгами и неплохо с интересно. И они ломают рынок кардинально. Единственное, часть продуктовых компаний - они не разрабатывают сами. а заказывают разработку.

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

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

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

• Что разрабатывать просто, миф потому как много фейлов и нет уверенности результата.
• Что сложно. Потому что год поучил Java - и вполне способный программист. Не то, что в космической отрасли.
• Что разработка ПО прохожа на производство. Факт - разработка ПО это только проектирование. Говорит, что статистика по миру по НИР и ОКР примерно соответствует статистике Standish group по успеху программных проектов.
• Разработка ПО - инженерная дисциплина. Факт - гуманитарная. Я: он тут противоречит предыдущему факту. Ну или надо все НИР и НИОКР объявить гуманитарными.
• Говорит, что Коберн (Коуберн?) исследовал корреляцию между успехом проекта и применяемой методологии. Обнаружил, что корреляции нет.
• Миф. Разработку ПО можно ускорить.
  • Реально есть формула расчета оптимальной длительности, и сократить можно только на 20% максимум.
  • В ответах на вопросы он формулу продиктовал. Длительность проекта в месяцах = 2.5 * корень кубический из трудоемкости в человеко-месяцах.
• Миф. Проблему можно закидать денигами.
• Миф. Проблемы решаются процессом
• Миф. KPI мотивирует
• Миф. Работу программистов нельзя измерить.
• Миф. Незаминимых людей нет. Факт: есть цена замены. Выход нового - 2-12 месяцев. Цена замены порядка годовой зарплаты.
• Миф. Программисты антибюрократичны. Факт - они антиидиотичны.
• Миф о железном треугольнике. Опровергается разработкой Word :)
• Миф: программистами невозможно управлять. Факт - управлять можно, но не как МакДональдсом, а иначе.

Позитив. Правда тоже много известных тезисов.

• Теория W Барри-Боэма. Использовать теорию корпоративных игр с ненулевой суммой. Общение, взаимовыгодный процесс и взаимовыгодный продукт.
• Выбрать правильный продукт - тот что приносит 500% прибыли, а не 10%. Ссылка на Демарко. :) Я: это из серии, что правильный человек сидит на берегу и ждет, когда проплывет труп врага.
• Правильный персонал
• Маслоу в развитии. Первые 4 уровня - дефицитарные потребности, насыщенные на 80% они перестают интересовать. А потом, верхние, самореализация - идут бесконечно.

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

• Формула E=IQ*EQ*EQ и баян про IQ и EQ
• Эшби, Введение в кибернетику 1959. Для хорошего управления число состояний управляющего объекта должно быть не меньше количества состояний объекта управления. Я: следствие: население (государства), рассматриваемое как объект правления имеет очсень малое количество состояний.
• Цикл Наблюдать - Общаться - Анализировать - Синтезировать - Пробовать - Обобщать Я: сомнительно, если честно, что цикл такой.

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

• Многие обламываются на внедрении сразу - не могут свести много своих списков в один. Не надо сразу. Главное - освободить голову от жужжания дел, а то, что в ежедневнике - не жужжит, его можно позднее перенести, работая пока на нескольких списках. Чтобы выписать все дела из головы, достаточно пары часов. Результат вас удивит - у нее получилось около 100 пунктов.
• Потом - сортировка на списки по Аллену и перенес в средство, где будем вести (если выписывали отдельно).
• А дальше - приучаем себя на регулярной основе совершать действия со списками.
  • Раз в день, 10-20 минут, просмотреть список и выгрузить лишнее из головы. Она этим занимается в метро, по пути на работу и с работы. Еще иногда внутри дня выгрузку делает.
  • Еженедельно - список отложенных и когда-нибудь. Вдруг пора переносить.
  • Еще - приучила себя ловить идеи. Задачи - о них напомнят.
• Следующий этап, ТОЛЬКО когда предыдущий пройден, списки - ведутся и с ними работаешь. Тогда делаешь приоритеты, Напоминалки, делить списки по контекстам. У нее контексты конкретного человека - "заодно спросить, уточнить".

Грабли

• Есть грабли - начинаешь беспокоиться о системе дел. Постоянно. Это неправильно.
• Излишняя фокусировка на инструменте. Он должен быть удобным, но не должен брать много мыслей.
• Сложная система связей
• Внедрить сразу
• Два списка Рабочее/Личное
• Невнятная формулировка. Ловушка для тех. кто использует outlook - кидают письмо и не пишут. что по нему надо сделать. Надо писать, не не делают.

В докладе был краткий список инструментов. Она использует Remember The Milk. Плюс задачи из писем в течении дня - в Outlook. Но по концу дня - все переносится в Remember The Milk, послать можно Fwd письма.

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

Помимо прочего фиксация дел обеспечивает, что "если вы чего-то не делаете - вы точно знаете, что именно вы не делаете".

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

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

• Поппендик: у каждого работника должно быть два менеджера: Профессор (do things right) и Предприниматель (do rights things).
• Product Owner = Product Manager. do rights things.
• do things right - команда, а для качества возникают менторы по ролевым специализациям (программирование, тестирование)
• А scrum master - это третье, сотрудничество, фасилитатор. Do things fast.
• Нужен баланс между всеми составляющими менеджмента. Если перекос к Предпринимателю - дерьмовый процесс и продукт, если к Профессору - хорошо делаем ненужное. И так далее.

Получился хороший рассказ как работает scrum of scrum и делится ответственность.

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

• знание цели - PO
• автономность - SM
• мастерство - Mentor

Ирина Виноградова, Владимир Ли. Планируем релиз играючи. Игры не получилось, речь шла о средстве визуализации на Excel для планирования релизов, написанном под ту митодику, которая применяется в Касперском (оценка фич в разрезе ролей). Средство - хорошее и правильное, но игры - все-таки нет. А форма доклада - хорошая, местами как диалог между Product Manager и Project Manager + Team.

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

Конференция Req-Labs в Киеве прошла хорошо. Есть мелкие проблемы, которые я перечислю сразу - чтобы организаторы их учли, если прочтут мой отзыв. WiFi практически не работает, так что за докладчиков - я так и не голосовал. Залы - очень длинные и экран сзади видно плохо и мелко, можно, наверное, было попробовать повернуть расположение, повесив 2-3 экрана. А еще - не хватало указателей на улице к конференции для новичков в Киеве - в парк Пушкина в первый день и к нужной двери бизнес-центра во второй. А так - организация достойная. Два трека, большие перерывы для общения. Отдельный зал для общения с докладчиками, правда там было не слишком много народа.

А главное - достойное качество докладов. Много практических докладов, мало теоретиков. При этом, что характерно, эти авторы практических докладов теорию знают на высоком уровне. Поэтому рассказ практик идет в контексте современных теорий. Или наоборот, теории сильно иллюстрируются практиками. Что на современных конференциях встречается не так часто, как хотелось бы. О ценности докладов говорит то, что я очень много конспектировал на ноуте. Может быть, кончено, что я просто был на лучшей половине докладов. Но, с другой стороны, лучший по итогам голосования на facebook в день конференции докладе я пропустил. Это "Бизнес-аналитик или бизнес-синтетик? Или как сделать бизнес-анализ чуть менее унылым" Артёма Сердюка (ISM Ukraine, Украина), который шел параллельно с докладом Пола Тернера. Буду будет смотреть видео.

Что интересно - организаторы говорят, что при организации Конференции были воплощены многие идеи, высказанные участниками мозгового штурма на мастер-классе в рамках AnalystDays в Минске.

Дальше - краткий обзор докладов.

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

Второй день SECR-2012 был не хуже первого, и это - очень радует. Я по прежнему ходил между 5 треками, чтобы охватить побольше докладов, хотя и не столь активно, как в первый день: наверное, устал. Были пересечения по интересным докладам, из-за которых несколько хороших докладов я точно пропустил. Кроме того, я не ходил на технологические доклады, близкие к железу, и на доклады по мобильным устройствам - потому что это - не мой профиль. А там тоже было много интересного. Так что не надо думать, что мои отчеты исчерпывающе описывают конференцию.

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

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

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

Практический опыт применения eye-tracking для оптимизации интерфейсов и сегментации аудитории. Сергей Котырев, Umisoft Любопытный доклад о практическом опыте - оценка usability сайта на основе движения глаз. при этом испытуемым давались конкретные задания, например, скачать демо-версию или добавить новость, а они сайт видели впервые. Из очень интересного - оказалось, что мужчины и женщины сильно по-разному себя ведут, если мужчины при скачивании демо сразу обнаруживали кнопку "Скачать" - (подсвеченную оранжевым, но в углу), то женщины уходили в описание функционала, и только там, другим путем доходили до скачивания демо. А про добавление новости - там была контринтуитивная засада, для появления этой функции надо было глобально перейти в режим редактирования, и эту кнопку находили не сразу. Но! когда ее просто контрастно подсветили черным вместо серого - время сократилось до приемлемого, так что даже при не слишком интуитивных решениях можно многого добиться простой работой с выделением элементов.

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

Чего хотят Заказчики?… Или особенности национальных «внедрений». Валерий Бирин, IBA На большинстве проектов есть жесткая ситуация со сроками, бюджетом, ресурсами. И если Yordan в Death March видит в этом проблему, и говорит о выживании на таком проекте, то DeCarlo в eXtreme project management видит возможности. В любом случае, на таких проектах для успеха важна психологическая и коммуникативная составляющая, и направление потока мыслей и эмоций заказчика и команды.

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

• Все заказчики хотят чтобы проект прошел спокойно. Хотя тут я бы поспорил: заказчик он же не дурак, и часто понимает. что проект спокойно пройти не может потому что сроки и деньги. А если вдруг может - значит сроки и деньги можно уменьшить. То есть он готов к жесткому проекту, и встречаются менеджеры, которые от этого получают фан. Не от проблем, конечно, но от их решения.
• Нельзя говорить заказчику, что он тупой. В принципе.
  • "Вы нас считаете дураками, как мы можем с вами работать?" Как реакция на фразу в пылу спора "Ну, наше же ПО - для умных людей"
• Нельзя оценивать своих программистов перед заказчиком - хорошие, плохие и прочее.
• Заказчики - ранимые. Нельзя показать его чувствовать как ребенка, который привлекает внимание.
  • Нельзя: "Я не смогу сегодня поработать, потому что есть важная задача от другого клиента"
  • Нельзя: "У вас должно работать так, потому что так работает у вашего конкурента"
• В обратную сторону - тоже нельзя. Нужно собственное достоинство.
• Заказчика надо активно информаировать - что для него сделано!
• Нельзя сильно приукрашивать - надо помнить, что за свои слова надо будет отвечать.

Практика - семинар в начале проекта про взаимоотношения с заказчиком.

Если есть вопросы и истории - пишите, я обязательно отвечу. Блог http://vbirin.blogspot.ru/ (правда, это я поискал, данные из презентации я не записал, но можно там посмотреть).

Обучение коду в мире онлайн. Бенджамин Б. Бедерсон, University of Maryland Рассказывал о современном дистанционном обучении. Его идеи и те изменения, которые оно вносит в процесс, например, возможность прервать урок и продолжить с места, перейти на другую тему при непонтках, быстро заполнить ответы - они понятны. Но при этом в целом происходит переход в другое качество, и это - правильно учитывать при создании программы.

А еще при обучении компьютеру дистанционное обучение с ильно меняет картину, ддавая такие возможности как live coding. И сейчас есть множество площадок для этого.

• khanacademy.org - Live Coding
• pthontutor.com - live diagramming

Ворчуны на проекте – положительные и отрицательные стороны. Как эффективно работать с такими людьми с учетом психологического климата в команде? Владимир Железняк, Дмитрий Снисар, IT-Boost.com Рассказ - case study. Психология по конкретному поводу. По делу, поскольку проблема распространенная - интересно. Ну и докладчик - говорит живо. Да, если бы психология входила в базовую вузовскую подготовку программистов и менеджеров, то такие доклады были бы не нужны. Но у нас же это не так, только ВШЭ пытается - о чем вчера рассказывала Елена Мандрикова.

И - остальные доклады.

Как реализовать себя на глобальном рынке? Александр (Sasha) Галицкий, Almaz Capital Partners Доклад открывал день, и начало диссонировало: "слайды просто картинки, я плохой докладчик". Но в целом доклад хороший.

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

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

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

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

Управление проектами 80-го уровня, или размер имеет значение! Возможности и ограничения применения статистических моделей для управления проектом. Юлиан Ларионов, Николай Сокорнов, Reksoft. В общем-то в докладе оставляет смутное впечатление. Идет некоторое наукообразие, для меня - очевидное, которое надо решать практически, а не заботится теорией. Понятно, что есть грабли, на которые не надо наступать. Но их надо предъявлять конкретно. А то доклад получается на том уровне абстракции, который не интересен совершенно. И это - обидно, потому что за докладом точно стоит практический опыт, который был бы интересен, даже если размер там не 80-й (это для меня когда сотни человеко-лет).

Моделирование и облачные вычисления. Ричард Соули, OMG Ричард выступал на SECR в 2010, о необходимости стандартов, осознанном еще в Балтиморском пожаре (1904) :) А теперь иллюстративный ряд теперь - на множестве электрических розеток и вилок. А множество usb-разъемов, питания для телефонов и ноутов, думаю, тоже нашло бы отклик.

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

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

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

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

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

О требованиях к средствам автоматизации приемочных тестов при использовании подхода «разработка, управляемая описанием поведения». Евгений Пышкин, Максим Мозговой, Михаил Глухих, СПбГПУ Доклад про BDD и полуавтоматическое построение тестов от сценариев поведения. Авторы провели сравнение различных средств по разным характеристикам, правда, больше по описаниям и материалам, а не практически. В этой области они новички, в чем сами признались, и целью было не только показать результаты, но и получить отклик от тех, кто использует, потому как раньше на SECR тема не поднималась. Зал - откликнулся. А сама тема - новая именно для SECR, на профильной конференции SQA days про тесты от BDD я слышал в нескольких докладах.

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

Автоматизация миграции динамически формируемых запросов. Семён Григорьев, Яков Кириленко, LANIT-TERCOM Я слушал небольшой кусочек в конце - потому что был на других докладах, так что, возможно, недооцениваю доклад. И, по-моему, я это слышал, хотя, может от другой фирмы. Перенос MS SQL -> Oracle, в системе много кода, который вызывает SQL, а запросы строятся по-разному. При этом надо было встроиться на уровень обращений к БД, не трогая коды системы (как я понял). Идея - интересная, автоматизированное преобразование, половину удалось перевести автоматом, в остальных автомат дает хорошую обертку, даже если сам запрос преобразовать не получается. И там приходится конвертировать уже сформированный запрос динамически. Реализация - порядка 20К на F#. И получился хороший рабочий результат, хотя с формальной точки зрения безошибочность гарантировать и нельзя. Подход в принципе может быть применен не только для SQL, но и для разных DSL, генерации HTML и т.п., m4, eval jscript.

Дискуссия. Сохранится ли профессия программиста? Это была определенная разрядка в конце конференции. Тем более, что на сцене были люди существенно разных взглядов. Андрей Терехов отстаивал профессию системного программиста, которому требуется хорошее базовое образование, знание алгоритмики и математики, а Стас Фомин, наоборот, говорил о том, что эти знания бессмысленны для основной массы программистов. С чем, кстати, были согласны многие, хотя и не столь явно. Были предложения посмотреть на развитие hardware - не того, которое компьютеры, а того, которое скобяные изделия - где основное производство ушло в программистов и наладчиков станков с ЧПУ, а люди с напильниками остались фрагментарно. Хотя мне эта аналогия кажется сомнительной.

Интересна классификация программистов, как это видит Павел Ходалев из Deutsche Bank

1. Яйцеголовые (у них - в inhouse)
2. те кто им снаряды подносят;
3. Commodity
4. Support

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

Классификация от Стаса:

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

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