Собрал и и немного дополнил свои заметки с прошедших только что в Питере 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, который маршрутизирует запросы. А новое пишем в сервисы.

И в конце были критерии выбора
* На стадии 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.