Forwarded from topdatalab (Roman Zykov)
Про AI автоматизацию в кодинге!
Моя задача проста — писать код меньше, а делать больше.
Что использую я:
1. Github Copilot Pro — очень удобно быстро что-то поправить.
Доступны разные модели, в том числе Sonnet 3.7.
2. CLINE + DeepSeek API — дешево, у меня даже получалось что-то сделать в полностью автоматическом режиме.
Потом DeepSeek стал очень популярным, и его API временно перестало работать.
Сейчас всё вернулось, но API работает медленно.
3. Мой бот дата инженера:
https://chatgpt.com/g/g-67dbef1047b48191951a514758f9ffc5-data-engineer-topdatalab
Думал про популярный Cursor, пока не прочитал сравнение:
👉 Сравнение Cursor vs CLine на Reddit
Кратко:
— Окно контекста больше у CLINE
— Нет API ограничений
— Но стоит дороже
⸻
Сейчас изучаю:
📘 Прокачка промптов в CLine
Хочу добиться ещё большей автоматизации в больших проектах! 🚀
Моя задача проста — писать код меньше, а делать больше.
Что использую я:
1. Github Copilot Pro — очень удобно быстро что-то поправить.
Доступны разные модели, в том числе Sonnet 3.7.
2. CLINE + DeepSeek API — дешево, у меня даже получалось что-то сделать в полностью автоматическом режиме.
Потом DeepSeek стал очень популярным, и его API временно перестало работать.
Сейчас всё вернулось, но API работает медленно.
3. Мой бот дата инженера:
https://chatgpt.com/g/g-67dbef1047b48191951a514758f9ffc5-data-engineer-topdatalab
Думал про популярный Cursor, пока не прочитал сравнение:
👉 Сравнение Cursor vs CLine на Reddit
Кратко:
— Окно контекста больше у CLINE
— Нет API ограничений
— Но стоит дороже
⸻
Сейчас изучаю:
📘 Прокачка промптов в CLine
Хочу добиться ещё большей автоматизации в больших проектах! 🚀
Forwarded from it пингвин | data engineer
Недавний пост про джоины набрал много просмотров и репостов. Значит такая информация интересна.
Продолжим наваливать базу 🤝
Популярные вопросы с собесов (lvl junior):
1) В какой последовательности БД на самом деле выполняет команды запроса:
Ответ:
Порядок выполнения SQL-запроса:
1. FROM (и JOIN) – выбираются таблицы и соединяются
2. WHERE – фильтруются строки
3. GROUP BY – группировка данных
4. HAVING – фильтрация групп
5. SELECT – выбор полей (включая вычисляемые)
6. DISTINCT – удаление дубликатов
7. ORDER BY – сортировка результатов
8. LIMIT / OFFSET – ограничение вывода
Более удобный вид:
2) UNION ALL vs UNION - в чем разница?
UNION ALL:
• Не удаляет дубликаты
• Работает быстро (простое объединение)
• Сохраняет исходный порядок строк
• Используется, когда важна скорость и нужны все данные
UNION
• Удаляет повторяющиеся строки
• Работает медленно - требует сортировки (ресурсозатратно)
• Может изменить порядок строк
• Используется, когда нужны уникальные записи
Также могут дать простую задачку:
Ответ:
Будет работать если тип полей в таблицах одинаковый (но возможно некоторые СУБД итак могут сделать неявное преобразование).
Вернется 2 строки:
13 14
13 15
3) Отличие UPDATE TABLE от ALTER TABLE.
Немного странный вопрос, но в этом и прикол. Некоторые джуны на нем тупят😄
UPDATE TABLE:
• Изменяет сами данные в таблице (строки)
• Пример: UPDATE users SET age = 30 WHERE id = 1;
• Тип операции - DML (Data Manipulation Language). Поэтому операции нужно COMMIT-ть или при необходимости можно откатить - ROLLBACK
• Блокирует строки (зависит от СУБД). *Про блокировки сделаю отдельный пост, тема непростая.
ALTER TABLE:
• Изменяет структуру таблицы (добавить/удалить/изменить поле, ограничение, партицию, переименование таблицы и тд.).
• Пример: ALTER TABLE users ADD COLUMN email VARCHAR(100);
• Тип операции - DDL (Data Definition Language). Авто COMMIT, откатить нельзя (но есть нюансы, зависит от СУБД)
• Может блокировать всю таблицу
Подскажите плз вам интересна эта тема? Предлагайте свои варианты почему можно навалить базы?
#Вопросы_с_собесов #база #sql #jun
Продолжим наваливать базу 🤝
Популярные вопросы с собесов (lvl junior):
1) В какой последовательности БД на самом деле выполняет команды запроса:
select distinct
from
join
where
group by
having
order by
limit
Ответ:
Порядок выполнения SQL-запроса:
1. FROM (и JOIN) – выбираются таблицы и соединяются
2. WHERE – фильтруются строки
3. GROUP BY – группировка данных
4. HAVING – фильтрация групп
5. SELECT – выбор полей (включая вычисляемые)
6. DISTINCT – удаление дубликатов
7. ORDER BY – сортировка результатов
8. LIMIT / OFFSET – ограничение вывода
Более удобный вид:
FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT
2) UNION ALL vs UNION - в чем разница?
UNION ALL:
• Не удаляет дубликаты
• Работает быстро (простое объединение)
• Сохраняет исходный порядок строк
• Используется, когда важна скорость и нужны все данные
UNION
• Удаляет повторяющиеся строки
• Работает медленно - требует сортировки (ресурсозатратно)
• Может изменить порядок строк
• Используется, когда нужны уникальные записи
Также могут дать простую задачку:
Даны таблицы T1(col1, col2), T2(col1, col3).
Наполнение таблиц:
T1
(13, 15)
(13, 15)
(13, 15)
T2
(13, 15)
(13, 14)
Будет ли работать запрос? Если будет работать, то сколько строк вернет?
SELECT * FROM T1
UNION
SELECT * FROM T2
Ответ:
Будет работать если тип полей в таблицах одинаковый (но возможно некоторые СУБД итак могут сделать неявное преобразование).
Вернется 2 строки:
13 14
13 15
3) Отличие UPDATE TABLE от ALTER TABLE.
Немного странный вопрос, но в этом и прикол. Некоторые джуны на нем тупят
UPDATE TABLE:
• Изменяет сами данные в таблице (строки)
• Пример: UPDATE users SET age = 30 WHERE id = 1;
• Тип операции - DML (Data Manipulation Language). Поэтому операции нужно COMMIT-ть или при необходимости можно откатить - ROLLBACK
• Блокирует строки (зависит от СУБД). *Про блокировки сделаю отдельный пост, тема непростая.
ALTER TABLE:
• Изменяет структуру таблицы (добавить/удалить/изменить поле, ограничение, партицию, переименование таблицы и тд.).
• Пример: ALTER TABLE users ADD COLUMN email VARCHAR(100);
• Тип операции - DDL (Data Definition Language). Авто COMMIT, откатить нельзя (но есть нюансы, зависит от СУБД)
• Может блокировать всю таблицу
Подскажите плз вам интересна эта тема? Предлагайте свои варианты почему можно навалить базы?
#Вопросы_с_собесов #база #sql #jun
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Engineering / Инженерия данных / Data Engineer / DWH
Тренировки по алгоритмам от Яндекса
https://yandex.ru/yaintern/training/algorithm-training
После регистрации приходит письмо с подготовительными лекциями на YT https://youtube.com/playlist?list=PL6Wui14DvQPz_vzmNVOYBRqML6l51lP0G&si=FdTT_WhXPNZnOx46
https://yandex.ru/yaintern/training/algorithm-training
После регистрации приходит письмо с подготовительными лекциями на YT https://youtube.com/playlist?list=PL6Wui14DvQPz_vzmNVOYBRqML6l51lP0G&si=FdTT_WhXPNZnOx46
Тренировки по алгоритмам от Яндекса
Новый сезон — новые задачи и форматы
Forwarded from что-то на инженерном
Основные алгоритмы джойнов
Next level для тех, кто освоил типы джойнов, и теперь готов к оптимизации своих запросов 😎
Ниже приведены ключевые алгоритмы джойнов, используемые в реляционных СУБД и распределенных системах (Spark, Hadoop). Каждый из них решает определенные задачи в зависимости от объема данных, их структуры и инфраструктуры.
▫️Nested Loop Join - для каждой строки левой таблицы сканируется вся правая таблица (вложенные циклы).
— подходит для очень маленьких таблиц (до 1 тыс. строк)
— используется в SQLite, PostgreSQL для простых запросов
— простая реализация
— не требует сортировки или индексов
— сложность O(N*M) → неприменим для больших данных.
▫️Hash Join - состоит из двух фаз:
Build Phase: создается хеш-таблица для меньшей таблицы.
Probe Phase: большая таблица итерируется, и ключи ищутся в хеш-таблице.
— используется, если одна таблица помещается в память (справочники, малые датасеты), например в PostgreSQL для джойна пользователей и заказов.
— быстрый поиск за счет хешей → O(N + M).
— не требует сортировки.
— требует много памяти.
— неэффективен для skewed-ключей.
▫️Sort-Merge Join - сначала обе таблицы сортируются по ключу джойна. Далее происходит слияние отсортированных данных (как в алгоритме двух указателей).
— подходит для больших таблиц, которые нельзя броадкастить, и если данные уже отсортированы (например, партиционированы по дате).
— стабильная работа на больших данных.
— минимизирует использование памяти.
— дорогая сортировка → O(N log N + M log M)
— не подходит для skewed data.
▫️Broadcast Join (Map-Side Join) - маленькая таблица рассылается на все ноды кластера. Джойн выполняется локально на каждой ноде без Shuffle.
— используется, если маленькая таблица ≤ 10% памяти ноды (справочники, конфигурации), например для джойна логов и справочника стран на spark.
— нет Shuffle → экономия сети.
— максимальная скорость для маленьких таблиц.
— риск OOM, если таблица слишком большая.
▫️Shuffle Hash Join - обе таблицы перемешиваются (Shuffle) по ключу. На каждой ноде строится хеш-таблица для одной из таблиц.
— подходит для больших таблиц, когда одна из них после фильтрации помещается в память.
— быстрее Sort-Merge для средних данных.
— риск spill на диск при нехватке памяти.
▫️Bucket Join - данные предварительно разбиваются на бакеты по ключу, затем джоин выполняется между соответствующими бакетами. Подходит для частых джойнов по одному ключу (ETL-пайплайны).
▫️Skew Join - добавление случайного префикса (соли) к «тяжелым» ключам для распределения нагрузки. Далее происходит динамическое разбиение: дробление партиций с skewed-ключами. Подходит для данных с сильным перекосом (например, 80% записей по одному ключу).
▫️Grace Hash Join - комбинация Hash Join и внешней сортировки. Если хеш-таблица не влезает в память, данные разбиваются на партиции и обрабатываются по частям. Подходит для очень больших таблиц, которые не помещаются в память.
❔Как выбрать алгоритм?
1 — смотрим на размер данных:
Небольшая таблица → Broadcast Join
Большие таблицы → Sort-Merge или Shuffle Hash
2 — смотрим на структуру данных:
Отсортированы → Sort-Merge
Skewed-ключи → Skew Join
3 — инфраструктура:
Spark → используйте хинты (BROADCAST, MERGE).
Реляционная СУБД → опирайтесь на планировщик и индексы.
❕Запомнить:
— Nested Loop и Hash Join - база для СУБД.
— Broadcast и Sort-Merge - основа для распределенных систем.
— Всегда анализируйте план выполнения (explain в SQL, df.explain() в Spark) + метрики (память, сеть).
Next level для тех, кто освоил типы джойнов, и теперь готов к оптимизации своих запросов 😎
Ниже приведены ключевые алгоритмы джойнов, используемые в реляционных СУБД и распределенных системах (Spark, Hadoop). Каждый из них решает определенные задачи в зависимости от объема данных, их структуры и инфраструктуры.
▫️Nested Loop Join - для каждой строки левой таблицы сканируется вся правая таблица (вложенные циклы).
— подходит для очень маленьких таблиц (до 1 тыс. строк)
— используется в SQLite, PostgreSQL для простых запросов
— простая реализация
— не требует сортировки или индексов
— сложность O(N*M) → неприменим для больших данных.
▫️Hash Join - состоит из двух фаз:
Build Phase: создается хеш-таблица для меньшей таблицы.
Probe Phase: большая таблица итерируется, и ключи ищутся в хеш-таблице.
— используется, если одна таблица помещается в память (справочники, малые датасеты), например в PostgreSQL для джойна пользователей и заказов.
— быстрый поиск за счет хешей → O(N + M).
— не требует сортировки.
— требует много памяти.
— неэффективен для skewed-ключей.
▫️Sort-Merge Join - сначала обе таблицы сортируются по ключу джойна. Далее происходит слияние отсортированных данных (как в алгоритме двух указателей).
— подходит для больших таблиц, которые нельзя броадкастить, и если данные уже отсортированы (например, партиционированы по дате).
— стабильная работа на больших данных.
— минимизирует использование памяти.
— дорогая сортировка → O(N log N + M log M)
— не подходит для skewed data.
▫️Broadcast Join (Map-Side Join) - маленькая таблица рассылается на все ноды кластера. Джойн выполняется локально на каждой ноде без Shuffle.
— используется, если маленькая таблица ≤ 10% памяти ноды (справочники, конфигурации), например для джойна логов и справочника стран на spark.
— нет Shuffle → экономия сети.
— максимальная скорость для маленьких таблиц.
— риск OOM, если таблица слишком большая.
▫️Shuffle Hash Join - обе таблицы перемешиваются (Shuffle) по ключу. На каждой ноде строится хеш-таблица для одной из таблиц.
— подходит для больших таблиц, когда одна из них после фильтрации помещается в память.
— быстрее Sort-Merge для средних данных.
— риск spill на диск при нехватке памяти.
▫️Bucket Join - данные предварительно разбиваются на бакеты по ключу, затем джоин выполняется между соответствующими бакетами. Подходит для частых джойнов по одному ключу (ETL-пайплайны).
▫️Skew Join - добавление случайного префикса (соли) к «тяжелым» ключам для распределения нагрузки. Далее происходит динамическое разбиение: дробление партиций с skewed-ключами. Подходит для данных с сильным перекосом (например, 80% записей по одному ключу).
▫️Grace Hash Join - комбинация Hash Join и внешней сортировки. Если хеш-таблица не влезает в память, данные разбиваются на партиции и обрабатываются по частям. Подходит для очень больших таблиц, которые не помещаются в память.
❔Как выбрать алгоритм?
1 — смотрим на размер данных:
Небольшая таблица → Broadcast Join
Большие таблицы → Sort-Merge или Shuffle Hash
2 — смотрим на структуру данных:
Отсортированы → Sort-Merge
Skewed-ключи → Skew Join
3 — инфраструктура:
Spark → используйте хинты (BROADCAST, MERGE).
Реляционная СУБД → опирайтесь на планировщик и индексы.
❕Запомнить:
— Nested Loop и Hash Join - база для СУБД.
— Broadcast и Sort-Merge - основа для распределенных систем.
— Всегда анализируйте план выполнения (explain в SQL, df.explain() в Spark) + метрики (память, сеть).
Forwarded from Data Engineering / Инженерия данных / Data Engineer / DWH
3 ресурса для освоения GIT с интерактивными заданиями
https://learngitbranching.js.org/?locale=ru_RU - Learn Git Branching
Интерактивный тренажер, позволяющий визуализировать и отрабатывать команды Git в режиме реального времени. Подходит как для новичков, так и для опытных пользователей.
https://git-school.github.io/visualizing-git/ - Visualizing Git
Веб-приложение, которое наглядно демонстрирует, как различные команды Git влияют на структуру коммитов, помогая лучше понять внутренние процессы системы контроля версий.
https://ohmygit.org/ - Открытая игра, обучающая Git с помощью визуализации внутренних структур репозиториев в реальном времени. Имеет интерфейс в виде игровых карт для запоминания команд и интегрированный терминал для выполнения произвольных команд Git.
https://learngitbranching.js.org/?locale=ru_RU - Learn Git Branching
Интерактивный тренажер, позволяющий визуализировать и отрабатывать команды Git в режиме реального времени. Подходит как для новичков, так и для опытных пользователей.
https://git-school.github.io/visualizing-git/ - Visualizing Git
Веб-приложение, которое наглядно демонстрирует, как различные команды Git влияют на структуру коммитов, помогая лучше понять внутренние процессы системы контроля версий.
https://ohmygit.org/ - Открытая игра, обучающая Git с помощью визуализации внутренних структур репозиториев в реальном времени. Имеет интерфейс в виде игровых карт для запоминания команд и интегрированный терминал для выполнения произвольных команд Git.
learngitbranching.js.org
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
Forwarded from что-то на инженерном
Как продакт выбирает инженера, часть 2
На прошлой неделе был пост-интервью с Product Owner о том, как он выбирает инженеров в свою команду. Он собрал много реакций и репостов, поэтому мы решили сделать еще один совместный пост🔥
Как устроен процесс отбора резюме инженеров?
1. Сейчас, когда направление разрослось, появилась возможность переложить большую часть процесса отбора на техлида. PO подключается только на последнем этапе собеседования. Раньше приходилось заниматься самому. В любом случае вначале назначенный на вакансию рекрутер делает первичный отбор резюме в соответствии с требованиями, в основном с HH. Сама компания выкладывать вакансию в открытый доступ не любит: слишком много шлака летит в ответ. Пару раз мне приходилось участвовать в отборе резюме на HH cовместно с рекрутером чтобы откалибровать требования - адская работа.
2. Инициатор вакансии (техлид) по каждому резюме дает обратную связь ректрутеру. С успешными рекрутер должен договориться о собеседовании, по неуспешным - принять к сведению комментарии (хочется в это верить)
3. Если случился матч, техлид проводит интервью с кандидатом на предмет соответствия требованиям и хард скиллов. Рекрутер присутствует и оценивает психологический портрет кандидата (вполуха, есть подозрение)
4. Если и тут возникла обоюдная любовь, состоится второе собеседование, со мной. Моя задача оценить насколько кандидат впишется в процесс и в команду, насколько готов работать над нашими задачами. Ну и с другой стороны рассказать кандидату, с чем придется столкнуться, ответить на вопросы. До этого этапа по моему опыту доходит 4-8 человек, до первого собеседования - в разы больше. Резюме просмотрено еще на порядок больше. Т.е. Найм - это в любом случае десятки часов руководителей, затягивать его или повторять слишком часто никому не хочется, проще поступиться частью требований.
5. Остался последний шаг перед оффером - проверка HR и СБ. Тут могут всплыть несоответствия в резюме, или уход со скандалом с прошлой работы, о котором кандидат умолчал, но на моей памяти с успешными кандидатами такого не было.
Что для тебя ред флаг/и в резюме?
Ред флагов у меня немного: 3-4 последних места работы продолжительностью год-два - вот, пожалуй, и все. С остальным можно жить.
Сейчас популярно накрутчивать опыт. Как ты к этому относишься и как распознаешь накрутчиков?
Если учебный опыт включен в резюме, это хорошо видно, тут либо тебе нужен джун, либо нет. В целом без опыта пройти все этапы собеседования на мидла без посторонней помощи нереально. Перед выставлением оффера документы проверяет Служба безопасности. Ну и испытательные срок никто не отменял. Не вижу в накручивании никакого смысла, только репутацию испортите.
Как ты реагируешь, когда твой оффер перебивают? (Ты предложил 300тыс, а соискатель говорит, что согласится только на 350)
Нередкий случай в целом. Если кандидат примерно одновременно дошел до афера в двух компаниях, хочет работать у нас, но в другой компании предлагают больше, можно и попросить уровнять. Процесс найма у нас построен так, что практически ни у кого нет личного интереса экономить на кандидате. Если деньги в бюджете на вакансии есть - в целом не жалко. А если запрос в бюджет не вписывается - не судьба. Но если в шорт-листе были еще кандидаты, параллельно запустится общение с ним, на всякий случай.
P.S. Пожалуй, этот разговор позволил мне взглянуть на работу менеджеров с другого ракурса. Поскольку со стороны инженеров я часто замечаю нападки в адрес некомпетентности PM/PO: что они неправильно проводят собесы, не разбираются досконально во всех технологиях, задают глупые вопросы. Да, менеджеры не всегда погружаются в технические нюансы так глубоко, как хотелось бы. Но их фокус - не в деталях технологий, а в сборке пазла, где каждая деталь - это запросы бизнеса, динамика команды и долгосрочные цели продукта.
А вам приходилось сталкиваться с неочевидными нюансами найма? 👀
На прошлой неделе был пост-интервью с Product Owner о том, как он выбирает инженеров в свою команду. Он собрал много реакций и репостов, поэтому мы решили сделать еще один совместный пост🔥
Как устроен процесс отбора резюме инженеров?
1. Сейчас, когда направление разрослось, появилась возможность переложить большую часть процесса отбора на техлида. PO подключается только на последнем этапе собеседования. Раньше приходилось заниматься самому. В любом случае вначале назначенный на вакансию рекрутер делает первичный отбор резюме в соответствии с требованиями, в основном с HH. Сама компания выкладывать вакансию в открытый доступ не любит: слишком много шлака летит в ответ. Пару раз мне приходилось участвовать в отборе резюме на HH cовместно с рекрутером чтобы откалибровать требования - адская работа.
2. Инициатор вакансии (техлид) по каждому резюме дает обратную связь ректрутеру. С успешными рекрутер должен договориться о собеседовании, по неуспешным - принять к сведению комментарии (хочется в это верить)
3. Если случился матч, техлид проводит интервью с кандидатом на предмет соответствия требованиям и хард скиллов. Рекрутер присутствует и оценивает психологический портрет кандидата (вполуха, есть подозрение)
4. Если и тут возникла обоюдная любовь, состоится второе собеседование, со мной. Моя задача оценить насколько кандидат впишется в процесс и в команду, насколько готов работать над нашими задачами. Ну и с другой стороны рассказать кандидату, с чем придется столкнуться, ответить на вопросы. До этого этапа по моему опыту доходит 4-8 человек, до первого собеседования - в разы больше. Резюме просмотрено еще на порядок больше. Т.е. Найм - это в любом случае десятки часов руководителей, затягивать его или повторять слишком часто никому не хочется, проще поступиться частью требований.
5. Остался последний шаг перед оффером - проверка HR и СБ. Тут могут всплыть несоответствия в резюме, или уход со скандалом с прошлой работы, о котором кандидат умолчал, но на моей памяти с успешными кандидатами такого не было.
Что для тебя ред флаг/и в резюме?
Ред флагов у меня немного: 3-4 последних места работы продолжительностью год-два - вот, пожалуй, и все. С остальным можно жить.
Сейчас популярно накрутчивать опыт. Как ты к этому относишься и как распознаешь накрутчиков?
Если учебный опыт включен в резюме, это хорошо видно, тут либо тебе нужен джун, либо нет. В целом без опыта пройти все этапы собеседования на мидла без посторонней помощи нереально. Перед выставлением оффера документы проверяет Служба безопасности. Ну и испытательные срок никто не отменял. Не вижу в накручивании никакого смысла, только репутацию испортите.
Как ты реагируешь, когда твой оффер перебивают? (Ты предложил 300тыс, а соискатель говорит, что согласится только на 350)
Нередкий случай в целом. Если кандидат примерно одновременно дошел до афера в двух компаниях, хочет работать у нас, но в другой компании предлагают больше, можно и попросить уровнять. Процесс найма у нас построен так, что практически ни у кого нет личного интереса экономить на кандидате. Если деньги в бюджете на вакансии есть - в целом не жалко. А если запрос в бюджет не вписывается - не судьба. Но если в шорт-листе были еще кандидаты, параллельно запустится общение с ним, на всякий случай.
P.S. Пожалуй, этот разговор позволил мне взглянуть на работу менеджеров с другого ракурса. Поскольку со стороны инженеров я часто замечаю нападки в адрес некомпетентности PM/PO: что они неправильно проводят собесы, не разбираются досконально во всех технологиях, задают глупые вопросы. Да, менеджеры не всегда погружаются в технические нюансы так глубоко, как хотелось бы. Но их фокус - не в деталях технологий, а в сборке пазла, где каждая деталь - это запросы бизнеса, динамика команды и долгосрочные цели продукта.
А вам приходилось сталкиваться с неочевидными нюансами найма? 👀
Forwarded from DevFM
Как я провожу синки с тимлидами
Недавно с коллегами заходил разговор за формат синков с тимлидами. Расскажу, как я провожу подобные встречи.
Формат
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.
Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.
2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.
3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.
Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.
Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение
О применении ТГ для асинхронной работы была отдельная статья.
#teamwork #devfm
Недавно с коллегами заходил разговор за формат синков с тимлидами. Расскажу, как я провожу подобные встречи.
Формат
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.
Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.
2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.
3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.
Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.
Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение
О применении ТГ для асинхронной работы была отдельная статья.
#teamwork #devfm
Telegram
DevFM
Ведение дел – мой опыт
Часто начинающие тим лиды имеют сложности с тайм-менеджментом. У них появляются новые зоны ответственности, новые задачи, интерапты, о которых они раньше и не слышали, больше общения с людьми. В общем, совершенно новый опыт.
Что уж…
Часто начинающие тим лиды имеют сложности с тайм-менеджментом. У них появляются новые зоны ответственности, новые задачи, интерапты, о которых они раньше и не слышали, больше общения с людьми. В общем, совершенно новый опыт.
Что уж…
Forwarded from РИСЕРЧОШНАЯ
Кратко
Подробно
Видео
#LLM #NLP #NOTION
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM