Forwarded from Алексей
claude для кода gpt для проверки qwen для оценки gemini для того чтобы понять что написано
Forwarded from Quant Researcher
Nautilus Trader — индустриальный бэктестинг
https://github.com/nautechsystems/nautilus_trader
Если вы пытались превратить красивую идею в реплицируемый PnL, вы знаете, как это весело и увлекательно: бэктест не сходится, исполнение — по ценам с ффилами, а латенси существует только на словах.
Nautilus Trader — это попытка закрыть именно этот разрыв. Проект от Nautech Systems, open-source, сразу целится в production-grade trading stack.
🧠 Ключевая идея
Бэктест = симуляция реальной торговой системы, а не просто прогон сигналов по историческим ценам.
Библиотека моделирует не только рынок, но и ордера, исполнение, задержки, комиссии, частичную ликвидность, состояние портфеля, event-driven логику.
Фактически, это единый движок для research, backtesting, paper trading, live.
Без переписывания стратегии под каждый этап.
⚙️ Архитектура
- Event-driven ядро (никаких «for price in prices»)
- Строгое разделение:
- Strategy
- Execution
- Portfolio
- Risk
- Детальная модель ордеров (limit / market / stop / OCO и т.д.)
- Поддержка crypto, FX, equities
- Python + Rust (где нужна скорость)
Это не обертка над pandas, а торговый симулятор, ближе по духу к тому, как думают HFT / prop desks.
📊 Почему это важно для квантов
Большинство стратегий умирают не из-за идеи, а из-за недоучтённого исполнения, хвостов распределения PnL, нелинейностей при масштабировании.
Nautilus Trader заставляет как можно раньше подумать про ликвидность, проскальзывание, устойчивость PnL, path-dependence.
А значит — лучше понимать, какие риски вы реально покупаете или продаете.
⸻
А выкаким порошком пользуетесь:
• моделируете исполнение в бэктестах?
• знаете, чувствительность своего PnL от проскальзывания и комиссий?
Quant Researcher
https://github.com/nautechsystems/nautilus_trader
Если вы пытались превратить красивую идею в реплицируемый PnL, вы знаете, как это весело и увлекательно: бэктест не сходится, исполнение — по ценам с ффилами, а латенси существует только на словах.
Nautilus Trader — это попытка закрыть именно этот разрыв. Проект от Nautech Systems, open-source, сразу целится в production-grade trading stack.
🧠 Ключевая идея
Бэктест = симуляция реальной торговой системы, а не просто прогон сигналов по историческим ценам.
Библиотека моделирует не только рынок, но и ордера, исполнение, задержки, комиссии, частичную ликвидность, состояние портфеля, event-driven логику.
Фактически, это единый движок для research, backtesting, paper trading, live.
Без переписывания стратегии под каждый этап.
⚙️ Архитектура
- Event-driven ядро (никаких «for price in prices»)
- Строгое разделение:
- Strategy
- Execution
- Portfolio
- Risk
- Детальная модель ордеров (limit / market / stop / OCO и т.д.)
- Поддержка crypto, FX, equities
- Python + Rust (где нужна скорость)
Это не обертка над pandas, а торговый симулятор, ближе по духу к тому, как думают HFT / prop desks.
📊 Почему это важно для квантов
Большинство стратегий умирают не из-за идеи, а из-за недоучтённого исполнения, хвостов распределения PnL, нелинейностей при масштабировании.
Nautilus Trader заставляет как можно раньше подумать про ликвидность, проскальзывание, устойчивость PnL, path-dependence.
А значит — лучше понимать, какие риски вы реально покупаете или продаете.
⸻
А вы
• моделируете исполнение в бэктестах?
• знаете, чувствительность своего PnL от проскальзывания и комиссий?
Quant Researcher
Forwarded from max.sh
Когда-то давно, во времена учебы в ШАДе, нам читали интенсив по основам архитектуры GPU и разработки на CUDA. Обещали рассказать, как устроены видеокарты и почему они эффективны для машинного обучения. Я тогда дальше
Лекции читали разработчики из Nvidia. Да, это было такое время, когда у компании был Московский офис и они периодически нанимали DL-инженеров, а иногда и стажеров (марафон технических раундов и глубоких вопросов на понимание, чтобы побороться за 2 стажерские позиции).
Курс, по моему мнению, получился ужасным. Материал стремительно усложнялся без какой-либо оглядки на аудиторию и тот факт, что ко второй лекции половина слушателей уже отвалилась. Я потерял суть происходящего уже минуте на 20-30 первой лекции, в момент когда термины вида SM, warp schedulers, cuda cores заполняли каждый слайд, а повествование превратилось во внутренний митап для инженеров Nvidia.
Худо-бедно интенсив я закрыл, решая задачи методом проб и ошибок. От курса в голове не осталось почти ничего. Разве что боязнь копаться в деталях работы с GPU.
Позже, уже в 2022-2023 году, модели перестали влазить в память одной ГПУ и нужно было учиться паралелить, оценивать эффективность инфраструктуры в поисках ответа на вопрос: а почему все так медленно? are we compute bound or communication bound? Снова я столкнулся с GPU акселераторами лицом к лицу. Документации от Nvidia было не очень много, так что неподготовленному читателю входить было не просто. Но дело двигалось тем же путем проб и ошибок и общением с коллегами по работе.
А хороших гайдов на понимание все еще не было. Мне кажется их и сейчас не очень много. ( Как и специалистов в этой области. Performance Engineer крайне актуальная роль в области DL на ближайшие годы)
Недавно наткнулся на "книгу" от ребят из DeepMind, они проделали невероятную методологическую работу. И выпустили онлайн-учебник How to Scale Your Model. Центральный предмет книги о том, как учить трансформеры на больших кластерах, арифметику моделей (откуда набегает так много гигабайтов памяти, чтобы сделать один forward pass) и что такое TPU/GPU. К каждой главе идет еще набор квизов, чтобы посчитать что-нибудь руками.
Крайне Рекомендую!
https://jax-ml.github.io/scaling-book/
model.to('cuda:0') в этом вопросе ничего не знал, поэтому с интересом записался.Лекции читали разработчики из Nvidia. Да, это было такое время, когда у компании был Московский офис и они периодически нанимали DL-инженеров, а иногда и стажеров (марафон технических раундов и глубоких вопросов на понимание, чтобы побороться за 2 стажерские позиции).
Курс, по моему мнению, получился ужасным. Материал стремительно усложнялся без какой-либо оглядки на аудиторию и тот факт, что ко второй лекции половина слушателей уже отвалилась. Я потерял суть происходящего уже минуте на 20-30 первой лекции, в момент когда термины вида SM, warp schedulers, cuda cores заполняли каждый слайд, а повествование превратилось во внутренний митап для инженеров Nvidia.
Худо-бедно интенсив я закрыл, решая задачи методом проб и ошибок. От курса в голове не осталось почти ничего. Разве что боязнь копаться в деталях работы с GPU.
Позже, уже в 2022-2023 году, модели перестали влазить в память одной ГПУ и нужно было учиться паралелить, оценивать эффективность инфраструктуры в поисках ответа на вопрос: а почему все так медленно? are we compute bound or communication bound? Снова я столкнулся с GPU акселераторами лицом к лицу. Документации от Nvidia было не очень много, так что неподготовленному читателю входить было не просто. Но дело двигалось тем же путем проб и ошибок и общением с коллегами по работе.
А хороших гайдов на понимание все еще не было. Мне кажется их и сейчас не очень много. ( Как и специалистов в этой области. Performance Engineer крайне актуальная роль в области DL на ближайшие годы)
Недавно наткнулся на "книгу" от ребят из DeepMind, они проделали невероятную методологическую работу. И выпустили онлайн-учебник How to Scale Your Model. Центральный предмет книги о том, как учить трансформеры на больших кластерах, арифметику моделей (откуда набегает так много гигабайтов памяти, чтобы сделать один forward pass) и что такое TPU/GPU. К каждой главе идет еще набор квизов, чтобы посчитать что-нибудь руками.
Крайне Рекомендую!
https://jax-ml.github.io/scaling-book/
jax-ml.github.io
How To Scale Your Model
Training LLMs often feels like alchemy, but understanding and optimizing the performance of your models doesn't have to. This book aims to demystify the science of scaling language models: how TPUs (and GPUs) work and how they communicate with each other…
Forwarded from Machine head - Александр О.
Анатомия ИИ-агентов. Часть 1 - Истоки и архитектура. [1/2]
Подходит концу первая рабочая неделя этого года. Дабы провести выходные с пищей для ума, самое время с двух ног запрыгнуть в устройство ИИ-агентов. Начнем с истоков.⚡️
Первыми практическими предшественниками современных ИИ-агентов стали экспертные системы, появившиеся в 1960-х годах. Экспертная система — это система искусственного интеллекта (весьма ограниченного), которая на основании знаний и опыта эксперта-человека может решать задачи в определенной области. В 1965 году в Стэнфордском университете Эдвард Фейгенбаум создал DENDRAL — первую в истории экспертную систему для определения структуры химических веществ.
Прорыв в понимании ИИ-агентов произошел в 1973 году, когда Карл Хьюитт разработал модель актора — подход, позволяющий создавать системы, где независимые агенты взаимодействуют друг с другом через обмен сообщениями. Одной из первых таких систем стала Distributed Problem Solver, созданная в 1981 году. В 1986 году Марвин Минский в книге “Society of Mind” предложил представлять сложные задачи как результат взаимодействия множества отдельных агентов, работающих в “сообществе”. Почему это важно? Модель актора обеспечила сдвиг ментальной модели программирования от систем с общей памятью и блокировками к архитектуре, основанной на передаче сообщений и изоляции состояния.
Современный ИИ-агент, следуя принципам акторной модели и построенный поверх большой лингвистической модели, отличителен 3-мя ключевыми свойствами:
Свойство 1. Автономность и независимое выполнение задач.
В понимании современных ИИ-агентов речь идет о способности агента к планированию следующего шага. В отличие от “голой” LLM, где мы работаем в режиме “запрос-ответ”, агент действует в, так называемом, агентском цикле: Наблюдение → Планирование → Действие. Агентский цикл конечен. Независимо от его сложности, агент на вход получает запрос, запускает цикл и его цель вернуть ожидаемый результат. Вот, что делают шаги цикла:
1. Наблюдение. Агент анализирует результаты своих предыдущих действий, собирает данные из окружения, выполняет контекстное обогащение.
2. Планирование. Агент использует различные методы рассуждений для определения наилучшего способа действий. Модель начинает думать над решением запроса пользователя, разрабатывает план для дальнейших действий и определяет, какие инструменты можно использовать.
3. Действие. Агент выбирает необходимые инструменты и начинает их использовать в соответствии с задачами, сформулированными на этапе планирования.
Свойство 2. Интеграция с инструментами и окружением
В шаге планирования и действия агенту доступно мета-описание его окружения: команд, которые может выбрать LLM, для взаимодействия с окружающим миром. Между командой и LLM - тонкий слой управляющего кода, интерпретирующего текстовые ответы в вызов кода самой команды. Именно поэтому к LLM выдвигается требование к способности отвечать структурированно (Structured output). Действуя, агент делает 1 или множество запросов к LLM, получая структурированные ответы, вызывает инструменты - обычный код в функциях и классах с поведением, исполняемый процессором, выполняет работу, а также сверяется с исходным планом.
продолжение...
Подходит концу первая рабочая неделя этого года. Дабы провести выходные с пищей для ума, самое время с двух ног запрыгнуть в устройство ИИ-агентов. Начнем с истоков.
Первыми практическими предшественниками современных ИИ-агентов стали экспертные системы, появившиеся в 1960-х годах. Экспертная система — это система искусственного интеллекта (весьма ограниченного), которая на основании знаний и опыта эксперта-человека может решать задачи в определенной области. В 1965 году в Стэнфордском университете Эдвард Фейгенбаум создал DENDRAL — первую в истории экспертную систему для определения структуры химических веществ.
Прорыв в понимании ИИ-агентов произошел в 1973 году, когда Карл Хьюитт разработал модель актора — подход, позволяющий создавать системы, где независимые агенты взаимодействуют друг с другом через обмен сообщениями. Одной из первых таких систем стала Distributed Problem Solver, созданная в 1981 году. В 1986 году Марвин Минский в книге “Society of Mind” предложил представлять сложные задачи как результат взаимодействия множества отдельных агентов, работающих в “сообществе”. Почему это важно? Модель актора обеспечила сдвиг ментальной модели программирования от систем с общей памятью и блокировками к архитектуре, основанной на передаче сообщений и изоляции состояния.
Современный ИИ-агент, следуя принципам акторной модели и построенный поверх большой лингвистической модели, отличителен 3-мя ключевыми свойствами:
Свойство 1. Автономность и независимое выполнение задач.
Многие проводят равенство между автономностью и самостоятельностью, мол, агент живет сам по себе и делает работу, как человек, то нет. Самостоятельность - способность не только выполнять действия без надзора, но и ставить подцели, адаптироваться к неизвестным заранее условиям. Дело не в технических ограничениях. Самостоятельность (и его объем) - производное от доверия, а доверие - краеугольный камень любых внешних, не только агентских систем.
В понимании современных ИИ-агентов речь идет о способности агента к планированию следующего шага. В отличие от “голой” LLM, где мы работаем в режиме “запрос-ответ”, агент действует в, так называемом, агентском цикле: Наблюдение → Планирование → Действие. Агентский цикл конечен. Независимо от его сложности, агент на вход получает запрос, запускает цикл и его цель вернуть ожидаемый результат. Вот, что делают шаги цикла:
1. Наблюдение. Агент анализирует результаты своих предыдущих действий, собирает данные из окружения, выполняет контекстное обогащение.
2. Планирование. Агент использует различные методы рассуждений для определения наилучшего способа действий. Модель начинает думать над решением запроса пользователя, разрабатывает план для дальнейших действий и определяет, какие инструменты можно использовать.
3. Действие. Агент выбирает необходимые инструменты и начинает их использовать в соответствии с задачами, сформулированными на этапе планирования.
Свойство 2. Интеграция с инструментами и окружением
В шаге планирования и действия агенту доступно мета-описание его окружения: команд, которые может выбрать LLM, для взаимодействия с окружающим миром. Между командой и LLM - тонкий слой управляющего кода, интерпретирующего текстовые ответы в вызов кода самой команды. Именно поэтому к LLM выдвигается требование к способности отвечать структурированно (Structured output). Действуя, агент делает 1 или множество запросов к LLM, получая структурированные ответы, вызывает инструменты - обычный код в функциях и классах с поведением, исполняемый процессором, выполняет работу, а также сверяется с исходным планом.
продолжение...
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Machine head - Александр О.
Анатомия ИИ-агентов. Часть 1 - Истоки и архитектура. [2/2]
В начало
Свойство 3. Память
LLM не обладает собственной памятью (или состоянием) между запросами - каждый запрос обрабатывается независимо, как в первый раз. То, что мы называем агентом, является обычной программой с собственным окружением. Как и любая другая программа, она может хранить состояние в оперативной памяти, обращаться к базам данных, собирать необходимый контекст для выполнения пользовательской задачи. Простейший вид памяти - сохранение всей последовательности запросов к LLM и ее ответов.
Так же как человеческий мозг имеет полушария и специализированные отделы, обеспечивающие нам интеллектуальные способности во всем их многообразии, ИИ-агент может быть разделен на части для пущей интеллектуальности. Программную архитектуру можно представить в виде фрактала - узора, обладающего свойством самоподобия: его части в уменьшенном масштабе повторяют структуру целого, где основной узор - агентский цикл. Агентский цикл, как архитектурная единица, в том же виде используется для создания под-модулей: планировщика, рефлексии, цензора, интерпретатора и тд. Когда и как эти подмодули-микроагенты (не путать с суб-агентами) будут вступать в работу определяет разработчик, склеивая их в процесс всё тем же обычным кодом (как, увидим в следующих статьях).
——
Подытоживая, архитектура ИИ-агента удивляет своей простотой и масштабируемостью, являясь кирпичиком системы любой сложности. Агент может быть как простейшим SingleRun-вызовом к LLM с остановкой после ответа, так и ReAct-агентом, самостоятельно принимающим решение как действовать дальше и когда заканчивать. Их и будем разбирать далее.
Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned!✌️
В начало
Свойство 3. Память
LLM не обладает собственной памятью (или состоянием) между запросами - каждый запрос обрабатывается независимо, как в первый раз. То, что мы называем агентом, является обычной программой с собственным окружением. Как и любая другая программа, она может хранить состояние в оперативной памяти, обращаться к базам данных, собирать необходимый контекст для выполнения пользовательской задачи. Простейший вид памяти - сохранение всей последовательности запросов к LLM и ее ответов.
Так же как человеческий мозг имеет полушария и специализированные отделы, обеспечивающие нам интеллектуальные способности во всем их многообразии, ИИ-агент может быть разделен на части для пущей интеллектуальности. Программную архитектуру можно представить в виде фрактала - узора, обладающего свойством самоподобия: его части в уменьшенном масштабе повторяют структуру целого, где основной узор - агентский цикл. Агентский цикл, как архитектурная единица, в том же виде используется для создания под-модулей: планировщика, рефлексии, цензора, интерпретатора и тд. Когда и как эти подмодули-микроагенты (не путать с суб-агентами) будут вступать в работу определяет разработчик, склеивая их в процесс всё тем же обычным кодом (как, увидим в следующих статьях).
——
Подытоживая, архитектура ИИ-агента удивляет своей простотой и масштабируемостью, являясь кирпичиком системы любой сложности. Агент может быть как простейшим SingleRun-вызовом к LLM с остановкой после ответа, так и ReAct-агентом, самостоятельно принимающим решение как действовать дальше и когда заканчивать. Их и будем разбирать далее.
Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Nikolay
Амазон
1)https://www.amazon.jobs/en/principles
2)https://medium.com/@scarletinked/are-you-the-leader-were-looking-for-interviewing-at-amazon-8301d787815d 3)https://docs.google.com/spreadsheets/d/1oBA6vanArm8gh79vzUnyJL-1kriLiGznYKh8gXAfD4s/edit?usp=drivesdk 4)https://www.notion.so/BE-Interview-8adc74cf14ad450fab3083e0633d2821#7b7c9b724012423f9572ef0787536c6e тут собираем вопросы https://docs.google.com/document/d/10mS6Whiybl3VjO9t3ZbMhp9TinNWBIArQoqmTaoSfqs/edit?usp=sharing 5) https://www2.hws.edu/pdf/career/behavioral_interview_questions.pdf
1)https://www.amazon.jobs/en/principles
2)https://medium.com/@scarletinked/are-you-the-leader-were-looking-for-interviewing-at-amazon-8301d787815d 3)https://docs.google.com/spreadsheets/d/1oBA6vanArm8gh79vzUnyJL-1kriLiGznYKh8gXAfD4s/edit?usp=drivesdk 4)https://www.notion.so/BE-Interview-8adc74cf14ad450fab3083e0633d2821#7b7c9b724012423f9572ef0787536c6e тут собираем вопросы https://docs.google.com/document/d/10mS6Whiybl3VjO9t3ZbMhp9TinNWBIArQoqmTaoSfqs/edit?usp=sharing 5) https://www2.hws.edu/pdf/career/behavioral_interview_questions.pdf
amazon.jobs
Leadership Principles
We use our Leadership Principles every day, whether we’re discussing ideas for new projects or deciding on the best way to solve a problem. It’s just one of the things that makes Amazon peculiar.
Forwarded from DziS Science | Data Science
Привет всем!👋
Сегодня поговорим про небольшую оптимизацию кода по памяти.
Известный факт, что неизменяемые структуры, которые имеют фиксированные размеры, имеют некоторые преимущества в сравнении с изменяемыми.
В рамках проектов, где часто вызываются миллионы мелких объектов (например, узлы в графе, события в симуляции, кастомные токены) проблема утечки памяти встает очень остро. Отчасти, это касается и атрибутов объектов.
По умолчанию🐍 хранит атрибуты объектов в словаре, включенном в метод
Для решения проблемы предлагается использовать метод
Он отключает создание
Рассмотрим на примере:
🔸 Определим классический класс
🔸 Теперь определим объекты классов
- Какие разницы в этих объектах?
🔵 В
Пример:
Причина такого поведения лежит именно в формировании класса с использованием
🔵 В obj2 нет словаря атрибутов
Проверить это просто:
Вывод следующий (до добавления атрибута):
Таким образом, если мы имеет часто используемый класс и нам не нужна свобода в изменении состава атрибутов, то правильнее использовать конструкцию со
Ставь 🔥, если не знал.
Ставь👍, если знал.
#ds_лайфхаки
Сегодня поговорим про небольшую оптимизацию кода по памяти.
Известный факт, что неизменяемые структуры, которые имеют фиксированные размеры, имеют некоторые преимущества в сравнении с изменяемыми.
В рамках проектов, где часто вызываются миллионы мелких объектов (например, узлы в графе, события в симуляции, кастомные токены) проблема утечки памяти встает очень остро. Отчасти, это касается и атрибутов объектов.
По умолчанию
__dict__ (появился он в языке 8 февраля 2012 года), который, как и обычный словарь имеет динамическое выделение памяти и может быть расширяем, что при всех своих плюсах создает большую нагрузку на память. Для решения проблемы предлагается использовать метод
__slots__. Он отключает создание
__dict__ и резервирует память только под конкретные атрибуты, что помогает оптимизировать код по памяти, но жестко фиксирует набор атрибутов объекта, что является одновременно и плюсом и минусом. Рассмотрим на примере:
CoordinatesDict`и класс `CoordinatesSlots с использованием __slots__import sys
class CoordinatesDict:
def __init__(self, x, y,z):
self.x = x
self.y = y
self.z = z
class CoordinatesSlots:
__slots__ = ['x', 'y', 'z'] # Фиксируем атрибуты
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
obj1 и obj2:obj1 = CoordinatesDict(1, 2, 3)
obj2 = CoordinatesSlots(1, 2, 3)
- Какие разницы в этих объектах?
obj1 можно дополнительно объявить новый атрибут, скажем, dist и присвоить ему значение, он пополнит ряды __dict__. В obj2 аналогичная операция вернет AttributeErrorПример:
obj1.dist = 2
obj1.__dict__
>>>{'x': 1, 'y': 2, 'z': 3, 'dist': 2}obj2.dist = 2
>>>AttributeError: 'CoordinatesSlots' object has no attribute 'dist'
Причина такого поведения лежит именно в формировании класса с использованием
__slots__. Такой класс, как говорилось ранее, хранит атрибуты в массиве фиксированной размерности, отключая возможность работы со словарем атрибутов (то есть у вас не появляется __dict__), а все атрибуты, не записанные в массив, поднимают ошибку. __dict__, а следовательно на него не требуется память.Проверить это просто:
print(sys.getsizeof(obj1), sys.getsizeof(obj1.__dict__))
print(sys.getsizeof(obj2))
print(sys.getsizeof(obj2.__dict__))
Вывод следующий (до добавления атрибута):
48 272
56
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
/tmp/ipython-input-390784945.py in <cell line: 0>()
18 print(sys.getsizeof(p1), sys.getsizeof(p1.__dict__))
19 print(sys.getsizeof(p2))
---> 20 print(sys.getsizeof(p2.__dict__))
AttributeError: 'CoordinatesSlots' object has no attribute '__dict__'
Таким образом, если мы имеет часто используемый класс и нам не нужна свобода в изменении состава атрибутов, то правильнее использовать конструкцию со
__slots__Ставь 🔥, если не знал.
Ставь👍, если знал.
#ds_лайфхаки
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тимлид Очевидность | Евгений Антонов
Контекст тимлида
Недавно записывал один подкаст, где одним из вопросов мы затронули контекст тимлида.
Это полезно понимать как для текущего тимлида в разрезе его нагрузки в настоящий момент, так и для тимлида, который приходит в новую команду/компанию, в разрезе того, что ему необходимо добрать, чтобы нормально работать.
Члены команды
Все люди разные и имеют свои особенности, мотивацию, текущие цели, особенности характера, темперамента, разные жизненные ценности, разные жизненные ситуации. На это накладывается, как они взаимодействуют между собой. Этот комбинаторный взрыв нужно знать и следить за ним регулярно, ибо, как говорил Гераклит, «всё течёт, всё меняется».
Рабочие процессы
Понятное дело, тут про всякую организационную и операционную деятельность, которая сейчас в команде присутствует, НО…
Есть еще исторический контекст того, что уже пробовали, что работало хорошо, а что плохо и почему.
Есть еще процессный долг, когда что-то сейчас как-то работает не лучшим образом и/или на ручной тяге, а надо бы это улучшить, но пока не было времени точить пилу, ведь дедлайн скоро и надо пилить.
Проекты и продукты
В вотчине тимлида есть набор проектов и продуктов. Это можно разбить на две части:
- Менеджерская. Проектный менеджмент, планирование, контроль, сроки, дедлайны, риски, KPI, OKR, договоренности с заказчиками и смежниками, ценность самих продуктов.
- Техническая. Само устройство, архитектура, технический долг.
Стратегия
Сейчас как-то всё работает, а как и для чего оно всё будет работать в будущем? Тут тоже 2 стула:
- Менеджерский. Басфактор, подготовка преемника, обучение и развитие команды. Цели и ценность самой команды и как она должна выглядеть в будущем.
- Технический. Технологическая стратегия тоже важна. Не просто «нам нальют х2 пользователей, мы железом ливанем, да и всё».
Наём
Кто-то из команды уходит, или открываются новые вакансии (про которые надо вообще понять, зачем они нужны, сформулировать портрет кандидата и дальше отбором заниматься), надо кого-то прособеседовать, или надо кого-то удержать, или надо, наоборот, кого-то уволить. Всё это тоже в контексте тимлида загружено.
Руководство
Надо хорошо понимать своё руководство: его ожидание, его личность, его особенности работы, то, как и когда по каким вопросам репортить, как просить помощи, как и когда спорить, как не спорить и вот это вот всё.
Политика
Есть хорошая картинка про то, как НА САМОМ ДЕЛЕ выглядит оргструктура https://ic.pics.livejournal.com/talent_a/45400893/2597/2597_original.jpg, и вот понимание этого контекста тоже очень важно. Всегда у людей есть куча неформальных историй, амбиций, притязаний, фаворитизма, протекции, обид, претензий и т. д. При непонимании этих негласных связей можно наступить на невидимые грабли, которых на официальной карте местности не должно быть.
Итог
У тимлида чертова гора контекста, которые ему нужно знать, держать в голове, в планах и регулярно использовать.
Поэтому я всегда диву даюсь, когда слышу «да у него там 2-3 человека, это ж на полдня в неделю менеджерской работы».
Или когда приходит новый тимлид, и от него сразу ждут такой же объем выполнения планов, как от прошлого, в которого этот контекст уже был вгружен и у которого все социальные связи установлены.
Недавно записывал один подкаст, где одним из вопросов мы затронули контекст тимлида.
Это полезно понимать как для текущего тимлида в разрезе его нагрузки в настоящий момент, так и для тимлида, который приходит в новую команду/компанию, в разрезе того, что ему необходимо добрать, чтобы нормально работать.
Члены команды
Все люди разные и имеют свои особенности, мотивацию, текущие цели, особенности характера, темперамента, разные жизненные ценности, разные жизненные ситуации. На это накладывается, как они взаимодействуют между собой. Этот комбинаторный взрыв нужно знать и следить за ним регулярно, ибо, как говорил Гераклит, «всё течёт, всё меняется».
Рабочие процессы
Понятное дело, тут про всякую организационную и операционную деятельность, которая сейчас в команде присутствует, НО…
Есть еще исторический контекст того, что уже пробовали, что работало хорошо, а что плохо и почему.
Есть еще процессный долг, когда что-то сейчас как-то работает не лучшим образом и/или на ручной тяге, а надо бы это улучшить, но пока не было времени точить пилу, ведь дедлайн скоро и надо пилить.
Проекты и продукты
В вотчине тимлида есть набор проектов и продуктов. Это можно разбить на две части:
- Менеджерская. Проектный менеджмент, планирование, контроль, сроки, дедлайны, риски, KPI, OKR, договоренности с заказчиками и смежниками, ценность самих продуктов.
- Техническая. Само устройство, архитектура, технический долг.
Стратегия
Сейчас как-то всё работает, а как и для чего оно всё будет работать в будущем? Тут тоже 2 стула:
- Менеджерский. Басфактор, подготовка преемника, обучение и развитие команды. Цели и ценность самой команды и как она должна выглядеть в будущем.
- Технический. Технологическая стратегия тоже важна. Не просто «нам нальют х2 пользователей, мы железом ливанем, да и всё».
Наём
Кто-то из команды уходит, или открываются новые вакансии (про которые надо вообще понять, зачем они нужны, сформулировать портрет кандидата и дальше отбором заниматься), надо кого-то прособеседовать, или надо кого-то удержать, или надо, наоборот, кого-то уволить. Всё это тоже в контексте тимлида загружено.
Руководство
Надо хорошо понимать своё руководство: его ожидание, его личность, его особенности работы, то, как и когда по каким вопросам репортить, как просить помощи, как и когда спорить, как не спорить и вот это вот всё.
Политика
Есть хорошая картинка про то, как НА САМОМ ДЕЛЕ выглядит оргструктура https://ic.pics.livejournal.com/talent_a/45400893/2597/2597_original.jpg, и вот понимание этого контекста тоже очень важно. Всегда у людей есть куча неформальных историй, амбиций, притязаний, фаворитизма, протекции, обид, претензий и т. д. При непонимании этих негласных связей можно наступить на невидимые грабли, которых на официальной карте местности не должно быть.
Итог
У тимлида чертова гора контекста, которые ему нужно знать, держать в голове, в планах и регулярно использовать.
Поэтому я всегда диву даюсь, когда слышу «да у него там 2-3 человека, это ж на полдня в неделю менеджерской работы».
Или когда приходит новый тимлид, и от него сразу ждут такой же объем выполнения планов, как от прошлого, в которого этот контекст уже был вгружен и у которого все социальные связи установлены.
