Karo Sarkisyan. Сейчас или никогда: Универсальная стратегия уничтожения зомби-багов. Типичная ситуация при быстром развитии: фокус на разработку новых фич, а некритичные баги копятся и копятся. В какой-то момент их становится слишком много, и уже в статистике сложно разобраться, отделив старые зомби от новых багов. Zombie - баги, которые висят без движения долго, полгода и больше. Их средства борьбы
* Каждый баг имеет владельца
* В Jira их выносят на отдельные компоненты, и включается процесс разработки этих компонентов в виде устранения всех багов
* И отдельные дашборды и анализ по процессу устранения зомби-багов по этим компонентам, еженедельный статус
А еще они в основной цикл включили ограничение по числу багов, с которым можно выходить на merge, с учетом их критичности. В результате число багов сократилось, а зомби - исчезли.
* Каждый баг имеет владельца
* В Jira их выносят на отдельные компоненты, и включается процесс разработки этих компонентов в виде устранения всех багов
* И отдельные дашборды и анализ по процессу устранения зомби-багов по этим компонентам, еженедельный статус
А еще они в основной цикл включили ограничение по числу багов, с которым можно выходить на merge, с учетом их критичности. В результате число багов сократилось, а зомби - исчезли.
Serhii Bryt. Selenide + Playwright Java = unite and rule. Вместо того, чтобы тестировать приложение в броузерах, можно тестировать на движках - их всего три (Chromium, Gecko, WebKit). При этом убирается web-драйвер, и это ускоряет тестирование. У них были тесты на Selenium и их надо было ускорить, без сильного переписывания. Selenium по архитектуре работает плохо, если больше 20 полей. Selenide позволяет писать значения в поля с помощью JS - намного быстрее, хотя некоторые события при этом теряются, это не эквивалентно вводу пользователем. А в PlayWright по-другому устроен движок поиска и заполнение, разница в 4-5 раз. Поскольку переписывать тесты не хотели, то идея была оставить Selenide и использовать Playwrite для заполнения полей. Дальше разные конкретные примеры скриптов и демонстрации: как присоединить PlayWrite к Selenide, как правильно создавать сессию, чтобы не заботиться о закрытии, как записывать видео и трейсы.
❤1
Olivier Denoo. Jobs-to-be-done approach. Это было изложение подхода Jobs to be done по одноименной книге Jim Kalbach (Джим Калбах). Интернет говорит, что у подхода есть несколько версий. Подход основан на том, что пользователь (потребитель) всегда покупает работу (job), чтобы достичь каких-то своих целей или решить проблемы. Эту работу может быть сделать для него человек (компания) - будет оказана услуга, либо быть сделана с помощью продукта, который он купит. Например, ему не нужен скейт как вещь, которая хранится в доме, ему нужно летом гонять в парке - и это можно не только на скейте. А когда он хочет кофе - это может быть обеспечено кофе-машиной, а может - человеком, который это кофе приготовит. Итого job contents: who (job taker), what (job), how (process), when (context), goal (value). Job taker != buyer != approver - надо различать.
Подход говорит, что job надо формулировать в терминах результата, удовлетворяемых потребностей, которые не зависят от способа, которым выполняется работа. А ценность зависит от контекста использования. Бутылка колы в магазине, в баре, на природе и на дискотеке стоит сильно по-разному. Одна и та же игрушка в детской комнате и в виде любимой игрушки ребенка тоже имеют разную ценность. Есть два аспекта оценки: социальная - оценка обществом, финансы, и эмоциональная - личная оценка, полученный опыт. При этом потребности, которые закрывает job - не всегда однозначны, иногда вспомогательные оказываются главными - был пример дорогой дизайнерской выжималки сока для цитрусовых, которую по основному назначению использовать нельзя - весь стол будет залит соком, он течет мимо стакана.
Для оценки используются две координаты: importance и satisfaction, и выяснять их надо у тех, кто будет этим пользоваться. Ну и дальше искать сегменты возможности с high importance, low satisfaction, тут есть разные способа оценки, которые были в презентации.
Формула для предложения for (target jobber) - frustation by (pain) - our solution (product or service) - offers (capacity to solve) - unlike (alternative). И надо тестировать гипотезы - формулируем предложение, в которое верим, и проверяем.
За подробностями - к книгам, но вообще концепт, что покупают не продукты а работу, которую этот продукт делают, на мой взгляд может интересным образом смещать акценты. Надо будет еще подумать.
Подход говорит, что job надо формулировать в терминах результата, удовлетворяемых потребностей, которые не зависят от способа, которым выполняется работа. А ценность зависит от контекста использования. Бутылка колы в магазине, в баре, на природе и на дискотеке стоит сильно по-разному. Одна и та же игрушка в детской комнате и в виде любимой игрушки ребенка тоже имеют разную ценность. Есть два аспекта оценки: социальная - оценка обществом, финансы, и эмоциональная - личная оценка, полученный опыт. При этом потребности, которые закрывает job - не всегда однозначны, иногда вспомогательные оказываются главными - был пример дорогой дизайнерской выжималки сока для цитрусовых, которую по основному назначению использовать нельзя - весь стол будет залит соком, он течет мимо стакана.
Для оценки используются две координаты: importance и satisfaction, и выяснять их надо у тех, кто будет этим пользоваться. Ну и дальше искать сегменты возможности с high importance, low satisfaction, тут есть разные способа оценки, которые были в презентации.
Формула для предложения for (target jobber) - frustation by (pain) - our solution (product or service) - offers (capacity to solve) - unlike (alternative). И надо тестировать гипотезы - формулируем предложение, в которое верим, и проверяем.
За подробностями - к книгам, но вообще концепт, что покупают не продукты а работу, которую этот продукт делают, на мой взгляд может интересным образом смещать акценты. Надо будет еще подумать.
👍5❤1
Сразу за SQAdays EA идет AnalystDays EA, и теперь заметки оттуда. Татьяна Половинкина. Система D5 = DDD+DD и при чем тут аналитики? Насыщенный доклад про Domain Driven Design и Data Driven. Основной тезис: в 2020 концепт ограниченных контекстов DDD добрался-таки до проектирования хранилищ данных и на смену централизованным хранилищам пришел Data Mesh. До этого все было централизованным, от переезда DWH, известных с 1980х в Data Lake в 2000 ничего принципиально не изменилось. И теперь с этим надо жить. Ну а теперь - заметки.
Аналитики - не вымрут. Потому что аналитик - специалист по изменениям - а это будет только увеличиваться. Но скоуп меняется, теперь надо все больше данные анализировать. Четвертая промышленная революция показала, что данные важны, а пятая - окончательно погрузит нас в матрицу.
Концепты DDD
* Ограниченные контексты: одинаковые слова воспринимаются по-разному. DRP: disaster recovery plan или distribution requirement planing. Покупатель - атрибуты. Я тут добавлю, что в одних системах покупатель - тот, кто уже совершил покупку, а в других - тот, кто потенциально готов купить и его надо до покупки довести, и это тоже разные представления.
* Единый язык. Аналитик - Дата инженер - Data Scienst, BI. Data Engineer - далеко не всегда понимает смысл данных, он как дизайнер - умеет располагать и сжимать. Несколько лет назад была аналогичная проблема с админами - появились DevOps. Тут тоже будет решение.
* От логики к инструментам. Есть много методик, с разными подробностями. Но во всех общий принцип, что начинаем двигаться от бизнес-логики, и можно просто именно это и делать. Я тут согласен, а если у заказчика есть любимая методика - то надо просто быстренько прикинуть, как то, что вы делаете, брендировать эnим способом - потому что очень многие методики - очень тяжеловесны и не жизнеспособны. При этом, естественно, никто не запрещает взять из методики полезное.
DD - Data Driven. Тонем в потоке данных, надо как-то разбивать и научиться управлять. Масштабируемость и эволюция в каждом домене. Но! недопоминание и недоверие между доменами. Что делать? Управлять данными, определить то, что производят домены. Data Product - данные, которые нужны другим доменам. Доступные, Понятные, Надежные, Безопасные, Читаемые.
Тут у меня мысль. Есть старая добрая книга Николас Вирт "Алгоритмы + Структуры данных = Программы" (1976). Насколько похоже, что все - как там, только слагаемые надо переставить и уровень абстракции в примерах поднять, чтобы перенести на современные методы? Может, перечитаю ее под этим углом зрения.
Data Domain - децентрализированная распределенная система с малыми зависимостями, не ждем согласований и т.п. Два подхода.
* DAAP: data as a product, выдает данные как есть
* DAAS: data as a service, выдает ответы на запрос как сервис.
Данные должны иметь ценность. Единообразной методики оценки ценности - нет. Поэтому вам надо самим ее извлекать.
Что меняется с Data Mesh, децентрализацией данных?
* Сетевая федерированная структура. Как и карта доменов в DDD, пусть укрупненно. Децентрализация управления
* Поддерживать разумные исторически сложившиеся связи
* Четкое понимание задач домена
* Двухсторонняя конкуренция (эволюция).
И дальше по отдельным направлениям.
* Продукт. Множественность (повторное использование - бюджет), Разделение проблем и задач (сеньор и миддл). От MVP к Roadmap
* Модульность: Анализ домена от и до. Пересмотр записимостей. Матрица коммуникация. -- Распределяет поток по людям
* Данные: Ценность, Data Driven, DaaP и DaaS
Вывод: думай глобально, действуй локально. Глобальное видение - но не оцепенение, а активные действия в области, где можешь.
А вообще можно считать, что эти подходы применял Юлий Цезарь. Разделяй и Властвуй - это про DDD. А захватывая провинцию - он строил дороги и это тогдашний способ Data Driven.
Аналитики - не вымрут. Потому что аналитик - специалист по изменениям - а это будет только увеличиваться. Но скоуп меняется, теперь надо все больше данные анализировать. Четвертая промышленная революция показала, что данные важны, а пятая - окончательно погрузит нас в матрицу.
Концепты DDD
* Ограниченные контексты: одинаковые слова воспринимаются по-разному. DRP: disaster recovery plan или distribution requirement planing. Покупатель - атрибуты. Я тут добавлю, что в одних системах покупатель - тот, кто уже совершил покупку, а в других - тот, кто потенциально готов купить и его надо до покупки довести, и это тоже разные представления.
* Единый язык. Аналитик - Дата инженер - Data Scienst, BI. Data Engineer - далеко не всегда понимает смысл данных, он как дизайнер - умеет располагать и сжимать. Несколько лет назад была аналогичная проблема с админами - появились DevOps. Тут тоже будет решение.
* От логики к инструментам. Есть много методик, с разными подробностями. Но во всех общий принцип, что начинаем двигаться от бизнес-логики, и можно просто именно это и делать. Я тут согласен, а если у заказчика есть любимая методика - то надо просто быстренько прикинуть, как то, что вы делаете, брендировать эnим способом - потому что очень многие методики - очень тяжеловесны и не жизнеспособны. При этом, естественно, никто не запрещает взять из методики полезное.
DD - Data Driven. Тонем в потоке данных, надо как-то разбивать и научиться управлять. Масштабируемость и эволюция в каждом домене. Но! недопоминание и недоверие между доменами. Что делать? Управлять данными, определить то, что производят домены. Data Product - данные, которые нужны другим доменам. Доступные, Понятные, Надежные, Безопасные, Читаемые.
Тут у меня мысль. Есть старая добрая книга Николас Вирт "Алгоритмы + Структуры данных = Программы" (1976). Насколько похоже, что все - как там, только слагаемые надо переставить и уровень абстракции в примерах поднять, чтобы перенести на современные методы? Может, перечитаю ее под этим углом зрения.
Data Domain - децентрализированная распределенная система с малыми зависимостями, не ждем согласований и т.п. Два подхода.
* DAAP: data as a product, выдает данные как есть
* DAAS: data as a service, выдает ответы на запрос как сервис.
Данные должны иметь ценность. Единообразной методики оценки ценности - нет. Поэтому вам надо самим ее извлекать.
Что меняется с Data Mesh, децентрализацией данных?
* Сетевая федерированная структура. Как и карта доменов в DDD, пусть укрупненно. Децентрализация управления
* Поддерживать разумные исторически сложившиеся связи
* Четкое понимание задач домена
* Двухсторонняя конкуренция (эволюция).
И дальше по отдельным направлениям.
* Продукт. Множественность (повторное использование - бюджет), Разделение проблем и задач (сеньор и миддл). От MVP к Roadmap
* Модульность: Анализ домена от и до. Пересмотр записимостей. Матрица коммуникация. -- Распределяет поток по людям
* Данные: Ценность, Data Driven, DaaP и DaaS
Вывод: думай глобально, действуй локально. Глобальное видение - но не оцепенение, а активные действия в области, где можешь.
А вообще можно считать, что эти подходы применял Юлий Цезарь. Разделяй и Властвуй - это про DDD. А захватывая провинцию - он строил дороги и это тогдашний способ Data Driven.
👍1
Параллельно на первом слоте был доклад Aleš Štempihar из Словакии БА как бизнес-консультант - есть ли у БА потенциал стать чем-то большим, чем просто ИТ-специалистом. Он прошел путь от бизнес-аналитика до стратегического консультанта. Я пришел ближе к концу, но хочу отметить, что доклад - интересный. Хотя Алекс рассказывал именно свой путь, но этот путь соответствует тому, что происходило в отрасли, какие именно вызовы ставились и решались. Например, 2008-2018 был период lanced Scored Card и аналогичных изменений, а с 2018 - Dogital Transformation. И, во-первых, интересно проверить себя на понимание всего этого, а, во-вторых, разные отрасли и компании развиваются в разном темпе и вполне возможно это придет, хотя с отставанием. Хотя, конечно, хотелось бы чтобы в докладе было больше раскрыт характер задач и польза, наносимая компанией их решением, а не просто обозначение решаемой проблемы. Впрочем, я слушал небольшой кусочек. Может. кто из присутствовавших напишет подробнее.
Ну и вы ретроспективно можете прикинуть: а может, вы тоже могли бы это решать, и, может, стоит уйти в консультанты? Я про себя из тесного знакомства с бизнес-консультантами и наблюдения за их работой, участия в проектах знаю, что это - не совсем мое, но люди - разные.
Ну и вы ретроспективно можете прикинуть: а может, вы тоже могли бы это решать, и, может, стоит уйти в консультанты? Я про себя из тесного знакомства с бизнес-консультантами и наблюдения за их работой, участия в проектах знаю, что это - не совсем мое, но люди - разные.
Екатерина Кушнир. Делегирование – важный навык каждого аналитика. Передаем задачи и ответственность правильно. Основная мысль - если у вас большая задача или даже целиком ответственность за функциональную область, то надо делегировать задачи. Это, во-первых, часто сокращает время, а, во-вторых, перестает делать вас незаменимым. Ведь незаменимые не могут болеть и уходить в отпуск, и должны перерабатывать, если задач много, а это ведет к стрессу и выгоранию вместо радости и развития.
В начале было про навыки аналитика: качественно выполнять задачи; правильно демонстрировать результаты выполненной работы; брать на себя ответственность. С ответственностью у многих проблемы. Ответственность - это про то, что не делать много задач, много работать, переживать за задачи и сильно стараться. Это знать, что нужно выполнить и к какому сроку и именно это делать, доводя задачи до конца. Если аналитик умеет брать ответственность, то из начинающего быстро превращается в мидла, потому что задачи - относительно простые. Но по мере усложнения задач - это получается тяжелее, выше неопределенность, и потому сроки и качество, и откладывание на потом. И вместо развития - стресс и выгорание.
Делаю большую задачу. Когда стоит делегировать: не успеваю в оговоренные сроки, не успеваю делать другие задачи, из-за ограничений по времени в связи с другими активностями. Если вы отвечаете за функциональную область - делегировать обязательно. Удобно, что вы все знаете. Но есть риски для команды, когда вы выпадаете, и для вас - если область уйдет из проекта. Без делегирования вы ограничиваете свое развитие. Маячки для делегирования: есть риски для репутации или ограничения по сроком.
С делегированием связаны страхи: не хочу делить похвалу, потеряю ценность, задачу сделают плохо. Тут надо понимать: брать ответственность и делать самостоятельно - разные вещи. При делегирование именно вы продолжаете обеспечивать результат перед руководителем - и можно выделать не целиком, а частные задачи. Например, нарисовать схему процесса.
А вдруг сделают задачу плохо? Но вы же передаете не кому-нибудь. Вы передаете тем, кто мотивирован, ему будет полезно для развития, и сможет сделать. Оба - не встречаются, достаточно только одного. И надо учитывать, и понимать, как это скажется при выполнении. Я отмечу, что тут принципиальное противоречие: если задача полезна для развития, значит человек ее не делал - и нет гарантий что сможет, то есть оба пункта не достижимы в принципе. Но поскольку Екатерина говорит, что достаточно одного, то это неважно.
Когда мы делегировали - у нас появляется время. И у нас появляется время для других задач и собственного развития. Замотивированная команда, задачи выполнены в срок, вы проявили лидерские качества.
Как делегировать? Вы смотрите по задачам, какие можно делегировать. Дальше - обсуждаете с руководством, что вы хотите делегировать и ценность для проекта от такого решения. И если оно согласилось - то обсуждаете с человеком. Если руководство возражает - то сразу обсуждаете риски, обычно получается, что не уложимся в сроки - и пусть руководство эти риски принимает. Можно обсуждение с руководителем и сотрудником менять местами, если вы предполагаете, что руководитель одобрит. Но совсем пропускать обсуждение с руководителем - не стоит.
Что делегировать нельзя? То, в чем не разбираетесь. Вы не сможете их правильно делегировать. А еще - это полезно для вашего развития. Хочу отметить, однако, что, если вы заботитесь о сроках проекта и в команде есть способный эксперт именно для этой задачи, то делегирование может быть уместно. Обычно это ситуация, когда вы отвечаете за функциональную область целиком, и в ней прилетела нетипичная или очень сложная для вас задача. Конечно, наломать дров и разобраться для вас - полезно, а для проекта - не всегда. Умение во-время запросить помощь эксперта - важный навык, встречающийся не часто.
В начале было про навыки аналитика: качественно выполнять задачи; правильно демонстрировать результаты выполненной работы; брать на себя ответственность. С ответственностью у многих проблемы. Ответственность - это про то, что не делать много задач, много работать, переживать за задачи и сильно стараться. Это знать, что нужно выполнить и к какому сроку и именно это делать, доводя задачи до конца. Если аналитик умеет брать ответственность, то из начинающего быстро превращается в мидла, потому что задачи - относительно простые. Но по мере усложнения задач - это получается тяжелее, выше неопределенность, и потому сроки и качество, и откладывание на потом. И вместо развития - стресс и выгорание.
Делаю большую задачу. Когда стоит делегировать: не успеваю в оговоренные сроки, не успеваю делать другие задачи, из-за ограничений по времени в связи с другими активностями. Если вы отвечаете за функциональную область - делегировать обязательно. Удобно, что вы все знаете. Но есть риски для команды, когда вы выпадаете, и для вас - если область уйдет из проекта. Без делегирования вы ограничиваете свое развитие. Маячки для делегирования: есть риски для репутации или ограничения по сроком.
С делегированием связаны страхи: не хочу делить похвалу, потеряю ценность, задачу сделают плохо. Тут надо понимать: брать ответственность и делать самостоятельно - разные вещи. При делегирование именно вы продолжаете обеспечивать результат перед руководителем - и можно выделать не целиком, а частные задачи. Например, нарисовать схему процесса.
А вдруг сделают задачу плохо? Но вы же передаете не кому-нибудь. Вы передаете тем, кто мотивирован, ему будет полезно для развития, и сможет сделать. Оба - не встречаются, достаточно только одного. И надо учитывать, и понимать, как это скажется при выполнении. Я отмечу, что тут принципиальное противоречие: если задача полезна для развития, значит человек ее не делал - и нет гарантий что сможет, то есть оба пункта не достижимы в принципе. Но поскольку Екатерина говорит, что достаточно одного, то это неважно.
Когда мы делегировали - у нас появляется время. И у нас появляется время для других задач и собственного развития. Замотивированная команда, задачи выполнены в срок, вы проявили лидерские качества.
Как делегировать? Вы смотрите по задачам, какие можно делегировать. Дальше - обсуждаете с руководством, что вы хотите делегировать и ценность для проекта от такого решения. И если оно согласилось - то обсуждаете с человеком. Если руководство возражает - то сразу обсуждаете риски, обычно получается, что не уложимся в сроки - и пусть руководство эти риски принимает. Можно обсуждение с руководителем и сотрудником менять местами, если вы предполагаете, что руководитель одобрит. Но совсем пропускать обсуждение с руководителем - не стоит.
Что делегировать нельзя? То, в чем не разбираетесь. Вы не сможете их правильно делегировать. А еще - это полезно для вашего развития. Хочу отметить, однако, что, если вы заботитесь о сроках проекта и в команде есть способный эксперт именно для этой задачи, то делегирование может быть уместно. Обычно это ситуация, когда вы отвечаете за функциональную область целиком, и в ней прилетела нетипичная или очень сложная для вас задача. Конечно, наломать дров и разобраться для вас - полезно, а для проекта - не всегда. Умение во-время запросить помощь эксперта - важный навык, встречающийся не часто.
Про презентацию результатов заказчику - Екатерина не рекомендует это делать, кроме отдельных случаев, например, разработки макетов. Отмечу, что это часто правильно - у вас налажен контакт, вы принимали задачи. Но может быть отдельная ситуация, когда исполнитель растет человек, общающийся с заказчиком.
Про сроки. Вы даете +50% к вашей оценке - потому что делаете не вы. И надо закладывать на ревью. Ревью нужно, даже если задачу делает эксперт потому что исполнитель не владеет всем контекстом. Например, передали нарисовать sequence-диаграмму по написанному сценарию, потому что он классно рисует и любит это. Но не факт, что он при этом поймет сценарий адекватно, диаграмма может получиться красивой, но с ошибками.
Делегирование - инструмент карьерного роста. Чтобы расти - надо брать ответственность. Риск для репутации и ограничения - повод делегировать. Сами выбираем что и кому делегировать. При правильном делегировании - все участники выигрывают. А если кто-то не доволен - значит где-то ошиблись.
Про сроки. Вы даете +50% к вашей оценке - потому что делаете не вы. И надо закладывать на ревью. Ревью нужно, даже если задачу делает эксперт потому что исполнитель не владеет всем контекстом. Например, передали нарисовать sequence-диаграмму по написанному сценарию, потому что он классно рисует и любит это. Но не факт, что он при этом поймет сценарий адекватно, диаграмма может получиться красивой, но с ошибками.
Делегирование - инструмент карьерного роста. Чтобы расти - надо брать ответственность. Риск для репутации и ограничения - повод делегировать. Сами выбираем что и кому делегировать. При правильном делегировании - все участники выигрывают. А если кто-то не доволен - значит где-то ошиблись.
Alena Demysheva из Quantori. Не надо стесняться: как коммуницировать с теми,кто знает больше тебя и не чувствовать себя студентом. Вы хотите перейти в другую область - но вы сомневаетесь, ведь там вы не специалист, окажетесь в позиции начинающего. Она 1.5 года назад из eCommerce перешла в Life Science, сейчас делится опытом.
На первой встрече просто молчала - потому что поняла процентов 20. Потом все-таки решила задач, и попробовала интегрировать слова эксперта. И в конце пообещала стандартные сроки, плюс не вела аудио-запись, только notes- а в терминах путаница. Был провал. Вторая попытка - погружение в домен. Стихийно. Попробовала охватить 10-летнюю программу за неделю. И это тоже не получилось. Плюс обесценила опыт бизнес-аналитика. И не использовала компетенции анализа при изучении. А еще - не спрашивала экспертов компании, хотела сама разобраться. Переработки, срыв сроков, выгорание. Подумала о смене. Но все-таки было жаление идти в этот домен.
И она изменила подход.
* Подготовка к встрече: Выписать пункты гордости (два высших, грант для компании), выписать прошлые ошибки и решения ситуаций - дает опору и уверенность
* Коммуникации на встрече: предупреждает о волнении - первый проект в новой области, это настраивает собеседника; переформулирование тезисов эксперта "я правильно поняла, что ..." - доверие; "Простите, что дублирую"; Благодарность за ответы; Выбрать удобный эксперту канал для продолжения коммуникации
* После встречи отправить meeting notes - чтобы получить обратную связь, исправление формулировок.
Погружение в домен как проект
* Структура погружения в домен
* Приоритеты
* Декомпозиция задач
* Словарь, и его согласуешь с экспертом - там есть тонкости
* Просить помощь экспертов и коллег
В результате: укладываемся в сроки, быстрая адаптация, хорошее самочувствие и уверенность и даже предложение улучшений.
Напоминание, поставила каждый день: "Сделанное лучше идеального не сделанного" - борьба с перфекционизмом.
Когда ты разговариваешь с экспертом - ты не студент, говорите на равных. Нет задачи обучиться, у вас есть общая задача сделать проект. Надо опираться на сильные стороны, разрешать себе делать ошибки, искать свои способы самопомощи.
На первой встрече просто молчала - потому что поняла процентов 20. Потом все-таки решила задач, и попробовала интегрировать слова эксперта. И в конце пообещала стандартные сроки, плюс не вела аудио-запись, только notes- а в терминах путаница. Был провал. Вторая попытка - погружение в домен. Стихийно. Попробовала охватить 10-летнюю программу за неделю. И это тоже не получилось. Плюс обесценила опыт бизнес-аналитика. И не использовала компетенции анализа при изучении. А еще - не спрашивала экспертов компании, хотела сама разобраться. Переработки, срыв сроков, выгорание. Подумала о смене. Но все-таки было жаление идти в этот домен.
И она изменила подход.
* Подготовка к встрече: Выписать пункты гордости (два высших, грант для компании), выписать прошлые ошибки и решения ситуаций - дает опору и уверенность
* Коммуникации на встрече: предупреждает о волнении - первый проект в новой области, это настраивает собеседника; переформулирование тезисов эксперта "я правильно поняла, что ..." - доверие; "Простите, что дублирую"; Благодарность за ответы; Выбрать удобный эксперту канал для продолжения коммуникации
* После встречи отправить meeting notes - чтобы получить обратную связь, исправление формулировок.
Погружение в домен как проект
* Структура погружения в домен
* Приоритеты
* Декомпозиция задач
* Словарь, и его согласуешь с экспертом - там есть тонкости
* Просить помощь экспертов и коллег
В результате: укладываемся в сроки, быстрая адаптация, хорошее самочувствие и уверенность и даже предложение улучшений.
Напоминание, поставила каждый день: "Сделанное лучше идеального не сделанного" - борьба с перфекционизмом.
Когда ты разговариваешь с экспертом - ты не студент, говорите на равных. Нет задачи обучиться, у вас есть общая задача сделать проект. Надо опираться на сильные стороны, разрешать себе делать ошибки, искать свои способы самопомощи.
👍3👎1🔥1
Антон Семенченко. Релокация в IT, стрессоустойчивость и психологическая самодиагностика. Помогал готовить Алексей Казак, он врач-психиатр. В докладе - медицинские подходы для самодиагностике, и это, на мой взгляд - очень ценное, там много простых методик. А еще - алгоритм принятия решений по релокации или по возвращению, если она оказалась неудачной, и его можно применять и для других радикальных изменений жизни.
Для начала были определения.
* Тревога - чувство внутреннего беспокойства в ответ на реальную или мнимую систему с реакцией вегетативной нервной системы (сердцебиение, потливость и так далее).
* Страх - нормальная психологическая и физиологическая реакция на действительную угрозу или опасность или ее предчувствие. Там где предчувствие опасности - Страх и Тревога может смешиваться. Но тревога - она и про мнимое тоже
* Фобия - чрезмерная и беспричинная степень страха под воздействием или ожиданием особого объекта или обстоятельства
* Депрессия - стойкое (недели+) снижение настроения, утрата интересов и способности получать удовольствие с повышенной утомляемостью. И там - сложный медицинский вопрос. Входим постепенно, можем не заметить
* Стресс - состояние психологического и физического напряжения в ответ на внешнее воздействие, это - нормально
* Стрессоустойчивость - способность переживать стресс
Пирамида Маслоу. При релокации ее уместно использовать и смотреть на удовлетворенность нижележащих уровней. Бывают исключения, но на них рассчитывать не стоит. Пример. Компания выиграла грант на внедрение софта в Афганистане. И предложило ему. С точки зрения высших уровней это могло быть предложением века - карьера, финансы и т.п. Но безопасность - нет, особенно потому что трое детей - и они внедряли удаленно. Но есть и другие, кто, например, настраивает в Ливии боевые лазеры, а они не настраиваются. То есть уровни у каждого свои.
Таблица стрессоустойчивости Холмса и Раге. Разработана, чтобы при приеме на работу или назначении на ответственную должность понимать - выдержит или нет. Там баллы по поводу каждого стрессового случая, и ты ставишь галочки, что у тебя в жизни есть. При переезде согласия с семьей и близкими добиться почти невозможно. Например, дети - он уезжаешь от друга. Заполните таблицу для переезда. Если значение будет близко к пороговому - повод задуматься. Потому как еще в проекте что-то пойдет не так - и будет тяжело.
Психологические защиты. Способ преодоления тревог и страхов. У каждого - свой арсенал, у кого-то большой, у кого-то - маленький.
* Примитивные - как дети: я в домике, закрыть глаза, взять за руку
* Невротические - избегание, навязчивые мысли о катастрофе, завышение уровня угрозы и т.п. и они могут придти к неврозу, психосоматике. Головная боль может быть психосоматическая или сосудистая, специалисты умеют разделять - и надо тут обращаться. Интеллектуализация и рационализация, в том числе иррациональных страхов. И психотерапевтам с нами-аналитиками работать с этим сложнее. Мы придумываем кучу аргументов, почему точно не надо идти на работу - так же как алкоголик обоснует, почему сегодня обязательно надо выпить.
* Зрелые - условно осознанные. Юмор, подавление, аскетизм, альтруизм. Это может быть способом ухода от проблем. А еще - предвосхищение и сублимация в увлечения и хобби.
Hospitalal anxiety and depression scale. 14 пунктов, 4 варианта ответов. 0-7 - нома, 8-10 субклинически, больше - клинически. Анкета используется в медицине - можете сделать самооценку.
Когнитивные функции: внимание, память, мышление, обучение, речь, интеллект... И есть когнитивные искажения. Они могут приводить к систематичным отклонениям в поведении, восприятии или мышлении, навязчивые идеи. В эпоху перемен это обостряется. Когда много информации, когда быстро принимаем решения, когда срабатывает избирательное забывание при том, что мы думаем, что все запомнили. И эффект Даннинга-Крюгера.
Для начала были определения.
* Тревога - чувство внутреннего беспокойства в ответ на реальную или мнимую систему с реакцией вегетативной нервной системы (сердцебиение, потливость и так далее).
* Страх - нормальная психологическая и физиологическая реакция на действительную угрозу или опасность или ее предчувствие. Там где предчувствие опасности - Страх и Тревога может смешиваться. Но тревога - она и про мнимое тоже
* Фобия - чрезмерная и беспричинная степень страха под воздействием или ожиданием особого объекта или обстоятельства
* Депрессия - стойкое (недели+) снижение настроения, утрата интересов и способности получать удовольствие с повышенной утомляемостью. И там - сложный медицинский вопрос. Входим постепенно, можем не заметить
* Стресс - состояние психологического и физического напряжения в ответ на внешнее воздействие, это - нормально
* Стрессоустойчивость - способность переживать стресс
Пирамида Маслоу. При релокации ее уместно использовать и смотреть на удовлетворенность нижележащих уровней. Бывают исключения, но на них рассчитывать не стоит. Пример. Компания выиграла грант на внедрение софта в Афганистане. И предложило ему. С точки зрения высших уровней это могло быть предложением века - карьера, финансы и т.п. Но безопасность - нет, особенно потому что трое детей - и они внедряли удаленно. Но есть и другие, кто, например, настраивает в Ливии боевые лазеры, а они не настраиваются. То есть уровни у каждого свои.
Таблица стрессоустойчивости Холмса и Раге. Разработана, чтобы при приеме на работу или назначении на ответственную должность понимать - выдержит или нет. Там баллы по поводу каждого стрессового случая, и ты ставишь галочки, что у тебя в жизни есть. При переезде согласия с семьей и близкими добиться почти невозможно. Например, дети - он уезжаешь от друга. Заполните таблицу для переезда. Если значение будет близко к пороговому - повод задуматься. Потому как еще в проекте что-то пойдет не так - и будет тяжело.
Психологические защиты. Способ преодоления тревог и страхов. У каждого - свой арсенал, у кого-то большой, у кого-то - маленький.
* Примитивные - как дети: я в домике, закрыть глаза, взять за руку
* Невротические - избегание, навязчивые мысли о катастрофе, завышение уровня угрозы и т.п. и они могут придти к неврозу, психосоматике. Головная боль может быть психосоматическая или сосудистая, специалисты умеют разделять - и надо тут обращаться. Интеллектуализация и рационализация, в том числе иррациональных страхов. И психотерапевтам с нами-аналитиками работать с этим сложнее. Мы придумываем кучу аргументов, почему точно не надо идти на работу - так же как алкоголик обоснует, почему сегодня обязательно надо выпить.
* Зрелые - условно осознанные. Юмор, подавление, аскетизм, альтруизм. Это может быть способом ухода от проблем. А еще - предвосхищение и сублимация в увлечения и хобби.
Hospitalal anxiety and depression scale. 14 пунктов, 4 варианта ответов. 0-7 - нома, 8-10 субклинически, больше - клинически. Анкета используется в медицине - можете сделать самооценку.
Когнитивные функции: внимание, память, мышление, обучение, речь, интеллект... И есть когнитивные искажения. Они могут приводить к систематичным отклонениям в поведении, восприятии или мышлении, навязчивые идеи. В эпоху перемен это обостряется. Когда много информации, когда быстро принимаем решения, когда срабатывает избирательное забывание при том, что мы думаем, что все запомнили. И эффект Даннинга-Крюгера.
Эмоциональное выгорание. Деморализация, разочарование, усталость. Это процесс, а не результат - можно выгореть незаметно. Эмоциональная истощенность, деперсонализация (снижение личностной вовлеченности) и асоциальное поведение на работе (грубые шутки и т.п. - пробуем себя подстегнуть), редукция профессиональных навыков с нарастающим ощущением некомпетентности.
Я прихожу на работу позже - все позже, но рационализирую, что это в интересах проекта, чтобы больше сделать и общатьcя с заказчиком - но делаете вы меньше, а совещаний избегаете.
Признаки Maslush & Juckson: часто смотрим на часы, сопротивляемся выходу на работу, откладываем встречи, избегаем творческого подхода к задачам и так далее - найдите и используйте.
Алгоритм, который советует применить. Шаги - стандартные, а реализация - разная
* Расчет ROI: что приобретем, а что потеряем в случае релокации. С учетом личной важности разных факторов. Часто считают, что переедет - и все наладится. не так. Если тут были проблемами с поиском девушки, то в Англии они усугубятся. Family risk 0 понять за детей и супруги-супруга. Например, в Минске встретить собаку без хозяина почти невозможно, а в Армении или Грузии - их много, они добродушные, но если боишься - будешь бояться гулять и особенно бегать, если увлекаешься. Медицина - если здоров, можно поехать в страну с дорогой или слабой медициной, а если слабое здоровье, или дети болеют - там риски. А еще беременность - там медицина важна. У него были проблемы, спорт их еще местами усугубил - про Белоруссию он знает, что она в топ-3 в мире и у него связи.
* Теоретическое исследование про переезд - истории из разных источников.
* Практическое исследование. Попробовать. А то товарищ решил провести остаток дней у моря и повыше, продал квартиру в Минске и купил там - и тут выяснил, что там зимой по утрам иней, и ему очень некомфортно ходить. Через два года вернулся. А мог снять квартиру на зиму.
Tips и Tricks
* Есть сайты - статистика преступлений по городам и районам. Посмотрите
* Был в Алма-Ате. Оказывается есть подвох. Много ломбардов. Посмотреть, кто туда входит - и увидеть кто входит. Оказывается много групп молодых людей приносят телефоны - откуда они?
* Зайти в любую травму и посмотреть кто. Не разбито лицо и тяжело раздроблена правая рука - значит начали кого-то бить, он увернулся и попали на по асфальту. Значит с детьми туда ехать не стоит.
Что дальше? Есть три книги, которые рекомендуются тем, кто хочет
* Джекобсон Секреты психиатрии
* Маккей, Скин, Фаннинг. Конитивно-поведенческая терапия для преодоления тревожности, страха, беспокойства и паники
* Франц Александр Психосоматическая медицина: принципы и применения
Я прихожу на работу позже - все позже, но рационализирую, что это в интересах проекта, чтобы больше сделать и общатьcя с заказчиком - но делаете вы меньше, а совещаний избегаете.
Признаки Maslush & Juckson: часто смотрим на часы, сопротивляемся выходу на работу, откладываем встречи, избегаем творческого подхода к задачам и так далее - найдите и используйте.
Алгоритм, который советует применить. Шаги - стандартные, а реализация - разная
* Расчет ROI: что приобретем, а что потеряем в случае релокации. С учетом личной важности разных факторов. Часто считают, что переедет - и все наладится. не так. Если тут были проблемами с поиском девушки, то в Англии они усугубятся. Family risk 0 понять за детей и супруги-супруга. Например, в Минске встретить собаку без хозяина почти невозможно, а в Армении или Грузии - их много, они добродушные, но если боишься - будешь бояться гулять и особенно бегать, если увлекаешься. Медицина - если здоров, можно поехать в страну с дорогой или слабой медициной, а если слабое здоровье, или дети болеют - там риски. А еще беременность - там медицина важна. У него были проблемы, спорт их еще местами усугубил - про Белоруссию он знает, что она в топ-3 в мире и у него связи.
* Теоретическое исследование про переезд - истории из разных источников.
* Практическое исследование. Попробовать. А то товарищ решил провести остаток дней у моря и повыше, продал квартиру в Минске и купил там - и тут выяснил, что там зимой по утрам иней, и ему очень некомфортно ходить. Через два года вернулся. А мог снять квартиру на зиму.
Tips и Tricks
* Есть сайты - статистика преступлений по городам и районам. Посмотрите
* Был в Алма-Ате. Оказывается есть подвох. Много ломбардов. Посмотреть, кто туда входит - и увидеть кто входит. Оказывается много групп молодых людей приносят телефоны - откуда они?
* Зайти в любую травму и посмотреть кто. Не разбито лицо и тяжело раздроблена правая рука - значит начали кого-то бить, он увернулся и попали на по асфальту. Значит с детьми туда ехать не стоит.
Что дальше? Есть три книги, которые рекомендуются тем, кто хочет
* Джекобсон Секреты психиатрии
* Маккей, Скин, Фаннинг. Конитивно-поведенческая терапия для преодоления тревожности, страха, беспокойства и паники
* Франц Александр Психосоматическая медицина: принципы и применения
Алексей Романов, Ekaterina Romanova. Разговор Архитектора и Product Owner: Как понять, что нужно переходить на микросервисы? Очень интересная форма подачи доклада - это разговор Product Owner в выдуманной небольшой компании, которая online продавала билеты на offline-мероприятия в регионах, и у которой был монолит, и которая решила стать еще и организатором online-мероприятий с выдачей сертификатов, продажей записей, нужно развивать личный кабинет участника и организатора, да еще выходит на международный рынок, и потребуется интеграция с разными платежными системами, с архитектором, которого позвали на развитие системы. В докладе было про плюсы и минусы перехода на сервисную архитектуру.
В чем проблемы монолита?
* С ростом системы увеличивается сложность.
* Требуются аппаратные ресурсы для увеличения производительности
* Сложность рефакторинга и внедрения новых технологий - будет не хватать производительности стека.
* Любые изменения требуют повторного тестирования и развертывания
* Невозможность параллельной работы большого количества человек с одной кодовой базой - сильная связность, сложные merge
* Большая стоимость архитектурных ошибок - архитектурные ограничения
Если распилить монолит на несколько независимых микросервисов.
* Писать проще, чем большой монолит
* Горизонтальное масштабирование и отказоустойчивость
* Уменьшается вероятность ошибок, так как тестировать маленький функционал проще. Проще понять.
Что такое микросервисная архитектура? Модульный подход, основанный на слабозависимых заменяемых компонентах. Сфокусированные, сервис выполняет свою задачу, например: сервис подписи сертификатов. Слабосвязанные, изменения в одном требуют изменений в другом. Высокосогласованные - содержат все нужные методы. И маленький.
В чем плюсы для конкретного решения?
* Большая стабильность. Падение одного сервиса не затронет другими, падение сертификатов не затронет видеотрансляции или продажу билетов.
* Разнообразие технологий
* Меньшая стоимость ошибок, можно сервис выкинуть и переписать
Минусы
* Время коммуникации по сети на взаимодействие
* Нужна хорошая система деплоя и развертывания новых виртуальных машин. Пока 3-4 можно без них, когда 20 - нет.
* Хорошее описание API между сервисами. Публичный контракт, держим консистентным.
* Отказоустойчивость не только сервисов, но и сети.
* При проектировании обрабатывать разрушения отдельных сервисов.
* Сложность декомпозиции из-за сильной связанности данных.
Вот тут я хочу сказать, что если посмотреть на минусы, то они уничтожают плюсы. Например, остальные части системы работают при падении одного сервиса, но появляется больше точек отказа, включая сеть. А забота о консистентности обработки в случае отказов, если задействуется несколько сервисов сильно увеличивает сложность разработки, и требует понимания межсервисного взаимодействия. Так же увеличивается сложность построения комплексных запросов по данным. которые в монолите лежат в одной базе. Таких пунктов много. И они в докладе, в общем-то не обозначены, а в результате оптимистичные ожидания вполне могут оказаться неверными. Вообще про грабли микросервисной архитектуры неделю назад был хороший доклад Филиппа Дельгядо на Saint Highload, у меня на сайте есть конспект.
Что меняется в разработке?
* Появляется DevOps - отдельная компетенция
* Декомпозиция задачи по сервисам, с ответственностью команд за отдельные сервисы. Нужно согласование API между командами.
* Хотя команды изолированы, есть взаимодействие.
Как переносить? Сохраняем монолит, откусываем кусочке. Поверх - dispatcher, который маршрутизирует запросы. А новое пишем в сервисы.
В чем проблемы монолита?
* С ростом системы увеличивается сложность.
* Требуются аппаратные ресурсы для увеличения производительности
* Сложность рефакторинга и внедрения новых технологий - будет не хватать производительности стека.
* Любые изменения требуют повторного тестирования и развертывания
* Невозможность параллельной работы большого количества человек с одной кодовой базой - сильная связность, сложные merge
* Большая стоимость архитектурных ошибок - архитектурные ограничения
Если распилить монолит на несколько независимых микросервисов.
* Писать проще, чем большой монолит
* Горизонтальное масштабирование и отказоустойчивость
* Уменьшается вероятность ошибок, так как тестировать маленький функционал проще. Проще понять.
Что такое микросервисная архитектура? Модульный подход, основанный на слабозависимых заменяемых компонентах. Сфокусированные, сервис выполняет свою задачу, например: сервис подписи сертификатов. Слабосвязанные, изменения в одном требуют изменений в другом. Высокосогласованные - содержат все нужные методы. И маленький.
В чем плюсы для конкретного решения?
* Большая стабильность. Падение одного сервиса не затронет другими, падение сертификатов не затронет видеотрансляции или продажу билетов.
* Разнообразие технологий
* Меньшая стоимость ошибок, можно сервис выкинуть и переписать
Минусы
* Время коммуникации по сети на взаимодействие
* Нужна хорошая система деплоя и развертывания новых виртуальных машин. Пока 3-4 можно без них, когда 20 - нет.
* Хорошее описание API между сервисами. Публичный контракт, держим консистентным.
* Отказоустойчивость не только сервисов, но и сети.
* При проектировании обрабатывать разрушения отдельных сервисов.
* Сложность декомпозиции из-за сильной связанности данных.
Вот тут я хочу сказать, что если посмотреть на минусы, то они уничтожают плюсы. Например, остальные части системы работают при падении одного сервиса, но появляется больше точек отказа, включая сеть. А забота о консистентности обработки в случае отказов, если задействуется несколько сервисов сильно увеличивает сложность разработки, и требует понимания межсервисного взаимодействия. Так же увеличивается сложность построения комплексных запросов по данным. которые в монолите лежат в одной базе. Таких пунктов много. И они в докладе, в общем-то не обозначены, а в результате оптимистичные ожидания вполне могут оказаться неверными. Вообще про грабли микросервисной архитектуры неделю назад был хороший доклад Филиппа Дельгядо на Saint Highload, у меня на сайте есть конспект.
Что меняется в разработке?
* Появляется DevOps - отдельная компетенция
* Декомпозиция задачи по сервисам, с ответственностью команд за отдельные сервисы. Нужно согласование API между командами.
* Хотя команды изолированы, есть взаимодействие.
Как переносить? Сохраняем монолит, откусываем кусочке. Поверх - dispatcher, который маршрутизирует запросы. А новое пишем в сервисы.
И в конце были критерии выбора
* На стадии MVP или Proof of Concept - монолит. Если есть четкое понимание, как будет развиваться приложение - сервисы.
* Если понимания дальнейшего понимания есть - можно пока жить на монолите. Но писать осторожно, думая, что может переехать.
* Если есть понимание высоконагруженных частей - их надо выносить отдельно
* Развертывание монолита проще, но вообще есть много инструментов.
* Если часть временная - то можно выносить в отдельные сервисы. Потому что в монолите разработчики могут переиспользовать
* Консистентность - если есть такие задачи, то либо монолит, либо выделение консистентной части в один сервис.
* Но при этом хранение больших объемов данных лучше выносить в сервисы, чтобы можно было сменить технологию БД.
* На стадии MVP или Proof of Concept - монолит. Если есть четкое понимание, как будет развиваться приложение - сервисы.
* Если понимания дальнейшего понимания есть - можно пока жить на монолите. Но писать осторожно, думая, что может переехать.
* Если есть понимание высоконагруженных частей - их надо выносить отдельно
* Развертывание монолита проще, но вообще есть много инструментов.
* Если часть временная - то можно выносить в отдельные сервисы. Потому что в монолите разработчики могут переиспользовать
* Консистентность - если есть такие задачи, то либо монолит, либо выделение консистентной части в один сервис.
* Но при этом хранение больших объемов данных лучше выносить в сервисы, чтобы можно было сменить технологию БД.
👍3
Анастасия Соболева. Трудные диалоги в жизни аналитика. Аналитик - центр коммуникации. И занимается переговорами. И есть смысл не просто защищать свою позицию, а предварительно посмотреть все поле торга. Как это делать - было показано на кейсе: была разработка, когда команда А завершила разработку, и команда Б близка к завершению, но разработка еще идет, пришла безопасность, которая требовала квалифицированную электронную подпись, сказав, что это подразумевалось в рекомендациях, надо было догадаться, поэтому делать надо бесплатно и в те же сроки. Как решить, команда будет делать?
Для каждой из команды брать доработку рискованно. При этом команда А начинает работать с заказчиком и хочет увеличивать присутствие, а команда Б - давно работает, обе заинтересованы в присутствие. Безопасность ссылается на требование регулятора, но там нет жесткой обязательности, при этом она не заинтересована в продукте - им надо подложить соломку. А заказчик требует сроки, потому что уже купил рекламу, и им не важно конкретное решение.
Дальше выписывают варианты решения и возможный workaround - может, надо на первом шаге вообще через людей работать. Ресурсы. А почти закончила разработку. А Б - могут быть часть сил. Она представляет команду Б. Предпочтительное решение и пределы торга. И просчитывает тоже самое для других участников. Понимает, что может и не угадать. Спектр для Б: от сохранения решения до полной реализации. И возможное привлечение сотрудников или бюджета. И еще привлечение безопасности -через экспертов, чтобы они пришли, помогли, им оплатили. Для А - они не будут заинтересованы в переработку, но, вероятно, дадут ресурс, если его оплатить. И получается, что команда Б, скорее, будет делать, и будет поле торга. И возможный workaround. В результате переговоров в данном случае нашли workaround, получилось убедить безопасность на сокращенное решение. Но подготовка - давала уверенность. Самое главное при такой подготовке переговоры идут более ответственно и получаются взвешенные решения.
Для каждой из команды брать доработку рискованно. При этом команда А начинает работать с заказчиком и хочет увеличивать присутствие, а команда Б - давно работает, обе заинтересованы в присутствие. Безопасность ссылается на требование регулятора, но там нет жесткой обязательности, при этом она не заинтересована в продукте - им надо подложить соломку. А заказчик требует сроки, потому что уже купил рекламу, и им не важно конкретное решение.
Дальше выписывают варианты решения и возможный workaround - может, надо на первом шаге вообще через людей работать. Ресурсы. А почти закончила разработку. А Б - могут быть часть сил. Она представляет команду Б. Предпочтительное решение и пределы торга. И просчитывает тоже самое для других участников. Понимает, что может и не угадать. Спектр для Б: от сохранения решения до полной реализации. И возможное привлечение сотрудников или бюджета. И еще привлечение безопасности -через экспертов, чтобы они пришли, помогли, им оплатили. Для А - они не будут заинтересованы в переработку, но, вероятно, дадут ресурс, если его оплатить. И получается, что команда Б, скорее, будет делать, и будет поле торга. И возможный workaround. В результате переговоров в данном случае нашли workaround, получилось убедить безопасность на сокращенное решение. Но подготовка - давала уверенность. Самое главное при такой подготовке переговоры идут более ответственно и получаются взвешенные решения.
Radik Adiulin. CustDev в B2B: краткий гайд и уроки после 100 проведенных интервью. Перед тем, как разрабатывать - делают CustDev, чтобы убеиться, что продукт будет востребован. Есть Качественные и количественные исследования, разные способы. В докладе - про CustDev интервью - но процесс custdev этим не исчерпывается. Это лишь часть фазы customer exploratory.
Задача интервью: понять как пользователи принимают решения, в области, где вы делаете продукт
* Кто наши пользователи
* Какую проблему решает наш продукт
* Как эти пользователи выбирают продукты
В чем разница b2c и b2b?
* b2b больше обосновывает через рациональные инструменты (деньги, kpi лиц, принимающих решения и т.п.), то b2c - эмоциональная история, лишь сопровождаемая рациональным.
* b2b - чаще пользуются одни, а покупают другие. Как дети родителям.
* b2c - проще разговорить, потому что говорят про себя, а не про компанию
* b2b - проще понять, компании более однообразны, чем люди
Этапы
* Гипотеза - обязательно прописать, даже если идея продукта - мутная.
* Целевая аудитория
* Скрипт - следование ему не догма, но скрипт должен быть.
* Интервью - заметки или запись с последующим прослушиванием, можно проводить вдвоем, в конце вопрос: о чем важном не спросили
* Результаты - фиксируем общую ситуацию, обычно достаточно 8-12 интервью, и но это не догма, а внутренне ощущение, что ты знаешь ответы
* Итоги и артефакты. Документируйте - гипотезу, аудиторию, скрипты, результаты, выводы - потому что вы на этом основании будете принимать решения о продукте, а на разработке будут всплывать вопросы об их основаниях.
Проблемы
* Нет респондентов: network, отдел продаж, конференции, комьюнити, соцсети (но надо прокачать сервисы), отзывы конкурентов, платные сервисы.
* Интервью идут не гладко - ответы не дают понимания ситуации. Надо проверять свою гипотезу, может неверный сегмент аудитории. Если коммуникация не идет - попросите помощи, признайтесь в волнении
* Исследование не дает инсайтов - надо проверить гипотезу, она вполне может быть неверной, надо ее менять, может быть нужен другой инструмент исследований.
Стоит это 30-40 часов, занимает от 2 недель до 2 месяцев.
Кого опрашивать в b2b, пользователя или того, кто платит? Зависит от продукта. Если бухгалтерия или CRM - то того, кто покупает, он построит специалистов, потому что их много. А вот в сегментах, где дефицит квалифицированных специалистов, которые могут уйти, если их построят - то к пользователям надо идти. Можно еще поделить сегменты, про деньги - с одним, а сейла - о том, почему он до сих пор ведет Excel, а не пользуется CRM.
Задача интервью: понять как пользователи принимают решения, в области, где вы делаете продукт
* Кто наши пользователи
* Какую проблему решает наш продукт
* Как эти пользователи выбирают продукты
В чем разница b2c и b2b?
* b2b больше обосновывает через рациональные инструменты (деньги, kpi лиц, принимающих решения и т.п.), то b2c - эмоциональная история, лишь сопровождаемая рациональным.
* b2b - чаще пользуются одни, а покупают другие. Как дети родителям.
* b2c - проще разговорить, потому что говорят про себя, а не про компанию
* b2b - проще понять, компании более однообразны, чем люди
Этапы
* Гипотеза - обязательно прописать, даже если идея продукта - мутная.
* Целевая аудитория
* Скрипт - следование ему не догма, но скрипт должен быть.
* Интервью - заметки или запись с последующим прослушиванием, можно проводить вдвоем, в конце вопрос: о чем важном не спросили
* Результаты - фиксируем общую ситуацию, обычно достаточно 8-12 интервью, и но это не догма, а внутренне ощущение, что ты знаешь ответы
* Итоги и артефакты. Документируйте - гипотезу, аудиторию, скрипты, результаты, выводы - потому что вы на этом основании будете принимать решения о продукте, а на разработке будут всплывать вопросы об их основаниях.
Проблемы
* Нет респондентов: network, отдел продаж, конференции, комьюнити, соцсети (но надо прокачать сервисы), отзывы конкурентов, платные сервисы.
* Интервью идут не гладко - ответы не дают понимания ситуации. Надо проверять свою гипотезу, может неверный сегмент аудитории. Если коммуникация не идет - попросите помощи, признайтесь в волнении
* Исследование не дает инсайтов - надо проверить гипотезу, она вполне может быть неверной, надо ее менять, может быть нужен другой инструмент исследований.
Стоит это 30-40 часов, занимает от 2 недель до 2 месяцев.
Кого опрашивать в b2b, пользователя или того, кто платит? Зависит от продукта. Если бухгалтерия или CRM - то того, кто покупает, он построит специалистов, потому что их много. А вот в сегментах, где дефицит квалифицированных специалистов, которые могут уйти, если их построят - то к пользователям надо идти. Можно еще поделить сегменты, про деньги - с одним, а сейла - о том, почему он до сих пор ведет Excel, а не пользуется CRM.
Екатерина Лысенко. Сколько благородства в рисках? Прекрасный доклад о том, как заниматься рисками. Под "заниматься" в докладе имеется ввиду порождение списков потенциальных событий, которые влияют на проект и обсуждение нашей готовности их пережить, включая принятие риска: "будут бить - будем отбиваться". Есть еще варианты работы с рисками, я о них напишу в конце, а пока - конспект доклада.
Фразы "риск - дело благородное", "кто не рискует - не пьет шампанское" Екатерину всегда смущали. В рисками надо работать, и эта работа очень близка работе с багами, которые тоже случаются. Баг - частный случай риска.
Риск не всегда несет угрозу, как и стресс. Есть дистресс: все плохо и мы все умрем, и эустресс: все плохо, но мы всех победим. Так и события - одни несут угрозу, а другие - открывают возможность, и надо быть готовым ее подхватить. Цель управления рисками - за все хорошее и против всего плохого.
Что достигается путем работы с рисками?
* Возможность более точного определения срока и границ проекта. Это не про курсы, где учат "что будет, когда сломает ногу", "что будет, если не хватит финансирование" - не анализ не провели, или команду не набрали. Рисками занимаешься в истории от полугода (в старой реальности)
* Гибкость планирования и построения стратегии - про риски ты думаешь, и у тебя появляются сценарии. И не только на работе, но и в жизни. К сожалению или к радости - непонятно, иногда это как паранойя, а иногда выручает.
* Повышение прозрачности на уровне компании
* Сокращение числа инцидентов - вы об этом подумали
* Качество взаимодействия
* Качество взаимодействия между бизнес-подразделениями и разработкой - увеличивается понимание
* Формирование ценностного подхода на корпоративном уровне
Комикс из Дилберта, по-моему. Я оценил шансы что все пройдет гладко 70%. То есть когда провалится - ты признаешь, что был неправ? Но я только оценил шансы... Если у руководства такое отношение, то работать с рисками бесполезно. Риск менеджмент - это не игра в одни ворота. Риск - у компании, любой риск - твой риск. Нельзя заниматься в позиции эксперта. Риски приводят нас к необходимости анализировать, а это - ретроспективные практики. Самокопание, умение признавать собственные ошибки и далее - права на ошибку.
Типизация рисков. В разных книгах - по-разному, до 12. У нее - 4.
* Нормативно-правовые: законодательство и т.п.
* Ресурсные Прибыль, время, люди, техника. Риски по технике сейчас увеличились, на Кипре месяц нет поставки клавиатур с русскими буквами, с поставкой серверов, ноутбуков.
* Репутационные. По потребителям, пользователям, контрагентам, сообществам. И может быть положительный риск, представьте вы рассказываете о классной трансформации регламента или условиях работы - и репутацию запоминают. Социально-значимый контекст. Шаттлы, трагедия Челленджера - через два часа Рейган выступил с обращением к нации, и впервые начал "Нэнси и я" - семейная тема, и он нивелировал значительную часть рисков. Несоответствие качеству
* Технические риски: интеграционные, инфраструктурные и архитектурные. Внезапно узнаешь, что железка не отдает количество залитого топлива, а true/false.
Выявляют через анкетирование, мозговой штурм, изучение процессов и документации, анализ данных. Очень важно, чтобы на мозговых штурмах были представители всех бизнес-подразделений, нельзя качественно играть за другого. Как написано в коде - точно так и работает. И дальше посмотреть разницу между тем, что думает бизнес, и что есть на самом деле. Анализ данных - не средние, а особые случаи, которые выбиваются - вам важно понять что было там, и может ли это повториться.
Как работать с рисками? ROAMboard. Табличка, двигаем по доске: Resolved - Owned (есть владелец) - Accepted (принят участниками) - Mitigated (последствия минимизированы). Что классно? В работе с доской вы приучаете компанию к тому, что вы открыто обсуждаете риски и проблемы, что они должны быть видны всем. И вы начинаете разделять (share) ответственность. Есть антифрод или безопасность, вы показываете, за что они отвечают.
Фразы "риск - дело благородное", "кто не рискует - не пьет шампанское" Екатерину всегда смущали. В рисками надо работать, и эта работа очень близка работе с багами, которые тоже случаются. Баг - частный случай риска.
Риск не всегда несет угрозу, как и стресс. Есть дистресс: все плохо и мы все умрем, и эустресс: все плохо, но мы всех победим. Так и события - одни несут угрозу, а другие - открывают возможность, и надо быть готовым ее подхватить. Цель управления рисками - за все хорошее и против всего плохого.
Что достигается путем работы с рисками?
* Возможность более точного определения срока и границ проекта. Это не про курсы, где учат "что будет, когда сломает ногу", "что будет, если не хватит финансирование" - не анализ не провели, или команду не набрали. Рисками занимаешься в истории от полугода (в старой реальности)
* Гибкость планирования и построения стратегии - про риски ты думаешь, и у тебя появляются сценарии. И не только на работе, но и в жизни. К сожалению или к радости - непонятно, иногда это как паранойя, а иногда выручает.
* Повышение прозрачности на уровне компании
* Сокращение числа инцидентов - вы об этом подумали
* Качество взаимодействия
* Качество взаимодействия между бизнес-подразделениями и разработкой - увеличивается понимание
* Формирование ценностного подхода на корпоративном уровне
Комикс из Дилберта, по-моему. Я оценил шансы что все пройдет гладко 70%. То есть когда провалится - ты признаешь, что был неправ? Но я только оценил шансы... Если у руководства такое отношение, то работать с рисками бесполезно. Риск менеджмент - это не игра в одни ворота. Риск - у компании, любой риск - твой риск. Нельзя заниматься в позиции эксперта. Риски приводят нас к необходимости анализировать, а это - ретроспективные практики. Самокопание, умение признавать собственные ошибки и далее - права на ошибку.
Типизация рисков. В разных книгах - по-разному, до 12. У нее - 4.
* Нормативно-правовые: законодательство и т.п.
* Ресурсные Прибыль, время, люди, техника. Риски по технике сейчас увеличились, на Кипре месяц нет поставки клавиатур с русскими буквами, с поставкой серверов, ноутбуков.
* Репутационные. По потребителям, пользователям, контрагентам, сообществам. И может быть положительный риск, представьте вы рассказываете о классной трансформации регламента или условиях работы - и репутацию запоминают. Социально-значимый контекст. Шаттлы, трагедия Челленджера - через два часа Рейган выступил с обращением к нации, и впервые начал "Нэнси и я" - семейная тема, и он нивелировал значительную часть рисков. Несоответствие качеству
* Технические риски: интеграционные, инфраструктурные и архитектурные. Внезапно узнаешь, что железка не отдает количество залитого топлива, а true/false.
Выявляют через анкетирование, мозговой штурм, изучение процессов и документации, анализ данных. Очень важно, чтобы на мозговых штурмах были представители всех бизнес-подразделений, нельзя качественно играть за другого. Как написано в коде - точно так и работает. И дальше посмотреть разницу между тем, что думает бизнес, и что есть на самом деле. Анализ данных - не средние, а особые случаи, которые выбиваются - вам важно понять что было там, и может ли это повториться.
Как работать с рисками? ROAMboard. Табличка, двигаем по доске: Resolved - Owned (есть владелец) - Accepted (принят участниками) - Mitigated (последствия минимизированы). Что классно? В работе с доской вы приучаете компанию к тому, что вы открыто обсуждаете риски и проблемы, что они должны быть видны всем. И вы начинаете разделять (share) ответственность. Есть антифрод или безопасность, вы показываете, за что они отвечают.
Цикл работы с рисками: Периодическая оценка - Выявление риска - Анализ риска - Оценка риска - Принятие решения.
Разработка продукта - не столько риск задержки разработки, сколько риск не выдержать успех, когда пользователи вдруг массово пришли. Риски могут принимать разные. Астронавт не вернется - принимает он, принимает пиар-служба (а если случится - что делаем) и так далее. Дальше был пример - риск не-выпекания колобка.
Есть риски, которые нивелировать дороже, чем принять. Все люди болеют - решим в моменте, нет скамейки запасных.
Атрибуты риска. Не только содержание риска, но название, последствия реализации риска. У одного риска могут быть разные причины - можно раздавать ответственности. Критичность.
Психология. Когда у тебя много проблем в стрессе, ты все равно берешь проблемы. Помогаешь другим, сообществу - чтобы получить подтверждение. А реально начинаешь тонуть.
Про критичность - почитать японские книги про минимализм. Там лучше всего написано. Есть проблема - обведите кружочком, сделайте шаблон, действуйте по шаблону, стало неудобно - поменяйте шаблон.
Обоснование в цифрах. Поддержка говорит "умираем". А выясняется, что два студента пару часов в неделю разбирают - а исправление пара недель рефакторинга команды - и пусть студенты разбирают. С нормативно-правовыми тоже самое, последствия разные: если отнимут лицензию - надо чинить, а если небольшой штраф - можно заплатить.
Триггер. Ситуация, которая должна наступить, чтобы риски сработали. Не обязательно катастрофа. Триггер обычно тоже риск. Можно в ROAM board - связи между рисками. В некоторый момент перейдете от ROAM board к mindmap. Это - следующий этап.
А теперь - мои дополнения. Во-первых, помимо такой простой работы может быть сценарное планирование: если данное событие произойдет, то мы сделаем это и это (План-Б), при этом, чтобы во-время среагировать, будем следить за этим и этим. Например, так работают с рисками стартапов венчурные компании: чтобы не влипнуть с инвестициями, при не достижении таких-то результатов в такие-то сроки и деньги (веха) мы закрываем проект, а команду будем пристраивать таким-то образом (чтобы у людей не было страха за судьбу). А во-вторых во многих корпорациях целью работы с рисками является на задача выполнить проект, как у Екатерины, а задача избежать наказания менеджеров за провал проекта, и это - совсем другая работа с рисками.
Разработка продукта - не столько риск задержки разработки, сколько риск не выдержать успех, когда пользователи вдруг массово пришли. Риски могут принимать разные. Астронавт не вернется - принимает он, принимает пиар-служба (а если случится - что делаем) и так далее. Дальше был пример - риск не-выпекания колобка.
Есть риски, которые нивелировать дороже, чем принять. Все люди болеют - решим в моменте, нет скамейки запасных.
Атрибуты риска. Не только содержание риска, но название, последствия реализации риска. У одного риска могут быть разные причины - можно раздавать ответственности. Критичность.
Психология. Когда у тебя много проблем в стрессе, ты все равно берешь проблемы. Помогаешь другим, сообществу - чтобы получить подтверждение. А реально начинаешь тонуть.
Про критичность - почитать японские книги про минимализм. Там лучше всего написано. Есть проблема - обведите кружочком, сделайте шаблон, действуйте по шаблону, стало неудобно - поменяйте шаблон.
Обоснование в цифрах. Поддержка говорит "умираем". А выясняется, что два студента пару часов в неделю разбирают - а исправление пара недель рефакторинга команды - и пусть студенты разбирают. С нормативно-правовыми тоже самое, последствия разные: если отнимут лицензию - надо чинить, а если небольшой штраф - можно заплатить.
Триггер. Ситуация, которая должна наступить, чтобы риски сработали. Не обязательно катастрофа. Триггер обычно тоже риск. Можно в ROAM board - связи между рисками. В некоторый момент перейдете от ROAM board к mindmap. Это - следующий этап.
А теперь - мои дополнения. Во-первых, помимо такой простой работы может быть сценарное планирование: если данное событие произойдет, то мы сделаем это и это (План-Б), при этом, чтобы во-время среагировать, будем следить за этим и этим. Например, так работают с рисками стартапов венчурные компании: чтобы не влипнуть с инвестициями, при не достижении таких-то результатов в такие-то сроки и деньги (веха) мы закрываем проект, а команду будем пристраивать таким-то образом (чтобы у людей не было страха за судьбу). А во-вторых во многих корпорациях целью работы с рисками является на задача выполнить проект, как у Екатерины, а задача избежать наказания менеджеров за провал проекта, и это - совсем другая работа с рисками.
👍2
Полторы недели назад был в Ереване на SQAdays и AnalystDays. Влад Орликов сделал площадку общения между ИТ-шниками, которые оказались в разных странах ввиду современной геополитики, на конференции было много международных спикеров. Я хочу отметить не только активное общение, но и спокойную, ламповую обстановку и общий позитив. Публикую отчет https://mtsepkov.org/SQA-Analyst-EA2022 - собрал в него заметки с докладов и добавил общие впечатления.
👍10
Первый доклад ArchDays. Сергей Харламов. Архитектура масштабирования: ускоряем обработку и повышаем доступность данных. В современных распределенных системах транзакционность ACID на уровне системы, а не отдельной ноды или процесса практически не поддерживается, фокус на высокой доступности на смену ACID пришел BASE: Base Availability при сбоях, Soft state вместо acid-консистентности, Eventual consistency согласованность в будущем. При этом такие решения часто реализуются поверх старого РДБМСб которое используется как базовое хранилище в legacy- системах, от которых не отказываются. Для достижения используются различные механизмы: репликация баз данных; разные виды кеширования, при которых кэш работает как промежуточная БД, организованная по-другому, чем исходная; стриминг CQRS; CDC (Change Data Capture). Эти механизмы могут быть доступны в виде готовых решений, для других в БД предусмотрены точки расширения, третьи реализуются на уровне кода приложения. Засада в том, что в этих механизмах нужно разбираться для разбора инцидентов пользователей, и так же для понимания рисков при падении и последующем восстановлении. Это - не внутренность разработки, которая была В докладе был обзор шаблонов и разбор плюсов и побочных эффектов. Но рассказывать текстом - бесполезно, надо смотреть схемы на слайдах, так что смотрите презентацию.
👍2
Максим Юнусов. Изобретение архитектурного решения. Начат с классической ситуации: получив требования по времени отклика под нагрузкой и доступность сервиса с намеком, что для этого сервис должен масштабироваться, Архитектор выдает решение: PostgreSQL + хореография на событиях + Apache Kafka. Вопрос: как решение связано с исходными требованиями? И дальше был разбор предлагаемого порождения решений. Для начала посмотрим, что предлагают методологии: TOGAF, SEI, ADR. Интересно, что они все исходят из того, что должны быть стандартные решения, и задача выбора состоит лишь во взвешивании вариантов. Различается косметика, подходы к принятию и документированию этих решений. И это - печально. Поэтому предлагается посмотреть на смежные области, а именно на ТРИЗ. Там много интересного и полезного.
* Исходное описание - лишь описание ситуации, в ней пока не выявлено противоречие. Необходимо до этого довести, получить задачу.
* Противоречия бывают двух видов: противоречат два нефункциональных требования или нефункциональное требование противоречит архитектурному принципу.
* Для нефункциональных требований нужна заинтересованная сторона - кто заинтересован в его исполнении.
* Нефункциональное требование стоит подвергать сомнению. Действительно ли доступность сайта ниже 99.99 или время отклика более 0.1c приведет к оттоку пользователей (если это указали как основание требования). Может быть, требование можно ослабить или вообще снять?
* Решать противоречия следует, только если требования реально актуальны. Иначе будет overdesign, необоснованно сложное решение.
* Архитектурные принципы и ограничения тоже стоит подвергать сомнению.
* Антипаттерн, если в задаче не должно быть заложен подход к решению, когда сразу говорят, что из требований следует необходимость масштабировать сервиса на кластер
* Антипаттерн, если свобода сведена к свободе выбора из известного. А именно это предлагают методологии.
Разрешение противоречия
* Идеальное решение без ограничений
* Вводим ограничения до потери качества
* Формулируем физическое противоречие
Пример: архив должен создаваться для обеспечения надежности и НЕ должен создаваться, так как деградирует время отклика. Решаем
* во времени: делаем архив, когда низкая нагрузка
* в пространстве: делаем с отдельной ноды БД, которая для этого
* в структуре: две базы данных: для записи и для архива
* взаимодействия: приостанавливаем процесс архивирования при интенсивных запросах
* Архив как идеальный объект, архивирование без архива. Например, если архив нужен для отката - делаем откат иным образом, откручивая обработку событий назад.
* Исходное описание - лишь описание ситуации, в ней пока не выявлено противоречие. Необходимо до этого довести, получить задачу.
* Противоречия бывают двух видов: противоречат два нефункциональных требования или нефункциональное требование противоречит архитектурному принципу.
* Для нефункциональных требований нужна заинтересованная сторона - кто заинтересован в его исполнении.
* Нефункциональное требование стоит подвергать сомнению. Действительно ли доступность сайта ниже 99.99 или время отклика более 0.1c приведет к оттоку пользователей (если это указали как основание требования). Может быть, требование можно ослабить или вообще снять?
* Решать противоречия следует, только если требования реально актуальны. Иначе будет overdesign, необоснованно сложное решение.
* Архитектурные принципы и ограничения тоже стоит подвергать сомнению.
* Антипаттерн, если в задаче не должно быть заложен подход к решению, когда сразу говорят, что из требований следует необходимость масштабировать сервиса на кластер
* Антипаттерн, если свобода сведена к свободе выбора из известного. А именно это предлагают методологии.
Разрешение противоречия
* Идеальное решение без ограничений
* Вводим ограничения до потери качества
* Формулируем физическое противоречие
Пример: архив должен создаваться для обеспечения надежности и НЕ должен создаваться, так как деградирует время отклика. Решаем
* во времени: делаем архив, когда низкая нагрузка
* в пространстве: делаем с отдельной ноды БД, которая для этого
* в структуре: две базы данных: для записи и для архива
* взаимодействия: приостанавливаем процесс архивирования при интенсивных запросах
* Архив как идеальный объект, архивирование без архива. Например, если архив нужен для отката - делаем откат иным образом, откручивая обработку событий назад.
👍4
Евгений Лукьянов. Как Event Storming, DDD и чистая архитектура помогают запустить стартап. Реально история стартапа в области здоровья, в котором много алгоритмики и ML. На первом шаге была проверка алгоритмов, потом - проверка концепции на знакомых с интерфейсом на чат-боте. При этом разработку вел один человек на python, и получился сложный, взаимно-перевязанный код из множества сервисов, который очень сложно дальше дорабатывать. В некоторый момент потребовалось научиться вести разработку командой, а для этого потребовалось разобраться и упростить то, что сделано, обеспечить возможность подключения новичков. А потом был следующий этап - проверка спроса на сервис с партнерами, и там был следующий такт изменений.
На первом этапе
* Event Storming, чтобы разобраться, что делает приложение. Он показал, что основной разработчик не слишком представляет.
* Шаг к гексагональной архитектуре
* Внедрили тактические паттерны DDD: сбор бизнес-логики в агрегаты, Value-object, большие сервисы разбили на UseCase.
* Сделали референсный проект для погружения новичков.
На втором этапе
* Научили аналитиков пользоваться Event storming. Получились ограниченные контексты, области поделились. И в контекстах можно менять технологии.
* Нарисовали интерфейсы, отдали партнерам на тестирование.
* Типизация стандартных решений позволила включать новичков на локальные задачи. У новичка на следующий день есть сделанная простая задача. Разделение по квалификации.
* Прогнозирование. Сложный агрегат - 2 недели, простой два дня, объект-значение 6 часов, usecase 3 часа. За счет типизации решений.
* Trunk Based Development. Без веток. Потому что решение конфликтов было дорогим. Но Trunk based - невозможен без автоматики и хорошего тестирования.
* Тесты - есть заранее подготовленные данные окружения для запуска теста.
* Локальная сборка экономит деньги. Build-server - предохранитель.
* TDD для сложных мест
* Начали допускать тех.долг на этапах апробации решений
* Ограничили свободу - типовые узлы уже изготовлены, используешь их.
Книга: Accelerate: The Science of Lean Software Development and DevOps. Jez Humble, Gene Kim, Nicole Forsgren.
На первом этапе
* Event Storming, чтобы разобраться, что делает приложение. Он показал, что основной разработчик не слишком представляет.
* Шаг к гексагональной архитектуре
* Внедрили тактические паттерны DDD: сбор бизнес-логики в агрегаты, Value-object, большие сервисы разбили на UseCase.
* Сделали референсный проект для погружения новичков.
На втором этапе
* Научили аналитиков пользоваться Event storming. Получились ограниченные контексты, области поделились. И в контекстах можно менять технологии.
* Нарисовали интерфейсы, отдали партнерам на тестирование.
* Типизация стандартных решений позволила включать новичков на локальные задачи. У новичка на следующий день есть сделанная простая задача. Разделение по квалификации.
* Прогнозирование. Сложный агрегат - 2 недели, простой два дня, объект-значение 6 часов, usecase 3 часа. За счет типизации решений.
* Trunk Based Development. Без веток. Потому что решение конфликтов было дорогим. Но Trunk based - невозможен без автоматики и хорошего тестирования.
* Тесты - есть заранее подготовленные данные окружения для запуска теста.
* Локальная сборка экономит деньги. Build-server - предохранитель.
* TDD для сложных мест
* Начали допускать тех.долг на этапах апробации решений
* Ограничили свободу - типовые узлы уже изготовлены, используешь их.
Книга: Accelerate: The Science of Lean Software Development and DevOps. Jez Humble, Gene Kim, Nicole Forsgren.
👍1
Геннадий Круглов. SAGA — эволюция и новые смыслы. Сообщество архитекторов решило разобраться, что же такое SAGA, и в докладе представлен результат этого. К сожалению, не впечатляющий. Начали от базовых понятий, подняли статьи 1980-х о том, что же такое - транзакции, какие у них свойства (ACID) и какие проблемы. Одна из них - long life transaction при распределенных системах, которые при формальной реализации ведут к эскалации блокировок. И потому предложено делать промежуточный коммиты внутри транзакции, разбивая их на малые участки, после которых бизнес-консистентности нет, а SAGA - концептуальный способ восстановления этой консистентности, тоже предложенный давно, в 1986. За счет того, что есть управляющая часть, которая в случае прерывания в неконсистентном состоянии либо откатывает шаги, для чего должны быть предусмотрены средства отката, либо проталкивает до завершения, если для этого есть средства. Собственно, все. Как это реализуется - было за пределами доклада, хотя были ссылки на статьи Microsoft, Red Hat, AWS, Camunda. В общем, жаль, что содержание ограничилось этим. Я тут хочу отметить, что в сентябре был доклад Филиппа Дельгадо "Микросервисы через боль и превозмогание" на Saint Highload (кому интересно - мой конспект), где в числе прочего он говорил про SAGA, пунктиром обозначив минимум четыре шаблона реализации. И я надеялся услышать про шаблоны и концепты более детально, а получилась лишь историческая справка про статьи 1980-х о транзакциях и SAGA.