Презентация моего выступления "Как строить образ будущего и идти к нему - схемы самоопределения" — на моем сайте https://mtsepkov.org/SelfDet-StTL Там есть ссылка на предыдущую версию, пока запись этого не опубликована.

Артур Орлов. Дебажим коммуникацию: протоколы общения человеков. Коммуникация неизбежно идет с потерей информации, этому есть системные причины: сообщение с полным контекстом были бы бесконечны, поэтому мы их запаковываем, опуская известный контекст и разные общеизвестные вещи, а получатель сообщения - распаковывает на то, что ему известно. Ему известно другое, и понимает он по-другому. Задача - минимизировать потери. Об этом и был рассказ. Теперь подробности.

Disclaimer: Если рассказанное противоречит тому, что вы знаете - вспомните 4 закон Артура Кларка: для любого эксперта существует аналогичный с противоположной точкой зрения - мне очень понравился.

Коммуникация - опосредованный способ повлиять на окружение и способ обновить свою карту реальности, и непосредственный способ повлиять на свое состояние. Смысл коммуникации - получить обратную связь. В TCP - есть квитанции. А тут мы забываем, я сказал - все услышали.

Ключевые вопросы коммуникации: Какой результат, Чего ради и какой ценой, Как я пойму, что достиг.

Если после выкладки посыпалась смежная система, то заявление "Какого *** вы не предупредили о выкладке?" - не конструктивно, второй уходит в защиту, а еще запоминает наезд. Потому в сообщении нет цели.

Коммуникация - обмен сообщениями, двухсторонний, (реже 3-4, больше - разваливается на парные), асинхронный. Кажется, что часто синхронный диалог - но это отдельный навык, а когда двое кричат друг на друга - никакого диалога. Мультиканальный вербальная и невербальная; информационная и эмоциональная составляющая (факт и отношение к нему). Эмоции чаще передают невербально, но это не обязательно так. Далее - про вербальную историю. Невербальная - отдельные тренинги.

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

Синхронизация контекстов.
* Общий словарь и язык, включая мемасики
* Скорость, ритм, громкость - монотонный стук колес в поезде способствует общению
* Репрезентативные системы
* Тело - положение, движение. Это для загрузки эмоционального состояния.

Виды потерь информации.
* Обобщение. Все, всегда, никогда, как обычно. На практике есть конкретная ситуация.
* Упущение. Лучше, Хуже, Самый, Сложно, Надо, Невозможно, Не сработает - какие основания, почему лучше. Невозможно обычно - я не знаю способа. Задача "оптимизировать" - по каким критериям, а то увеличили скорость, а надо было уменьшить память.
* Искажение. Номинализация (глагол превращается в существительное, рефакторинг или техдолг), Форма глагола (сделать что-то или поработать над чем-то (бесконечно)).

Как восстанавливать.
* Разделять: вы понимаете или у вас иллюзия понимания.
* Анализ структуры речи до содержания. По форме можно многое понять. Слышишь "это лучше" - спрашиваешь критерии
* Восстанавливать пропущенное (критерии сравнения, убеждения, ценности) - почему считаем так, а не иначе, кому ты должен
* Приводить к разделяемым критериям - факты, по которым мы будем согласны.
* Бонус: видеть карту мира говорящего. Вы будете понимать, что ему важно.

Ключевые идеи доклад.
* Информация неизбежно теряется при передаче
* Объем уточнений зависит не от вас, а от собеседника
* Понимание - активная функция
* Понять за другого - невозможно. Можно только дать доступ к информации
* Смысл коммуникации - чтобы получить обратную связь

Чек-лист на коммуникацию.
* Понимать чтобы что. Зачем я в этой коммуникации. Выплеснуть эмоции - нужен ли собеседник.
* Подстроиться под человека, попасть в его ритм и его цели.
* Передача на языке собеседника
* Сверка понимания. Ты задачу понял, скажи как - не слишком хорошо, лучше "Давай сверимся, я хочу понять, правильно ли рассказал"
* Восстановление информации. Хочешь-то ты чего? Каковы цели другого

Анастасия Артамонова. 10 «синдромов» в одной команде. Всегда была ситуация, когда человек навешивал на себя ярлык, чтобы получить плюшки, которые этот ярлык несет, но при этом не выдавать результатов, которые ярлык требует. Например, рыцарь, который подвигов не совершал и не собирается, а эмулирует. А в последние годы появился другой подход - навесить на себя ярлык особенного и достойного жалости, чтобы меньше работать за те же плюшки. Конечно, ложные нищие были всегда, но сейчас увеличилось разнообразие особенностей. В докладе Анастасия рассказывала про конкретные ярлыки - интроверты, прократинаторы, трудоголики, все - токсичные, я - самозванец, я выгораю, социофбушки, депрессивные, спасатели, не в ресурсе. Показывала, ради чего ярлыки навешивают - что ожидают и чего избегают за счет ярлыка, и как отличать ярлык-симулякр от реальной ситуации, потому что и депрессия и трудоголизм и все остальное - существуют. Просто ложный интроверт или социофобушник не может общаться по работе, а на корпоративе его интроверсия пропадает. Ложный трудоголик или спасатель демонстрирует шаблон поведения, но не выдает результата. Выгорающие или депрессивные или те, кто не в ресурсе рассчитывают на снисхождение в рабочих вопросах, но на корпоратив - всегда готовы. И так далее. Как с этим бороться? Не играйте в эту игру, лишите выгод - спектакль закончится. Только надо отличать симулякры от тех, у кого реальные проблемы, и об этом тоже были признаки.

Собрал и и немного дополнил свои заметки с прошедших только что в Питере Highload и Teamlead в отчет https://mtsepkov.org/Highload-2022-Spb Конференции прошли спокойно и конструктивно. На обеих было много интересных докладов и общения.

Три дня я в Ереване на SQAdays EA и AnalystDays EA. Как обычно, публикую заметки с докладов. Alexey Alter-Pesotskiy из Stream. Let's test openely. Неожиданный подход Open testing, когда разработка тестов для продукта массового использования вынесено в сообщество пользователей, в то время как сам продукт разрабатывает команда разработчиков и исходный код закрыт. Речь идет про Steam Chat - сервис обмена текстовыми и голосовыми сообщениями, встроенного в платформу Steam и не существующего отдельно - он дает дополнительный функционал для тех, кто использует платформу. Почему возникло такое решение? С одной стороны, функциональность - дополнительная, и потому обычная разработка тестов внутри неизбежно будет по остаточному принципу, что скажется на качестве. но. с другой стороны, для пользователей функциональность важная, поэтмоу качество - важно. Open testing позволяет привлечь из сообщества тех, для кого качество чата важно. Понятно, что они должны еще уметь писать тесты, но таких достаточно много. И они достаточно креативны, чтобы придумывать и писать сложные тесты. Есть риски - по доступу, включая историю git и логи CI, по знанию backdoor, которые сделаны для тестирования - их могут попробовать использовать на проде для других целей, по тому, что пользователи будут понимать - как оно на самом деле с тестированием и надежностью продукта. И риски - оправдываются. При этом доступ предоставляется не любому желающему анониму. В докладе были архитектурные схемы инструментов и компонентов, обеспечивающих flow разработки и тестирования дя открытого тестирования, примеры pipeline и так далее, много техники. Это надо смотреть в презентации.

Первый слот SQAdays EA я делал выбор между докладом Joel Oliveira "Don't get exhausted! Be wiser!" и Антона Семенченко "Слои, модули и шаблоны проектирования в контексте AQA". Антона я знаю давно и слышал много раз, а у Joel было очень заманчивая аннотация доклада, и я сделал выбор в его пользу. В чем раскаиваюсь, потому что, увы, это доклад без содержания.

Основной тезис Joel - очень правильный. Исчерпывающее тестирование (exhaustivу testing) - невозможно, это надо признать и не истощать бесполезно свои силы, тестировать разумно, а не на убиваясь. И в этом помогут инструменты. На этом содержание, увы, кончилось, дальше был рассказ в метафоре набора инструментов, которые должны быть клевые и нужные, а не старые и ржавые, и при этом ими не надо увлекаться и набирать слишком много. И в числе инструментов должны быть методики тестирования. Все это правильно, но без методик и примеров, как именно за счет этого обеспечить разумное тестирование - бессодержательно. Было правило Парето про 80-20 в разных вариантах: 80% багов в 20% модулей, 80% пользователей используют 20% фич и так далее, но опять-таки как это использовать, чтобы сократить объем тестирования - не показано, ведь в силу общности этого правила его можно применять несколько раз, пока ты не останешься с единственным тесткейсом на одну фичу. И для меня отсутствие содержания не спасали клевые картинки и шутки докладчика...

Так что я в не выдержал и ушел на доклад Антона. У него тоже был высокий уровень абстракции и общих подходов, и большие списки шаблонов программирования, но при этом, в отличие от доклада Joel было много конкретных примеров, применения этих паттернов для целей тестирования, в том числе сложных. Например, про Singleton - хотя он антипаттерн, для тестирования очень уместен. И? например, Web-драйвер лучше реализовать через него, а для параллельного тестирования можно реализовать установку на уровне пула потоков. Или про рефакторинг: чаще всего from conditional to polimirfism и обратно, и это приземлено на примеры, начинается все с малого числа кейсов и применяем if, а как увеличивается - берем Фаулера и по нему делаем полиморфизм. А когда проект становится зрелым и становится понятно, что в каких-то точках вариативности не будет - сворачиваем назад от полиморфизма к простому коду с условиями. Но, к сожалению, поскольку пришел только на вторую половину, целостный конспект не получается. Буду смотреть доклад, он интересный и содержательный.

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

Параллельно со сменой системы они анализировали и меняли процессы. В общем, с процессами были проблемы, включая ситуации, когда для новой нормативки приходилось выкладывать сырой релиз. Тут сделали скоринговую модель для оценки рисков и quality gates на процессе, дайджесты. Правда, тут сильно не хватало деталей, было интересно посмотреть эту модель и ее применение. Понятно, что все в деталях рассказать не успеешь, но пара примеров была бы интересна. Кстати, и про решенные проблемы тоже было бы интересно услышать конкретные примеры, может, люди узнают свои и тоже запустят смену платформы. Впрочем, в кулуарах детали можно было узнать.

А дальше была часть про технологии, и тут очень нетривиальный момент: новая платформа была в микросервисной архитектуре с контейнеризацией. Раньше подобные решения практически блокировала безопасность, а в рамках этого проекта они научились это проходить. И теперь есть прецедент не только для тестирования, но и для применения другого софта на той же архитектуре.

Очень хороший доклад Натальи Савастюк Обратная связь и самомотивация, которая опиралась не только на свою практику, но и на опросы людей о том, что они ожидают про обратную связь, и это тоже было на слайдах. Доклад вызвал у меня размышления, и дальше будет не только конспект, но и мои ремарки.

Стартовый тезис - очень обидно, когда люди увольняются просто потому, что им не дают обратную связь. Особенно лиды. Людям нужна обратная связь, только 4% говорят, что не получают и им не нужно. 46% получают достаточно, а остальные не получают вообще или получают недостаточно.

Но людям нужна разная обратная связь. Есть простой тест - вопрос "Ты хороший тестировщик? Почему?" Ответы делятся на две категории: с внутренней референцией - ответственно подхожу к работе, успеваю, делаю чек-листы; и с внешней референцией - хвалит лид,разработчики не жалуются, баги берут в первую очередь и так далее. Люди с внутренней референцией сами оценивают свою работу. Людям с внешней референцией нужна позитивная обратная связь - от руководителя, команды, более опытные специалисты, пользователи.

Я тут отмечу, что деление ответов по внутренней и внешней референцией хорошо соответствует делению людей на Интровертов и Экстравертов по Майерс-Бриггс (в других типологиях деление может отличаться), а по Майерс-Бригс есть статистика, что люди делятся примерно пополам. Казалось бы, это противоречит результатам опроса, но дальше в подробностях видно, что противоречие кажущееся, потому что среди той половины, которая получает обратную связь и удовлетворена ей достаточно много получают обратную связь очень редко, иногда, и удовлетворены ей - интероверты в том числе в этой группе, а не только среди 4% не желающих обратной связи.

Интересно, что группа, которая получает достаточно обратной связи - выделили коллег и подопечных. А вот те, кто считают, что не хватает - их не выделили, и проектного менеджера тоже не выделили - они видят обратную связь лишь от руководителя. Впрочем, при получении обратной связи надо быть разборчивым. Был случай, когда Head HR заявил тестировщику "твое профразвитие тестировщика закончилось, идите в проектные менеджеры". Девочка не проработала 2 лет, и ясно, что перспективы есть - просто Head HR не специалист. Она уволилась, наверное, туда, где увидят перспективы развития. Понятно, что в этой ситуации стоит разобраться с профессионализмом Head HR, но вообще когда слушаете обратную связь - оценивайте компетентность того, кто ее дает.

Как часто надо давать обратную связь? Два отчетливых пика: раз в месяц и "по каждой мелочи спасибо, молодец" - это среди тех, кто не получает, остальные варианты меньше. Из тех, кто получает - треть получают ежедневно, и еще треть - иногда. А дальше по 14% "в работе", ежемесячно, и реже.

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

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

Обратная связь - реакция, сигналы или информация о совершенных или несовершенных действиях, сказанных словах и эмоциях. Дают люди, система (падение системы - обратная связь) и вы сами. Что делать - решаете сами, можно заметить и что-то менять, можно заметить и не менять, и можно не заметить.

Алгоритмы похвалы и выговора для личных бесед.
* Важно конкретно рассказать
* Использовать факты, убрать гипотезы и интерпретации
* Рассказать о своих эмоциях и чувствах
* Объяснить негативные и позитивные последствия
* Объяснить ожидаемый в будущем результат.
Упражнение. Дать негативную обратную связь на пропущенный баг, и позитивную. Выполняется втроем: один дает, второй - получает, а третий - следит за алгоритмом.

Очень важно. Людям с сильной внутренней референцией обратная связь не слишком нужна. Отмечу, что это тоже известно из типологии Майерс-Бриггс, и там исследования показывают, что обратная связь им нужна разная: экстравертов перехвалить невозможно, они принимают высокие оценки как должное, а вот интраверты относятся к частой похвале настороженно, начинают искать в ней скрытые мотивы "не с проста он меня хвалит", и это необходимо учитывать, давая обратную связь.

Должна ли быть легкая критика в позитивном фидбеке? 57% - да, еще 30% - нужно, но осторожно; обязательно и нет - по 7%. Так что в целом - нужно, но помните, что треть людей - ранимые, и это надо учитывать.

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

Вывод для всех: если нужна обратная связь - не ждите, а придите и заберите.

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

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

Я тут отмечу, что колесо баланса - очень спорно, потому я знаю людей, сфокусированных на работе и не выгорающих, и вообще работа для высокого смысла без выгорания часто встречается. Конечно, спецы на это отвечают "у них такой баланс". Но мое мнение - другое. колесо баланса - для ситуации, когда работа является у тебя каторгой, высасывающей энергию, ты накапливаешь эту энергию за счет других активностей и отдаешь на работе. На мой взгляд, это - ситуация прошлого, когда работа - для зарабатывания денег, а позитив получаешь в другом месте. А сейчас тут надо просто менять работу, искать место, которое будет давать энергию, такая возможность в ИТ точно есть при дефицитном рынке персонала. Впрочем, у конкретного человека вполне может быть и другой выбор, просто надо представлять себе спектр и не думать, что хорошей работы, которая дает драйв и энергию не бывает. Хотя, конечно, с драйвом есть другая опасность, ты реально забываешь о восстановлении, получая драйв, и выгораешь, но другим образом. но тут надо решать другую задачу. Не "спать 8 часов, потому что колесо баланса велит", а "спать столько, чтобы силы достаточно восстанавливались для физиологически продуктивной работы". И "Не уделять детям (семье) достаточно время и внимания, потому что так положено", а "эффективно выделять время и внимание для выполнения принятых в долгую обязательств, которые принял, создав семью и заведя детей, явно или неявно". Подобные постановки в статьях и книгах по колесу баланса я не встречал, хотя, может, я недостаточно их читал.

Егор Шагаев. Используем OpenShift для нагрузочного тестирования. Короткий доклад о том, что вместо подъема новых виртуальных машин с JMeter можно использовать OpenShift для подъема новых контейнеров. Конструкция собирается из
* OpenShift - платформа контейнеризации
* JMeter - машинка нагрузочного тестирования
* InfluxDB - база данных метрик
* Grafana - визуализация
В OpenShift делаем JMeter мастер и много Jmeter Slave: мастер контролирует нагрузку, а Slave - ее запускают. Тестируемые приложения, а также Grafana могут быть внутри Open Shift или снаружи.

Когда нужно? Когда тестировщиков - несколько и вы хотите централизовать запуск тестов - можно на открытых средствах сделать то, что дают дорогие платформы. И когда есть административные ограничения на заказ виртуальных машин, заявки долго согласуются, а поднять квоту в Open Shift можно относительно просто.

Далее была короткая запись демонстрации интерфейса OpenShift с комментариями, что происходит.

Karo Sarkisyan. Сейчас или никогда: Универсальная стратегия уничтожения зомби-багов. Типичная ситуация при быстром развитии: фокус на разработку новых фич, а некритичные баги копятся и копятся. В какой-то момент их становится слишком много, и уже в статистике сложно разобраться, отделив старые зомби от новых багов. Zombie - баги, которые висят без движения долго, полгода и больше. Их средства борьбы
* Каждый баг имеет владельца
* В 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, как правильно создавать сессию, чтобы не заботиться о закрытии, как записывать видео и трейсы.

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). И надо тестировать гипотезы - формулируем предложение, в которое верим, и проверяем.

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

Сразу за 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.

Параллельно на первом слоте был доклад Aleš Štempihar из Словакии БА как бизнес-консультант - есть ли у БА потенциал стать чем-то большим, чем просто ИТ-специалистом. Он прошел путь от бизнес-аналитика до стратегического консультанта. Я пришел ближе к концу, но хочу отметить, что доклад - интересный. Хотя Алекс рассказывал именно свой путь, но этот путь соответствует тому, что происходило в отрасли, какие именно вызовы ставились и решались. Например, 2008-2018 был период lanced Scored Card и аналогичных изменений, а с 2018 - Dogital Transformation. И, во-первых, интересно проверить себя на понимание всего этого, а, во-вторых, разные отрасли и компании развиваются в разном темпе и вполне возможно это придет, хотя с отставанием. Хотя, конечно, хотелось бы чтобы в докладе было больше раскрыт характер задач и польза, наносимая компанией их решением, а не просто обозначение решаемой проблемы. Впрочем, я слушал небольшой кусочек. Может. кто из присутствовавших напишет подробнее.
Ну и вы ретроспективно можете прикинуть: а может, вы тоже могли бы это решать, и, может, стоит уйти в консультанты? Я про себя из тесного знакомства с бизнес-консультантами и наблюдения за их работой, участия в проектах знаю, что это - не совсем мое, но люди - разные.

Екатерина Кушнир. Делегирование – важный навык каждого аналитика. Передаем задачи и ответственность правильно. Основная мысль - если у вас большая задача или даже целиком ответственность за функциональную область, то надо делегировать задачи. Это, во-первых, часто сокращает время, а, во-вторых, перестает делать вас незаменимым. Ведь незаменимые не могут болеть и уходить в отпуск, и должны перерабатывать, если задач много, а это ведет к стрессу и выгоранию вместо радости и развития.

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

Делаю большую задачу. Когда стоит делегировать: не успеваю в оговоренные сроки, не успеваю делать другие задачи, из-за ограничений по времени в связи с другими активностями. Если вы отвечаете за функциональную область - делегировать обязательно. Удобно, что вы все знаете. Но есть риски для команды, когда вы выпадаете, и для вас - если область уйдет из проекта. Без делегирования вы ограничиваете свое развитие. Маячки для делегирования: есть риски для репутации или ограничения по сроком.

С делегированием связаны страхи: не хочу делить похвалу, потеряю ценность, задачу сделают плохо. Тут надо понимать: брать ответственность и делать самостоятельно - разные вещи. При делегирование именно вы продолжаете обеспечивать результат перед руководителем - и можно выделать не целиком, а частные задачи. Например, нарисовать схему процесса.

А вдруг сделают задачу плохо? Но вы же передаете не кому-нибудь. Вы передаете тем, кто мотивирован, ему будет полезно для развития, и сможет сделать. Оба - не встречаются, достаточно только одного. И надо учитывать, и понимать, как это скажется при выполнении. Я отмечу, что тут принципиальное противоречие: если задача полезна для развития, значит человек ее не делал - и нет гарантий что сможет, то есть оба пункта не достижимы в принципе. Но поскольку Екатерина говорит, что достаточно одного, то это неважно.

Когда мы делегировали - у нас появляется время. И у нас появляется время для других задач и собственного развития. Замотивированная команда, задачи выполнены в срок, вы проявили лидерские качества.

Как делегировать? Вы смотрите по задачам, какие можно делегировать. Дальше - обсуждаете с руководством, что вы хотите делегировать и ценность для проекта от такого решения. И если оно согласилось - то обсуждаете с человеком. Если руководство возражает - то сразу обсуждаете риски, обычно получается, что не уложимся в сроки - и пусть руководство эти риски принимает. Можно обсуждение с руководителем и сотрудником менять местами, если вы предполагаете, что руководитель одобрит. Но совсем пропускать обсуждение с руководителем - не стоит.

Что делегировать нельзя? То, в чем не разбираетесь. Вы не сможете их правильно делегировать. А еще - это полезно для вашего развития. Хочу отметить, однако, что, если вы заботитесь о сроках проекта и в команде есть способный эксперт именно для этой задачи, то делегирование может быть уместно. Обычно это ситуация, когда вы отвечаете за функциональную область целиком, и в ней прилетела нетипичная или очень сложная для вас задача. Конечно, наломать дров и разобраться для вас - полезно, а для проекта - не всегда. Умение во-время запросить помощь эксперта - важный навык, встречающийся не часто.

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

Про сроки. Вы даете +50% к вашей оценке - потому что делаете не вы. И надо закладывать на ревью. Ревью нужно, даже если задачу делает эксперт потому что исполнитель не владеет всем контекстом. Например, передали нарисовать sequence-диаграмму по написанному сценарию, потому что он классно рисует и любит это. Но не факт, что он при этом поймет сценарий адекватно, диаграмма может получиться красивой, но с ошибками.

Делегирование - инструмент карьерного роста. Чтобы расти - надо брать ответственность. Риск для репутации и ограничения - повод делегировать. Сами выбираем что и кому делегировать. При правильном делегировании - все участники выигрывают. А если кто-то не доволен - значит где-то ошиблись.

Alena Demysheva из Quantori. Не надо стесняться: как коммуницировать с теми,кто знает больше тебя и не чувствовать себя студентом. Вы хотите перейти в другую область - но вы сомневаетесь, ведь там вы не специалист, окажетесь в позиции начинающего. Она 1.5 года назад из eCommerce перешла в Life Science, сейчас делится опытом.

На первой встрече просто молчала - потому что поняла процентов 20. Потом все-таки решила задач, и попробовала интегрировать слова эксперта. И в конце пообещала стандартные сроки, плюс не вела аудио-запись, только notes- а в терминах путаница. Был провал. Вторая попытка - погружение в домен. Стихийно. Попробовала охватить 10-летнюю программу за неделю. И это тоже не получилось. Плюс обесценила опыт бизнес-аналитика. И не использовала компетенции анализа при изучении. А еще - не спрашивала экспертов компании, хотела сама разобраться. Переработки, срыв сроков, выгорание. Подумала о смене. Но все-таки было жаление идти в этот домен.

И она изменила подход.
* Подготовка к встрече: Выписать пункты гордости (два высших, грант для компании), выписать прошлые ошибки и решения ситуаций - дает опору и уверенность
* Коммуникации на встрече: предупреждает о волнении - первый проект в новой области, это настраивает собеседника; переформулирование тезисов эксперта "я правильно поняла, что ..." - доверие; "Простите, что дублирую"; Благодарность за ответы; Выбрать удобный эксперту канал для продолжения коммуникации
* После встречи отправить meeting notes - чтобы получить обратную связь, исправление формулировок.

Погружение в домен как проект
* Структура погружения в домен
* Приоритеты
* Декомпозиция задач
* Словарь, и его согласуешь с экспертом - там есть тонкости
* Просить помощь экспертов и коллег

В результате: укладываемся в сроки, быстрая адаптация, хорошее самочувствие и уверенность и даже предложение улучшений.

Напоминание, поставила каждый день: "Сделанное лучше идеального не сделанного" - борьба с перфекционизмом.

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

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

Для начала были определения.
* Тревога - чувство внутреннего беспокойства в ответ на реальную или мнимую систему с реакцией вегетативной нервной системы (сердцебиение, потливость и так далее).
* Страх - нормальная психологическая и физиологическая реакция на действительную угрозу или опасность или ее предчувствие. Там где предчувствие опасности - Страх и Тревога может смешиваться. Но тревога - она и про мнимое тоже
* Фобия - чрезмерная и беспричинная степень страха под воздействием или ожиданием особого объекта или обстоятельства
* Депрессия - стойкое (недели+) снижение настроения, утрата интересов и способности получать удовольствие с повышенной утомляемостью. И там - сложный медицинский вопрос. Входим постепенно, можем не заметить
* Стресс - состояние психологического и физического напряжения в ответ на внешнее воздействие, это - нормально
* Стрессоустойчивость - способность переживать стресс

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

Таблица стрессоустойчивости Холмса и Раге. Разработана, чтобы при приеме на работу или назначении на ответственную должность понимать - выдержит или нет. Там баллы по поводу каждого стрессового случая, и ты ставишь галочки, что у тебя в жизни есть. При переезде согласия с семьей и близкими добиться почти невозможно. Например, дети - он уезжаешь от друга. Заполните таблицу для переезда. Если значение будет близко к пороговому - повод задуматься. Потому как еще в проекте что-то пойдет не так - и будет тяжело.

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

Hospitalal anxiety and depression scale. 14 пунктов, 4 варианта ответов. 0-7 - нома, 8-10 субклинически, больше - клинически. Анкета используется в медицине - можете сделать самооценку.

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

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

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