Осенний 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, включая монетизацию, о которой разработчики не часто задумываются. Модели монетизации АПИ - их очень много. Но самые интересные - непрямые. Ни разработчик не платит, ни ему не платят, но компания деньги получает. Например, в Acronics АПИ такое, что данные - в его облаке, а оно платное. Или АПИ дает трафик, а он - платный. А еще если у вас есть АПИ, то к нему кто-то написал интеграцию. И ее жалко переписывать - и они не уйдут к конкурентам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мифы

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

Процессы

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

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

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

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

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

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

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

Пост на 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 сервисов. И это - вовсе не микро.

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

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

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

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