2022-03-28: осенний Analyst Days - интересные доклады и много общения

Короткая ссылка: AnalystDays-2021b

Ссылки сюда (4) →

О других конференциях

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

Так что конференция безусловно стоит посещения, очередная будет в конце мая в Москве. И, кстати, я там тоже буду выступать с докладом «Как строить образ будущего и идти к нему - схемы самоопределения». Фокусом будет самоопределение в пути профессионального развития, но эти схемы можно применять и для других случаев, что актуально в наше время, и это можно будет обсудить в кулуарах. Я не планировал специально, просто так получилось.

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

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

А на прошедшей AnalystDays, которой посвящен отчет я делал доклад Проектирование в разных культурах и парадигмах разработки, в котором рассказывал историю изменения подходов к проектированию софта. История ИТ - это несколько эпох, подходы - менялись, устройство систем - тоже. Каждая из эпох порождала свои учебники. При этом, что интересно, многие корпоративные платформы, такие как SAP и 1С сформировались в 1990-е, когда объектные языки уже были, а объектного проектирования - еще не было, и несут во внутреннем устройстве подходы, сформированные еще в 1970-х, классическим учебником по которым является Николас Вирт "Алгоритмы + Структуры данных = Программы", позднее дополненные подходами проектирования интерфейсов (в 1970 их не было) и взаимодействия с пользователем - use case, user story и так далее. И когда вы работаете над постановкой, в которых эти системы должны взаимодействовать с современными микросервисными приложениями, основанными на совершенно других парадигмах разработки и проектирования, эти разрывы между эпохами надо преодолевать. А для этого их полезно представлять. И в докладе была big picture этой истории.

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

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

Григорий Печенкин. Модели пользователей и как их применяют

Пост на FB Григорий Печенкин. Модели пользователей и как их применяют. Три типовых модели пользователей:

• Функциональные роли, в которых пишут use case. Коберн. Тут все хорошо, но только когда у вас есть бизнес-процесс и роли ясны.
• Стереотипы, для которых пишут user story. Майк Кон. Если ты угадал с разбиением по сценариям - молодец. Но этот метод не всегда позволяет спроектировать интерфейс, который понравится твоим пользователям - о нем известны только цели.
• Персоны. Алан Купер Об интерфейсе. Он - для массового пользователя, и как раз позволяет делать интерфейсы адекватным пользователям. Он наиболее дорогой - нужно этнографическое исследование, на этом срезают угол и получают суррогат предыдущего метода.

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

Наталья Леонова и Леонид Юденков. Интервью. Как говорить с людьми про требования

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

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

Иван Хахарев. Сломать систему - реинжиниринг портала с китайскими пользователями

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

Пятая перепись, которая оказалась удачной.

• Выбор одного главного мыслителя (+тест Белбина - там способности), который отвечает за магистраль.
• Сбор информации по инцидентам за последний год, при этом важно: начальное обращение и ответ
• Группировка типовых инцидентов
• Сбор всех больных мест со всех аналитиков

Начало реинжиниринга.

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

Процесс

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

Анна Мелехова, Лаборатория Касперского. API: под каким углом на них смотреть

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

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

А ее вопрос - как сделать чтобы АПИ было хорошим

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

Практики протокола. REST. Есть модели зрелости.

• Первый уровень - когда все через один метод со множеством параметров
• А следующий - когда много вызовов с систематическими параметрами

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

Симметричность. Если есть inc - должен быть dec, и исключения должны быть обоснованы.

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

Интуитивно-понятное. Если один и тот же тип в двух АПИ - то должно полностью совпадать. Форматы и структуры ошибок и так далее.

АПИ - должно получить согласования архитектора.

Соответствует работающему сервису. При этом внешняя нагрузка и внутренняя - разные. Зловреды, DOS и так далее.

Обратная совместимость. Ее надо тащить 10 лет.

Спеки или аннотации. swagger и аналоги. Из них можно делать документацию, получать работающие семплы и так далее. Генерации.

API Reference. И там должно работать.

Мифы

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

Процессы

• Публикация АПИ. Релиз новой версии, и окончание версии.
• Архитектурное review
• API Guideline от архитектора - как устроено АПИ в нашей компании. Включая стандарта по безопасности.
  • Важно, что требования по безопасности ломают обратную совместимость, но ты обязан их вносить!
• Найдите архитектора - вам поможет

Релиз новой версии. Хороший пример - PayPal. Каждое изменение надо доказать.

• Почему мы должны публиковать версию, а не можем сделать change существующей.
• Тесты - надо делать на все версии, совместимость с которой вы тестируете.
• Идея: у кого-то есть идея - ОК, но guide и примеры для upgrade ты пишешь сам. Он думает, и желание уходит...

Ресурсы для публичного АПИ - их много, есть список. И людей и средств, и тот же API Reference - не дешев.

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

Максим Донцов и Дмитрий Шмойлов, Лаборатория Касперского. Безопасность в силу дизайна: как выстроить процесс анализа архитектуры продуктов

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

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

Александр Козлов из Accenture. Аналитика в условиях Fix-Price и Agile. Как не наломать дров и примирить непримиримое

Пост на FB Александр Козлов из Accenture. Аналитика в условиях Fix-Price и Agile. Как не наломать дров и примирить непримиримое. Ситуация: есть fix price контракт по ТЗ, которому год и потому оно устаревшее и не слишком актуальное, поэтому заказчик хочет Agile, чтобы скорректировать ситуацию и проект был успешен, и он готов разменивать скоуп, если будут основания. Вполне актуальная ситуация. У команды при этом был agile coach, который объяснял про user story, customer journey map и прочие детали agile-подхода, но вот про fix price и особенности контрактования он - не в курсе, это надо самим адаптироваться. Про тот реальный процесс который получился. На входе - крупноблочный бэклог на основе ТЗ с предварительными оценками, согласуем с заказчиком. Дальше при подготовке очередных спринтов - детализация требований, проработка. Постоянное сопоставление бэклога и ТЗ и инициация процесса изменений контракта для размена скоупа. Контракт предусматривал сдачу формальной документации - они договорились, что она будет собрана из детализации user story, которые делают для разработчиков, плюс общих разделов со структурой данных и описанием интеграций - их вели отдельно. И так далее. Проект на полгода, было 6 демо заказчику с выкаткой на пред-прод. В целом успешно, заказчик доволен, у них контракт на развитие уже по T&M. Заказчик - разумный. Переработки были, но работа в выходные и переработки у них в компании норма.

Кристина Кожевникова. Кайдзен и работа аналитика

Пост на FB Кристина Кожевникова. Кайдзен и работа аналитика. Рассказ был про Цикл PDCA и методику применения изменений ADKAR. На кейсе из собственного опыта, по которому, правда, конкретики не было. Но, может, так и лучше для понимания методов. Итак, вы в каждом своем проекте делаете техническую документацию, которая состоит из некоторого набора документов, для которых у вас некоторая методика их подготовке. Документацию делает команд проекта. Еще есть команда, которая держит методику подготовки и ее совершенствует - меняет набор документов, способ их создания.

Цикл PDCA. У вас очередной проект, и вы там планируете что-то в изготовлении документов улучшить, например, поменять состав документов, и это предлагает как раз команда, которая держит методологию. Это - Plan. Дальше Do вы по-новому делаете документы в рамках этого проекта, это делает команда проекта, хотя представители методологов участвуют. Какие-то документы получились. И на Check вместе проверяем: новые документы получились лучше старых, гипотезы об улучшении оправдались, или нет? Что пришлось доводить уже по месту, поверх методологии? И следующая стадия Act меняет методологию с учетом результатов сопоставления, и тиражируем это решение на всех, кто у нас делает документацию.

Про ADKAR. Поскольку делает документацию команда проекта, а методологию меняет команда методологов, то она должна убедить команды проектов искренне сделать по-новому - иначе никакого улучшения тоже не получится. Начинается с Awareness - осведомленность о новом, затем Desire - убеждение что это новое лучше, мотивация поменять способ работы, затем Knowledge - знание о новом в деталях, теория нового, Ability - умение и возможность работы по новому, претворение теории в практику и Reinforcement - фиксация, что новый способ реально вошел в жизнь.

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

Александр Соляр. Современная Микросервисная архитектура в банковской сфере

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

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

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

Александр Козлов из Lamoda. ИТ-схема. Как не заблудиться в дремучем лесу вашего ИТ-ландшафта

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

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

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 12:07, 28 марта 2022 • нет комментариев