Просмотр исходного текста страницы Блог:Максима Цепкова/2022-10-12: SQAdays и AnalystDays в Ереване - общение через границы

{{Conf-Ref}}

Неделю с небольшим назад, 31.09-02.10.2022 в Ереване прошли две конференции — [https://sqadays.eu/ru/program/99290 '''SQAdays-EA'''] и [https://analystdays.eu/ru/program/99243 '''AnalystDays-EA''']. Влад Орликов сделал площадку общения между ИТ-шниками, которые оказались в разных странах ввиду современной геополитики. Это реально удалось, хотя участников было и не слишком много. На конференции было много международных спикеров, она шла на русском и английском с синхронным переводом в обе стороны. И я хочу отметить не только активное общение, но и спокойную, ламповую обстановку. И общий позитив. Может быть, это просто влияние малого числа участников. А может быть, еще сказывается аура города — в Ереване нет той суеты, которая очень характерна для Москвы, да и в Петербурге и Минске проявляется. Я тут отмечу, что большинство активностей на конференции как раз инициирует всякую движуху, а может быть реально стоит именно замедлиться. При этом, что интересно, эта спокойная обстановка не мешала участникам общаться на стендах, проходить квесты, получать призы. Просто это делали более спокойно.

Это об общих впечатлениях о конференции. В конце отчета будет несколько технических моментов для тех, кто планирует этой осенью еще поучаствовать в конференциях в Ереване. А в целом — спасибо Владу Орликову за организацию комфортной и позитивной конференции в это непростое время.

Я сам активно общался на конференции, встретился с многими знакомыми и познакомился с новыми людьми. А потом еще три дня смотрел Ереван в компании с некоторыми другими участниками, которые тоже спланировали посмотреть город. Я там был первый раз, мне интересно.

Выступать у меня планов не было, но на SQAdays-EA выступил с экстренной заменой [[Самоопределение: чего я хочу от жизни и работы (SQAdaysEA-2022)|'''Самоопределение: чего я хочу от жизни и работы''']]. На AnalystDays тоже был готов к выступлению, но не потребовалось.

А теперь — заметки с докладов, которые я публиковал в ходе конференции. Они - в том порядке, в котором я их слушал, но я хочу отдельно отметить доклады Натальи Савастюк про обратную связь и самомотивацию, Антона Семенченко про проектирование AQA и про и релокацию и стрессоустойчивость с простыми методами самодиагностики, Алены Демышевой про освоение новой предметной области, Татьяны Половинкиной про D5 - Domain Driven Design и Data Driven и Екатерины Лысенко про риски.

= SQAdays =

== Первый слот: Joel Oliveira или Антона Семенченко ==

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

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

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

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

== Alexey Alter-Pesotskiy из Stream. Let’s test openely ==

Неожиданный подход Open testing, когда разработка тестов для продукта массового использования вынесено в сообщество пользователей, в то время как сам продукт разрабатывает команда разработчиков и исходный код закрыт. Речь идет про Steam Chat — сервис обмена текстовыми и голосовыми сообщениями, встроенного в платформу Steam и не существующего отдельно — он дает дополнительный функционал для тех, кто использует платформу. Почему возникло такое решение? С одной стороны, функциональность — дополнительная, и потому обычная разработка тестов внутри неизбежно будет по остаточному принципу, что скажется на качестве. но. с другой стороны, для пользователей функциональность важная, поэтому качество — важно. 

Open testing позволяет привлечь из сообщества тех, для кого качество чата важно. Понятно, что они должны еще уметь писать тесты, но таких достаточно много. И они достаточно креативны, чтобы придумывать и писать сложные тесты. Есть риски — по доступу, включая историю git и логи CI, по знанию backdoor, которые сделаны для тестирования — их могут попробовать использовать на проде для других целей, по тому, что пользователи будут понимать — как оно на самом деле с тестированием и надежностью продукта. И риски — оправдываются. При этом доступ предоставляется не любому желающему анониму. В докладе были архитектурные схемы инструментов и компонентов, обеспечивающих flow разработки и тестирования для открытого тестирования, примеры pipeline и так далее, много техники. Это надо смотреть в презентации.

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

А я вспомнил, что в 2013 на SQAdays в Питере слушал доклад Рины Ужевко, как она организовывала тестирование online-игры Мое королевство силами игроков. Кому интересно — можно почитать [[Блог:Максима Цепкова/2013-04-29: SQAdays-13 (весна 2013)|мой отчет]] или посмотреть [https://sqadays.com/ru/talk/7774 сам доклад].

== Роман Колташов и Евгений Щеголяев из ПСБ. Импортозамещение системы тестирования ==

Роман Колташов и Евгений Щеголяев из ПСБ рассказывали про импортозамещение системы управления тестированием. Проект — интересный. Ситуация была стабильной, импортной системой люди были в целом довольны, там 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 (Джим Калбах). Интернет говорит, что у подхода Jobs-to-be-done есть несколько версий. Подход основан на том, что пользователь (потребитель) всегда покупает работу (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) — frustration by (pain) — our solution (product or service) — offers (capacity to solve) — unlike (alternative)'''. И надо тестировать гипотезы — формулируем предложение, в которое верим, и проверяем.

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

= AnalystDays =

== Татьяна Половинкина. Система 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 Scientist, BI. Data Engineer — далеко не всегда понимает смысл данных, он как дизайнер — умеет располагать и сжимать. Несколько лет назад была аналогичная проблема с админами — появились DevOps. Тут тоже будет решение.
* От логики к инструментам. Есть много методик, с разными подробностями. Но во всех общий принцип, что начинаем двигаться от бизнес-логики, и можно просто именно это и делать. Я тут согласен, а если у заказчика есть любимая методика — то надо просто быстренько прикинуть, как то, что вы делаете, брендировать этим способом — потому что очень многие методики — очень тяжеловесны и не жизнеспособны. При этом, естественно, никто не запрещает взять из методики полезное.

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 из Словакии. БА как бизнес-консультант — есть ли у БА потенциал стать чем-то большим, чем просто ИТ-специалистом ==

Параллельно на первом слоте был доклад Aleš Štempihar из Словакии «БА как бизнес-консультант — есть ли у БА потенциал стать чем-то большим, чем просто ИТ-специалистом». Он прошел путь от бизнес-аналитика до стратегического консультанта. Я пришел ближе к концу, но хочу отметить, что доклад — интересный. Хотя Алекс рассказывал именно свой путь, но этот путь соответствует тому, что происходило в отрасли, какие именно вызовы ставились и решались. Например, 2008—2018 был период lanced Scored Card и аналогичных изменений, а с 2018 — Digital 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
* Есть сайты — статистика преступлений по городам и районам. Посмотрите
* Был в Алма-Ате. Оказывается есть подвох. Много ломбардов. Посмотреть, кто туда входит — и увидеть кто входит. Оказывается много групп молодых людей приносят телефоны — откуда они?
* Зайти в любую травму и посмотреть кто. Не разбито лицо и тяжело раздроблена правая рука — значит начали кого-то бить, он увернулся и попали на по асфальту. Значит с детьми туда ехать не стоит.

Что дальше? Есть три книги, которые рекомендуются тем, кто хочет
* Джекобсон Секреты психиатрии
* Маккей, Скин, Фаннинг. Когнитивно-поведенческая терапия для преодоления тревожности, страха, беспокойства и паники
* Франц Александр Психосоматическая медицина: принципы и применения

== Алексей Романов и Екатерина Романова. Разговор Архитектора и Product Owner: Как понять, что нужно переходить на микросервисы? ==

Очень интересная форма подачи доклада — это разговор Product Owner в выдуманной небольшой компании, которая online продавала билеты на offline-мероприятия в регионах, и у которой был монолит, и которая решила стать еще и организатором online-мероприятий с выдачей сертификатов, продажей записей, нужно развивать личный кабинет участника и организатора, да еще выходит на международный рынок, и потребуется интеграция с разными платежными системами, с архитектором, которого позвали на развитие системы. В докладе было про плюсы и минусы перехода на сервисную архитектуру.

В чем проблемы монолита?
* С ростом системы увеличивается сложность.
* Требуются аппаратные ресурсы для увеличения производительности
* Сложность рефакторинга и внедрения новых технологий — будет не хватать производительности стека.
* Любые изменения требуют повторного тестирования и развертывания
* Невозможность параллельной работы большого количества человек с одной кодовой базой — сильная связность, сложные merge
* Большая стоимость архитектурных ошибок — архитектурные ограничения

Если распилить монолит на несколько независимых микросервисов.
* Писать проще, чем большой монолит
* Горизонтальное масштабирование и отказоустойчивость
* Уменьшается вероятность ошибок, так как тестировать маленький функционал проще. Проще понять.

Что такое микросервисная архитектура? Модульный подход, основанный на слабозависимых заменяемых компонентах. Сфокусированные, сервис выполняет свою задачу, например: сервис подписи сертификатов. Слабосвязанные, изменения в одном требуют изменений в другом. Высокосогласованные — содержат все нужные методы. И маленький.

В чем плюсы для конкретного решения?
* Большая стабильность. Падение одного сервиса не затронет другими, падение сертификатов не затронет видеотрансляции или продажу билетов.
* Разнообразие технологий
* Меньшая стоимость ошибок, можно сервис выкинуть и переписать

Минусы
* Время коммуникации по сети на взаимодействие
* Нужна хорошая система деплоя и развертывания новых виртуальных машин. Пока 3-4 можно без них, когда 20 — нет.
* Хорошее описание API между сервисами. Публичный контракт, держим консистентным.
* Отказоустойчивость не только сервисов, но и сети.
* При проектировании обрабатывать разрушения отдельных сервисов.
* Сложность декомпозиции из-за сильной связанности данных.
 
Вот тут я хочу сказать, что если посмотреть на минусы, то они уничтожают плюсы. Например, остальные части системы работают при падении одного сервиса, но появляется больше точек отказа, включая сеть. А забота о консистентности обработки в случае отказов, если задействуется несколько сервисов сильно увеличивает сложность разработки, и требует понимания межсервисного взаимодействия. Так же увеличивается сложность построения комплексных запросов по данным. которые в монолите лежат в одной базе. Таких пунктов много. И они в докладе, в общем-то не обозначены, а в результате оптимистичные ожидания вполне могут оказаться неверными. Вообще про грабли микросервисной архитектуры неделю назад был хороший доклад Филиппа Дельгядо на Saint Highload, у меня на сайте есть [[Блог:Максима Цепкова/2022-09-29: Saint Highload и Saint Teamlead - рабочая обстановка|конспект]].

Что меняется в разработке?
* Появляется DevOps — отдельная компетенция
* Декомпозиция задачи по сервисам, с ответственностью команд за отдельные сервисы. Нужно согласование API между командами.
* Хотя команды изолированы, есть взаимодействие.

Как переносить? Сохраняем монолит, откусываем кусочке. Поверх — dispatcher, который маршрутизирует запросы. А новое пишем в сервисы.

И в конце были критерии выбора
* На стадии MVP или Proof of Concept — монолит. Если есть четкое понимание, как будет развиваться приложение — сервисы.
* Если понимания дальнейшего понимания есть — можно пока жить на монолите. Но писать осторожно, думая, что может переехать.
* Если есть понимание высоконагруженных частей — их надо выносить отдельно
* Развертывание монолита проще, но вообще есть много инструментов.
* Если часть временная — то можно выносить в отдельные сервисы. Потому что в монолите разработчики могут переиспользовать
* Консистентность — если есть такие задачи, то либо монолит, либо выделение консистентной части в один сервис.
* Но при этом хранение больших объемов данных лучше выносить в сервисы, чтобы можно было сменить технологию БД.

== Анастасия Соболева. Трудные диалоги в жизни аналитика ==

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

Для каждой из команды брать доработку рискованно. При этом команда А начинает работать с заказчиком и хочет увеличивать присутствие, а команда Б — давно работает, обе заинтересованы в присутствие. Безопасность ссылается на требование регулятора, но там нет жесткой обязательности, при этом она не заинтересована в продукте — им надо подложить соломку. А заказчик требует сроки, потому что уже купил рекламу, и им не важно конкретное решение.

Дальше выписывают варианты решения и возможный 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.

== Екатерина Лысенко. Сколько благородства в рисках? ==

Прекрасный доклад о том, как заниматься рисками. Под «заниматься» в докладе имеется ввиду порождение списков потенциальных событий, которые влияют на проект и обсуждение нашей готовности их пережить, включая принятие риска: «будут бить — будем отбиваться». Есть еще варианты работы с рисками, я о них напишу в конце, а пока — конспект доклада.

Фразы «риск — дело благородное», «кто не рискует — не пьет шампанское» Екатерину всегда смущали. В рисками надо работать, и эта работа очень близка работе с багами, которые тоже случаются. Баг — частный случай риска.

Риск не всегда несет угрозу, как и стресс. Есть дистресс: все плохо и мы все умрем, и эустресс: все плохо, но мы всех победим. Так и события — одни несут угрозу, а другие — открывают возможность, и надо быть готовым ее подхватить. Цель управления рисками — за все хорошее и против всего плохого.

Что достигается путем работы с рисками?
* Возможность более точного определения срока и границ проекта. Это не про курсы, где учат «что будет, когда сломает ногу», «что будет, если не хватит финансирование» — не анализ не провели, или команду не набрали. Рисками занимаешься в истории от полугода (в старой реальности)
* Гибкость планирования и построения стратегии — про риски ты думаешь, и у тебя появляются сценарии. И не только на работе, но и в жизни. К сожалению или к радости — непонятно, иногда это как паранойя, а иногда выручает.
* Повышение прозрачности на уровне компании
* Сокращение числа инцидентов — вы об этом подумали
* Качество взаимодействия
* Качество взаимодействия между бизнес-подразделениями и разработкой — увеличивается понимание
* Формирование ценностного подхода на корпоративном уровне

Комикс из Дилберта, по-моему. Я оценил шансы что все пройдет гладко 70 %. То есть когда провалится — ты признаешь, что был неправ? Но я только оценил шансы… Если у руководства такое отношение, то работать с рисками бесполезно. Риск менеджмент — это не игра в одни ворота. Риск — у компании, любой риск — твой риск. Нельзя заниматься в позиции эксперта. Риски приводят нас к необходимости анализировать, а это — ретроспективные практики. Самокопание, умение признавать собственные ошибки и далее — права на ошибку.

Типизация рисков. В разных книгах — по-разному, до 12. У нее — 4.
* Нормативно-правовые: законодательство и т. п.
* Ресурсные Прибыль, время, люди, техника. Риски по технике сейчас увеличились, на Кипре месяц нет поставки клавиатур с русскими буквами, с поставкой серверов, ноутбуков.
* Репутационные. По потребителям, пользователям, контрагентам, сообществам. И может быть положительный риск, представьте вы рассказываете о классной трансформации регламента или условиях работы — и репутацию запоминают. Социально-значимый контекст. Шаттлы, трагедия Челленджера — через два часа Рейган выступил с обращением к нации, и впервые начал «Нэнси и я» — семейная тема, и он нивелировал значительную часть рисков. Несоответствие качеству
* Технические риски: интеграционные, инфраструктурные и архитектурные. Внезапно узнаешь, что железка не отдает количество залитого топлива, а true/false.

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

Как работать с рисками? ROAMboard. Табличка, двигаем по доске: Resolved — Owned (есть владелец) — Accepted (принят участниками) — Mitigated (последствия минимизированы). Что классно? В работе с доской вы приучаете компанию к тому, что вы открыто обсуждаете риски и проблемы, что они должны быть видны всем. И вы начинаете разделять (share) ответственность. Есть антифрод или безопасность, вы показываете, за что они отвечают.

Цикл работы с рисками: Периодическая оценка — Выявление риска — Анализ риска — Оценка риска — Принятие решения.

Разработка продукта — не столько риск задержки разработки, сколько риск не выдержать успех, когда пользователи вдруг массово пришли. Риски могут принимать разные. Астронавт не вернется — принимает он, принимает пиар-служба (а если случится — что делаем) и так далее. Дальше был пример — риск не-выпекания колобка.

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

Атрибуты риска. Не только содержание риска, но название, последствия реализации риска. У одного риска могут быть разные причины — можно раздавать ответственности. Критичность.

Психология. Когда у тебя много проблем в стрессе, ты все равно берешь проблемы. Помогаешь другим, сообществу — чтобы получить подтверждение. А реально начинаешь тонуть.

Про критичность — почитать японские книги про минимализм. Там лучше всего написано. Есть проблема — обведите кружочком, сделайте шаблон, действуйте по шаблону, стало неудобно — поменяйте шаблон.

Обоснование в цифрах. Поддержка говорит «умираем». А выясняется, что два студента пару часов в неделю разбирают — а исправление пара недель рефакторинга команды — и пусть студенты разбирают. С нормативно-правовыми тоже самое, последствия разные: если отнимут лицензию — надо чинить, а если небольшой штраф — можно заплатить.

Триггер. Ситуация, которая должна наступить, чтобы риски сработали. Не обязательно катастрофа. Триггер обычно тоже риск. Можно в ROAM board — связи между рисками. В некоторый момент перейдете от ROAM board к mindmap. Это — следующий этап.

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

== Иван Пашков из AquivaLabs. Паттерны коммуникации с англоязычными заказчиками ==

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

Пересказывать — бесполезно, надо просто смотреть презентацию и доклад.

= Технические моменты конференции =

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

* Были очень большие задержки рейсов, до 12+ часов, особенно FlyOne Armenia. На это еще наложилась отмена Аэрофлотом рейса Питер-Ереван, теперь только через Москву.
* Overbooking гостиниц, а также разное кидалово, когда пишут об отмене ранее сделанного бронирования потому, что отключили воду, а потом номера почти сразу появляются на booking за большую цену (1.5-2 раза). Многие приехали еще посмотреть Ереван, и вынуждены были неделю жить кусочками по 1-2 ночи. Это массово, не у одного-двух человек, минимум у трети из тех, с кем общаюсь были проблемы. Booking как-то помогает найти альтернативы, кому-то удавалось договориться прямо на месте чтобы «нашли номер» за небольшую доплату.
* Карты МИР работают, работает Яндекс-доставка и Яндекс-такси. Но! Яндекс-такси в аэропорту «очухивается» и стартует минут 10-15 через WiFi аэропорта (может, через мобильный я бы тоже дождался, просто я переключился в какой-то момент), до этого заказать не получается — он не видит аэропорт, не видит адрес назначения. При том что в Яндекс-карты Армения загружена.
* Яндекс-такси из аэропорта до центра Еревана — 2000 драм = 300 рублей — там 15-20 минут ехать. Таксисты начинают торг от 2500 РУБЛЕЙ, (в 8 раз), ниже 1200 не опускаются (я пока ждал что Яндекс очухается — слушал альтернативы). Были казусы, когда люди договаривались «за 2500» имея ввиду драмы, а на вопрос получали «нет, это рубли». Были случаи, когда водитель от Яндекс-такси требовал доплаты (в частике, до приезда) 1000 рублей (в три ночи), но со следующим получалось договориться на 200 рублей доплаты.
* Орликов говорит, что они все что можно (полиграфия и так далее) — заказывали и везли из России, с местными договориться не получалось: или космические цены, или никаких гарантий, что тебя не кинут. Не кидают только «своих», которых привел местный уважаемый человек… То есть рынок услуг не развит, говорит даже в 2010 в России было лучше. Он молодец, несмотря на это для участников конфа была очень комфортной.
{{wl-publish: 2022-10-12 09:35:40 +0300 | MaksTsepkov }}