Вопрос. Если команда против и выходит в саботаж, что делать?
Ответ - можно, но другим инструментом. В лекции инструмент из психологии, а есть еще социология. Надо разобраться с кланом саботажников, и как-то убедить их присоединиться. Для этого ответить на вопрос - как вы соотноситесь с кланом саботажников? Вы вместе, или отдельно? Если вместе - то рассмотреть риски. Если отдельно - есть способ понижения социальной значимости группы возражающих. Объединившись - вы защищаете безопасность социальной группы и повышаете значимость. Если вы офигенные - нет стимула к развитию, важно удержать статус-кво, и изгонять лидера, который хочет изменения. "Вы все профи, но вместе - говно, потому что результат не поставляете". Нельзя, чтобы вас сделали общим врагом: не они против вас, а вы вместе борете агрессивное окружение, не PVP (player versus player) , а PVE (player versus environment). При этом важно снизить значимость племени, не снижая значимость индивида, со снижением значимости индивида начинается треш.

Что почитать? Есть хороший бизнес-роман Рей Иммельман "Босс бесподобный или бесполезный". Будете искать - есть еще книги с похожими названиями: "Хороший босс, плохой босс" и "Хороший плохой босс", они про другое, не путайте.

Вопрос. Я рядовой участник команды изменений, но рядовой. Как работать, если опытный человек говорит "это не будет работать". Ответ: ты присоединяешься "давайте обсудим почему".

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

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

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

#sqadays Эмиль Барлыбаев из Doubletapp. На старт... Внимание... Нагружаем! Короткий рассказ про организацию нагрузочного тестирования. Потому что важно не просто дать нагрузку - надо дать разную нагрузку для определения разных характеристик. Для начала надо понять, какие запросы будут давать основную нагрузку, обычно они составляют малое количество функционала, и тестировать надо именно их, а не по площади. Далее даем нагрузку и делим три зоны: слабую, когда потребляемые ресурсы постоянны, а время отклика около нуля и не растет, основную, в которой ресурсы растут линейно и рост времени отклика примерно линеен по нагрузки, и стрессовую, когда мы постепенно приближаемся к максимуму нагрузки. В целом у нас - образная кривая, и эти зоны - ее деление. В примере пределом было 100 rps, слабая дона 0-40, рабочая 40-80 и стрессовая от 80. Дальше сравниваем вычисленную нагрузку с ожидаемой. Если ожидаемая ниже - то можно сокращать ресурсы. Если больше - нужно масштабирование, горизонтальное (больше нод) или вертикальная (мощность ноды). И делаем три вида тестов: под рабочей нагрузкой проверяем стабильность работы, стрессовое для проверки работоспособности под большой нагрузкой и долгое (8+ часов) тестирование под низкой нагрузкой, чтобы увидеть, что ресурсы сервиса не текут. Еще нужно тестирование всплеска, обычно есть события, когда ожидается всплеск нагрузки, вплоть до перегрузки, и надо проверить, что когда оно проходит, сервис возвращается к рабочим параметрам. Помимо этого нужно тестирование объема, что накопление данных не повышает время отклика. И в конце доклада - оформление отчета и рекомендации lzk начинающего, но это - стандартно.

#sqadays - публикую что не успел вчера Анфиса Лаврова. Проектирование процесса тестирования по проблемам. Любопытный доклад об успешном сокращении регресса от 6 недель до 2, а далее до одной, с уменьшением числа занятых тестировщиков с 5 до 3, то есть трудоемкость уменьшилась в 10 раз. Что важно - были разобраны неверные шаги, которые предприняли сначала. А также показано применение различных методов - организации процессов, анализ причин на простых примерах. Так что в целом - успех. А сами неверные шаги служат хорошей иллюстрацией того, как применение стереотипных ответов может оказаться неверным в конкретной ситуации.

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

Есть два способа проектирования процессов: от целей, например "уменьшить трудоемкость регресса", или от проблем "долгий регресс" Проектирование от целей начинается с модели to be и применяется для новых процессов, а также при существенных изменениях условий и ресурсов для существующих, а проектирование от проблем - с анализа as is и применяется для улучшения существующих процессов.

Теперь про регресс. Исторически регресс включал 5000+ кейсов, которые вручную прогоняли на 3 платформах с различными базами данных, на которых работал продукт. И это требовало 6 недель при команде тестирования в 5 человек. Это было долго и трудоемко. Кога Анфиса пришла как руководитель отдела, то перед ней была поставлена задача сокращения времени регресса. Вторую задачу, которую она видела, было увеличение мотивации самих тестировщиков. Но оценив задачи по степени влияния, она решила сфокусироваться на регрессе. Идея о том, что регресс можно ускорить, увеличив мотивацию, в докладе рассмотрена не была, по-видимому, было очевидно, что объем работ носит объективный характер, и если его делать быстрее - просто увеличится число ошибок.

Очевидное решение - автоматизация. Теестировщики в команде умели писать код, и попробовали писать автотесты. Эксперимент был 2 спринта, и в конце собрали статистику: за это время разработано 50 новых тест-кейсов, а автоматизировали всего 20 тест-кейсов. Процесс явно не сходится. Кроме того, выполнение этих тест-кейсов - не более часа, а на разработку потратили 6 человеко-недель, то есть срок окупаемости получается большой, 250 прогонов. Впрочем, для этого анализа надо было отделить построение инфраструктуры автотестов, которое явно было внутри, и посмотреть динамику с учетом обучения. Но в целом было видно, что метод при нынешних ресурсах команды - не перспективный.

Вторая попытка - увеличить ресурсы. Временно добавили тестировщика из соседней команды, это 20% мощности. Регресс сделали быстрее на 10% - 5.5 недель. Но суммарная трудоемкость при этом увелчилась на 10%, 30 -> 33, что логично. Я отмечу, что результат - предсказуем.

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

Крмое того, продукт состоит из модулей, новые фичи трогают не все модули, и, хотя вероятность затронуть соседние модули существует, она не слишком велика. Поэтому тест-кейсы разделили по приоритетам в зависимости от важности проверяемого функционала, и для тех модулей, которые не менялись в релизе, решили прогонять только приоритетные тест-кейсы. Наконец, часть функционала продукта клиентами не используется, и для него тоже проверяют только приоритетные тест-кейсы. В результате регресс сократили до 2 недель с 6, в три раза, а потом еще до 1 недели и его делают 3 тестировщика вместо 5. Остальных не уволили, они занялись автоматизацией и другими вопросами. При этом качество релизов не ухудшилось.

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

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

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

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

Схема планирования тестирования с учетом рисков из стандарта, на ней много блоков, в простом случае часть из них становятся тривиальными, но где именно - зависит от проекта. Фазы: определить контекст -> организовать разработку плана тестирования -> определить и изучить риски -> определить подходы к обработке рисков -> разрабатываем стратегию тестирования (ресурсы и инструменты) -> определить персонал и график -> оформить план -> согласовать план.

Виды риска:
* риск проекта: персонал, поставщики, организация, лицензии, техника
* Риск продукта - опыт пользователя: функциональность, ошибки и та далее.

Параметры для оценки риска продукта ISO 25010, оценка качества системы: Функциональность, Производительность, Совместимость, Удобство использования, Сопровождаемость, Надежность, защищенность, Переносимость. В стандарте идет детализация, но практически это редко не требуется. К каждой характеристике добавляем "риск" - получаем 8 рисков. Оцениваем влияние на пользователя и на обслуживание системы.

Качество системы - качество ПО (качество ресурсов + качество ворклфлоу) + качество смежных компонентов.

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

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

#sqadays Антон Семенченко. Чистая архитектура в контексте Автоматизации тестирования. Это был доклад о том, как архитектура влияет на качество продукта и тестирование. Антон ведет фундаментальную проработку темы и сейчас материала на 16 часов. Он обещал выложить его в понедельник, а сам доклад был обзорным рассказом без презентации. Но главная цель - не передать содержание, а показать тестировщикам, что им надо не дистанцироваться от архитектурной работы, не принимать разработанную архитектуру как данность, а активно участвовать в работе над архитектурой. Дальше - тезисы, записанные с голоса.

Смысл Архитектуры - снижение стоимости продукта на всех этапах, включая тестирование и эксплуатация.

Отделить архитектуру от дизайна невозможно ни в строительстве, ни в ИТ. Дверная ручка - - дизайн, фундамент здания - архитектура, а декоративные колонны - что? В ИТ тоже самое, есть design pattern и architecture pattern, но многое на стыке. К архитектуре точно относится принципы деления на компоненты и организации взаимодействия между ними, к дизайну - детали внутреннее устройство компонент, а вот выделение отдельных компонент или принципы проектирования компонент - на стыке.

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

Роберт Мартин. Clear Architecture. В одной из глав он приводит 4 варианта архитектуры: трехкомпонентрная, функционально-разделенная, сущность-плугины и еще один. При этом в коде - одинаковое количество классов и интерфейсов. Получается, что логически ошибки везде одинаковы - раз речь идет о коде. Но раз они одинаковы, то архитектура не влияет на тестируемость? Но опыт говорит о другом. Проверки в коде - разработчиками в unit-test, и если это делают - то ошибки должны быть найдены. Тогда где влияние архитектуры?

Юнит-тесты, code review и многие другие практики. И QA должны понимать эти аспекты и участвовать в проработке, вписывать их в свою стратегию тестирования. И дальше фокусироваться на пересечения границ.

Автотесты - куда встраивать: есть unit, api, есть функциональные. Куда ставить? Автотесты - тоже часть архитектуры системы в целом. Чтобы тестировать слои изолировано, полезно встраивать промежуточные слои: command-line, api для тестирования. Это позволяет статьи независимым от того, что тестируешь на этапе подготовки данных для конкретного теста, сделать тесты более изолированными. Если в приложении часто возникают проблемы безопасности - давайте вынесем их за скобки функциональных тестов и будем проверять их отдельно, а для этого сделаем способ работы, при котором "все позволено" - но отдельным модулем, который точно не выкатим на прод.

Design pattern humble object. Скромный объект. Разобьем сложный объект на два, разделим сложность. Так в свое время появился MVC: разделим на клиенте визуальное представление (View) и бизнес-логику (Controller). Потом еще был Module-View-Presenter, MVVM - они тоже делили сложность. Декомпозиция уменьшает сложность разработки, обеспечивает независимое тестирование и локализации ошибки. База данных. СУБД - plugin для приложения. ORM - плугин для плугина.

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

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

Сегодня в МШУ Сколково на #Highload - он сюда вернулся из Крокуса. Как обычно, много треков и много людей. На первый доклад хотел пойти на Точки отказа в хайлоад-системах от Константина Козловского, но там - жесткое переполнение зала. Поэтому пошел на Сергея Бережного, Эволюция сервисов и средств разработки и ностальгирую по прошлому - в докладе история технологий интернета примерно с 1997 года по площади - операционки, редакторы, базы данных, средства разработки и так далее. К сожалению, эволюции, то есть логики развития, а не просто истории фактов, в докладе нет, просто сборка логотипов. Это жаль, это - интересно. В вопросах было: почему Яндекс ушел с FreeBSD на Ubuntu? Ответ - эксплуатационные характеристики для управления большим количеством машин в кластере. А смысл доклада - вспомнить именно open source решений, и таким образом показать их вклад в развитие ИТ, общность разработчиков, которые не зависит от конкуренции между компании. И анонс инициативы Яндекса по грантам для Open Source разработки.

#highload Евгений Кульгин из CDEK: Mattermost на стероидах: как мы запустили и развиваем корпоративный мессенджер. Был телеграм, slack, skype для видео, проблемы что несколько мессенджеров и внешних, при этом slack - снаружи, нет контроля за работой сотрудников и помнит только 10к сообщений. Плюс важно держать мессенджер под контролем: он встравивается в бизнес-процессы, и отрубание их крэшит - поэтому решили развернуть локально mattermost. RocketChat тоже пробовали, но оказался нестабильным. И дальше был технический рассказ о проблемах, которые они решали: отказоустойчивость, хранение изображений, ограничение доступа к каналам, сервис, чтобы увидеть просмотр сообщения в виде привычных галочек и так далее. Они остаются на бесплатной версии и делают сервис подключаемыми плугинами, работают с подключением elastic search вместо собственного индексатора и своих уведомлений. Mattermost часть из этого дает в платной версии, но там, по отзывам, оно неудобно, например, для настройки доступа к каналам надо идти в консоль, для проверки что прочитали - жать кнопки, это не появляется как галочки и так далее. Поэтому все равно нужна собственная разработка. Делает все это один разработчик, который больше решает задачи devops. Если задумаетесь про mattermost - доклад точно полезен. Свои доработки они планируют публиковать без кодов (готовили к выступлению, не успели), а если будет интерес - подумают, как открыть доступ к кодам.

#highload Виктор Бурцев из Яндекс: Слишком… много… асинхронщины… На что обращать внимание при работе с фичей из десятка сервисов, обрабатывающих 15 000 асинхронных задач в секунду. Поверх основного функционала Яндекс-такси есть функционал live activity - обновление состояния на клиенте, включая активность разных плашек. Все это обеспечивается большим количеством сервисов асинхронной работы, которые, преимущественно, работают по таймеру, а не по событиям - чтобы сбалансировать нагрузку. И рассказ был о том, как перестраивать архитектуру, чтобы обеспечить нужную производительность. Например, запрос от задачи в core-сервис создает недопустимую нагрузку - поэтому делаем промежуточное redis-хранилище, в котором обновление по событиям, а уже к нему идет обращение за данными. В докладе был ряд конкретных кейсов, без обобщений и выделения шаблонов. Их интересно осмыслить, если вы решаете такие задачи, может, появятся идеи уже для ваших задач. И общие рекомендации, прежде всего логи и мониторинг, при чем не общий по hardware, а внутри конкретных задач. А по организации взаимодействия - понимайте, что возможны падения и самые разные ответы смежных сервисов, это надо обрабатывать и вести себя разумно, не создавая дополнительной нагрузки.

#highload Андрей Цветцих мз Тинькофф: Эволюция и мифы CQRS. Доклад на стыке концептов и практики. Концептуально CQRS был придуман, когда запросов чтения много больше, чем запросов изменения данных. В этом случае логично отделить чтение от изменения данных, чтобы по-разному их масштабировать. Но для этого надо разделить запросы на чтение - query и изменение - command. И при этом единый класс, который обрабатывает конкретную сущность, делится, как минимум, на два обработчика: для запросов и для команд, а в перспективе для каждой команды и запроса появляется свой обработчик.

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

Дальше был рассказ о практической реализации, в том числе решении задач по выделению общих частей обработки команд, которые в классике реализуются за счет приватных методов. А в этом случае их делают как отдельные сервисы, но надо заблокировать обращение снаружи, в C# это internal. Первый этап - просто разделить методы в коде и работать на общей базе, и это можно делать постепенно. Когда методы разнесены. можно распилить один сервис на два: на чтение и запись, это Андрей сказал уже в ответах на вопросы. И тут не обязательно разделять код, можно начать со специализации экземпляров. Дальше можно разнести базы для чтения и запросов, настроив репликацию master-slave и по-разному масштабируя, но у этого есть понятная обратная сторона - появляется замедление обновления данных при чтении. В коде при этом возникают два соединения, в одном запрещено обновление. В коде важно для обновлений читать предыдущее состояние из write-базы, а не из read. А следующим шагом можно вместо master-slave делать разные структуры данных, оптимизированные на запись и на чтение, с трансформацией при передаче данных. Модель для чтения может обновляться синхронно, если она носит характер кэша, но, как правило, это делают асинхронно. Асинхронное обновление не дает задержки, но нарушается консистентность и повышается сложность, надо разбираться с нарушением порядка сообщений, и вообще с ошибками обновления, которые рассинхронизовывают write и read базы.

Следующая часть - мифы CQRS. Они реально мешают применению.
* Query не может менять состояние и даже писать логи. Это неверно, нельзя лишь меняем основную модель. А логе, метрики и кэши - меняем. И логи - это важно, потому что работу надо мониторить.
* Query может читать только read-модель. Это не так, если нет проблем с производительностью - читайте основную, так что в read-модель можно выгружать не все.
* Command не может читать read-модель. Это действительно так, потому что в ней не актуальные данные, и можно пропустить обновление.
* Command не может возвращать значение. Это не так. Если мы создаем сущность, можно вернуть ее ключ, если что-то обновляем, то можно вернуть данные. Однако, это требует синхронной обработки команды. Если вы захотите потому перейти на асинхронное взаимодействие, то это не получится. То есть формально можно будет новый асинхронный запрос обернуть таймером до обработки, но это может отменить эффект перехода на асинхронное взаимодействие. Хотя есть разные кейсы.

Прошел #Highload. Я был только первый день, как обычно, публиковал заметки с докладов, но успел не все. Поэтому решил быстро собрать и опубликовать отчет https://mtsepkov.org/Highload-2023, читайте! В целом - было интересно, хотя и немного сумбурно: highload вернулся в Сколково, 11 треков и 3600+ офлайн участников. Но лично мне возвращение понравилось. И у меня получилось заглянуть в технологии, до этого для меня так работал только Питерский highload. Спасибо организаторам и до встречи на #Teamlead, где я буду не только слушателем - я буду рассказывать про инженерную модель личности человека, попытке воедино собрать модели нейрофизиологии и психологии в единую архитектуру.

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

Такие стереотипы формируются в детстве, Дарья полагает, что они встроены в культуру^ russian feedback, красная ручка , много указаний на ошибок и мало похвалы в школе и так далее. Я думаю, что привязка к русской культуре неверна, судя по количеству западных книг, где объясняется примерно тоже самое, так что проблема общая, хотя культурный контекст, естественно, накладывает свои акценты. И такая привязка обесценивает культуру в целом. Тезисы из зала - что есть опыт западных компаний, где перегибы в другую сторону.

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

Ключом для изменения является вопрос: что я хочу достигнуть в коммуникации, и помогаю я этому своими формулировками или мешаю.
Общие рекомендации, чтобы убрать эмоциональную реакцию:
* Оценивать работу, а не личность
* Исключить личные местоимения
* Переключить смысл с прошлого на настоящее и будущее.
* Надо было -> Можно. Мы все что-то должны, это смягчает коммуникацию.
* Негатив предмет давть очень предметно.
* Заменять "но" на "и" и "лишь" и "только" - ценить усилия, а не обесценивать.

Дальше те формулировки, с которыми работали, и варианты изменений
* Вы допустили ошибку -> У нас проблема, Произошла нештатка, Ой как интересно получилось, Можем сделать по-другому. Переключить смысл с прошлого на будущее.
* Вы выбрали неудочное решение -> мы что-то не учли, есть вариант лучше, из каких вариантов мы выбирали, давайте еще подумаем
* Вы не выполнили -> Работа не доделана, Согласно требованиям, этого недостаточно..., Планируется что-то доделать? В работе отсутствует...
* Нужно было выбрать другое решение -> В следующий раз нужно; стоит пересмотреть; предлагаю попробовать
* Я сделал бы совсем по другому - это переход на личности, и из прошлого в будущее -> Как смотришь на то, чтобы сделать вот так, Рассмотрим альтернативы, А как можно еще это сделать? Можно сделать так...
* Ты работаешь как все; за воротами миллион - обесценивает.
* Вы конечно правы, но ... -> Я частично согласен... Есть другая точка зрения ... Я в работе сталкивался... Вы правы, и в то е время ...
* Позитив: Спасибо, сделано верно, и предлагаю сделать еще что-то...

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

Как общаешься сам с собой? Такими формулировками или нет? Ты даже не моешь встать рано замените на "предлагаю завтра встать пораньше".

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

Сообщение: Привет, что там с задачей? Паника и напряженка, излишний контроль. У нее пример: руководитель спрашивает "Мы за последние полгода nps считали ..." - эмоции. Потому справилась спросила - а что? - Инвестор запросил, если есть - отправим. Рабочая ситуация. Тут идея - до вопроса дать контекст. Я вспомнил, что тут была такая задача, что с ней происходит. Или что-то еще.

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

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

#Teamlead Яна Фёдорова. ИмаДЖУНариум — представление джунов о лидах. Яна пришла в тестирование из преподавания английского. Она умеет работать с обратной связью от учеников, и применила это для джунов. Реальное исследование, анонимный опрос 100 джунов и обработка результата, именно этим доклад интересен. Джуны - актуальная тема: 120 курсов по 100 джунов в месяц - 12к новичков на рунке. В курсах рассказывают, что с руководителем легко и можно классно пообщаться, и новички из ВУЗов приходят с этим ожиданиями. Если меняют специализацию, то легче, уже есть понимание, что происходит.

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

В исследовании 100 джунов рассказали кейсы взаимодействия с руководителем в ответ на открытый вопрос.
* 17% - супер-тимлид
* 26% - не взаимодействую с тимлидом, созвоны раз в месяц
* 44% - работать невозможно, терплю ради стажа, избегаю взаимодействия
* 13% - прекратили сотрудничество, не сработались

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

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

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

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

Как джуны оценивают лидов:
* Просто лид. Говорят, что лидом делают хорошего разработчика и он превращается в просто лида. И ничего не поменял.
* Душа компании. Весельчаки, заводные. Но если постоянно весело - пропадает серьезность, и подчиненные перестают всерьез работать, про задачи - отшучиваются
* Бабаушка. О тебе всегда заботятся, на 1:1 хочется закутаться в пледик
* Токсичный лид: токсик - современный мем. Считает, что делает одолжение, что ты работаешь, отпускает шутки. Много новеньких, потому что старенькие не задерживаются, новенькие тоже уходят, и потом читаем в интернете "ужасная компания", а не "ужасный Иван Иванович"

Руководители про джунов
* Ботаник. Читает пользовательское соглашение, читает все требования, работают тщательно, но очень долго
* Проактивный. Первые в очереди на выгорание, давайте все, готовы работать все время. За ними надо следить - могут сгореть.
* Виноват не я! Так сложилось. Стремятся переложить не только ответственность, но и задачи.
* Младенец. Хотят прямой ответ на вопрос, не любят исследовать, пояснения, наставления, все показать.
* Память золотой рыбки: пришел-спросил-забыл. Спросил кого спросить - не спросил, забыл. Что делал вчера - не помнит.

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

Тимлид - как препод. Джуны - как студенты первого курса. Они обычно приходят с горящими глазами, и дальше зависит от того, как выстроен процесс.

Что делать? Общаться словами через рот. Коммуницируйте.

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

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

#Teamlead Сергей Яныкин из СберМаркет: Как и зачем тимлиду расти выше по карьере. Возможный путь из тимлида - в руководители многих команд и дальше в CTO/CPO/CFO и так далее. Для начала надо решить, стоит ли по нему идти?

Демотиваторы.
* Точно надо будет больше работать. Пример календаря - у него сихрон 2 часа, 2-3 часа с семьей, потом разгребает все что нужно.
* Вы всегда будете плохим. Вы вне команды, где-то начинаете закручивать гайки на перформанс, ребята видят, что вы поменялись - стали плохим. А если наоборот, комфортно для подчиненных, то плохой для руководителя.
* Неопределенность процессов. Для команды понятно - scrum, kanban, ретро, дейли. Выше фреймвоков обычно нет, есть большая специфика.
* Работа с зарплатами и бюджетом. И кейсы, когда подчиненные получает больше. Дали 50к на повышение зарплат на 10 человек - как поделить, и кто-то будет недоволен, скажет что так мало.

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

Как сделать level up?

1. Подготовить себя - будет больше переключений контекста и другие задачи, к этому надо готовиться.
* Управление проектами и командами. Где-то есть проджекты, а где-то нет - и надо вести проекты, делать арбитраж, искать бюджеты, фасилитация встреч и так далее. Книги: Larson An elegant puzzle. Том Демарко Deadline. Голдратт Цель.
* Многозадачность, и много входов по задачам: ИБ, инфра, HR, смежники. Книга - Максим Дорофеев Джедайские техники.
* Ситуационное руководство. Direct-Coaching-Support-Delegating
* Продукт. Цель миссия и стратегия компании. Если у компании нет - плохо. Понимание, какими метриками оперирует компания. Книги: Cagan Inspired. Румельт Хорошая стратегия, плохая стратегия.
* Техника. Алгоритмы и паттерны проектирования. Мартин Чистая архитектура.

2. Подготовить команду. Зачем: вас промоутят, команда без руководителя - она перестала так же перформить.
Метрики: velocity plan-fact; cumulative diagram - поиск bottleneck, predict lead time - предсказание поставок и срока ожидания.

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

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

Кейс после отпуска:
* команда работает также - премия
* команда работала хуже - как улучшится
* команда работала лучше - уволили, вы руководитель мешал

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

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

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

#Teamlead проходит вместе с #KnowlegeConf и #Techlead, и этот доклад - про архитектуру. Руслан Сафин из Byndyusoft: Раз архитектура — as Code, почему бы её не покрыть тестами?! Такие тесты могут обеспечить актуальность архитектуры и проверить соблюдение принципов архитектуры. В докладе были примеры и инструменты, которые они выложили в open source.

Architecture As Code. Архитектура определяет принципы, на которых строится взаимодействие между сервисами. Это не просто картинка взаимодействующих сервисов. Картинка - наглядна, но принципов на ней нет. Картинка хороша для коммуникации, но у нее нет версионирования, и нельзя сделать сравнение. Поэтмоу и появился Architecture As Code: описываем схемы на языке, картинка строится автоматически. Распространенные инструменты: PlantUML и Structurizr, есть и другие. Когда описываем взаимодействие сервисов в PlantUML, описываем сервисы и их взаимодействие.

Проблемы архитектур:
* не актуальность - при чем часто еще сложно разобраться,
* декларативность: показывает, что есть business logic - repository - db. А можно ли напрямую?
* контроль - есть договоренность, что напрямую нельзя, но новичок не знал - и сделал

Решение проблем - через автоматизацию, тесты по архитектуре.
1. Актуальна ли архитектура проду?
2. Соблюдает ли архитектура выбранные принципы.

Дальше разбор на примере, в котором есть внешние сервисы и внутренний периметр, разделенные предохранительным уровнем, а внутри база данных с обращением через репозитории.

Откуда брать происходящее на проде
* Service mesh и реальный трафик. Действительно реальность. Но: (1) нет редких связей, сложно симулировать и потому долгая обратная связь - только с прода
* Infrastructura as code - она дает знания о возможных связях: конфиги кубера с обращениями, топики кафки и так далее. Информации там больше. Можно проверить надежность - сколько подов запущено, действительно ли они на разных нодах. Мы из обоих источников формируем списки сервисов и структуру связей и сравниваем. B в докладе - пример сравнения, он сделал open source реализацию такого сравнения.

Проверка принципов.
* anti corruption level - на границе есть адаптеры, и с внешними сервисами общение только через них. Помечаем адаптеры и внешние сервисы тегам, и проверяем, что внешние сервисы только через них.
* DB пассивна, а обращение к ней - только через репозитории - тоже разметка сервисов-репозиториев, и проверка, что из репозитория единственная исходящая связь через базу данных, а в базе данных - только входящая из репозитория.
* Внешние REST - только через API gateway - тип связи
* Операции записи - только через оркестратор бизнес-процессов, так как у него механизм компенсирующих транзакций - красим связи чтение-запись, и проверяем, что запись только у оркестратора.
Для проверки принципов мы раскрасили сервисы и атрибуты - важно, чтобы эта раскраска сопоставлялась с конфигами на проде и проверялась тестами соответствия проду. Иначе в архитектуре пометили связь read only, а в конфиге открыты любые обращение - контроля нет.

Тесты включаются в общую систему тестов. Если на этапе разработки поправили конфиг так, что архитектура нарушена, то при разворачивании на СI/CD тест упадет. Принципы архитектуры могут нарушаться случайно и сознательно. Тесты отсеют изменения по незнанию. А для соблюдения принципов нужно approve архитектора на изменения тестов.

Трудоемкость: 2 чел-нед архитектора + 2 чел-нед разработчика + 0.5 чел-нед девопса.

Результат: актуализировали архитектуру, привели к единым конвенциям, нашли топики кафки, куда только писали и не читали, нашли неиспользуемые зависимости в конфигах и коде, актуализировали понимание внешних систем, измерили и зафиксировали архитектурный техдолг, переключили на api gateway все необходимые зависимости, убрали дублирование в конфигах и архитектуре

Бонус для монолита. Другая команда у них посмотрела доклад - и написала проверку для архитектуры модульного монолита. Тоже в open source, можно брать.

#Teamlead Наталия Смирнова. Как подготовить идеальную встречу в формате брейншторма. Метод известен давно, но попытка провести часто заканчивается без результата: появляется множество идей, с которыми непонятно что делать, или идут бесконечные споры без результата. Наталья рассказывала о формате, который позволяет получить результат.

Брейншторм придумал Alex Osborn. Правила: не критикуем идеи; больше идей богу идей; любые идеи приветствуются, идеи порождают другие и снимают опасения сказать глупость; комбинируем идеи для получения новых.

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

Как действовать. (1) Организационный план: Цель, Продукт встречи, Люди, Возможные проблемы на встрече. (2) Фасилитационный план обсуждения.

Цель фокусирует встречу. Например, идеи для понижения затрат для продвижения рекламы, или идеи для нового сегмента пользователей. Фокус есть, пошел поток идей. Что по итогам? Сколько идей забрать, какие критерии хорошей идеи? Например топ-10 с плюсами и минусами. Или отсортировать по затратам. Приглашенные участники, их опыт. Круто позвать с разным опытом - чтобы была новизна. Необычная локация: за город, если есть бюджет, другая переговорка, что-то креативное в знакомой переговорке. Проблемы: проговорили всю встречу, проспорили, ушли внутрь и не вернулись.

Проблемы призван снимать фасилитационный план. 4 фазы встречи, для каждого - форматы и примеры.
0 - легализация креативного мышления без критики. Модельное упражнение, например, встреча в лесу - что можно сделать со мхом, идея - можно орать, не стесняясь.
1. Сбор данных и генерация идей с выходов в зону стонов. Сначала каждый генерит любые идеи индивидуально. Потом делим на малые подгруппы, в каждой - своя тема, например, сегменты рынка или портреты пользователей, потом обсуждаем.
Как обсуждать не критикуя? Вопросы только на понимание.

1а. Формат 1-2-4-все или 1-3-6-все (если 12). Сначала каждый свое, потмо объединяет, кластеризует, комбинирует.
1б. World cafe. Сначала генерация по столикам, а потом - переход, знакомимся с идеями и порождаем новые. Зона стонов может быть уже здесь. В конце владельцы плакатов рассказывают всем.

2. Перевести из зоны стонов в сходящееся решение. Голосование как выбор предпочтительных идей. Без критики. В world cafe можно по разному правила, за что голосовать - за плакат или идеи на нем.

3. Выработать решение. У вас есть, например, 5 идей и надо почеленджить.
3а - Классифицируем. Разделить про ресурсам и ценности.
3б - Сценарии: что будет, если сделать, и что, если не сделать. Две группы, одна по позитивным сценариям, другая - по негативным
3в - Три направления мышления: оптимисты, пессимисты, и как сделать
3г - Ценность - для компании, для клиентов, для партнеров - тоже работа в группах.
В этой части можно использовать один формат или несколько, в зависимости от целей встречи.

#Teamlead Александр Коротков из Тинькофф. Автоматизация без бед. Когда "да", а когда "нет"? Основной тезис доклада: процессы важнее автоматизации, потому что автоматизация работает только при регулярных процессах, если у вас хаос, то автоматизация не поможет. Более того, побочные эффекты автоматизации могут нарушить отлаженный процесс, например, отвалить существенную часть. Например, при изменении автоматизации workflow задач случайно отвалили интеграцию с ботом, который напоминал о review - и время ревью выросло с нескольких часов до пары дней, потому что разработчики привыкли, что о review напоминает бот и эти задачи смотреть не надо. Для оценки упорядоченности процесса используется Кеневин фреймворк. Но хаос в процессе может быть скрытым, был пример, когда тестировщики массово скипали красные тесты, потому что они краснели из-за нехватки CPU.

И в конце - общий алгоритм работы.
1. Убедиться что мы в ordered-зоне - то есть процессы отлажены
2. Определить узкое место в процессе. Если можно расшить - расшиваем, если нет - болевую точку справа
3. Прикидываем профит и как оцениваем
4. Принимаем решение
5. Автоматизируем по возможности MVP
6. Оцениваем результат.
7. Переводим автоматизацию в complicated|obvious - чтобы не свалиться в chaotic.

Я отмечу, что в целом все рассказанное разумно, но если пойти в область enterprise-разработки, то там часто невозможно стабилизировать процесс до его автоматизации из-за эффекта масштаба. Конечно, бизнес понимает, что автоматизация - это относительно жестко, и старается пропустить какие-то тестовые прогоны процесса с поддержкой на Excel и другими подручными средствами, но это не всегда возможно, и по-любому воспроизводство на масштабе всегда меняет процесс. Особенно это касается, когда новый процесс оптимизирует старый. И автоматизация процесса в темпе его становления - отдельная увлекательная задача, которую я решал. Но в целом - все верно.

Последний доклад первого дня #Teamlead я слушал на треке #KnowledgeConf. Анастасия Граф. База знаний — конструктор, или Как угодить всем. Практический доклад по созданию базы знаний в небольшой компании Maxim Technology - это разработка платформы для Taxi Maxim, третий агрегатор в России. У Анастасии команда 7 человек технических писателей, которые на входе все были джунами, сейчас каждый вырос. Задача - решить вопрос с документацией, создав базу знаний.

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

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

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

Как это реализовано технически?

Классификация контента.
* Глоссарий. Иначе война. Определение терминов, которое везде.
* Справочник - один короткий вопрос. Как только статья разрослась и отвечает на несколько вопросов - делим
* Старица книги. На входе была задача про две книги: для бизнеса - что делает и для разработчиков - как сделано и почему.

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

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

Отчеты confluence - подборка по меткам и по свойствам страницы. Отчет по свойствам - метки и фильтры. Общий и тематический глоссарии делают из них. Три типа меток.
* Метка статуса - готовность документа: В работе - ревью - Опубликована - На корректировку.
* Тематические метки, для ограничения поиска
* Технический метки - классификация по назначению, например "термин"
Макроы: сделать подборку (поиск), сделать термин, отчет по свойствам страницы для сборки глоссария, содержимое по меткам.

У них нет секретов, смотреть можно все. Это особенность. Если права есть появляется сложность: вы готовить отчет, но коллега может не видеть. Переиспользование контента позволяет обновлять максимально быстро. А отчеты дают тематические выборки, поэтому можно обновлять или проверять по темам, когда что-то изменилось.

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

Они используются только доступный из коробки функционал. И в вопросах пришла очень интересная инфа: оказывается, плагин плагин confluence, который используется для создания словарей, сливает все словари в облако разработчикам в Германию...

Ну а я в заключении зову всех завтра в 10 утра на свой доклад про модель личности.