#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, можно брать.
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? Продолжение круглого стола
🔹Зал «Конгресс-холл». Теряем доверие, а потом пробуем его вернуть. Серёжа Попов (Skillbox)
Доклад поднимает тему важности доверия в командной работе и причин, по которым руководители регулярно разрушают его. Спикер подсветит моменты, в которых доверие теряется и последствия этого. Расскажет о возможностях восстановления.
🔹Зал «Пекин+Шанхай». Неизбежное сопротивление без потери рассудка. Александр Крылов (Bimeister).
Есть ли варианты сделать все так, чтобы и изменения внедрить, и не разругаться с коллективом? Кажется, что варианты есть.
🔹Зал «Дели+Калькутта». Продолжение воркшоп-игры «Галактика» от Екатерины Лисейчевой (Мандариновая лиса) и Александра Белякова (GAMIFY THIS): от проблемы до найденного решения.
🔹Зал «Бангалор». Как правильно принимать неправильные решения. Дарья Рябченко (Холдинг Т1, Группа Иннотех).
Этот доклад отвечает на вопрос, что делать, если на «правильно» нет ни времени, ни остальных ресурсов? Можно ли с минимальной болью сделать «неправильно»?
🔹Зал «Уфа». База знаний — конструктор, или Как угодить всем. Анастасия Граф (Maxim Technology).
Какие типичные проблемы есть у баз знаний? Статьи устаревают, их сложно актуализировать из-за копипаста и сложно найти. Анастасия расскажет, как можно сделать эти проблемы менее острыми с помощью переиспользования контента между статьями и еще ряда интересных методик.
🔹Зал «Сингапур». Как мы ВКонтакте ускоряем t2m c помощью ML. Михаил Шваркунов (VK, ВКонтакте).
Михаил расскажет, как применять ML для ускорения работы с автотестами.
🔹Зал «Рио». Встреча с Программным комитетом TeamLead Conf
🔹Зал «Кейптаун». А что, если разделить команду? Елена Елизарова (СберЗдоровье).
Доклад о том, как выходить из ситуации, когда: большая команда занимается всем на свете; невозможно сделать шаг в сторону или повернуться без того, чтобы не задеть чей-то локоть; никто не понимает, к кому и с чем идти.
🔹Зал «Найроби+Касабланка». Зачем разработчику LLM? Продолжение круглого стола
Forwarded from Максим Цепков (Maxim Tsepkov)
#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г - Ценность - для компании, для клиентов, для партнеров - тоже работа в группах.
В этой части можно использовать один формат или несколько, в зависимости от целей встречи.
Брейншторм придумал 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
Проголосуйте, пожалуйста, за канал ☺️
https://t.iss.one/TeamLeadChannel?boost
Telegram
TeamLead Сonf++
Проголосуйте за канал, чтобы он получил больше возможностей.
Forwarded from Максим Цепков (Maxim Tsepkov)
#Teamlead Александр Коротков из Тинькофф. Автоматизация без бед. Когда "да", а когда "нет"? Основной тезис доклада: процессы важнее автоматизации, потому что автоматизация работает только при регулярных процессах, если у вас хаос, то автоматизация не поможет. Более того, побочные эффекты автоматизации могут нарушить отлаженный процесс, например, отвалить существенную часть. Например, при изменении автоматизации workflow задач случайно отвалили интеграцию с ботом, который напоминал о review - и время ревью выросло с нескольких часов до пары дней, потому что разработчики привыкли, что о review напоминает бот и эти задачи смотреть не надо. Для оценки упорядоченности процесса используется Кеневин фреймворк. Но хаос в процессе может быть скрытым, был пример, когда тестировщики массово скипали красные тесты, потому что они краснели из-за нехватки CPU.
И в конце - общий алгоритм работы.
1. Убедиться что мы в ordered-зоне - то есть процессы отлажены
2. Определить узкое место в процессе. Если можно расшить - расшиваем, если нет - болевую точку слева
3. Прикидываем профит и как оцениваем
4. Принимаем решение
5. Автоматизируем по возможности MVP
6. Оцениваем результат.
7. Переводим автоматизацию в complicated|obvious - чтобы не свалиться в chaotic.
Я отмечу, что в целом все рассказанное разумно, но если пойти в область enterprise-разработки, то там часто невозможно стабилизировать процесс до его автоматизации из-за эффекта масштаба. Конечно, бизнес понимает, что автоматизация - это относительно жестко, и старается пропустить какие-то тестовые прогоны процесса с поддержкой на Excel и другими подручными средствами, но это не всегда возможно, и по-любому воспроизводство на масштабе всегда меняет процесс. Особенно это касается, когда новый процесс оптимизирует старый. И автоматизация процесса в темпе его становления - отдельная увлекательная задача, которую я решал. Но в целом - все верно.
И в конце - общий алгоритм работы.
1. Убедиться что мы в ordered-зоне - то есть процессы отлажены
2. Определить узкое место в процессе. Если можно расшить - расшиваем, если нет - болевую точку слева
3. Прикидываем профит и как оцениваем
4. Принимаем решение
5. Автоматизируем по возможности MVP
6. Оцениваем результат.
7. Переводим автоматизацию в complicated|obvious - чтобы не свалиться в chaotic.
Я отмечу, что в целом все рассказанное разумно, но если пойти в область enterprise-разработки, то там часто невозможно стабилизировать процесс до его автоматизации из-за эффекта масштаба. Конечно, бизнес понимает, что автоматизация - это относительно жестко, и старается пропустить какие-то тестовые прогоны процесса с поддержкой на Excel и другими подручными средствами, но это не всегда возможно, и по-любому воспроизводство на масштабе всегда меняет процесс. Особенно это касается, когда новый процесс оптимизирует старый. И автоматизация процесса в темпе его становления - отдельная увлекательная задача, которую я решал. Но в целом - все верно.
👍2
Доброе утро 🙌 Готовы ко второму дню конференции TeamLead++ Conf 2023? Будет также насыщенно и активно!
☕️ А пока мы предлагаем выпить чашечку ароматного кофе (или чая) и полистать расписание
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Друзья, в 10:00 ждём вас на первые доклады:
⠀
🔹Зал «Конгресс-холл». Карьерные кризисы как тренд нового времени. Юлия Аравина.
⠀
Из доклада участники узнают о типичных карьерных кризисах, которые происходят сейчас в IT, о внутренних блокерах, которые мешают что-то менять, а также получат практические советы о том, как это можно побороть.
⠀
🔹Зал «Пекин+Шанхай». Практический алгоритм действий для начинающих тимлидов. Капитолина Кузнецова (СберМаркет).
⠀
Капитолина расскажет, как справляться с ощущением хаоса и потери контроля в первые месяцы работы руководителем.
⠀
🔹Зал «Бангалор». Мы не будем делать базу знаний, и как антропология помогла нам это понять. Рита Канис (Just AI).
⠀
Бывало у вас такое, что вы делали базу знаний, а потом поняли, что она не решает изначальную проблему? Рита расскажет о методах из корпоративной антропологии, которые вы можете применить, чтобы понаблюдать за своими коллегами, процессами и культурой и найти подходящее именно им решение.
⠀
🔹Зал «Уфа». Отвечаем осмысленно. Валентина Уржумова (Dominion).
⠀
Из доклада Валентины узнаем, как давать ответы так, чтобы стать источником ясности и вдохновения. Посмотрим, как ответы могут препятствовать обучению и обмену знаний между командами и как это исправить.
⠀
🔹Зал «Сингапур». Назад в будущее. Как мы выстраиваем процесс управления архитектурой ИС. Павел Мутовин (Иркутская нефтяная компания).
⠀
Павел поделится тем, как они выстраивали подходы, выбирали инструменты и адаптировали под свои нужды решения для управления архитектурой IT-экосистемы нефтяной компании. Доклад будет интересен работникам IT-подразделений корпораций, основная деятельность которых не связана с разработкой ПО.
⠀
🔹Зал «Кейптаун». Меняя себя и других — понимай устройство: инженерная модель личности. Максим Цепков (mtsepkov.org).
⠀
Максима надо просто приходить слушать — огромный кругозор в разных моделях и методологиях позволяет ему находить далеко не самые очевидные закономерности и выискивать новые нюансы там, где, казалось бы, все очевидно.
⠀
🔹Зал «Конгресс-холл». Карьерные кризисы как тренд нового времени. Юлия Аравина.
⠀
Из доклада участники узнают о типичных карьерных кризисах, которые происходят сейчас в IT, о внутренних блокерах, которые мешают что-то менять, а также получат практические советы о том, как это можно побороть.
⠀
🔹Зал «Пекин+Шанхай». Практический алгоритм действий для начинающих тимлидов. Капитолина Кузнецова (СберМаркет).
⠀
Капитолина расскажет, как справляться с ощущением хаоса и потери контроля в первые месяцы работы руководителем.
⠀
🔹Зал «Бангалор». Мы не будем делать базу знаний, и как антропология помогла нам это понять. Рита Канис (Just AI).
⠀
Бывало у вас такое, что вы делали базу знаний, а потом поняли, что она не решает изначальную проблему? Рита расскажет о методах из корпоративной антропологии, которые вы можете применить, чтобы понаблюдать за своими коллегами, процессами и культурой и найти подходящее именно им решение.
⠀
🔹Зал «Уфа». Отвечаем осмысленно. Валентина Уржумова (Dominion).
⠀
Из доклада Валентины узнаем, как давать ответы так, чтобы стать источником ясности и вдохновения. Посмотрим, как ответы могут препятствовать обучению и обмену знаний между командами и как это исправить.
⠀
🔹Зал «Сингапур». Назад в будущее. Как мы выстраиваем процесс управления архитектурой ИС. Павел Мутовин (Иркутская нефтяная компания).
⠀
Павел поделится тем, как они выстраивали подходы, выбирали инструменты и адаптировали под свои нужды решения для управления архитектурой IT-экосистемы нефтяной компании. Доклад будет интересен работникам IT-подразделений корпораций, основная деятельность которых не связана с разработкой ПО.
⠀
🔹Зал «Кейптаун». Меняя себя и других — понимай устройство: инженерная модель личности. Максим Цепков (mtsepkov.org).
⠀
Максима надо просто приходить слушать — огромный кругозор в разных моделях и методологиях позволяет ему находить далеко не самые очевидные закономерности и выискивать новые нюансы там, где, казалось бы, все очевидно.
👍1
TL++ 2023 maps.pdf
802.9 KB
Чтобы вам было проще ориентироваться на площадке, ловите схемы 🙌
Forwarded from Максим Цепков (Maxim Tsepkov)
Последний доклад первого дня #Teamlead я слушал на треке #KnowledgeConf. Анастасия Граф. База знаний — конструктор, или Как угодить всем. Практический доклад по созданию базы знаний в небольшой компании Maxim Technology - это разработка платформы для Taxi Maxim, третий агрегатор в России. У Анастасии команда 7 человек технических писателей, которые на входе все были джунами, сейчас каждый вырос. Задача - решить вопрос с документацией, создав базу знаний.
Общие требования:
* Легко делиться знаниями, каждый может написать статью. Тогда люди делятся, чтобы второй раз с вопросом не приходили
* Понятный язык, без перевода с ит-шного на бухгалтерский
* Легко найти, нет библиотекаря, который весь день отвечает на вопрос "где найти статью"
* Все материалы достоверны и актуальны
Написали, принесли читателям, реакция: у вас много лепестков и не одного цветка. Интересно, но использовать не получается. Они провели анализ и доработали.
* Людей пугал конфлюенс - сделали много инструкций на повседневные задачи.
* Требование понятного языка дополнили: статьи отвечают целям и задачам пользователя
* Надо не просто легко найти, а быстро собрать подборку документов по теме и желательно самостоятельно.
* И нужна методология оценки актуальности статей полуавтоматом.
Для этого использовали принципы:
* Классификация контента, стабильные типы.
* Принцип единого источника: если контент нужен в нескольких местах, мы не копируем, а вставляем, так что при правке изменяется сразу везде.
* Шаблоны и отчеты для создания и пересборки контента
* Понятный принцип определения статуса разработки контента и его актуальности.
Как это реализовано технически?
Классификация контента.
* Глоссарий. Иначе война. Определение терминов, которое везде.
* Справочник - один короткий вопрос. Как только статья разрослась и отвечает на несколько вопросов - делим
* Старица книги. На входе была задача про две книги: для бизнеса - что делает и для разработчиков - как сделано и почему.
Принцип единого источника - переиспользование информации. Поэтому итоговый документ всегда набор справочников и терминов, собранная вручную, или подборка, создаваемая с помощью отчетов.
Шаблоны. Сделали для глоссария и для страницы справочника - включает чек-лист. История изменений - спрятана, есть в режиме редактирования, там ссылки на задачи и договоренности. Страница книги - тоже есть шаблон с договоренности, в нем набор стандартах заголовков с чеклистами. Контент - в справочниках. Поскольку документы сборные, история страницы не показывает изменения. Поэтому новости публикуются на отдельном канале.
Отчеты confluence - подборка по меткам и по свойствам страницы. Отчет по свойствам - метки и фильтры. Общий и тематический глоссарии делают из них. Три типа меток.
* Метка статуса - готовность документа: В работе - ревью - Опубликована - На корректировку.
* Тематические метки, для ограничения поиска
* Технический метки - классификация по назначению, например "термин"
Макроы: сделать подборку (поиск), сделать термин, отчет по свойствам страницы для сборки глоссария, содержимое по меткам.
У них нет секретов, смотреть можно все. Это особенность. Если права есть появляется сложность: вы готовить отчет, но коллега может не видеть. Переиспользование контента позволяет обновлять максимально быстро. А отчеты дают тематические выборки, поэтому можно обновлять или проверять по темам, когда что-то изменилось.
Как только сделали - в компании начали использовать. Возможность делать подборки, которые всегда актуальны - ценно. Новую статью заводят с помощью макроса, если не умеют - то без него, техписы видят обновления и дальше дорабатывают: редактируют, ставят метки, чтобы органично включилось в систему.
Они используются только доступный из коробки функционал. И в вопросах пришла очень интересная инфа: оказывается, плагин плагин confluence, который используется для создания словарей, сливает все словари в облако разработчикам в Германию...
Ну а я в заключении зову всех завтра в 10 утра на свой доклад про модель личности.
Общие требования:
* Легко делиться знаниями, каждый может написать статью. Тогда люди делятся, чтобы второй раз с вопросом не приходили
* Понятный язык, без перевода с ит-шного на бухгалтерский
* Легко найти, нет библиотекаря, который весь день отвечает на вопрос "где найти статью"
* Все материалы достоверны и актуальны
Написали, принесли читателям, реакция: у вас много лепестков и не одного цветка. Интересно, но использовать не получается. Они провели анализ и доработали.
* Людей пугал конфлюенс - сделали много инструкций на повседневные задачи.
* Требование понятного языка дополнили: статьи отвечают целям и задачам пользователя
* Надо не просто легко найти, а быстро собрать подборку документов по теме и желательно самостоятельно.
* И нужна методология оценки актуальности статей полуавтоматом.
Для этого использовали принципы:
* Классификация контента, стабильные типы.
* Принцип единого источника: если контент нужен в нескольких местах, мы не копируем, а вставляем, так что при правке изменяется сразу везде.
* Шаблоны и отчеты для создания и пересборки контента
* Понятный принцип определения статуса разработки контента и его актуальности.
Как это реализовано технически?
Классификация контента.
* Глоссарий. Иначе война. Определение терминов, которое везде.
* Справочник - один короткий вопрос. Как только статья разрослась и отвечает на несколько вопросов - делим
* Старица книги. На входе была задача про две книги: для бизнеса - что делает и для разработчиков - как сделано и почему.
Принцип единого источника - переиспользование информации. Поэтому итоговый документ всегда набор справочников и терминов, собранная вручную, или подборка, создаваемая с помощью отчетов.
Шаблоны. Сделали для глоссария и для страницы справочника - включает чек-лист. История изменений - спрятана, есть в режиме редактирования, там ссылки на задачи и договоренности. Страница книги - тоже есть шаблон с договоренности, в нем набор стандартах заголовков с чеклистами. Контент - в справочниках. Поскольку документы сборные, история страницы не показывает изменения. Поэтому новости публикуются на отдельном канале.
Отчеты confluence - подборка по меткам и по свойствам страницы. Отчет по свойствам - метки и фильтры. Общий и тематический глоссарии делают из них. Три типа меток.
* Метка статуса - готовность документа: В работе - ревью - Опубликована - На корректировку.
* Тематические метки, для ограничения поиска
* Технический метки - классификация по назначению, например "термин"
Макроы: сделать подборку (поиск), сделать термин, отчет по свойствам страницы для сборки глоссария, содержимое по меткам.
У них нет секретов, смотреть можно все. Это особенность. Если права есть появляется сложность: вы готовить отчет, но коллега может не видеть. Переиспользование контента позволяет обновлять максимально быстро. А отчеты дают тематические выборки, поэтому можно обновлять или проверять по темам, когда что-то изменилось.
Как только сделали - в компании начали использовать. Возможность делать подборки, которые всегда актуальны - ценно. Новую статью заводят с помощью макроса, если не умеют - то без него, техписы видят обновления и дальше дорабатывают: редактируют, ставят метки, чтобы органично включилось в систему.
Они используются только доступный из коробки функционал. И в вопросах пришла очень интересная инфа: оказывается, плагин плагин confluence, который используется для создания словарей, сливает все словари в облако разработчикам в Германию...
Ну а я в заключении зову всех завтра в 10 утра на свой доклад про модель личности.
👍3
Следующие доклады и мастер-классы стартуют в 11:20
⠀
🔹Зал «Конгресс-холл». Как писать хороший код в аутсорсе. Фёдор Борщёв (Федя и Самат).
⠀
В своем докладе Фёдор поделится секретами успешной аутсорс-разработки в части переиспользования кода и внедрения стандартов, а также ответит на вопросы: зачем инвестировать в DX и можно ли подружить программистов из аутсорса с программистами инхаус?
⠀
🔹Зал «Пекин+Шанхай». Как начать руководить незнакомыми тебе людьми. Марина Перескокова (Яндекс.Беспилотные технологии).
⠀
В рамках доклада участники получат алгоритм для руководителя, который попадает на проект с незнакомыми людьми и новыми технологиями. Узнают, как найти точки опоры в команде и какие действия предпринять в первую очередь в четырех направлениях: Люди, Продукт, Процессы, Технологии.
⠀
🔹Зал «Дели+Калькутта». 5 способов организации командной работы. Мастер-класс от Вирны Штерн и Александра Зизы (Aletheia Digital).
⠀
На мастер-классе мы разберем 5 ситуаций организации командной работы в IT, отличающиеся по целям, результатам, правилам, а также практики и поведение руководителя, которые стали обязательными для управления IT-командой.
⠀
🔹Зал «Бангалор». Нам не по пути: как правильно увольнять. Валерия Воронина (Холдинг Т1, Группа Иннотех).
⠀
Это ведь еще одна очень важная часть работы с командой. Вообще, увольнять сотрудников эмоционально сложно, но когда у тебя есть четкий план действий, ты сводишь эту составляющую к минимуму. У Валерии этот план есть. Послушаете — будет и у вас.
⠀
🔹Зал «Уфа». Обучение проектированию: аналитики и разработчики — есть контакт. Елена Попова (Directum).
⠀
Елена расскажет, как перейти от загрузки теории в головы людей до парного обучения аналитиков и разработчиков на примере кейсов, которые прожили их коллеги. При этом взаимодействие таких пар совсем не заканчивается на обучении. Приходите оценить полученный профит, набитые шишки, советы и выводы!
⤵️⤵️⤵️
⠀
🔹Зал «Конгресс-холл». Как писать хороший код в аутсорсе. Фёдор Борщёв (Федя и Самат).
⠀
В своем докладе Фёдор поделится секретами успешной аутсорс-разработки в части переиспользования кода и внедрения стандартов, а также ответит на вопросы: зачем инвестировать в DX и можно ли подружить программистов из аутсорса с программистами инхаус?
⠀
🔹Зал «Пекин+Шанхай». Как начать руководить незнакомыми тебе людьми. Марина Перескокова (Яндекс.Беспилотные технологии).
⠀
В рамках доклада участники получат алгоритм для руководителя, который попадает на проект с незнакомыми людьми и новыми технологиями. Узнают, как найти точки опоры в команде и какие действия предпринять в первую очередь в четырех направлениях: Люди, Продукт, Процессы, Технологии.
⠀
🔹Зал «Дели+Калькутта». 5 способов организации командной работы. Мастер-класс от Вирны Штерн и Александра Зизы (Aletheia Digital).
⠀
На мастер-классе мы разберем 5 ситуаций организации командной работы в IT, отличающиеся по целям, результатам, правилам, а также практики и поведение руководителя, которые стали обязательными для управления IT-командой.
⠀
🔹Зал «Бангалор». Нам не по пути: как правильно увольнять. Валерия Воронина (Холдинг Т1, Группа Иннотех).
⠀
Это ведь еще одна очень важная часть работы с командой. Вообще, увольнять сотрудников эмоционально сложно, но когда у тебя есть четкий план действий, ты сводишь эту составляющую к минимуму. У Валерии этот план есть. Послушаете — будет и у вас.
⠀
🔹Зал «Уфа». Обучение проектированию: аналитики и разработчики — есть контакт. Елена Попова (Directum).
⠀
Елена расскажет, как перейти от загрузки теории в головы людей до парного обучения аналитиков и разработчиков на примере кейсов, которые прожили их коллеги. При этом взаимодействие таких пар совсем не заканчивается на обучении. Приходите оценить полученный профит, набитые шишки, советы и выводы!
⤵️⤵️⤵️
🔹Зал «Сингапур». Как не писать бесполезный код. Митя Кожевников (Mindbox).
⠀
В докладе спикер расскажет о том, почему писать код, не разобравшись в проблеме, — плохая идея, приведет примеры плохих и хороших решений из своего опыта.
⠀
🔹Зал «Рио». Развитие управленческой зрелости у молодых тимлидов. Мастер-класс от Александра Захарова (TSQ Consulting).
⠀
Для эффективного решения проблемы необходимо найти ее исходную точку. Это и предлагает отработать Александр в своём воркшопе. Помимо этого, будут затронуты темы набора компетенций эффективного руководителя и поведенческих индикаторов. Будет интересно!
⠀
🔹Зал «Кейптаун». Сеньор в вакууме. Почему вы не тимлид? Александр Свеженцев (Ozon).
⠀
Какие могут быть блокеры для того, чтобы стать тимлидом? И не кроется ли причина в самом претенденте на должность?
⠀
🔹Зал «Найроби+Касабланка». Архитектура от словаря: определения как базис проектирования. Мастер-класс от Екатерины Лысенко (RoboGate).
⠀
В рамках мастер-класса вы узнаете, как словарь может стать вашим гидом в DDD. Погрузитесь в мир определений и их влияния на архитектуру. Поупражняетесь в формулировке и узнаете секреты внедрения этого подхода.
⠀
В докладе спикер расскажет о том, почему писать код, не разобравшись в проблеме, — плохая идея, приведет примеры плохих и хороших решений из своего опыта.
⠀
🔹Зал «Рио». Развитие управленческой зрелости у молодых тимлидов. Мастер-класс от Александра Захарова (TSQ Consulting).
⠀
Для эффективного решения проблемы необходимо найти ее исходную точку. Это и предлагает отработать Александр в своём воркшопе. Помимо этого, будут затронуты темы набора компетенций эффективного руководителя и поведенческих индикаторов. Будет интересно!
⠀
🔹Зал «Кейптаун». Сеньор в вакууме. Почему вы не тимлид? Александр Свеженцев (Ozon).
⠀
Какие могут быть блокеры для того, чтобы стать тимлидом? И не кроется ли причина в самом претенденте на должность?
⠀
🔹Зал «Найроби+Касабланка». Архитектура от словаря: определения как базис проектирования. Мастер-класс от Екатерины Лысенко (RoboGate).
⠀
В рамках мастер-класса вы узнаете, как словарь может стать вашим гидом в DDD. Погрузитесь в мир определений и их влияния на архитектуру. Поупражняетесь в формулировке и узнаете секреты внедрения этого подхода.
🎁 Друзья, нам не терпится вручить вам подарки.
⠀
☀️ Согревающий термос, созданный специально для тимлидов, будет ваш, если ответите всего на 3-5 быстрых вопроса о ваших впечатлениях о конференции.
Для интервью ждём вас около стенда Онтико у Выхода 1 с 12:00 до 13:00 🙌
⠀
Также приходите за другими приятностями:
⠀
😎 За улыбку - стикерпак
⠀
💡За прохождение профильного квиза - крутые носки
⠀
💬 За пост или стори ВКонтакте, Telegram с отметкой официального канала через @ - перчатки
⠀
✅ За подписку на все наши каналы - шарф
⠀
☀️ Согревающий термос, созданный специально для тимлидов, будет ваш, если ответите всего на 3-5 быстрых вопроса о ваших впечатлениях о конференции.
Для интервью ждём вас около стенда Онтико у Выхода 1 с 12:00 до 13:00 🙌
⠀
Также приходите за другими приятностями:
⠀
😎 За улыбку - стикерпак
⠀
💡За прохождение профильного квиза - крутые носки
⠀
💬 За пост или стори ВКонтакте, Telegram с отметкой официального канала через @ - перчатки
⠀
✅ За подписку на все наши каналы - шарф
❤2🔥2🥰1🤔1
Анонс докладов, которые стартуют в 12:40
⠀
🔹Зал «Конгресс-холл». Как стимулировать креативное мышление в команде IТ-специалистов. Анна Обухова.
⠀
Анна рассмотрит методы создания условий для стимулирования роста креативных идей в IТ-команде. Подробно исследует три типа креативности и методы воздействия на соответствующие части мозга. Участники получат практические инструменты, которые помогут генерировать новые идеи в команде и индивидуально.
⠀
🔹Зал «Пекин+Шанхай». Как прийти руководителем в старую команду и все сломать. Николай Животворев (Okko).
⠀
Как, придя на новое место, взять и разобраться, оценить, что происходит. Посмотреть на оргструктуру, как едет, как не едет, где что мешает и т.д. Т. е. перед тем, как начать что-то делать — надо сначала понять, почему и как работает. История для тех, кто спешит делать. Идеологически история верная.
⠀
🔹Зал «Дели+Калькутта». 5 способов организации командной работы. Продолжение мастер-класса от Вирны Штерн и Александра Зизы (Aletheia Digital).
⠀
🔹Зал «Бангалор». Как отладка культуры обмена знаниями привела нас к созданию ведущего в отрасли инфоресурса и зародила направление DevRel. Артем Пластинин (АйТи Капитал).
⠀
Вопрос передачи знаний в организации не нов, как и идея создания внутреннего сообщества практиков. Но не так часто встретишь действительно живое комьюнити внутри компании. Артем поделится своим опытом, как им удалось сделать так, чтобы практики активно пользовались внутренним ресурсом.
⠀
🔹Зал «Уфа». Системный подход к адаптации тимлидов. Ольга Елисеева (Инфосистемы Джет).
⠀
Иногда нужно не строить целые вселенные из процессов, людей и инструментов, а просто собраться с руководителями и сделать что-то простое для решения определенной задачи. Ольга расскажет, как на инициативе быстро создать специфичный онбординг, и поделится наработками, чтобы помочь сэкономить и вам
⤵️⤵️⤵️
⠀
🔹Зал «Конгресс-холл». Как стимулировать креативное мышление в команде IТ-специалистов. Анна Обухова.
⠀
Анна рассмотрит методы создания условий для стимулирования роста креативных идей в IТ-команде. Подробно исследует три типа креативности и методы воздействия на соответствующие части мозга. Участники получат практические инструменты, которые помогут генерировать новые идеи в команде и индивидуально.
⠀
🔹Зал «Пекин+Шанхай». Как прийти руководителем в старую команду и все сломать. Николай Животворев (Okko).
⠀
Как, придя на новое место, взять и разобраться, оценить, что происходит. Посмотреть на оргструктуру, как едет, как не едет, где что мешает и т.д. Т. е. перед тем, как начать что-то делать — надо сначала понять, почему и как работает. История для тех, кто спешит делать. Идеологически история верная.
⠀
🔹Зал «Дели+Калькутта». 5 способов организации командной работы. Продолжение мастер-класса от Вирны Штерн и Александра Зизы (Aletheia Digital).
⠀
🔹Зал «Бангалор». Как отладка культуры обмена знаниями привела нас к созданию ведущего в отрасли инфоресурса и зародила направление DevRel. Артем Пластинин (АйТи Капитал).
⠀
Вопрос передачи знаний в организации не нов, как и идея создания внутреннего сообщества практиков. Но не так часто встретишь действительно живое комьюнити внутри компании. Артем поделится своим опытом, как им удалось сделать так, чтобы практики активно пользовались внутренним ресурсом.
⠀
🔹Зал «Уфа». Системный подход к адаптации тимлидов. Ольга Елисеева (Инфосистемы Джет).
⠀
Иногда нужно не строить целые вселенные из процессов, людей и инструментов, а просто собраться с руководителями и сделать что-то простое для решения определенной задачи. Ольга расскажет, как на инициативе быстро создать специфичный онбординг, и поделится наработками, чтобы помочь сэкономить и вам
⤵️⤵️⤵️
🔹Зал «Сингапур». Как роль Feature Lead превращает разработчиков в супергероев. Секреты эффективности и полезные инструменты. Александр Коныгин (Яндекс Вертикали).
⠀
Все мы знаем про техлидов в продуктах. Но бывают задачи и вне продуктов, затрагивающие сразу несколько блоков системы. В таком случае нам поможет техлид на фичу или фичалид. В чем особенность такой роли? А не является ли это просто проджектом? Об этом и многом другом и поговорим.
⠀
🔹Зал «Рио». Развитие управленческой зрелости у молодых тимлидов. Продолжение мастер-класса от Александра Захарова (TSQ Consulting).
⠀
🔹Зал «Кейптаун». Relax, take IT easy: как вернуть спокойствие в работу, даже если сейчас устал и хочешь уйти. 3 инструмента специально для технарей. Ольга Красильникова (Bercut).
⠀
Полезные инструменты, позволяющие взять себя в руки и поуправлять замкнутыми кругами, в которые все мы время от времени попадаем.
⠀
🔹Зал «Найроби+Касабланка». Архитектура от словаря: определения как базис проектирования. Продолжение мастер-класса от Екатерины Лысенко (RoboGate).
⠀
Все мы знаем про техлидов в продуктах. Но бывают задачи и вне продуктов, затрагивающие сразу несколько блоков системы. В таком случае нам поможет техлид на фичу или фичалид. В чем особенность такой роли? А не является ли это просто проджектом? Об этом и многом другом и поговорим.
⠀
🔹Зал «Рио». Развитие управленческой зрелости у молодых тимлидов. Продолжение мастер-класса от Александра Захарова (TSQ Consulting).
⠀
🔹Зал «Кейптаун». Relax, take IT easy: как вернуть спокойствие в работу, даже если сейчас устал и хочешь уйти. 3 инструмента специально для технарей. Ольга Красильникова (Bercut).
⠀
Полезные инструменты, позволяющие взять себя в руки и поуправлять замкнутыми кругами, в которые все мы время от времени попадаем.
⠀
🔹Зал «Найроби+Касабланка». Архитектура от словаря: определения как базис проектирования. Продолжение мастер-класса от Екатерины Лысенко (RoboGate).
Forwarded from Максим Цепков (Maxim Tsepkov)
#Teamlead Елена Попова из Directum. Обучение проектированию: аналитики и разработчики — есть контакт. Проектирование интеграции и развития продукта - зона совместной работы аналитиков и разработчиков, так как в обоих случаях существенны как требования заказчика и взаимодействие с ним, так и технические аспекты. Требовалось организовать обучение, в ходе которого аналитики и разработчики научатся это делать совместно. Обучение организовано в группах, при этом внутри группы аналитики и разработчики разбиты на пары, которые будут работать совместно. Обучение - практикум, в которых люди разрабатывают проекты решения конкретных кейсов и обосновывают их. Эталонное решение для кейса тоже есть, его разбирают после представления своих, но нет интенции, что оно единственно правильное.
Обучение основано на цикле Колба. Теория - Эксперимент - Конкретный опыт - Рефлексия - Теория. В обучении часто с теории, но реально можно начинать с любой фазы. Важно замкнуть в цикл.
Для обучения надо сделать теорию - описать процесс проектирование, разделение труда в нем. Теорию можно собирать по компании, но Эксперты не могут объяснить, почему принимают какое-то решение. Но можно собирать опыт и выявлять закономерности. А еще опираться на внешние источники, по интеграции у них как раз один из сотрудников проводил внешний курс, где был алгоритм, и они скомбинировали эту теорию с опытом компании, и получили теорию для курса.
Workflow практикума: Теория - постановка задачи - самостоятельная проработка - практика. Обучение по группам, в которых несколько пар аналитик+разработчик, у каждой группы - куратор, он играет роль заказчика. Каждая группа представляет свое решение, и потом куратор показывает и объясняет эталонное. Для работы над разными кейсами группы миксуют, сохраняя пары, и меняют куратора, поэтому получается разное взаимодействие.
Получилось удачно, участники рекомендуют. А собранная теория интеграции - завирусилась, ее пересылают и используют в проектах.
Естественно, после первого цикла провели рефлексию.
* Эталонное решение после демо групп слушать тяжело - поэтому эталон записали и отдали на самостоятельное знакомство в спокойной обстановке с последующим обсуждением на встрече.
* Предполагают, что на постановке задачи будут вопросы по теории, их нет - всем понятно, а практика показывает, что не понятно. И потому сами подготовили вопросы ребятам и маленькие учебные кейсы.
Практикум нарабатывает умение создавать несколько вариантов решений на основе стандартных вариантов, выбирать один и его обосновывать. Навык генерить и сравнивать варианты - полезный, это подтверждается практикой. Хотя они могут быть уродливее, чем первый попавшийся, часто именно они ложатся в основу решения. А требование выбора из вариантов повышает их осознание, облегчает аргументацию заказчику. Практикум включают режим исследования у обучающихся: не оценка правильно или нет - а оценка и аргументация.
Проектирование совместно с разработчиком, а не в режиме челночной дипломатии аналитика - сокращает трудоемкость, были реальные кейсы.
В конце - чек-лист, как повторить путь, там теория, концепция практикумов, подготовка кейсов, выбор кураторов... Кураторы нужны квалифицированные, и это не так просто. Но реально трудоемкость - это на этапе подготовке практикума и кейсов, один кейс - до 40 часов. А встреча для обучения - всего 4 часа, их можно выделить в операционке без проблем. Кураторов привлекают возможностью поиздеваться над обучаемыми :)
Обучение основано на цикле Колба. Теория - Эксперимент - Конкретный опыт - Рефлексия - Теория. В обучении часто с теории, но реально можно начинать с любой фазы. Важно замкнуть в цикл.
Для обучения надо сделать теорию - описать процесс проектирование, разделение труда в нем. Теорию можно собирать по компании, но Эксперты не могут объяснить, почему принимают какое-то решение. Но можно собирать опыт и выявлять закономерности. А еще опираться на внешние источники, по интеграции у них как раз один из сотрудников проводил внешний курс, где был алгоритм, и они скомбинировали эту теорию с опытом компании, и получили теорию для курса.
Workflow практикума: Теория - постановка задачи - самостоятельная проработка - практика. Обучение по группам, в которых несколько пар аналитик+разработчик, у каждой группы - куратор, он играет роль заказчика. Каждая группа представляет свое решение, и потом куратор показывает и объясняет эталонное. Для работы над разными кейсами группы миксуют, сохраняя пары, и меняют куратора, поэтому получается разное взаимодействие.
Получилось удачно, участники рекомендуют. А собранная теория интеграции - завирусилась, ее пересылают и используют в проектах.
Естественно, после первого цикла провели рефлексию.
* Эталонное решение после демо групп слушать тяжело - поэтому эталон записали и отдали на самостоятельное знакомство в спокойной обстановке с последующим обсуждением на встрече.
* Предполагают, что на постановке задачи будут вопросы по теории, их нет - всем понятно, а практика показывает, что не понятно. И потому сами подготовили вопросы ребятам и маленькие учебные кейсы.
Практикум нарабатывает умение создавать несколько вариантов решений на основе стандартных вариантов, выбирать один и его обосновывать. Навык генерить и сравнивать варианты - полезный, это подтверждается практикой. Хотя они могут быть уродливее, чем первый попавшийся, часто именно они ложатся в основу решения. А требование выбора из вариантов повышает их осознание, облегчает аргументацию заказчику. Практикум включают режим исследования у обучающихся: не оценка правильно или нет - а оценка и аргументация.
Проектирование совместно с разработчиком, а не в режиме челночной дипломатии аналитика - сокращает трудоемкость, были реальные кейсы.
В конце - чек-лист, как повторить путь, там теория, концепция практикумов, подготовка кейсов, выбор кураторов... Кураторы нужны квалифицированные, и это не так просто. Но реально трудоемкость - это на этапе подготовке практикума и кейсов, один кейс - до 40 часов. А встреча для обучения - всего 4 часа, их можно выделить в операционке без проблем. Кураторов привлекают возможностью поиздеваться над обучаемыми :)
❤2
Друзья, следующие доклады и мастер-классы ждут вас в 13:50
⠀
🔹Зал «Конгресс-холл». База знаний — зеркало организационных процессов. Александра Камзеева (Lamoda Tech).
⠀
Александра расскажет о совместной эволюции организационных процессов и передачи знаний: от стартапа ко взрослой компании на примере Lamoda Tech; и о том, как база знаний может быть одновременно и флюгером, и своеобразной спецификацией организационных изменений.
⠀
🔹Зал «Пекин+Шанхай». Новый дивный мир: как изменились мотивация и система ценностей разработчиков и что делать дальше? Алиса Бобовникова (Яндекс Такси).
⠀
Алиса расскажет, как менялась мотивация в сфере IТ с течением времени, как мотивировать людей, для которых деньги не являются главным стимулом.
⠀
🔹Зал «Дели+Калькутта». Обсудить и не по(д|с)раться: конструктивное обсуждение сложных вопросов. Мастер-класс от Рустама Агамалиева (rustamagamaliev.ru) и Максима Дорофеева (mnogosdelal.ru). *Потребуется собственный ноутбук
⠀
Почему стоит прийти: если вы ищете свежие идеи, хотите выйти за рамки стандартных презентаций и готовы поделиться своим опытом и послушать опыт других, этот формат для вас. Здесь каждый сможет внести свой вклад в обсуждение и, возможно, открыть для себя нечто новое.
⠀
🔹Зал «Бангалор». Как экспертам компании делиться знаниями и не тратить на это 100 часов. Дарья Мулык (Sibedge).
⠀
Во многих компаниях самыми ценными источниками знаний остаются эксперты. Их постоянно отвлекают вопросами со всех сторон, обычно не оставляя артефактов, которые могут помочь другим. Дарья расскажет про построение системы обучения, в которой знания эксперта превращаются в курс для всей компании.
⠀
🔹Зал «Уфа». Онбординг в большой команде: процессы, продукт, архитектурный ландшафт. Злата Занина (Независимый эксперт).
⠀
В больших IТ-компаниях и проектах всегда актуален вопрос онбординга и не только в части включения новых членов команды в проекты, но и при передаче знаний и обеспечении преемственности. Как сделать так, чтобы вчерашние новички сами уже помогали новым? Об этом в докладе Златы.
⤵️⤵️⤵️
⠀
🔹Зал «Конгресс-холл». База знаний — зеркало организационных процессов. Александра Камзеева (Lamoda Tech).
⠀
Александра расскажет о совместной эволюции организационных процессов и передачи знаний: от стартапа ко взрослой компании на примере Lamoda Tech; и о том, как база знаний может быть одновременно и флюгером, и своеобразной спецификацией организационных изменений.
⠀
🔹Зал «Пекин+Шанхай». Новый дивный мир: как изменились мотивация и система ценностей разработчиков и что делать дальше? Алиса Бобовникова (Яндекс Такси).
⠀
Алиса расскажет, как менялась мотивация в сфере IТ с течением времени, как мотивировать людей, для которых деньги не являются главным стимулом.
⠀
🔹Зал «Дели+Калькутта». Обсудить и не по(д|с)раться: конструктивное обсуждение сложных вопросов. Мастер-класс от Рустама Агамалиева (rustamagamaliev.ru) и Максима Дорофеева (mnogosdelal.ru). *Потребуется собственный ноутбук
⠀
Почему стоит прийти: если вы ищете свежие идеи, хотите выйти за рамки стандартных презентаций и готовы поделиться своим опытом и послушать опыт других, этот формат для вас. Здесь каждый сможет внести свой вклад в обсуждение и, возможно, открыть для себя нечто новое.
⠀
🔹Зал «Бангалор». Как экспертам компании делиться знаниями и не тратить на это 100 часов. Дарья Мулык (Sibedge).
⠀
Во многих компаниях самыми ценными источниками знаний остаются эксперты. Их постоянно отвлекают вопросами со всех сторон, обычно не оставляя артефактов, которые могут помочь другим. Дарья расскажет про построение системы обучения, в которой знания эксперта превращаются в курс для всей компании.
⠀
🔹Зал «Уфа». Онбординг в большой команде: процессы, продукт, архитектурный ландшафт. Злата Занина (Независимый эксперт).
⠀
В больших IТ-компаниях и проектах всегда актуален вопрос онбординга и не только в части включения новых членов команды в проекты, но и при передаче знаний и обеспечении преемственности. Как сделать так, чтобы вчерашние новички сами уже помогали новым? Об этом в докладе Златы.
⤵️⤵️⤵️
🔹Зал «Сингапур». Как извлечь двойную пользу из «плана Б». Кир Дергачев (Нетология).
⠀
Кир расскажет, какие типы ситуаций бывают, какие планы могут пригодиться и как соединить оба подхода, чтобы получить запасной план, который будет помогать ежедневно.
⠀
🔹Зал «Рио». Jobs to be done для тимлидов продуктовых команд. Мастер-класс от Александры Зебелевой (Независимый консультант).
⠀
Мастер-класс направлен на улучшение понимания потребностей пользователя/заказчика и погружение в контекст продукта. Цель - определить, какие сейчас джобы выполняет продукт.
⠀
🔹Зал «Кейптаун». Как научиться быстро включаться в работу? Приемы управления своим состоянием. Екатерина Скимен (Деловой клуб LivreLady).
⠀
В докладе представлены обработанные результаты опроса нескольких сотен человек. Методы, которые предлагает Екатерина, помогли не одному случайному человеку, а работают для многих, потому что отобраны с помощью статистики.
⠀
🔹Зал «Найроби+Касабланка». Строим свою Вселенную знаний с помощью AI (мастер-класс по созданию wiki). Алексей Рахманов (FUN&SUN).
⠀
Алексей предлагает попробовать на практике самостоятельно настроить свой AI, о чем он подробно рассказывал в своем докладе. В результате мастер-класса участники заберут с собой не только инструкции, но и уже готовые наработки, которые можно будет использовать у себя в организации.
⠀
Кир расскажет, какие типы ситуаций бывают, какие планы могут пригодиться и как соединить оба подхода, чтобы получить запасной план, который будет помогать ежедневно.
⠀
🔹Зал «Рио». Jobs to be done для тимлидов продуктовых команд. Мастер-класс от Александры Зебелевой (Независимый консультант).
⠀
Мастер-класс направлен на улучшение понимания потребностей пользователя/заказчика и погружение в контекст продукта. Цель - определить, какие сейчас джобы выполняет продукт.
⠀
🔹Зал «Кейптаун». Как научиться быстро включаться в работу? Приемы управления своим состоянием. Екатерина Скимен (Деловой клуб LivreLady).
⠀
В докладе представлены обработанные результаты опроса нескольких сотен человек. Методы, которые предлагает Екатерина, помогли не одному случайному человеку, а работают для многих, потому что отобраны с помощью статистики.
⠀
🔹Зал «Найроби+Касабланка». Строим свою Вселенную знаний с помощью AI (мастер-класс по созданию wiki). Алексей Рахманов (FUN&SUN).
⠀
Алексей предлагает попробовать на практике самостоятельно настроить свой AI, о чем он подробно рассказывал в своем докладе. В результате мастер-класса участники заберут с собой не только инструкции, но и уже готовые наработки, которые можно будет использовать у себя в организации.
👍1