Текущая версия на 19:53, 27 июля 2020

SECR-2013 определенно удался. Два дня я слушал доклады, практически на всех слотах были интересные мне доклады, и это замечательно. Более того, я совершенно точно пропустил много хороших докладов, и даже доклад JetBrains про Kotlin и мастер-класс Макса Дорофеева по оценке проектов, потому что приходилось выбирать между параллельно идущими треками, которых в первый день было 4, а во второй — 5(!). Да, как сопредседатель программного комитета, я знал про тезисы большинства докладов и участвовал в рецензировании. Но тезисы сильно отличаются от живого доклада, воспринимаются по-другому, и, послушав доклады на конференции, я достаточно много узнал. Появились новые мысли. И все это не означает, что на конференции были только хорошие доклады высокого уровня. Казалось бы, можно было уменьшить число треков и поднять уровень. Но по тезисам, даже развернутым, доклад оценить нельзя, кроме того, разным участникам интересны не только доклады на разные темы, но и доклады разного уровня — потому что для применения в практической деятельности доклад должен попасть и в тему и в уровень восприятия. Поэтому доклады были разные. И участники — могли выбрать, а докладчики — увидеть реакцию и в следующий раз — сделать новый доклад лучше.

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

И конференция сильно обращена в будущее, о грядущем было достаточно много докладов, причем не от очень разных спикеров. Ивар Якобсон рассказывал про SEMAT — Essence: это только в конце прошлого года появившаяся в относительно законченном виде конструкция. Вил ван дер Аалст рассказывал про Process Mining — свежее, но уже оформившееся течение, основателем которого он является. Джим Стайклетер, директор по стратегии и инновации из Dell, рассказывал про тот мир инноваций, которым он живет, и это очень концентрированная картина, которую получаешь за доклад. А у Дэйва Томаса в презентации и докладе было много парадоксальных трендов современности, над которыми лично я планирую еще внимательно подумать.

И в этом мире компаниям и разработчикам надо жить и развиваться, успевать за этим миром. И началась конференция докладом Дмитрия Лощинина, президента Luxoft, о стратегии успешной компании. И были доклады и дискуссии, направленные на развитие стартапа, превращение продукта или его идеи в успешное предприятие. Кстати, был забавный кейс: продажи одного продукта плохо шли. Сделали тот же продукт, но для юристов, внешняя адаптация, в 10 раз увеличили цену, запустили рекламу — продажи серьезно выросли, и при этом продаж вдвое больше, чем активаций.

А еще многие ведущие компании — JetBrains, Parallels, Дойче Банк, Luxoft, Яндекс и другие — делились своими процессами, рассказывали о них, и это были не выступления первых лиц, а рассказы сотрудников, работающих внутри разработки. И было замечательное шоу Свена Петерса из Attlassian про современную разработку.

Но при всем этом на конференции было очень много технических докладов, и это тоже правильно. Был Крис Латтнер, главный архитектор в LLVM Compiler и директор разработки в Apple, он рассказывал про принципы и архитектуру LLVM и Clang, которые являются основой многих промышленных решений. Были доклады JetBrains, доклады из Parallels, секция мобильной разработки, которую вел Дмитрий Мартынов из Google. Я был далеко не везде, но слышал много отзывов. Были качественные узкоспециализированные доклады, например, профессора Бориса Штейнберга по высокопроизводительным вычислениям, при этом я от нескольких участников слышал, что тема оказалась им очень вовремя.

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

И до встречи на SQAdays, которая начинается через полторы недели во Львове и где, в дополнение к обычному формату, будет отдельный день с иностранными докладчиками.

Особенно понравившиеся доклады

Тенденции рынка сервисной разработки ПО. Формула успеха. Дмитрий Лощинин, Luxoft

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

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

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

Innovate or Die. Джим Стайклетер, Dell Services

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

XX век — minimize transaction cost. XXI век - Transformation, accelerate capatibility building and apply it to innovation. И обстановка кардинально меняется: from industrial work to creative and knowledge work. При этом технологии сами по себе ничего не меняют, они лишь делают возможным изменения. И задача — facilitate and accelerate, чтобы оказаться в целевом месте.

Innovation. New ideas + Forward thinking + Feasible + Viable + Valuable. Not a marketing term.

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

Agile и SEMAT — идеальные партнеры. Ивар Якобсон, Ivar Jacobson International

Ивар представлял в своем докладе Essence of Software Engeneering, созданный SEMAT. Это новая конструкция, которая в законченном виде появилась в конце прошлого года, формализм для описания процессов разработки в ИТ, от проектирования до эксплуатации и развития. Он родился из попытки научиться работать с тем многообразием процессов, которые есть: от SCRUM до водопада, комбинировать их, создавать адаптивные процессы, исходя из нужд конкретной организации и проекта. И авторам удалось создать такой формализм, что немаловажно — достаточно простой для понимания. И они описали на нем те процессы и практики, которые послужили источником. Описания достаточно компактны и наглядны, потому что визуальный язык входит в стандарт, при этом задействованы не только графические примитивы, но и цветовое выделение и другие визуальные эффекты.

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

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

ИТ 4.0 — возможности и проблемы. Дэйв Томас, Bedarra Research Labs

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

Некоторые я тут приведу, просто как примеры.

• Много современных дорог — это возврат к CRUD: applied fuctional programming, NoSQL database, Map Reduce
• Выразительность, кода против количества, microservice architecture вместо dependency strangle, less objects and frameworks...
• Data driven always more flexible then code driven.
• Меньше объектов — меньше рефакторинга. И это хорошо.
• Table oriented programming
• Scripting рулит — python, ruby, groovy...
• Enterprise MarshUp — это real SOA

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

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

Запись http://0x1.tv/20131025-22

Понравился доклад о научном подходе к проведению изменений — внедрению Agile в компании, потому что этим редко заморачиваются, и так сойдет. Ну и «как-то» оно получается.

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

Есть книга «50 мифов популярной психологии». Мифы — известны. Но большинство людей не относится к ним как к мифам.

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

Основная идея: есть 5 этапов изменений, на каждом этапе есть свои техники помощь.

1. Сопротивление изменениям. Не слышал, или слышал, но не нужно.
2. Размышление. Иногда задумывается, может стоит изменить.
3. Подготовка. Готовимся к изменениям — литература и прочее.
4. Действие. Активно меняем, пытаемся применять новое поведение. Около полугода.
5. Сохранение изменений — при успехе, чтобы избежать регресса.

Изначально теория разрабатывалась и применялась, чтобы избавить людей от вредных привычек, или наработать полезные, связанные со здоровьем. А они применили, когда внедряли Agile.

• Определяем этап, на котором находится разработчик.
• Пользуясь методиками, помогаем двигаться вперед.
• Есть 9 методов изменений и 150 техник. Получены различными школами психологии.
• Команда у них: специалист Agile + психолог.
• На первом этапе — повышение осознанности и социальное освобождение
• Еще метод — контробуславливание.

Выводы. Они довольно категоричны.

• Теория ТТМ — научная.
• Теория про принятие потери — 5 эмоций — опровергнута.
• А вот Mike Konh и его 5 этапов - личное мнение.

Feature Branches vs. Continuous Integration, или Как скрестить ежа с ужом. Евгений Кошкин, JetBrains

Евгений рассказывал о технике разработки и continious integreation на примере двух разработок в JetBrains: ReSharper и TeamCity. В обоих — интеграционные тесты. Они исполняются долго, у ReSharper — 4 часа, и это дает много проблем, о которых он будет говорить.

Команды применяют разные способы работы с ветками: ReSharper использует feature branches, а TeamCity используют фичи-toggles. Причина — TeamCity интегрирован со многими системами контроля версий, и во исполнении принципа «используем то, что разрабатываем» — хранит свои исходники в разных системах по модулям. А это делает ветки практически невозможными. Поэтому все изменения идут коммитом в основной ствол, который поднимается на корпоративном билд-сервере. И ошибаться нельзя, иначе можно остановить разработку во всей компании. Фичи-toggles дают возможность не опасаться коммитить новую функциональность — ее всегда можно отключить. Да, их надо специально проектировать, зато позднее при поставке конечным пользователям в случае неожиданных проблем часто можно посоветовать workaround с отключением какой-то новой функциональности.

ReSharper же перешел к созданию Feature Branches. Причина — желание независимо протестировать собственные изменения разработчика, не только на его машине, но и в пакетном режиме в заданном тестовом окружении (remote run). Ранее это не получалось, потому что технически для этого собирался патч локальных изменений разработчика, который накатывался на основную на момент билда теста версию, которая уже уходила вперед от той версии, на которой разработчик вел разработку, и тест очень часто падал именно из-за этого. Feature Branches позволил эту проблему решить, однако породил другие, связанные с merge версий. Они осложняются тем, что ReSharper — не отдельный продукт. Есть платформа, поверх которой разработаны два продукта: ReSharper и dotTrace, и у них - свои команды и релизы. При этом команды ReSharper и dotTrace используют свои ветки Платформы и вносят в них изменения, которые далее разработчики платформы должны забрать в свой код, быть может, переработав. Это довольно сложная конструкция, и однажды они упустили контроль за объемом этих изменений, в результате чего выпуск стабильной версии платформы со всеми изменениями, huge merge, шел полтора месяца. Они урок учли, и с тех пор это не повторялось.

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

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

How To Do Kick-Ass Software Development. Свен Питерс, Atlassian

Это было великолепное шоу про современную разработку. О том, что надо не боятся получать фидбэк о своем продукте простым путем, хотя пользователей может быть много, и его надо обрабатывать. О том, что надо расшивать bottleneck, обеспечивать accountability и scalability. О том, что качество кода — вещь тренируемая и надо этим заниматься. О работе в одной команде, методах collaboration. Чем плох e-mail, почему нужны чаты и окна видеосвязи.

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

Остальные доклады

LLVM и Clang — новейшие компиляторы и инструменты программиста. Крис Латтнер, LLVM

Крис Латтнер — создатель и главный архитектор LLVM comunity and projects.

LLVM — это не компилятор, а структура, umbrella project for compilers. Подходу 35 лет. Но результат еще недостаточно хорош и развивается. Во многих направлениях, обобщая частные кейсы. И область применения — много шире традиционных компиляторов, поскольку в нем есть много элементов для графики и игр: растеризация трехмерных изображений, open shading language — создание мультфильмов, скрипты в играх, а еще куча промышленных применений в компиляторах. Xcode Apple, Embarceadero C++, CRAY Fortran и куча экспериментальных разработок MacRuy and another Ruby, Pascal, Juilia.

Clang Compiler — это компилятор, программа. "C Lang"uage Family. C, C++, Objective-C. Compatibility GCC & VS. На LVVM — наследует.Очень быстрый (вдвое быстрее, чем GCC, в 1.5 раза — чем PHP). А еще есть debugger, linker, C++ standard lib, runtime, plugin...

Это был интересный доклад для тех, кто не соприкасается с этой темой близко, и возможность пообщаться с реальной звездой для тех, кто работает в связанных областях или использует LLVM.

Mine Your Own Business — использование Process Mining для превращения больших объемов данных в реальную ценность. Вил ван дер Аалст, Технический Университет Эйндховена, МНУЛ ПОИС НИУ ВШЭ

Process Mining — это промежуточная дисциплина между business process management (BPM) и data mining, которая оформилась недавно. Его начал разрабатывать Вил ван дер Аалст, и он же рассказывал о нем на конференции.

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

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

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

Проектирование качества. Наталья Руколь, Лаборатория Качества

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

К сожалению, помимо идеи, практических приемов в докладе было мало. Жаль.

Темные и светлые стороны DevOps. Александр Титов, Экспресс 42

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

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

Эффективное совещание. Дамир Тенишев, Return on Intelligence (ex Exigen Services)

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

Дело не в команде. Алексей Пименов, Finam

Стратегическое зрение. Со всех сторон. Сложно. Помощь — аллегория. «Лада» на дороге. И два «КамАЗа» вокруг: подгонятор и целепологатор. Целепологатор не должен уезжать слишком далеко и не должен тормозить. Подгонятор — ритм, скорость. Если далеко — может тормозить, если близко — стресс. А дальше к метафоре можно приложить цепочку ограничений. Целепологатор — Буфер max и Веревка min, Подгонятор — Барабан. Это — кратко. Но реально в докладе не получилось скомпоновать все эти части вместе так, чтобы они стали понятны во взаимосвязи. А без этого метафора получается не очень рабочим инструментом для принятия решений.

Как заставить данные работать на ваш бизнес? Ирина Максимова, CQG

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

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

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

Разработка больших кросс-культурных проектов с Agile. Андрей Дмитриев, Quickoffice

QuickOffice — Office для Android. Word+Excel+Point. Сейчас QuickOffice был куплен Google и стал бесплатным.

Они реально тыкались в технические ограничения платформы, например, в число методов. Работали четыре сплоченных команды в России, жесткий backlog, mercurial, репозиторий. Жесткое требование — всегда иметь shippable продукт. Это чтобы понимать окружение.

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

KPI разработчика. Евгения Фирсова, Яндекс.Деньги

Руководство потребовало придумать и внедрить систему KPI разработчиков полтора года назад. Она пошла в интернет поискать. Хотела простую схему для web-разработчиков с профитом. Не нашла. Пришлось включить голову. В результате родилась система, которая сейчас применяется.

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

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

Измерять нужно то, что мы хотим изменять и только это. Основой системы являются критерии. Каждый из них — нечто, что делают не все сотрудники. Например, выполняет ли сотрудник code review или выполняет рефакторинг, или умеет делать исследование. Список критериев известен, у них сейчас 14 штук и они бывают положительные или отрицательные (провалы). Критерии — именно возможность, без количественного измерения. То, что разработчик может занимался рефакторингом, не означает, что занимался этим за период.

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

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

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

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

Стратегия разработки ПО в R&D компании. Руслан Мартимов, СПбФ ОАО Концерн ВЕГА

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

А в процессе надо было разбираться с двумя проблемами.

• Слишком красивые решения в фреймворке — давим реальными задачами.
• И фиктивное использование — тут тоже давим.

Достаточно хорошее программное обеспечение. Где остановиться? Дамир Тенишев, Return on Intelligence (ex Exigen Services)

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

У кого отбирают хлеб аналитики? Лариса Мелихова, T-Systems

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

Технология универсального мониторинга состояния объектов различной природы. Слава Васильев, Красный Угол

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

Опыт разработки интеллектуальной обучающей системы «Волга». Наталия Смирнова, ИПУ РАН им. В.А. Трапезникова

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