Как написать стратегию инженерной команды
Когда вы руководите всем инженерным департаментом, или какой-то относительно самостоятельной его частью, многие вопросы начинают упираться в наличие стратегии – согласованного со всеми артефакта, который высокоуровнево описывает принципы работы команды, ее цели и основные вехи на пути к ним.
Любовь к наличию стратегии понятна – работа по принципам жадных алгоритмов с субоптимальными решениями всегда кажется неэффективной на длинной дистанции. Наличие плана помогает упорядочить неопределенность и создать иллюзию контроля.
Пост по ссылке – золото. Автор кратко рассказывает о принципах из книги «Хорошая стратегия, плохая стратегия», прикладывает их к разработке стратегии инженерной команды и, самое главное, дает подробный пример такой стратегии. Сама книга, кстати, топовая, тоже рекомендую прочитать. Идеи оттуда я использовал и при написании инженерных, и продуктовых стратегий.
Когда вы руководите всем инженерным департаментом, или какой-то относительно самостоятельной его частью, многие вопросы начинают упираться в наличие стратегии – согласованного со всеми артефакта, который высокоуровнево описывает принципы работы команды, ее цели и основные вехи на пути к ним.
Любовь к наличию стратегии понятна – работа по принципам жадных алгоритмов с субоптимальными решениями всегда кажется неэффективной на длинной дистанции. Наличие плана помогает упорядочить неопределенность и создать иллюзию контроля.
Пост по ссылке – золото. Автор кратко рассказывает о принципах из книги «Хорошая стратегия, плохая стратегия», прикладывает их к разработке стратегии инженерной команды и, самое главное, дает подробный пример такой стратегии. Сама книга, кстати, топовая, тоже рекомендую прочитать. Идеи оттуда я использовал и при написании инженерных, и продуктовых стратегий.
Lethain
Writing an engineering strategy.
Once you become an engineering executive, an invisible timer starts ticking in the background.
Tick tick tick. At some point that timer will go off,
at which point someone will rush up to you demanding an engineering strategy.
It won’t be clear what they…
Tick tick tick. At some point that timer will go off,
at which point someone will rush up to you demanding an engineering strategy.
It won’t be clear what they…
Топ-10 ошибок менеджера при найме сотрудника
Материалы про найм стабильно набирают в канале больше всего лайков. Серебряных пуль не бывает, идеальный процесс за вас никто не построит, но чужой опыт помогает избежать хотя бы части чужих ошибок.
Подключайтесь к открытому эфиру с Евгением Картавцом, руководителем из команды образовательных технологий Яндекса, во время которого он расскажет:
- Как правильно задавать вопросы про опыт и ошибки кандидата, а также на что обращать внимание
- Как подойти к структуре интервью
- Как проверять кандидата через ситуационные вопросы
- Как корректно показать профессионализм вашей команды, ее ценности и не отпугнуть кандидата
Ребята обещают отдельный фокус на популярных ошибках при найме новых сотрудников и способах их избежать.
📆Дата: 28 февраля, 19:00
👉Регистрация
Реклама. Информация о рекламодателе на сайте www.otus.ru
Материалы про найм стабильно набирают в канале больше всего лайков. Серебряных пуль не бывает, идеальный процесс за вас никто не построит, но чужой опыт помогает избежать хотя бы части чужих ошибок.
Подключайтесь к открытому эфиру с Евгением Картавцом, руководителем из команды образовательных технологий Яндекса, во время которого он расскажет:
- Как правильно задавать вопросы про опыт и ошибки кандидата, а также на что обращать внимание
- Как подойти к структуре интервью
- Как проверять кандидата через ситуационные вопросы
- Как корректно показать профессионализм вашей команды, ее ценности и не отпугнуть кандидата
Ребята обещают отдельный фокус на популярных ошибках при найме новых сотрудников и способах их избежать.
📆Дата: 28 февраля, 19:00
👉Регистрация
Реклама. Информация о рекламодателе на сайте www.otus.ru
Ситуационное лидерство
Одного идеального стиля управления командой нет. Его нужно менять в зависимости от степени неопределенности задач, стадии развития команды, личностей конкретных людей внутри. Я думаю, что универсальную модель того, какой стиль лидерства в какой ситуации использовать, выработать невозможно. Люди – сложные, их отношения друг с другом сложнее в квадрате, а влияние всего этого на рабочий процесс вообще плохо предсказуемо.
Но, как известно, все модели врут, но какие-то из них полезны. В статье рассматривается довольно рабочее приближение того, как, в зависимости от стадии развития команды по Ленсиони, выбирать один из четырех стилей управления, различающихся степенью жесткости контроля и автономностью команды.
Одного идеального стиля управления командой нет. Его нужно менять в зависимости от степени неопределенности задач, стадии развития команды, личностей конкретных людей внутри. Я думаю, что универсальную модель того, какой стиль лидерства в какой ситуации использовать, выработать невозможно. Люди – сложные, их отношения друг с другом сложнее в квадрате, а влияние всего этого на рабочий процесс вообще плохо предсказуемо.
Но, как известно, все модели врут, но какие-то из них полезны. В статье рассматривается довольно рабочее приближение того, как, в зависимости от стадии развития команды по Ленсиони, выбирать один из четырех стилей управления, различающихся степенью жесткости контроля и автономностью команды.
Давайте вместе разберем интересный кейс!
Есть команда, которая отвечает за технически сложный продукт. Скажем, за компилятор какого-нибудь языка. Под капотом компилятор состоит из нескольких отдельных подсистем, которые интегрируются друг с другом, но в целом довольно независимы. В команде 10 человек. Каждый из них – эксперт только в одной из подсистем. Экспертность тут означает хорошее понимание ее архитектуры, используемого стека технологий, кейсов пользователей и того, как похожие проблемы решаются в других языках. Вместить в одного человека экспертность сразу в нескольких подсистемах скорее всего не получится.
Команда находится на критическом пути сразу нескольких больших проектов. Для каждого из них нужно сделать ряд изменений в нескольких подсистемах (но не всех!). Распределением задач и их координацией занимается тимлид команды. Эта схема довольно плохо масштабируется по многим причинам – начиная с бас-фактора в лице тимлида, заканчивая тем, что все проекты в одну голову загружаются довольно-таки плохо.
Как бы вы реорганизовали команду и процессы в ней, чтобы:
- Одновременно могла вестись работа сразу по нескольким проектам.
- Тимлид не был бы блокирующим звеном.
- Оставались ответственные за принятие технических решений в каждой из подсистем.
Кстати, если хотите разобрать ваш кейс, пишите мне в личку – какие-то разберу сам, а какие-то в похожем режиме вброшу в канал!
Есть команда, которая отвечает за технически сложный продукт. Скажем, за компилятор какого-нибудь языка. Под капотом компилятор состоит из нескольких отдельных подсистем, которые интегрируются друг с другом, но в целом довольно независимы. В команде 10 человек. Каждый из них – эксперт только в одной из подсистем. Экспертность тут означает хорошее понимание ее архитектуры, используемого стека технологий, кейсов пользователей и того, как похожие проблемы решаются в других языках. Вместить в одного человека экспертность сразу в нескольких подсистемах скорее всего не получится.
Команда находится на критическом пути сразу нескольких больших проектов. Для каждого из них нужно сделать ряд изменений в нескольких подсистемах (но не всех!). Распределением задач и их координацией занимается тимлид команды. Эта схема довольно плохо масштабируется по многим причинам – начиная с бас-фактора в лице тимлида, заканчивая тем, что все проекты в одну голову загружаются довольно-таки плохо.
Как бы вы реорганизовали команду и процессы в ней, чтобы:
- Одновременно могла вестись работа сразу по нескольким проектам.
- Тимлид не был бы блокирующим звеном.
- Оставались ответственные за принятие технических решений в каждой из подсистем.
Кстати, если хотите разобрать ваш кейс, пишите мне в личку – какие-то разберу сам, а какие-то в похожем режиме вброшу в канал!
Пример системы грейдов и инструкция по ее раскатке
Компании регулярно делятся своими системами грейдов. Для них это полезно тем, что кандидаты будут знать, с чем они столкнутся, еще до прихода в компанию. Для нас это полезно, чтобы подсматривать интересные идеи и учиться на чужих ошибках.
В этот раз посмотрим на систему, выросшую из принятой внутри New Relic. Несколько интересных особенностей:
🤔Внутри каждого грейда есть три категории, которые отличаются фиксированным скачком в зарплате. Такое дробление ведет к тому, что повышения можно делать чаще.
💪Основной критерий различия между грейдами – импакт инженера на компанию. Он растет с уровня задач и фичей до уровня успеха всей компании.
🤝Менеджеры – отдельная ветка. При переходе в менеджеры зарплата не меняется, но тайтл может быть «меньше» текущего инженерного. Если зарплата находится за рамками нового менеджерского грейда, ее не понизят, но и повышать какое-то время не будут.
Компании регулярно делятся своими системами грейдов. Для них это полезно тем, что кандидаты будут знать, с чем они столкнутся, еще до прихода в компанию. Для нас это полезно, чтобы подсматривать интересные идеи и учиться на чужих ошибках.
В этот раз посмотрим на систему, выросшую из принятой внутри New Relic. Несколько интересных особенностей:
🤔Внутри каждого грейда есть три категории, которые отличаются фиксированным скачком в зарплате. Такое дробление ведет к тому, что повышения можно делать чаще.
💪Основной критерий различия между грейдами – импакт инженера на компанию. Он растет с уровня задач и фичей до уровня успеха всей компании.
🤝Менеджеры – отдельная ветка. При переходе в менеджеры зарплата не меняется, но тайтл может быть «меньше» текущего инженерного. Если зарплата находится за рамками нового менеджерского грейда, ее не понизят, но и повышать какое-то время не будут.
Rubick
Jade Rubick - Implementing software engineering levels (with fully-usable examples)
Jade shares example engineering levels, that you can use to craft engineering levels at your company.
Интенсив по отстаиванию своей позиции за 15 минут
Отстаивать свою точку зрения часто бывает сложно. Такие задачи очень энергозатратны, их хочется бесконечно прокрастинировать, сложиться в клубочек и спрятаться в ванной, лишь бы только не входить в конфронтацию. Но делать это все-таки приходится. Есть много полезных приемов, которые помогают облегчить страдания и лучше донести свои мысли. Вы можете попробовать вкатиться в них с помощью Telegram-симулятора, который на примере нескольких кейсов покажет эти приемы и посоветует, как их отработать на практике.
А помимо бота, в интенсив входит подробный видео-разбор темы и методичка с теорией и всеми приемами.
👉Симулятор в боте тут
Отстаивать свою точку зрения часто бывает сложно. Такие задачи очень энергозатратны, их хочется бесконечно прокрастинировать, сложиться в клубочек и спрятаться в ванной, лишь бы только не входить в конфронтацию. Но делать это все-таки приходится. Есть много полезных приемов, которые помогают облегчить страдания и лучше донести свои мысли. Вы можете попробовать вкатиться в них с помощью Telegram-симулятора, который на примере нескольких кейсов покажет эти приемы и посоветует, как их отработать на практике.
А помимо бота, в интенсив входит подробный видео-разбор темы и методичка с теорией и всеми приемами.
👉Симулятор в боте тут
Гайд по работе с RFC
RFC – это структурированный письменный пропозал, задача которого погрузить всех заинтересованных в решаемую проблему, возможные решения и их трейдоффы. RFC могут принимать разную форму и решать разные проблемв. Мы в Kotlin очень активно их используем. Например, запрашивая у сообщества фидбэк на новые языковые фичи.
В статье разбирается, как внедрить практику RFC в инженерные команды, которым важно получать больше фидбэка еще до этапа реализации фичи.
Несколько шаблонов таких RFC:
- Google Docs
- Notion
RFC – это структурированный письменный пропозал, задача которого погрузить всех заинтересованных в решаемую проблему, возможные решения и их трейдоффы. RFC могут принимать разную форму и решать разные проблемв. Мы в Kotlin очень активно их используем. Например, запрашивая у сообщества фидбэк на новые языковые фичи.
В статье разбирается, как внедрить практику RFC в инженерные команды, которым важно получать больше фидбэка еще до этапа реализации фичи.
Несколько шаблонов таких RFC:
- Google Docs
- Notion
Всем привет от команды Nebius!
Nebius — это международный спин-офф облачного бизнеса Яндекса с офисами в нескольких странах. Они создают платформу, позволяющую другим компаниям строить собственный локальный облачный бизнес.
Их сотрудники — это команда ярких и талантливых личностей с большим опытом работы в построении и развитии публичного облака.
Вы можете стать ее частью — компания активно нанимает сотрудников в офисы в Белграде и Амстердаме.
На данный момент открыты вакансии для:
• backend-разработчиков — языки Golang, Java, Python , С++, С#
• frontend-разработчиков
• full-stack разработчиков
• technical product managers
• SRE
Полные описания можно найти на сайте.
Если подходящие вам вакансии ещё не открыты — отправьте своё резюме на [email protected]
Nebius — это международный спин-офф облачного бизнеса Яндекса с офисами в нескольких странах. Они создают платформу, позволяющую другим компаниям строить собственный локальный облачный бизнес.
Их сотрудники — это команда ярких и талантливых личностей с большим опытом работы в построении и развитии публичного облака.
Вы можете стать ее частью — компания активно нанимает сотрудников в офисы в Белграде и Амстердаме.
На данный момент открыты вакансии для:
• backend-разработчиков — языки Golang, Java, Python , С++, С#
• frontend-разработчиков
• full-stack разработчиков
• technical product managers
• SRE
Полные описания можно найти на сайте.
Если подходящие вам вакансии ещё не открыты — отправьте своё резюме на [email protected]
Уровни постановки задач
В статье предлагается четыре уровня задач, которые можно делегировать своим сотрудникам:
🥚Выполнить алгоритм
🐣Решить задачу, самому выбрав способ ее выполнения
🐥Устранить проблему, самостоятельно разбив ее на набор задач
🐓Найти возможность или избежать проблем в какой-то области
Основная мысль – важно совмещать уровень человека, которым делегируется задача, и уровень самой задачи. Если неопределенность задачи выходит за зону комфорта сотрудника, он ее неосознанно понизит до удобного ему уровня, при этом пострадает результат. Если задача слишком простая, то либо сотрудник будет грустить от того, что его не ценят, либо самостоятельно расширит ее контекст и пойдет решать другую проблему.
Поймал себя на мысли, что при постановке задач продактам сам регулярно косячу, смешивая разные уровни постановки задач. Например, прошу устранить какую-то проблему, но сразу же накидываю какие-то варианты решения. Такой подход довольно деструктивен, так как для сотрудника пропадает ясность того, а что именно надо делать – самому искать способ решения проблемы, или выбрать предложенный руководителем вариант решения.
В статье предлагается четыре уровня задач, которые можно делегировать своим сотрудникам:
🥚Выполнить алгоритм
🐣Решить задачу, самому выбрав способ ее выполнения
🐥Устранить проблему, самостоятельно разбив ее на набор задач
🐓Найти возможность или избежать проблем в какой-то области
Основная мысль – важно совмещать уровень человека, которым делегируется задача, и уровень самой задачи. Если неопределенность задачи выходит за зону комфорта сотрудника, он ее неосознанно понизит до удобного ему уровня, при этом пострадает результат. Если задача слишком простая, то либо сотрудник будет грустить от того, что его не ценят, либо самостоятельно расширит ее контекст и пойдет решать другую проблему.
Поймал себя на мысли, что при постановке задач продактам сам регулярно косячу, смешивая разные уровни постановки задач. Например, прошу устранить какую-то проблему, но сразу же накидываю какие-то варианты решения. Такой подход довольно деструктивен, так как для сотрудника пропадает ясность того, а что именно надо делать – самому искать способ решения проблемы, или выбрать предложенный руководителем вариант решения.
Алгоритм приоритизации технического долга
✍️Составьте список всех проблемных мест кодовой базы, инфраструктуры и процессов. В детали надо закапываться ровно до того уровня, чтобы увидеть истинную причину проблемы, а не ее следствие. Например, важно отличать неправильно выбранный движок базы данных от плохо спроектированной модели.
🤔Для каждого элемента ответьте на вопрос “Что случится, если ничего с этой проблемой не делать?”. Если система будет деградировать – процент за техдолг высокий. Если все останется как есть – низкий. Если система улучшится – нулевой.
👀Теперь посмотрите на каждый элемент в разрезе того, участвует ли он в активной разработке новых фичей или находится в режиме поддержки. Если находится в режиме поддержки, дополнительно постарайтесь понять, усложняет ли ее факт наличия техдолга.
📊Используя полученные ответы на вопросы, приоритизируйте результат. Универсальных весов для оценки нет, в случае каждого проекта надо применять здравый смысл. Основная идея – в первую очередь исправляйте тот техдолг, из-за которого система со временем деградирует, и который участвует в появлении новых фич.
✍️Составьте список всех проблемных мест кодовой базы, инфраструктуры и процессов. В детали надо закапываться ровно до того уровня, чтобы увидеть истинную причину проблемы, а не ее следствие. Например, важно отличать неправильно выбранный движок базы данных от плохо спроектированной модели.
🤔Для каждого элемента ответьте на вопрос “Что случится, если ничего с этой проблемой не делать?”. Если система будет деградировать – процент за техдолг высокий. Если все останется как есть – низкий. Если система улучшится – нулевой.
👀Теперь посмотрите на каждый элемент в разрезе того, участвует ли он в активной разработке новых фичей или находится в режиме поддержки. Если находится в режиме поддержки, дополнительно постарайтесь понять, усложняет ли ее факт наличия техдолга.
📊Используя полученные ответы на вопросы, приоритизируйте результат. Универсальных весов для оценки нет, в случае каждого проекта надо применять здравый смысл. Основная идея – в первую очередь исправляйте тот техдолг, из-за которого система со временем деградирует, и который участвует в появлении новых фич.
Как работают Mergers & Acquisitions со стороны инженерной команды
CTO Calm, успевший поработать в Stripe, Uber и нескольких стартапах, написал лонгрид про то, как работает покупка компаний, и что в этом процессе ожидается от СТО.
🤔По каким причинам одна компания может решить влить в себя другую
📝Как стратегия бизнеса и инженерная оценка влияют на условия покупки
💬Какие шаги надо сделать и какие темы осветить в инженерной оценке
🧲О чем подумать с интеграционной точки зрения
Как бонус, держите ссылку на плейбук GitLab, в котором они описывают пошаговый алгоритм, по которому покупают стартапы.
CTO Calm, успевший поработать в Stripe, Uber и нескольких стартапах, написал лонгрид про то, как работает покупка компаний, и что в этом процессе ожидается от СТО.
🤔По каким причинам одна компания может решить влить в себя другую
📝Как стратегия бизнеса и инженерная оценка влияют на условия покупки
💬Какие шаги надо сделать и какие темы осветить в инженерной оценке
🧲О чем подумать с интеграционной точки зрения
Как бонус, держите ссылку на плейбук GitLab, в котором они описывают пошаговый алгоритм, по которому покупают стартапы.
Lethain
Engineering’s role in Mergers & Acquisitions.
I managed the engineering team at Digg as we ran out of money, and were eventually acquired. It was an eye opening experience, and I learned a great deal about the reality and the optics of selling a company, particularly one with no money and a shrinking…
Гайд по архитектурной документации
📐Разбор подходов к организации документации: arc42 и C4
💻Практики и инструменты для хранения архитектурной документации в коде
📈Тулинг для построения понятных диаграмм
📐Разбор подходов к организации документации: arc42 и C4
💻Практики и инструменты для хранения архитектурной документации в коде
📈Тулинг для построения понятных диаграмм
Новый вебинар про коммуникации в команде
Ребята из Soft Skills Lab продолжают серию открытых вебинаров про способы прокачки коммуникаций. В этот раз будут разбираться следующие вещи:
😳Как правильно распознавать и обрабатывать различные эмоции коллег
🙅♀️Как отстаивать свои границы и говорить “нет” таким образом, чтобы не сжечь мосты
💬Как давать развивающую обратную связь таким образом, чтобы она была полезной, а не обидной
🤨Как реагировать на манипуляции и переводить общение в конструктивное русло
📆Дата: 13 марта, 19:00 по Москве
👉Регистрация
Ребята из Soft Skills Lab продолжают серию открытых вебинаров про способы прокачки коммуникаций. В этот раз будут разбираться следующие вещи:
😳Как правильно распознавать и обрабатывать различные эмоции коллег
🙅♀️Как отстаивать свои границы и говорить “нет” таким образом, чтобы не сжечь мосты
💬Как давать развивающую обратную связь таким образом, чтобы она была полезной, а не обидной
🤨Как реагировать на манипуляции и переводить общение в конструктивное русло
📆Дата: 13 марта, 19:00 по Москве
👉Регистрация
17 типичных ошибок начинающих руководителей
Легендарная статья Александра Ложечкина про ошибки, которые он совершал сам и замечал за другими тимлидами.
💪Проще самому всё сделать, чем объяснить
👨🏻💼Я теперь руководитель и в детали влезать не хочу
🕷️Я хочу контролировать всё
😴Я не интересуюсь тем, что происходит
🤩Я хочу повышать боевой дух команды, поэтому хвалю всех
🤬Я считаю, что команда всегда должна быть в тонусе, поэтому постоянно завышаю планку требований
🍻Я — свой парень к команде
📏Теперь я — начальник, поэтому строю дистанцию
⭐️Фокус на результате, а не на развитии людей
🤝Попытка удерживать сотрудников
🤔Путать лояльность и преданность
😥Идти на компромиссы при найме
😎Поддаться лести и поверить в собственную значимость
🌴Имитировать вместо того, чтобы руководить
🏑Заставлять людей работать из под палки
😠Ревновать к успеху сотрудников
😳Стесняться своих ошибок, не признавать и замалчивать их
Легендарная статья Александра Ложечкина про ошибки, которые он совершал сам и замечал за другими тимлидами.
💪Проще самому всё сделать, чем объяснить
👨🏻💼Я теперь руководитель и в детали влезать не хочу
🕷️Я хочу контролировать всё
😴Я не интересуюсь тем, что происходит
🤩Я хочу повышать боевой дух команды, поэтому хвалю всех
🤬Я считаю, что команда всегда должна быть в тонусе, поэтому постоянно завышаю планку требований
🍻Я — свой парень к команде
📏Теперь я — начальник, поэтому строю дистанцию
⭐️Фокус на результате, а не на развитии людей
🤝Попытка удерживать сотрудников
🤔Путать лояльность и преданность
😥Идти на компромиссы при найме
😎Поддаться лести и поверить в собственную значимость
🌴Имитировать вместо того, чтобы руководить
🏑Заставлять людей работать из под палки
😠Ревновать к успеху сотрудников
😳Стесняться своих ошибок, не признавать и замалчивать их
Medium
О 17 типичных ошибках начинающих руководителей
Мои ошибки как руководителя
Большой гайд по организации онбординга в команду
👨👩👧👦Роли, необходимые для организации процесса, и набор задач для каждой из ролей
📝Учебный план, который должны пройти все новички
❌Основные проблемы, из-за которых программы онбординга получаются нерабочими
🔀Интеграция инженерного онбординга с общим онбордингом в компанию
Напоминаю, что не так давно мы записывали выпуск Подлодки на ту же тему. Если стало интересно – послушайте, там разбираем все детали!
👨👩👧👦Роли, необходимые для организации процесса, и набор задач для каждой из ролей
📝Учебный план, который должны пройти все новички
❌Основные проблемы, из-за которых программы онбординга получаются нерабочими
🔀Интеграция инженерного онбординга с общим онбордингом в компанию
Напоминаю, что не так давно мы записывали выпуск Подлодки на ту же тему. Если стало интересно – послушайте, там разбираем все детали!
Lethain
Running your engineering onboarding program.
Most companies say that it takes three to six months for newly hired engineers to fully ramp up.
Engineering leaders know it’s impolitic to admit that it takes their team longer than three to six months to onboard new engineers,
so that’s what they say out…
Engineering leaders know it’s impolitic to admit that it takes their team longer than three to six months to onboard new engineers,
so that’s what they say out…
Работа с подрядчиками
Мир изменчивый. Новые окна возможностей для продукта и бизнеса могут открыться в любой момент времени. Именно поэтому любые попытки построить четкие роадмапы или запланировать бэклог команды на год вперед почти всегда обречены на провал. Задача тимлида – организовать процессы и набор навыков в своей команде таким образом, чтобы быть готовым подстроиться под изменения.
Понятное дело, что ко всему не подготовишься. Например, вы занимаетесь маркетплейсом мебели. На WWDC Тим Кук показывает новые очки виртуальной реальности, а спустя пару дней на вас выходит региональный менеджер Apple, и предлагает фичеринг в App Store, если вы успеете перенести свое приложение в VR. Но у вас нет вообще никого, кто хоть когда-то работал бы с трехмерной графикой, а тем более мог бы сделать качественный проект в очень короткий срок. И подготовиться к такой ситуации не получится.
Самый очевидный путь действия в такой ситуации – найти подрядчика, которому можно будет делегировать проект. Но это только звучит просто. Подбор подрядчика – отдельный пласт знаний, не имея которого можно получить очень грустный результат. Я хочу рассказать про классных ребят из Рейтинга Рунета, которые занимаются как раз тем, чтобы сделать рынок айтишных подрядчиков максимально прозрачным. Они публикуют регулярные рейтинги лучших студий разработки и маркетинговых агентств, а заодно проводят классные исследования того, из чего вообще складывается успешное взаимодействие компании и подрядчика.
Если вы хотите прокачать свою насмотренность, подписывайтесь на Telegram-канал Рейтинга Рунета. Они делятся результатами своих исследований, публикуют кейсы выбора подрядчиков, и систематизируют информацию таким образом, чтобы вам проще было научиться на чужом опыте.
Вот несколько постов, с которых можно начать:
Рубрикатор интервью с разными компаниями про то, как они выбирают подрядчиков
Корни конфликтов с подрядчиками и способы их решения
Когда там уже ChatGPT заменит все агентства
Мир изменчивый. Новые окна возможностей для продукта и бизнеса могут открыться в любой момент времени. Именно поэтому любые попытки построить четкие роадмапы или запланировать бэклог команды на год вперед почти всегда обречены на провал. Задача тимлида – организовать процессы и набор навыков в своей команде таким образом, чтобы быть готовым подстроиться под изменения.
Понятное дело, что ко всему не подготовишься. Например, вы занимаетесь маркетплейсом мебели. На WWDC Тим Кук показывает новые очки виртуальной реальности, а спустя пару дней на вас выходит региональный менеджер Apple, и предлагает фичеринг в App Store, если вы успеете перенести свое приложение в VR. Но у вас нет вообще никого, кто хоть когда-то работал бы с трехмерной графикой, а тем более мог бы сделать качественный проект в очень короткий срок. И подготовиться к такой ситуации не получится.
Самый очевидный путь действия в такой ситуации – найти подрядчика, которому можно будет делегировать проект. Но это только звучит просто. Подбор подрядчика – отдельный пласт знаний, не имея которого можно получить очень грустный результат. Я хочу рассказать про классных ребят из Рейтинга Рунета, которые занимаются как раз тем, чтобы сделать рынок айтишных подрядчиков максимально прозрачным. Они публикуют регулярные рейтинги лучших студий разработки и маркетинговых агентств, а заодно проводят классные исследования того, из чего вообще складывается успешное взаимодействие компании и подрядчика.
Если вы хотите прокачать свою насмотренность, подписывайтесь на Telegram-канал Рейтинга Рунета. Они делятся результатами своих исследований, публикуют кейсы выбора подрядчиков, и систематизируют информацию таким образом, чтобы вам проще было научиться на чужом опыте.
Вот несколько постов, с которых можно начать:
Рубрикатор интервью с разными компаниями про то, как они выбирают подрядчиков
Корни конфликтов с подрядчиками и способы их решения
Когда там уже ChatGPT заменит все агентства