В 16:20 встречаемся на следующих докладах и мастер-классах:
⠀
🔹Зал «Конгресс-холл». Задокументировать всё. Семён Факторович (documentat.io).
⠀
Если вы в очередной раз не смогли найти, как у вас что-то работает, и первой мыслью было «А давайте всё задокументируем!», то Семён поможет разобраться, какие задачи стоят за этой фразой на самом деле, как уметь эти задачи понимать, между собой различать и выбирать подходящее решение.
⠀
🔹Зал «Пекин+Шанхай». Как исцелять команду в кризисных ситуациях. Светлана Гончар (Neoflex).
⠀
В рамках доклада Светлана даст четкий алгоритм действий, как диагностировать психологическое состояние команды, как понять, какие инструменты и в каких случаях использовать, если команда оказалась в кризисной ситуации с повышенной неопределенностью.
⠀
🔹Зал «Дели+Калькутта». Воркшоп-игра «Галактика» от Екатерины Лисейчевой (Мандариновая лиса) и Александра Белякова (GAMIFY THIS): от проблемы до найденного решения.
⠀
Это формат нетворкинга по командам для решения своих задач. Комбинируем тимлидов с тимлидами, продактов с продактами, etc.
⠀
🔹Зал «Бангалор». Легкий старт: как мониторить инженерные практики с помощью данных. Павел Колосов (Qbigtech (ex Admitad)).
⠀
В своём докладе Павел расскажет о том, каким образом без ресурсных вложений в аналитическую работу выявить проблемы в работе инженерной команды и вовремя принять корректирующие решения, а также приведёт несколько живых примеров для подкрепления своих тезисов.
⠀
🔹Зал «Уфа». Результаты исследования российских IТ-решений по управлению знаниями KMS tools. Владимир Лещенко (KM talks).
⠀
Сейчас наблюдается возрастающий интерес к IТ-инструментам управления знаниями в связи с необходимостью перестройки бизнес-процессов и необходимостью импортозамещения. Владимир в своем докладе представит результаты независимого исследования современных IТ-решений как итогового каталога инструментов.

⤵️⤵️⤵️

🔹Зал «Сингапур». Автоматизация без бед. Когда "да", а когда "нет"? Александр Коротков (Тинькофф)
⠀
Часто можно услышать, что автоматизация — это, конечно, хорошо. Но всегда ли это так? Может ли автоматизация принести больше вреда, чем пользы, если применять ее несвоевременно? В докладе Александр расскажет, как определить наилучший момент для автоматизации и создать настоящую ценность.
⠀
🔹Зал «Рио». Встреча с Программным комитетом TeamLead Conf
⠀
🔹Зал «Кейптаун». Как руководителю не тратить время на информационный мусор? Алексей Морозов (Научные исследования социальных инноваций).
⠀
Карьерный рост и амбициозные цели вынуждают постоянно учиться, ставить навыки, входить в новую для себя область. Времени все меньше и потому его ценность выше. Нужны инструменты для быстрой оценки информации, для отсева информационного мусора, чтобы не тратить свое время на интеллектуальных клоунов.
⠀
🔹Зал «Найроби+Касабланка». Зачем разработчику LLM?
⠀
На круглом столе рассмотрим преимущества технологии Copilot в области кодирования. Обсудим возможности и подходы к использованию нейросетей при разработке архитектуры IT-систем и ответим на острый вопрос — сможет ли ИИ в будущем заменить человека в сфере программирования.

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

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

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

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

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

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

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

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

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

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

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

Как джуны оценивают лидов:
* Просто лид. Говорят, что лидом делают хорошего разработчика и он превращается в просто лида. И ничего не поменял.
* Душа компании. Весельчаки, заводные. Но если постоянно весело - пропадает серьезность, и подчиненные перестают всерьез работать, про задачи - отшучиваются
* Бабаушка. О тебе всегда заботятся, на 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, можно брать.

Друзья, в 17:30 ждём вас на последних докладах первого дня TeamLead++ Conf 2023:

🔹Зал «Конгресс-холл». Теряем доверие, а потом пробуем его вернуть. Серёжа Попов (Skillbox)

Доклад поднимает тему важности доверия в командной работе и причин, по которым руководители регулярно разрушают его. Спикер подсветит моменты, в которых доверие теряется и последствия этого. Расскажет о возможностях восстановления.

🔹Зал «Пекин+Шанхай». Неизбежное сопротивление без потери рассудка. Александр Крылов (Bimeister).

Есть ли варианты сделать все так, чтобы и изменения внедрить, и не разругаться с коллективом? Кажется, что варианты есть.

🔹Зал «Дели+Калькутта». Продолжение воркшоп-игры «Галактика» от Екатерины Лисейчевой (Мандариновая лиса) и Александра Белякова (GAMIFY THIS): от проблемы до найденного решения.

🔹Зал «Бангалор». Как правильно принимать неправильные решения. Дарья Рябченко (Холдинг Т1, Группа Иннотех).

Этот доклад отвечает на вопрос, что делать, если на «правильно» нет ни времени, ни остальных ресурсов? Можно ли с минимальной болью сделать «неправильно»?

🔹Зал «Уфа». База знаний — конструктор, или Как угодить всем. Анастасия Граф (Maxim Technology).

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

🔹Зал «Сингапур». Как мы ВКонтакте ускоряем t2m c помощью ML. Михаил Шваркунов (VK, ВКонтакте).

Михаил расскажет, как применять ML для ускорения работы с автотестами.

🔹Зал «Рио». Встреча с Программным комитетом TeamLead Conf

🔹Зал «Кейптаун». А что, если разделить команду? Елена Елизарова (СберЗдоровье).

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

🔹Зал «Найроби+Касабланка». Зачем разработчику LLM? Продолжение круглого стола

#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г - Ценность - для компании, для клиентов, для партнеров - тоже работа в группах.
В этой части можно использовать один формат или несколько, в зависимости от целей встречи.

Друзья, мы очень хотим делиться с вами в сторис атмосферой на площадке, но нам не хватает голосов ☹️

Проголосуйте, пожалуйста, за канал ☺️

https://t.iss.one/TeamLeadChannel?boost

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

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

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

Друзья, в 10:00 ждём вас на первые доклады:
⠀
🔹Зал «Конгресс-холл». Карьерные кризисы как тренд нового времени. Юлия Аравина.
⠀
Из доклада участники узнают о типичных карьерных кризисах, которые происходят сейчас в IT, о внутренних блокерах, которые мешают что-то менять, а также получат практические советы о том, как это можно побороть.
⠀
🔹Зал «Пекин+Шанхай». Практический алгоритм действий для начинающих тимлидов. Капитолина Кузнецова (СберМаркет).
⠀
Капитолина расскажет, как справляться с ощущением хаоса и потери контроля в первые месяцы работы руководителем.
⠀
🔹Зал «Бангалор». Мы не будем делать базу знаний, и как антропология помогла нам это понять. Рита Канис (Just AI).
⠀
Бывало у вас такое, что вы делали базу знаний, а потом поняли, что она не решает изначальную проблему? Рита расскажет о методах из корпоративной антропологии, которые вы можете применить, чтобы понаблюдать за своими коллегами, процессами и культурой и найти подходящее именно им решение.
⠀
🔹Зал «Уфа». Отвечаем осмысленно. Валентина Уржумова (Dominion).
⠀
Из доклада Валентины узнаем, как давать ответы так, чтобы стать источником ясности и вдохновения. Посмотрим, как ответы могут препятствовать обучению и обмену знаний между командами и как это исправить.
⠀
🔹Зал «Сингапур». Назад в будущее. Как мы выстраиваем процесс управления архитектурой ИС. Павел Мутовин (Иркутская нефтяная компания).
⠀
Павел поделится тем, как они выстраивали подходы, выбирали инструменты и адаптировали под свои нужды решения для управления архитектурой IT-экосистемы нефтяной компании. Доклад будет интересен работникам IT-подразделений корпораций, основная деятельность которых не связана с разработкой ПО.
⠀
🔹Зал «Кейптаун». Меняя себя и других — понимай устройство: инженерная модель личности. Максим Цепков (mtsepkov.org).
⠀
Максима надо просто приходить слушать — огромный кругозор в разных моделях и методологиях позволяет ему находить далеко не самые очевидные закономерности и выискивать новые нюансы там, где, казалось бы, все очевидно.

Чтобы вам было проще ориентироваться на площадке, ловите схемы 🙌

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующие доклады и мастер-классы стартуют в 11:20
⠀
🔹Зал «Конгресс-холл». Как писать хороший код в аутсорсе. Фёдор Борщёв (Федя и Самат).
⠀
В своем докладе Фёдор поделится секретами успешной аутсорс-разработки в части переиспользования кода и внедрения стандартов, а также ответит на вопросы: зачем инвестировать в DX и можно ли подружить программистов из аутсорса с программистами инхаус?
⠀
🔹Зал «Пекин+Шанхай». Как начать руководить незнакомыми тебе людьми. Марина Перескокова (Яндекс.Беспилотные технологии).
⠀
В рамках доклада участники получат алгоритм для руководителя, который попадает на проект с незнакомыми людьми и новыми технологиями. Узнают, как найти точки опоры в команде и какие действия предпринять в первую очередь в четырех направлениях: Люди, Продукт, Процессы, Технологии.
⠀
🔹Зал «Дели+Калькутта». 5 способов организации командной работы. Мастер-класс от Вирны Штерн и Александра Зизы (Aletheia Digital).
⠀
На мастер-классе мы разберем 5 ситуаций организации командной работы в IT, отличающиеся по целям, результатам, правилам, а также практики и поведение руководителя, которые стали обязательными для управления IT-командой.
⠀
🔹Зал «Бангалор». Нам не по пути: как правильно увольнять. Валерия Воронина (Холдинг Т1, Группа Иннотех).
⠀
Это ведь еще одна очень важная часть работы с командой. Вообще, увольнять сотрудников эмоционально сложно, но когда у тебя есть четкий план действий, ты сводишь эту составляющую к минимуму. У Валерии этот план есть. Послушаете — будет и у вас.
⠀
🔹Зал «Уфа». Обучение проектированию: аналитики и разработчики — есть контакт. Елена Попова (Directum).
⠀
Елена расскажет, как перейти от загрузки теории в головы людей до парного обучения аналитиков и разработчиков на примере кейсов, которые прожили их коллеги. При этом взаимодействие таких пар совсем не заканчивается на обучении. Приходите оценить полученный профит, набитые шишки, советы и выводы!

⤵️⤵️⤵️