2015-10-26: SECR-2015 - понимание трендов и новые знания

Версия 10:20, 26 октября 2015

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

C переднего края

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

И вот, что особенно ценно, это был не просто рассказ, что так можно. Была живая демонстрация, как обращение к сервису развертывается на платформе BlueMix, предоставляющей доступ к сервисам, используя html+JavaScript, node.js и какую-то еще открытую графическую библиотеку, и получается html-страница с полем для текста на входе и визуальным представлением психологических характеристик автора, восстановленных по тексту на выходе. Приложение - в пределах десяти строк на JavaScript и html, понятно, что их не писали, а использовали заготовки и copy-paste, но все равно - они обозримы.

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

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

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

Следующий доклад из той же серии - Константин Быченков, Aligned Research Group. Big Data в обработке медицинских изображений. Речь шла о построении высоконагруженных систем анализа изображений для медицины, например, для распознавания и диагностики раковых опухолей на снимках. То, что врачи сейчас делают глазами, и где очень многое зависит от профессионализма и опыта самого врача. И в докладе многое было про техническую архитектуру таких приложений, про конкретные платформы, использовавшиеся для обеспечения хорошей производительности, в частности sparx cluster (и его преимущества перед hadoop на их классе задач). Интересно, что докладом заинтересовались люди из Касперского, у которых стоит задача классификации изображений для защиты детей от порнографии и прочего нежелательного контента.

Размышления об архитектуре

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

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

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

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

Надо отметить, что именно к этому пришел современный Agile в лице OMG Essence of Software Engineering. Поскольку каждая компания, а в пределе каждый проект создает уникальный продукт, то ему необходим собственный метод. И в конструкцию OMG Essence это заложено, при чем не старым менеджерским способом "вот полный список, вычеркните лишнее", а с использованием подходов к построению расширяемых систем в разработке: сделана ядерная конструкция со своим формализмом, в ней предусмотрено достаточно много разноуровневых точки расширения, а наработанные методы представляют собой "шаблон приложения" или сборку, которую можно сразу запустить, но которую можно изменять и добавлять другие техники, используя эти точки расширения.

Под этим углом зрения, кстати, очень интересно посмотреть на архитектуру современных open source проектов и библиотек, на логику их развития. Тут надо сказать, что в разработке библиотек и платформенных компонент отчетливо появился новый тренд, зафиксированный мной в прошлом году на GoToCon в Копенгагене. Раньше реализация библиотек под новые подходы, например, под реактивное программирование, выросшее из акторной модели, считалось делом вендоров. А теперь команды разработчиков, ведущих разработку конечного продукта или заказную разработку, столкнувшись с отсутствием хорошего решения для подходящего им шаблона, делают свое решение и выкладывают в open source. После чего следующая команда в аналогичной ситуации, обнаружив это решение, пусть пригодное им на 50%, берет его за основу и развивает далее в желаемую им сторону, так же выкладывая свои наработки в тот же продукт. При этом разработчики первой версии заинтересованы в появлении других контрибуторов и рекламируют свои решения во всяких профессиональных сообществах. И так оно развивается, привлекая все новых контрибуторов. При этом применяются разные механизмы координации, способы которых, в общем-то, тоже наработаны и различны. И это можно наблюдать и на структуре продукта: один получается относительно цельным, а в другом - ветвятся версии и отпочковываются отдельные продукты. И - главное - все это происходит быстрее, чем на тренд успевают среагировать большие вендоры. Понятно, что оно относится не ко всем областям, и Watson так не сделаешь. А вот библиотеки под шаблоны и подходы разработки - вполне. Да, в России я этого тренда пока не увидел, но думаю. что он придет - по мере того как все активнее будут использовать open source продукты - сначала разработчики начнут становится их контрибуторами, а потом - начнут и свои делать. Во всяком случае, в нашей компании доработки MediaWiki для корпоративной работы контрибутятся в репозиторий проекта, при этом в одних случаях делаются дополнения, а в других - новые плугины, замещающие старые (а еще - ведем отдельную корпоративную сборку. С отдельными библиотеками, на базе которых мы ведем разработку мы пока так не делали, но, с другой стороны, мы open source библиотеки и использовать начали куда позднее, чем MediaWiki.

А еще, уже вечером после доклада, у меня с Димой возникла интересная дискуссия - есть ли в software engineering значимая теоретическая работа, или там практика прежде всего, а теория - в лучшем случае приложение к ней для объяснения способов использования. К общему мнению не пришли, но достаточно много аргументов друг другу высказали. Я считаю, что теоретическая работа есть. Но путь - не такой, как в другой науке, потому что теория тут зарождается и приходит вместе с конкретным продуктом, и без этого - невозможна. Так в свое время рождался BPMN вместе с первой реализацией, многие идеи в языках программирования рождались вместе со своей реализацией, например, pattern matching или инкорпорирование sql в объектные языки в виде linq, или акторные модели. И это - практика, так сказать, экспериментальная физика, слитая с теоретической. Но затем теоретический шаблон отрывался от первой реализации и начинал жить независимо, уже как развитие чистой теории, и это развитие часто не только развивало существующие реализации, но и порождало новые реализации, иногда более удачные и вытесняющие предыдущие. Может быть, я еще напишу об этом отдельный пост.

О людях и softskill

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

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

1. Ледокол (warm-up). Вовлечение, плюс подождать задерживающихся. Пример - рассказать про week-end или хобби. И собрать людей, племена, очень быстро.
2. BraimWriting. Собрать идеи для своего процесса. Например идея автотестирования: напишите все два за, два против. Не высказаться, а написать и выложить одновременно. Параллельный процесс.
3. World-Cafe. Взаимно познакомиться с идеями. Масштабируется на 50-60 человек. Объединиться в пятерки, и переходить по столам. Трансляция стратегии тоже можно.
4. Five-to-Fit. Оценка пальцами, римские голосования. По 5-бальной системе + воздержался тоже ценно. Быстрый обмен мнениями.
5. Pro-Con анализ. За и против. Разложили по идеям то. что было в голосовании, добавили веса. Или можно Divide and Belch, когда надо выбрать. например, 3 идеи или фичи из большого списка. Каждый выбрал 3. Потом в парах: у одного 3 и другого 3 - выберите как пара 3. Потом - четверка выберите 3. И так далее.
6. Meeting Minute. Выработка проекта действий - Что делать, Кто и Когда.

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

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

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

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

Еще хороший доклад Антон Семенченко, COMAQA.BY. Треугольник “Принцип открытого кимоно + Delegation + Self-Communication Management” как инструмент мотивации. Много правильных тезисов про личный пример, доверие и другие способы. которые в целом при правильном применении могут обеспечить поднятие производительности человека в разы. И это был не рассказ о серебряной пуле, а рассказ о накопленном опыте, с многими оговорками, особенностями, границами применения и деталями. Например, как сочетается принцип доверия, в том числе, доверия вести переписку с клиентами от имени руководителя фирмы, с клиентскими отношениями и что надо сделать, чтобы это клиентами не воспринималось как обман. Ответ - принципиально выстраивать отношения по сервисной модели, сервис - обезличен. Или как сочетается доверие с правом на ошибку? Ответ - право должно быть, ошибка - выученный урок. И подчиненным и руководителем. И многое другое. Еще был анонс мастер-класса про оригинальную математическую модель счастья, которую Антон применяет - она не всеобщая, работает для 33% людей, но он отбирает в фирму именно таких людей.

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

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

И обо всем остальном

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

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

Роман Белков, СПбГУ. Kotlin для роботов: это функционально! На прошлой конференции о программировании роботов на F# рассказывали Сошников и Кирсанов. А в этом году был рассказ о программировании на Java-стеке. Выбрали Kotlin, потому что он много компактнее, удобнее и нагляднее. Но поскольку он очень плотно совместим с Java, и для event-driven программирования они использовали RxJava, а не библиотеку Kotlin, то можно писать и на Java. Но получается более длинно и менее понятно - в докладе были примеры. А еще на докладе были живые роботы - segway держал баланс, другой робот следил камерой и ехал за целью, да еще твитил какие-то фотки. И все это работает на JVM на самом роботе, и, как утверждается, берет всего 25% процессора и по памяти тоже есть резерв. То есть вполне работоспособная версия.

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

На этом я завершаю свой отчет о SECR.