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

А дальше были комментарии к отдельным практикам. Школа этим практикам не учит, вернее учила лишь косвенно. В теории детей надо подготовить к жизни, чтобы они могли себя прокормить, но на этом в школе фокуса нет, и в ВУЗе тоже. Раньше жизни учила улица и подъезд, а сейчас эта часть социальной жизни отвалилась, так что все - сами.

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

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

Собранность. Кривая забывания и компьютерная память. Мнемотехники. Удержания понятий. Список работает до 400 строк, а дальше - заведи базу данных. А до 400 - все равно написать, начиная с 2 строк, а лучше - с одной. У организации тоже есть собранность: либо коллектив помнит, каким проектом занимался вчера, или не помнит.

Понятия - математика, предметы окружающего мира - физика. Математическому мышлению не учат, учат отраслям математики. Так же как и физическому мышлению вообще.

Семантика. Нагружение знаков смыслом, связь их с реальным миром.

Теория понятий - теория прототипов или образцов, и это экспериментально подтверждено. Логики там нет. Объяснить нейросети, что такое двуручный меч?

Онтология - машинка типов. 5 уровней: foundation ontology - типы систем, практик - типы объектов труда, деятельности - типы объектов прикладных дисциплин - модель экземпляров объектов.

Алгоритмика. 1.0 - то, что все деляют, 2.0 - ИИ и обучение, 3.0 - когда онтологии и программы пишут нейронные сетки.

Логика. А чо такова? Реагировать на ошибки в рассуждениях. 2*2=5 - ну и что?

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

Методология - схема, как устроено предприятие. Она дает объекты внимания, альфа, которые меняются в ходе проекта.

Системная инженерия, то есть обобщенная инженерия систем. С 2017 года требований нет, архитектура - нечто другое. Инженерия платформ вместо devops.

А дальше пошли надстройки: инженерия конкретных систем, менеджмент - инженерия организация и инженерия личности.

#AnalystDays Айгуль Габдрахимова. Стресс, адаптация, гибкость: как аналитику сохранить нервы и мозги. Доклад из двух частей: стресса и про теорию множественного интеллекта Говарда Гарднера. И у меня этот доклад вызвал печальку по поводу современного уровня мышления, это как раз иллюстрация того, о чем говорил Левенчук и я в своих докладах. И я хочу разобрать, с чем эта печалька связана.

Первое. Про стресс, со ссылкой на научпоп модель было сказано, чо он возникает как реакция на изменения, естественный, и ничего с ним сделать нельзя. Но стоит проверить физиологию, потому что связан уровнем кортизола, и он может просто плохо выводиться почками. И стоит посмотреть на базовые потребности по Маслоу, потому как если вы стабильно не высыпаетесь, что-то в жизни надо менять. Так вот, современная наука знает о стрессе достаточно много, там 5-6 разных вариантов, со своими причинами и способами управления. И надо сначала диагностировать, что именно у вас, а потом - работать над устранением конкретных причин. Как при любых нарушениях. Если кому интересны подробности, то можно посмотреть доклады Обуховой, у нее их много, она профи - среди ее шести высших есть биология и нейрофизиология.

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

Третья печалька - про теорию множественных интеллектов, которая признана как актуальная теория в современной педагогике. Говард Гадрнер выделил 9 видов интеллекта: Внутриличностный, Вербальный (или лингвистический), Логико-математический, Экзистенциальный, Пространственный, Музыкальный, Межличностный, Телесно-кинестетический, Природоведческий, позднее добавил еще несколько. Причина появления этой теории понятна - социальный заказ объяснить, что все люди - ценны, независимо от их IQ. Он выполнен, IQ меняет только 3 из них, а есть вот еще сколько.

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

#AnalystDays Светлана Дергачева. Применение ТРИЗ для решения задач с предельным уровнем неопределенности. Тема ТРИЗ на ИТ-конференциях возникает регулярно, я слушал много докладов и хочу отметить, что это - замечательный доклад. Он - на основе большого практического опыта, а не просто на основе первоначального знакомства. При этом достигнуть такого уровня у Светланы получилось только с третьего раза, на первых попытках отпугивала инженергая сложность и приземление на совершенно другой материал - ведь подход Альтшулер создавал в 50-е. Но потом появилась сложная задача - определять, читерит ли студент на экзамене, при том, что нейронные сетки выдавали ответ с достоверностью 50%, там ТРИЗ помог и пошло развитие. Еще я отдельно хочу отметить оформление презентации и сквозной игровой пример с канарейкой, которой надо добыть еду зимой - это наряду с примерами из ИТ.

ТРИЗ - ощущение тупика, когда мы не знаем куда идти. Теодюль Рибо в своих исследованиях показал, что креативность линейно растет с возрастом ребенка, достигает пика в 12-15, а потмо идет на спад. Дети умеют рисовать картинки, которые не видели в реальной жизни, а инженеры уже преимущественно копируют. Я тут хочу отметить, что есть зефирный эксперимент (marshmallow Peter Skillman, русское описание), который показал, что креативность падает не сама по себе, ее подавляет система образования.

Проблемы на пути поиска решения.
* Полное отрицание новой идеи
* принятие на веру положений, высказанных авторитетом
* применение старых принципов действия в новых устройствах
* не умение перенести в новую область
* использование предметов только по назначению
Что рекомендует ТРИЗ.

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

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

Акцент на актора - работа с ресурсами, с простоями (нет задач у тестировщиков), с мотивацией, подход к людям в маленькой компании. Изолируем ресурс, расписываем как систему, 3 сильные стороны, формулировки "существует в среде", как добиться ситуации.

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

Дальше - поиск решения.

Системное мышление. Хороший инженер видит объект и вариации, а АРИЗ-инженер видит надсистему - систему - подсистему, все это в прошлое-настоящее-будущее и еще антиподы систем. И в презентации был хороший пример, эволюция faq -> чат-бот -> AI-помощник с соответствующей эволюцией надсистемы и подситемы.

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

Для формулирования противоречий хорошо помогает SWOT-анализ, их формулируют слабости и угрозы .

Способы решения противоречия:
* Симбиоз с системой. Что надо изменить внутри, чтобы соответствовать надсистеме, что в надсистеме мешает развитию, что надо изъять. Задача про экзамен студента - надо подружиться с LMS, а они все разные. Оказалось, что LMS не любят открывать в iframe. Они написали плугин, он изолирует и разрешает, и заодно куки решили.
* Обратная связь. Если обратная связь есть - изменить ее, если она не решает проблему.
* Конструктор - соединение разные элементы. Когда ломается узел, уходит человек, сложно заменить - представим его по частям, а не целиком.
* Применяем роль - де Боно взглянуть на задачу как ученый (факты), художник (эмоции), критик (риски), оптимист (плюсы), креатор (нестандартно, начальник (координация).
* Метод одноразового стаканчика - заменяем дорогой набором дешевых. Worker - их можно запускать много.
* Экстрадетализация. Когда нет никаких идей. Просто расписываешь задачу как маньяк, синонимы, прилагательные, глаголы, ассоциации - пока не щелкнет.
* Вред в пользу: использовать вредные факторы для положительного эффекта, устранить вредный за счет сложения с другим вредным, усилить вредный, чтобы перестал быть вредным. У них - 5 нейросетей-распозновалок до 300 мб (лицо, голос и так далее). Они перенесли загрузку на самое начало и пустили параллельно с административными шагами - проверить оборудование, сфотографировать документ и т.п. И они в конце вставили экран с правилами, и пока человек читает, кнопка "продолжить" не горит, они дают время человеку и себе.
* Инверсия. Глаголов, прилагательных, смыслов, меняем объекта и субъекта, инверсия актора, цели, порядка действий в процессе... Freemium и trial версии - сначала пользуйся, потом плати.
* Посредник - использовать промежуточный объект передающий или переносящий действие, на время присоединить легко удаляемый объект. Вынесение частей из монолитов.
* Дробление - декомпозиция: разделить на части, выполнить разборным, увеличить степень дробления. Модульность, микросервисы
* Вынесение лишнего. Отделить мешающее или выделить нужное. Живо-чат - вынесли чат из сервис-деска и можно прикрепить куда угодно, и еще контекст пишешь.
* Чуть меньше или чуть больше, если трудно точно нужное. Готовые библиотеки, пусть там есть не нужное, или наоборот, не хватает, но мало.
* Самообслуживание: объект должен сам себя обслуживать, выполняя вспомогательные или ремонтные операции. Использовать отходы.
Интеграция - когда даем клиенту сделать все самому.
* Копирование. Вместо недоступного сложного дорогого использовать дешевые копии. Использовать изменение масштаба.
* Сумасшедший микс - де Боно. Накидываем самые разные слова по ассоциациям, случайные. Накидали производных слов - кенгуру - накидали всплывашки "сделай перерыв - есть приложение для медитации". Или автомобиль - фиксация что пользователь в автомобиле, за рулем и что-то адаптируем.
* Замена. Замещаем актора: делают не разработчики, а дети, алкоголики или врачи. Замещаем других акторов: разработка делает интерфейс совместно с конкурентами. Можно замещать среду, объект, цели
* Выше скорость - меньше ям. Ускорить негативные процессы, адекватно оценить как ускорить. Фаст-фуды - снижение качества пищи в обмен на скорость. Картинка в плохом качестве на плохом интернете. Скелетон первой страницы, если там долгая загрузка элементов.
* Метод вируса - подселение агента во враждебную часть среды, чтобы сделать управляемой. Выписать агенты проблемной зоны - акторы, субъекты живые и неживые, можно ли заменить? Удаленный рабочий стол.

Дальше Отбор идей. Как генерить - методы ТРИЗ. Линия рациональности - выгоды против затрат.

Подводя итог. Мнемоника ЗППП: Задачи из проблемы; Подсистемы (и надсистемы); подбираем метод; приоритизируем фичи. И в конце довольно большой список литературы по ТРИЗ и смежным темам.

#AnalystDays Валерий Разномазов. Объектно-ориентированный подход в построении архитектуры решений. Глубокий доклад о применении DDD. И в нем противопоставление между опорой на бизнес-объекты и опорой на бизнес-процессы, которые автор называет "функциональным подходом" (от бизнес-функций). Аргумент за объект - они более стабильны и легче проявляются, и дальше на них можно строить разные процессы. А еще в докладе было очень классное определение архитектуры, отличающееся от обычного "важные, ключевые решения": система - большее, чем совокупность отдельных фич, и архитектура - это то, за счет чего система работает как целое. За это - отдельное спасибо Валерию.

Дальше конспект. Потребность в архитектуре порождается семантическим безумием, многообразием и вариативностью представления данных в разных системах. И как средство от этого - корпоративная архитектура данных, единый язык. Раньше это было относительно просто, на основе EBS и Global business objects by IBM - он давал общий формат xml ваших данных. А сейчас при построении экосистем на основе open api требуется объединить очень разное, например, продажу бургеров, онлайн кинотеатр и выдачу кредитов. А грядет интернет вещей, где объединять все со всем. Он астрофизик, и мыслит аналогиями: смысл сущностей - новая гравитация, туманность сведений о заемщике и галактика продуктов.

Доклад был на двух примерах: Событийно-ориентированная производственная систем Amanita, для которых был предварительный анализ и CRM психологов - понятная практика, в ней было рамочное пожелание заказчика без предварительного анализа.

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

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

Есть два варианта развития проектов: от бизнеса к ИТ и наоборот, от ИТ к бизнесу. Внедрение вендорского решения - от ИТ к бизнесу, перекраиваем бизнес под возможности ИТ. Бизнес может рухнуть, примеры есть. SaaS - тоже самое, натягиваем одно решение на другое.

Первоначальные требования: легаси, существующий проект или новый проект.
* Легаси - чужое. И часто без комментариев, и с атрибутным хранением.
* Если проект есть - можно сделать лингвистический анализ и частотный - можно построить граф.
* Принципиально новый проект, а заказчик не очень понимает что делает - то agile и UI/UX макетирование - можно стартовать.

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

Онтология - не патентуется, а воплощение в виде классов - патентуется. Бизнес-объект: DTO, Json (xml), таблица как проекции друг друга. Платформа дает json, а интеграция - xml с xsd.

При реализации событийно-ориентированная производственная система Amanita опирались на производственные журналы в цехах - там готовая модель событий, его можно сразу переносить в данные.

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

Ontology driven MSA. Границы микросервиса - границы домена. Микросервисы и цитадели: в цитаделях те объекты, которые относительно статичны и изменения не меняются. Еще в цитадель попадают данные, которые надо защищать.

Объектно-ориентированные RESTfull - привязываем к объектам. И дальше SCRUD.

Модель поставщик-потребитель. Объекты, и взаимодействие: синхронное или асинхронное

Интеграция по Фаулеру: File transfer, shared database, remote procedure invocation, messaging.

Amanita. Мониторинг брака - видеокамера - json - обработка данных - и два потока: нормально и отклонение. Kafka, она была известна. Но между Kafka и RabbitMQ - большая разница, зависит от того, нужна ли будет обработка.

Messaging: JSONSchema или XSD. И проверка в шлюзе API Gateway. В Amanita шлюз между фронтом и бэком. В современных проектах бизнес-логика - не SQL, а Java. Декомпозиция бизнес-идеи - выделяем субъекты и объекты - строим граф - строим json-схему - строим базу данных.

Сложности: У одного объекта бывает много хозяев, несколько мастер-систем, отсутствует корпоративная модель данных и глоссарий. Я отмечу, что тут должны работать ограниченные контексты из DDD.

#AnalystDays Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент). BPMN хорошо описывает процессы, особенно если дополнять его описанием орг.структуры и объектов данных, для которых есть отдельные нотации. Но есть отдельные этапы процессов, исполнение которых плохо описываются с помощью BPMN, потому что не представляют собой структурированный процесс. Диаграммы получаются запутанными и не проясняют содержание. И для отражения таких функций можно использовать две другие нотации.

Рассказ был на конкретном кейсе, проект генеральной прокуратуры по надзору за исполнением законов. Рамочно он хорошо описывается BPMN: Поступление, регистрация, назначение исполнителя - и дальше проверка или обоснованный отказ от нее. Операция назначения исполнителя: на ней надо выбрать человека с учетом тематики, квалификации и текущей занятости, и возможны сложные решения, когда назначают исполнителя и куратора. Эти факторы рассматриваются в совокупности. И для описания такого процесса удобно использовать DMN - decision model and notation. В простейшем варианте такое решение - просто таблица выбора исполнителя по критериям, а в сложном алгоритма нет, а схема фиксирует те данные, которые нужны для принятия решений - и они, во-первых, должны быть в системе а, во-вторых - представлены исполнителю для принятия решения, собраны совместно на экране. Элементы DMN: решение, модель бизнес-знаний, источник знаний, входные данные.

Далее был рассмотрена операция проведения проверки в рамках надзора. D рамках проверки может быть большое количество разных мероприятий и подготовлены различные документы, но их проведение - на усмотрение ответственного. И в финале тоже есть опциональная часть - обращение в суд. Для этого хорошо подходит нотация CMMN - Case management model notation. В ней акцент - не на процессе, а на информации по конкретному случаю. Цель процесса - ясна, а путь - вариативен и определяется исполнителем. Элементы CMMN: Сцена, этап, задача с критериями входа и выхода, веха. Строится так. (1) Папка "Проведение проверки". (2) Входные критерии - с чего начинается кейс. (3) Этапы проведения проверки: свернутые или развернутые. Дискреционный этап - не обязательный, выполнение зависит от исполнителя. (4) Критерии входа и выхода для каждого этапа, и артефакты, связанные с критерием. (5) Фрагментация плана. Для рассматриваемого примера: обязательный этап изучения дела и законодательства, даальше дискреционные этапы проведения мероприятий и подготовки документов реагирования, а потом - финальный обязательный этап - акт проверки, и снова дискреционный - работа с судом, а дальше выходные критерии.

В презентации были примеры диаграмм, их опубликуют быстро - можно смотреть. В Comunda есть работа с DMN, CMMN еще нет, обещают. Есть шаблоны для visio, в презентации были ссылки.

#AnalystDays Ярослав Кучеров из Газпромбанка. Матрица сценариев - инструмент бизнес-анализа. Матрица сценариев - способ представить варианты реализации. Мы выбираем бинарные параметры, которые конфигурируют поведение приложения, и дальше для каждого варианта приложения с их помощью определяем конфигурацию. Например, если надо сделать систему лояльности, то параметрами будет реализация конкретных фич: начислить баллы, списать баллы, посмотреть свои баллы, предложить клиенту списать баллы. И дальше для каждого канала взаимодействия с клиентом: авторизованный заказ на сайте, быстрый заказ без авторизации, мобильное приложение, официант в ресторане, колл-центр - определяем, какие сценарии в них должны быть реализованы. Получаем матрицу, согласуем с заказчиком и именно это делаем. Матрица дает наглядное представление, и в презентации было несколько вариантов и примеров из реальных проектов, помимо модельного.

Быстро собрал отчет https://mtsepkov.org/AnalystDays-2023b по конференции AnalystDays, дополнив посты, которые публиковал в ходе конференции, заметками с еще нескольких докладов. За два для я было много хороших докладов: Анатолий Левенчук про Интеллект-стек, лучший доклад про ТРИЗ из тех, что я слышал, глубокий доклад про ООП с хорошим определением архитектуры, узнал про нотации DMN и CMMN, дополняющие BPMN для не-процессных бизнес-функций и много других. Я сам рассказывал про рациональное и системное мышление и, по отзывам, получилось хорошо. И, как всегда, качественное общение. До новых встреч на других конференциях!

Выступил вчера на Podlodka Teamlead Crew Работа со стратегией в реалиях современного мира https://mtsepkov.org/StratPodlodka - теоретический экскурс про 10 школ стартегирования по стратегическому сафари Минцберга и принципы гибкой архитектуры, которые позволяют быстро делать проекты из собственного опыта с кейсами. После выступления почти час отвечал на вопросы, тема оказалась актуальной и востребованной

Как обычно, в начале сентября был на #festpir - большой конференции тренеров и коучей. Как всегда - феерия выступлений и общения. Для меня эта конференция - чувствительный индикатор времени и место встречи с интересными людьми. Как обычно, публиковал впечатления о наиболее запомнившихся выступлениях в телеграм-канале, но многое осталось только в заметках из-за насыщенной программы. Поэтому публикация отчета затянулась, но, наконец, сегодня я публикую заметки, дополненные впечатлениями о других выступлениях https://mtsepkov.org/PIR-2023 Я надеялся успеть до отчета посмотреть записи выступлений, которые были online, но то пока в будущем, надеюсь, что получится и тогда я дополню отчет. А сам я тоже выступал на ПИР с докладом "Я и мои аватары в спектакле жизни" про модель личности, видео уже опубликовано, а продолжение будет в конце ноября на Teamlead.

Смотрю записи докладов #festpir, которые не получилось увидеть на конференции. Марк Розин. Новые времена - новые песни - осмысление нового мировоззрения 21 века и его отличий от мировоззрения 20 века. Это сборка комплексной, целостной картины, а не отдельных трендов, чем и интересна. Дополнил отчет по ПИР, читайте конспект и мое осмысление услышанной картины (это в конце отчета, ссылка должна перейти туда).

Сегодня на #sqadays. Первый доклад Марина Тарасова из SimbirSoft: Индивидуальный план развития. Доклад важен мне, потому что сам я буду выступать на связанную тему - о самоопределении и профессиональном росте. Мне доклад очень понравился. Он начался с важного тезиса: компании выгодно вкладываться в специалиста, чтобы он развивался, хотя при этом сотруднику надо будет больше платить, потому что в результате проект компании лучше двигается. Отмечу, что это не для всех компаний справедливо, есть компании, предоставляющие тестировщиков на аутсорсинг в определенной нише рынка, и если сотрудник слишком развивается, то для него не могут найти проект, надо менять компанию.

Главное что дает индивидуальный план развития - визуализацию и прозрачность процесса. Чеканная формулировка: что визуализировано - достижимо, что достигнуто - достойно награды. По опросу аудитории, ИПР - не единственный способ, есть самостоятельное развитие с оценкой через внутреннюю оценку или контроферы и другие варианты.

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

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

Планы развития всегда включают soft skill, а не только hard. Не должно быть много: 1-2 hard + 1 soft. Откуда брать: из задач проекта, существующих проблем и потребностей улучшения, обратная связь от команды, будущие задачи - тренды и бизнес-цели проекта, опыт других, карьерное консультирование. Цели встраивают личное развитие в развитие проекта.

Развитие soft skill можно делать через доп.активности на проекте: демо, ретро, лидство (наставничество, кураторство), ревью и внепроектные активности - митапы, конференции, статьи.

Вопросы-помощники: зачем, хватает ли навыков для выполнения задачи, какие проблемы есть на проекте, какие задачи интересны?

После целей: декомпозиция цели на задачи - как с user story, критерии успеха и сроки и контролируем процесс.

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

Цикл контроля общий: Цель - План и параметры - Мониторинг в точках контроля - Коррекция по результатам мониторинга.

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

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

Про мотивацию есть книга Светлана Иванова "Мотивация на 100% - где у нее кнопка". Преподнесение информации - идеальна. Я, правда, тут хочу предостеречь: есть другая книга Шпренгер "Мифы мотивации", где автор разбирает все известные схемы мотивации и показывает, что они ведут к деградации в долгую. Книга - старая, но я критикуемые методы видел и в свежих, люди работают в короткую. Так что полезно самим соотнести перед применением.

Что делать, когда берут задачи и не делают? В точках контроля: "много работ на проекте" и т.п. Это прокрастинация, он не принимает задачи.Откуда взять ресурсы? Нет ответа на этот вопрос. Про тайм менеджмент рассказывать не будет. Мы взрослые и должны сами настраивать.

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

#sqadays Виталий Старостин из ПСБ. В чём измеряются инженеры по тестированию. Хороший доклад о том, как мониторинг сам по себе улучшает ситуацию, потому что проблемы становятся явными. У них количество людей сильно возросло, и они решили ввести метрики, чтобы понимать, кто и что делает, работы нет или ее не видно, опасения, что метрики покажут не адекватную картину, понятное отношение сотрудников, которые не хотят чтобы их мерили, потому что и так работают хорошо. И они решили двигаться, не смотря на опасения. В презентации был чек-лист идеальной метрики и полный набор метрик, который они используют. И подробно раздирались метрики для ручного регресса, который является дорогим процессом - 27 тестировщиков + капитан + команда разработки 3.5 дня на первую итерацию. Тест кейсы распределялись по тестировщикам автоматически равномерно по оценке трудоемкости, дальше тестировщики их выполняли, если кто-то не успевал - товарищи ему помогали, а выполнение тест-кейсов фиксировалось. Метрики позволили увидеть, кто именно из тестировщиков столкнулся с наибольшими проблемами и дальше поговорить, чтобы эти проблемы увидеть и решить. Из интересного: выяснилось, что алгоритм распределения тест-кейсов реально распределяет их неравномерно, выявились тест-кейсы с неверной оценкой, увидели, что процесс актуализации тест-кейса не работает, а он - дорогой. В целом был получен результат, время первой итерации сократилось в 1.5 раза, с 28 до 19 часов, и дальше это было стабильно. Они продолжают работать по выявленным проблемам. А потом будет следующий такт.

#sqadays Таисия Толстунова и Елена Коренева из VK Tech. Преодоление трудностей кросс-продуктового тестирования: подходы, лайфхаки и инструменты. Рассказ про VK workspace - коммуникационная платформа для бизнеса: teams, почта, календарь, мессенджеры, диск и так далее. Пользователи воспринимают продукт как целое, хотя могут пользоваться отдельными частями. И там появляются кросс-продуктовые фичи, которые интегрированы более чем в одном продукте и должны быть представлены единообразно. Разработкой занимается несколько команд или несколько участников из этих команд. И при этом всегда возможны не стыковки из-за несогласованных действий команд. Проблема понятная, и решения, в общем, тоже понятные - нужна координация и согласованность процессов, и это надо выстроить.

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

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

Казалось бы, все понятно, но далеко не всегда это делают и это - боль. Это было видно по реакции зала.

Презентация моего доклада - на моем сайте https://mtsepkov.org/SelfDetSQA23

#sqadays Иван Железков и Алексей Кожин из ПСБ. В стране невыученных уроков, или как создавалась школа тестирования ПСБ. Тотальный дефицит привел к тому, чтобы создать школу обучения новичков внутри. Потому что программы обучения на рынке очень слабо коррелируют с потребностями. Когда вы обучаете для себя - можно получить тех, кто нужен. И был короткий рассказ, как они это сделали.
1. Надо найти заказчика, который заинтересован в специалистах и скажет, кто и сколько нужен.
2. Как будем обучать? Внутренняя экспертиза, ее распространяем на студентов - готовим для себя. Выбрать экспертов
3. Опишите роль - кто должен получиться.
4. Разработайте контент.
5. Запустите обучение.

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

Весь набор знаний разбит на микрокурсы, каждый из 4 этапов.
1. Первичная оценка и передача знаний
2. Создание рабочего артефакта
3. peer2peer - студенты обмениваются артефактами и снимают ошибки друг у друга
4. Оценка экспертами результата

Этап peer2peer оказался очень ценным, студенты снимают большое количество ошибок, и еще закрепляют знания, что сильно разгруает экспертов на следующем этапе.

По результатам микрокурсов и оценке артефактов получается розочка компетенций: тест-дизайн, чек-листы и так далее.

Результаты:
* частичное решение проблемы подбора через обучения молодых - джун+, подтверждено
* снижение текучки - эксперты смогли проявить себя по-другому
* сокращение затрат на обучение за счет привлечения внутренних экспертов

В презентации было два ценных слайда: (1) фреймворк разработки, который применяет банк, со всеми артефактами и другими подробностями (2) розочка компетенций тестировщика, которая получается по результатам обучения.

#sqadays Анастасия Золотых из 2GIS. Тестирование на лету: новый подход к визуальному тестированию. Продукт Otello: web, мобилки, множество платформ, виджеты для встройки. Среднее время разработки и доставки фичи 5 дней, смесь ручного и автоматизированного тестирования, в автотестах - случайные разрешения для устройств и случайные данные с генерацией на лету. Их команда тестирует фронт, бэк и интеграция - через моки. Команда решала задачу расширить автотесты, добавив проверку по скриншотам, так как проверка на всех платформах и разрешениях - трудоемкая. Классический подход основан на том, что ты держишь эталонные скриншоты и сравниваешь с ними результаты, которые получил при прогоне теста. В их случае возникают сложности: эталонные скриншоты надо обновлять вручную, и не очевидно, что это даст меньше работы, чем ручное тестирование, к тому же на скриншоте - фиксированное разрешение и данные, нельзя использовать случайную генерацию.

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

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

#sqadays Алексей Пименов. Я предлагаю - они отказываются! Как обычно превосходный доклад о психологических аспектах сопротивления изменениям и работе с ними. Социальные аспекты сопротивления доклад не затрагивал, в вопросах они проявились, Леша отвечал и сказал, что об этом у нее есть отдельный доклад.

Распространенная реакция на предложение нового - отказ, ответ "нам будет неудобно", или тихий саботаж или итальянская забастовка. Есть методология Prosci (prosci.com) для работы с сопротивлением, там разные причины систематизированы, есть очень большой справочник и методики работы. Однако, можно поднять уровень рассмотрения.

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

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

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

Как сказал Леша, Канеман за свои исследования получил нобелевку, потом эти системы попробовали приземлить на механизмы работы мозга, это получилось не слишком хорошо, в результате вся теория сейчас под сомнением. Но она практична, поэтому ее стоит использовать. Я тут хочу дать развернутый комментарий, потому что сейчас готовлю доклад про по модель личности на Teamlead и детально разбираюсь с вопросами работы мозга. Дело в том, что когда модель Канемана приземляли на модель работы мозга, то использовали триединую модель Маклина, система-1 была локализована в рептильном мозге и лимбической системе, а система-2 - в неокортексе. С тех пор Маклин умер, а его модель объявили ненаучной. Но вся критика, которую я читал, сводится к нескольким пунктам (1) эти части мозга работают совместно, (2) модель - большое упрощение, а реально все устроено сложнее. Но про независимость Маклин не утверждал, не даром модель триединая, это уже упрощающие интерпретации типа "укроти своего внутреннего зверя", а то, что сложнее, так любая модель - упрощение, покажи, где она не работает, предложи альтернативу - а альтернатив не предлагают. При этом нейрохирурги продолжают эту модель использовать, и, более того, сами психологи продолжают использовать анатомические модели мозга на зоны следующего уровня детальности, то есть получается, что части - есть, а против агрегатов - возражают. В целом сама критика несет отчетливый отпечаток социальных, а не научных аспектов.

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