2020-02-16: Точка сборки - много интерактива, нетворкинга и глубоких разноплановых обсуждений
Вчера был на #ТочкаСборки. Это однодневная конференция Петербургского сообщества аналитиков. Вернее, не совсем конференция - она целиком состоит из интерактива разных форматов в длинных слотах на 1.5 часа. При этом на большинстве слотов - несколько выступающих, часто вместе с ведущим-фасилитатором. И готовят ее необычно - определяются темы слотов, и потом - спикеры для них, которые совместно с фасилитатором должны придумать формат и провести интерактив. При этом все спикеры вместе с фасилитаторами и организаторами были приглашены в групповой чат в телеграмме, где и происходит формирование программы и объединение по интересам. Форматы - самые разные: дискуссия спикера с участниками, диалог двух спикеров с разными точками зрения по вопросам от публики, обсуждение в формате world cafe, традиционный воркшоп с групповой работой. Три параллельных потока, 150 участников, 4 такта. Формат имеет свои ограничения по формату, потому что дискуссия при зале больше 50 человек - не слишком получается. Но организаторы хотят придумать способ расширения конференции с сохранением ее духа. Часть слотов записывали. Часть - потому что для мастер-классов и воркшопов с активной работой в группах в общем пространстве запись сделать невозможно.
Мой отзыв будет существенно неполон, потому что я, естественным образом, мог быть только на одном потоке из трех.
На первом слоте я слушал доклад Алексея Петрова "Метакомпетенции аналитика в цифровую эпоху" и участвовал в дискуссии с залом. Доклад начинался тезисом о том, что современный мир требует непрерывного развития, а метакомпетенции - это те из компетенций, которые позволяют нам развитваться. Дальше был обзор происходящего, в общем-то достаточно известный - стремительное изменение мира, исчезновение профессий, VUCA-мир и VUCA-ответ на него (Vision, Understanding, Clarity, Agility), дата-мир, черные лебеди катастроф типа атаки дронов и коронавируса... На мой взгляд, в целом обзор получился достаточно поверхностный, и, может быть, стоит сделать более системное представление. Правда, оно неизбежно окажется не столь катастрофичным, и, возможно, плохо выполнит основную задачу этой части выступления - побудить слушателей к изменениям. Кстати, про исчезающие профессии - сегодня лента FB принесла воспоминания о списке МШУ Сколково 2013 года исчезающих к 2020 году профессий. Турагент, копирайтер, лектор, архивариус, швея, лифтер, машинист и почтальон. - все живы и не думают умирать.
А следующая часть доклада была посвящена самим метакомпетенциям: системному мышлению, критическому мышлению и бизнес-осознанности. Основное что они позволяют делать - это держать контекст происходящих изменение и позиционировать себя в нем. И тут как раз было обсуждение с участниками - что именно вкладываются в эти понятия, как наличие этих компетенций проявляется в поведении человека. Был набор концептов и ссылок на литературу, в частности на ментальные модели Джозефа О'Коннора И набор легких инструментов, связанных с компетенциями. Например, декартовы вопросы для критического мышления: если вам предлагают сделать нечто, рассматривать что будет, если сделать, что будет если не делать, и в каждом варианте - какие возможности проявятся и окажутся упущенными. Такое всестороннее рассмотрение как раз позволяет увидеть все стороны. Эта часть доклада точно была интересна и полезна.
Следующие два слота, в которых я участвовал были посвящены современным архитектурным подходам мира современного ООП++ или постООП, сформулированным на основе трендов infoq https://www.infoq.com/articles/architecture-trends-2019/: микровервисы, REST, CQRS, отказ от транзакций и консистентности, eventual consistency, event driven architecture, correctly build distributed system, reactive programming. Часть из них появились не вчера, но все они достаточно новые. Разработчики их знают и применяют, строят приложения на их основе вместо прежних монолитов. Вопрос в том, насколько они влияют на работу аналитика, и насколько в ней надо разбираться. Первый слот вели Максим Шаломович (Max Shalomovich) и Евгений Асламов (Evgeny Aslamov) с фасилитацией Юлии Лапушко, в второй - я и Филипп Дельгядо, фасилитировал Алексей Фёдоров (Aleksei Fedorov). Идеи сессий у нас возникли независимо, но поскольку темы сильно связаны, то в ходе подготовке конференции мы их активно между собой обсуждали, то получилась общая тематическая поляна, но с различными взглядами на содержание, такая длинная сессия. И дальше я буду писать общем содержании, и, поскольку я вел одну из сессий, это изложение может оказатьcя не нейтральным. Но участники могут дополнить и скорректировать в комментариях.
Все согласились с тем, что аналитикам представлять конструкцию приложения необходимо. И, более того, им нужно уметь вести диалог с заказчиком, представляя конкретные решения. Потому что архитектурные подходы распределенной архитектуры, обеспечивая масштабируемость приложений под нагрузкой, а также возможность разработки функционала несколькими командами, ведут к неочевидным последствиям, ряд функционала, который в монолитных решениях получался "из коробки", становится трудно реализуем или даже невозможен.
Возьмем, например, интернет-магазин, которые поделен на вполне логичные сервисы: ведение заказов на сайте, обеспечение сборки и отгрузки заказов на складе, управление транспортом и доставкой, платежи и гейт к бухгалтерии. Отмечу, что это еде простой вариант деления. Есть естественное пожелание заказчика, чтобы оплата корзины на сайте становилась доступна только после того, как получено подтверждение наличие товара на складе и возможности отгрузки в желаемую дату. Если у вас монолит, то бизнес-логика по кнопке "подтвердить" делает необходимые проверки и переводит заказ в подтвержденный, в котором доступна оплата, и это происходит быстро. Если у вас распределенная реализация. то по кнопке подтвердить сервис сайта отправляет этот заказ в сервис склада для блокировки товара и в сервис доставки для блокировки ее ресурсов. А подтверждение придет потом, асинхронно и через неопределенное, в общем случае, время. И от любого из сервисов может придти отказ. Но при этом покупатели не склонны ждать подтверждения заказа долго, они уходят в другой интернет-магазин. Оплата же заказа, по которому получен отказ, чревата другим негативом и сложностями.
Решение тут должен принимать бизнес-заказчик, и у него возникает естественный вопрос: а зачем вы выбрали такую сложную архитектуру? При отсутствии обоснованного ответа он просто жестко требует выполнения пожеланий - и разработчики устраивают распределенные транзакции или другие аналогичные решения, которые в результате сводят на нет преимущества архитектуры, превращая ее из бизнес-обоснованного решения в игрушку, обеспечивающую им поток интересных и сложных задач. И это - печальный результат.
Именно поэтому аналитик должен представлять архитектуру реализации и отражать ее в модель предметной области, обеспечивая соответствие модели и реализации в соответствии с принципами DDD, а не используя монолитную модель при распределенной реализации приложения. В обсуждении было достаточно много реальных кейсов, был рассказ про подходы оркестрации и хореографии для взаимодействия разных сервисов. И была метафора "маленьких человечков" делающих работу информационной системы, которая помогает понять его реализацию.
При этом было отмечено, что все эти новые подходы не отменяют старое, а дополняют его. Внутри сервиса, если он реализован на объектном языке, работает ООП. А цели и бизнес-задачи не только проекта в целом, а каждой конкретной фичи и user story по-прежнему необходимо знать, чтобы принимать взвешенное решение архитектуры. При чем это необходимо знать даже больше чем раньше, потому что последствия излишней сложности решений более катастрофичны и сильно увеличивают стоимость развития и доработок. Но и простые решения будут ограничивать будущее масштабирование.
Для меня участие в этих сессиях было подготовкой будущего доклада на #AnalystDays "предметной области для разных парадигм программирования" в котором я буду говорить на те же темы. Участники тоже вынесли много интересного и практического.
Кстати, на сессиях много раз всплывал вопрос про различные области ответственности для аналитика. Подробного обсуждения этой темы не получилось, однако если говорить в терминах классических специализаций, то она включает специализации бизнес-аналитика, UX, системного аналитика и solution architect, последние не обязательно на уровне проектировщика, но обязательно на уровне понимания сделанной архитектуры. Потому что без этого видеть диалог с бизнесом о моделях реализации и обеспечивать взвешенное принятие решений не получится.
После интенсивных дискуссий я понял, что для последнего слота у меня уже нет сил на работу в группах и на активное восприятие информации и потратил его на нетворкинг. Хотя темы были интересные. А потом было афтерпарти в том же помещении и с интересными обсуждениями.
В заключении - большое спасибо организаторам конференции - Анне Абрамовой и Анне Горбатенко и всем остальным организаторам, спикерам и участникам за такое мероприятие.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.