Неделю с небольшим назад, 31.09-02.10.2022 в Ереване прошли две конференции — SQAdays-EA и AnalystDays-EA. Влад Орликов сделал площадку общения между ИТ-шниками, которые оказались в разных странах ввиду современной геополитики. Это реально удалось, хотя участников было и не слишком много. На конференции было много международных спикеров, она шла на русском и английском с синхронным переводом в обе стороны. И я хочу отметить не только активное общение, но и спокойную, ламповую обстановку. И общий позитив. Может быть, это просто влияние малого числа участников. А может быть, еще сказывается аура города — в Ереване нет той суеты, которая очень характерна для Москвы, да и в Петербурге и Минске проявляется. Я тут отмечу, что большинство активностей на конференции как раз инициирует всякую движуху, а может быть реально стоит именно замедлиться. При этом, что интересно, эта спокойная обстановка не мешала участникам общаться на стендах, проходить квесты, получать призы. Просто это делали более спокойно.

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

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

Выступать у меня планов не было, но на SQAdays-EA выступил с экстренной заменой Самоопределение: чего я хочу от жизни и работы. На 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-игры Мое королевство силами игроков. Кому интересно — можно почитать мой отчет или посмотреть сам доклад.

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

Роман Колташов и Евгений Щеголяев из ПСБ рассказывали про импортозамещение системы управления тестированием. Проект — интересный. Ситуация была стабильной, импортной системой люди были в целом довольны, там 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 мастер и много Jmeter Slave: мастер контролирует нагрузку, а Slave — ее запускают. Тестируемые приложения, а также Grafana могут быть внутри Open Shift или снаружи.

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

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

Karo Sarkisyan. Сейчас или никогда: Универсальная стратегия уничтожения зомби-багов

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

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

DD — Data Driven. Тонем в потоке данных, надо как-то разбивать и научиться управлять. Масштабируемость и эволюция в каждом домене. Но! недопоминание и недоверие между доменами. Что делать? Управлять данными, определить то, что производят домены. Data Product — данные, которые нужны другим доменам. Доступные, Понятные, Надежные, Безопасные, Читаемые.

Тут у меня мысль. Есть старая добрая книга Николас Вирт «Алгоритмы + Структуры данных = Программы» (1976). Насколько похоже, что все — как там, только слагаемые надо переставить и уровень абстракции в примерах поднять, чтобы перенести на современные методы? Может, перечитаю ее под этим углом зрения.

Data Domain — децентрализованная распределенная система с малыми зависимостями, не ждем согласований и т. п. Два подхода.

Данные должны иметь ценность. Единообразной методики оценки ценности — нет. Поэтому вам надо самим ее извлекать.

Что меняется с Data Mesh, децентрализацией данных?

И дальше по отдельным направлениям.

Вывод: думай глобально, действуй локально. Глобальное видение — но не оцепенение, а активные действия в области, где можешь.

А вообще можно считать, что эти подходы применял Юлий Цезарь. Разделяй и Властвуй — это про 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: часто смотрим на часы, сопротивляемся выходу на работу, откладываем встречи, избегаем творческого подхода к задачам и так далее — найдите и используйте.

Алгоритм, который советует применить. Шаги — стандартные, а реализация — разная

Tips и Tricks

Что дальше? Есть три книги, которые рекомендуются тем, кто хочет

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

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

В чем проблемы монолита?

Если распилить монолит на несколько независимых микросервисов.

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

В чем плюсы для конкретного решения?

Минусы

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

Что меняется в разработке?

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

И в конце были критерии выбора

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

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

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

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

Radik Adiulin. CustDev в B2B: краткий гайд и уроки после 100 проведенных интервью

Перед тем, как разрабатывать — делают CustDev, чтобы убеиться, что продукт будет востребован. Есть Качественные и количественные исследования, разные способы. В докладе — про CustDev интервью — но процесс custdev этим не исчерпывается. Это лишь часть фазы customer exploratory.

Задача интервью: понять как пользователи принимают решения, в области, где вы делаете продукт

В чем разница b2c и b2b?

Этапы

Проблемы

Стоит это 30-40 часов, занимает от 2 недель до 2 месяцев.

Кого опрашивать в b2b, пользователя или того, кто платит? Зависит от продукта. Если бухгалтерия или CRM — то того, кто покупает, он построит специалистов, потому что их много. А вот в сегментах, где дефицит квалифицированных специалистов, которые могут уйти, если их построят — то к пользователям надо идти. Можно еще поделить сегменты, про деньги — с одним, а сейла — о том, почему он до сих пор ведет Excel, а не пользуется CRM.

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

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

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

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

Что достигается путем работы с рисками?

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

Типизация рисков. В разных книгах — по-разному, до 12. У нее — 4.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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