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