Подборка статей про стратегию

Недавно наткнулся на серию заметок про разные аспекты работы над стратегией. В этих материалах не будет никаких готовых фреймворков, но меня они натолкнули на кучу полезных мыслей:

- Оценка стратегии через призму “ставок”, и баланса между risk и reward
- Про то, почему многим стратегиям не достает ясности, и почему они очень абстрактны
- Чем отличаются фокусировка и обобщение в стратегии
- Как собирать фидбэк на стратегию, и почему разные люди говорят разные вещи
- Почему у многих команд и компаний нет стратегии
- Нормально ли, если стратегия часто изменяется

Переход из тимлида в менеджеры менеджеров: вредные советы

Когда ты переходишь из роли тимлида в роль менеджера менеджеров, меняется очень многое. На этой неделе мне попался материал, многие советы из которого я считаю вредными. Давайте попробуем провести небольшой эксперимент. Я расскажу, почему считаю некоторые из предлагаемых автором вещей некорректными, а вы поставите 🔥, если формат понравится.

🎤Автор предлагает с первого месяца в новой роли ворваться в хайринг – разобрать все открытые вакансии, выяснить как они ложатся в общую стратегию, подключиться к процессу интервью самостоятельно. Цель всего этого – получить общую картину по тому, насколько здоровый в команде процесс найма.
💬Найм – это инструмент. До того, как пытаться его чинить, надо понять, а есть ли с ним вообще проблема. Наличие проблемы не определить, пока ты не понял, а что и зачем в командах разрабатывается. Поэтому я бы построил план по-другому:
1. Разобраться с общей стратегией компании, поговорив с релевантными людьми.
2. Выяснить, в чем заключается успех работы каждой из команд.
3. Поговорить с заказчиками и сотрудниками и собрать список известных им проблем, которые мешают достижению успеха.
4. Вместе с тимлидами своих команд оценить влияние этих проблем друг на друга, выделить корневые.
5. В зависимости от того, в чьей зоне влияния находятся проблемы, делегировать их решение тимлиду или заняться этим самостоятельно.

Найм – не обязательно самая горящая проблема. Без понимания контекста вы будете еще одним бесполезным ценным мнением, которое будет толтко мешать.

🎤Автор советует организовать регулярные встречи со всеми, с кем только можно – 1/1 с заказчиками, синки с коллегами, еженедельные митинги с прямыми подчиненными.
💬Синхронное общение – отличный инструмент для тех случаев, когда требуется соединить картины мира и знания нескольких людей чтобы быстро прийти к общему решению. Это очень дорогой инструмент – он сильно вырывает людей из рабочего контекста, причем в то время, которое удобно автору встречи, а не им.

Заводить кучу встреч без явной агенды с целью «посинкаться про статус» – вредно для всех участников. Вместо этого я бы рекомендовал следующий подход:
1. Асинхронное общение по умолчанию. Если вам нужно узнать статус каких-то проектов – настройте общение в чате или в проектном трекере.
2. Если требуется регулярное общение с одними и теми же людьми в рамках решения какой-то конкретной проблемы – регулярные встречи рабочих групп с внятной повесткой – тоже нормально.

В статье есть и хорошие мысли, конечно же. Например, понятная структура коммуникаций с руководителем, упор на делегирование, построение команды из прямых подчиненных. Основная проблема всего материала – то, что автор предлагает совершать много шума без понимания целей и решаемых проблем. Возможно, это поможет создать видимость пользы, но вот к результатам вряд ли приведет.

Как подходить к решению крупных проблем

🤔Не всегда первое приходящее на ум решение будет самым лучшим. Потратьте время на то, чтобы аргументировать его.
💬Проверьте, что проблему вообще стоит решать, поговорив с людьми с другим бэкграундом.
🤬Не поддавайтесь на критику сомневающихся, но отрабатывайте их возражения.
🤝Учитесь убеждать стейкхолдеров, находя свои аргументы для каждого из них.
👨‍👩‍👧‍👦Постройте две команды – инженерную, которая будет работать над решением каждый день, и расширенную, включающую в себя юристов, бизнес, дизайн и другие функции, которые могут пригодиться.

Обновление бизнес модели под меняющийся рынок, так, чтобы она приносила прибыль и умение успевать за динамичной средой – ключевые компетенции для всех, кто занимается развитием бизнеса или, являясь внутренним предпринимателем, стремиться повысить монетизацию продуктовой линейки.

Яндекс Практикум и бизнес-школа Сколково собрали образовательную программу Executive Product Management, которая уже в процессе обучения помогает посмотреть на бизнес-модель с точки зрения роста в текущих реалиях рынка и пересобрать ее так, чтоб получить новых клиентов и новые деньги.

Программа состоит из модулей:
⚫️Анализ ситуации и мышление на уровне бизнес-модели.
⚫️Трендвотчинг и изменение бизнес-модели
⚫️Редизайн бизнес-модели. Коммуникация изменений и питчинг.
⚫️Дорожная карта внедрения инноваций.
⚫️Лидерство в продуктовой команде.

В финале обучения вас ждёт презентация итогов работы и обратная связь от лидеров индустрии.
Обучение проходит в смешанном формате: офлайн и онлайн и длится 4,5 месяца. На обучение вам понадобится 10-15 часов в неделю:
- на офлайн-занятиях вы будете участвовать в воркшопах и деловых играх с лидерами индустрии и коллегами из других цифровых компаний,
- в онлайне вас ждут лекции, практические руководства от экспертов, а также мастермайнды и встречи с сокурсниками.

Стоимость программы 600 000 руб.

Узнать подробнее и записаться на курс можно по ссылке

Письмо от СЕО

Люди в команде всегда ценят прозрачность со стороны руководства. Интересный способ ее обеспечивать – писать регулярные письма или дайджесты на всю команду. Они могут включать в себя:
🤔Список ключевых проблем/хайлайтов, которые держат ваше внимание прямо сейчас
🚦Performance update – статус движения по ключевым целям или проектам
💬Разбор какого-то волнующего всех вопроса

Инструмент подойдет не только СЕО, но и руководителям больших команд на несколько десятков человек.

Дизайн-спринт – набор практик для быстрой проверки гипотез

- Подход предлагает провести полный цикл тестирования идеи – от формулировки проблемы до создания прототипа и проверки его на пользователях за пять дней
- В Додо попробовали адаптировать его к еще более короткому промежутку – к трем дням
- В первый день формулируется исходная проблема, критерии успешности и вопросы, на которые надо найти ответ
- Во второй день генерируются способы решения проблемы, выбирается самый перспективный и дорабатывается
- В третий день разрабатывается максимально простой прототип и тестируется на пользователях
- Подробнее про методологию можно почитать в книге «Спринт»
- Похожий подход мы пробовали применять и в Kotlin, когда решали проблему улучшения онбординга пользователей и создания нового сценария Get Started – получилось очень полезно

Что делает разработчиков несчастными

- В статье разбирается исследование 2000 разработчиков, задача которого – понять, на что влияет счастье разработчиков, и в чем основные причины его отсутствия
- Отсутствие счастья коррелирует с плохой продуктивностью, качеством кода, задержками и плохим перфомансом
- Оптимальная менеджерская стратегия – не пытаться растить счастье, а уменьшать причины несчастья
- Основные причины несчастья находятся в области, на которую могут влиять менеджеры: давление из-за сроков, плохое качество кода и инженерных практик, неперформящие коллеги, рутинные задачи

Как разные компании платят за дежурства

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

⛑Для дежурств нанимают выделенных людей, это основная их работа
📵Дежурства вне рабочих часов отсутствуют
📳Дежурства вне рабочих часов отсутствуют, но потенциально вас могут поднять звонком
🌏Дежурства обязательны для всех инженеров, регулируются сообразно трудовому кодексу конкретного региона
💵Дежурства – часть работы, оплачиваются либо компенсируются выходными
☝️Дежурят волонтеры, но все компенсируется
🤬Дежурства обязательны для всех и никак не компенсируются

Сложные вопросы, которые помогают придумывать новые идеи

Ограничения подстегивают креативность. Если вы проводите стратсессию, или просто ищете решение для сложной проблемы, попробуйте выкрутить возможные сложности на максимум и подумать, как вы с ними справитесь.

- Что надо сделать, чтобы оправдать повышение цен в 10 раз
- Все пользователи ушли, все надо отстраивать с нуля – как вы поменяете продукт
- Вам запрещено использовать ресурсы технического саппорта, как адаптироваться к ситуации
- Если сроки на реализацию проекта срежут в десять раз, как вы поменяете подход к реализации

Такие вопросы можно адаптировать и к небольшой команде разработки:

- Что произойдет, если ваш основной фреймворк задепрекейтят
- Все рекрутеры уволились, как поддержать найм
- В компании запретили все митинги до единого, как подстроить к этому ваши процессы

Вред KPI и метрик в процессе разработки

«Единственная причина вводить KPI – это отсутствие доверия к тому, что ваши разработчики заинтересованы разрабатывать с максимальным вложением своих сил и знаний и становиться лучше со временем».

Золотая статья для фанатов измерять в разработке все, что только возможно, прикрываясь цитатой про то, что нельзя улучшить процесс, который ты не измеряешь. Автор последовательно разбирает часто собираемые метрики и показывает для каждой, почему это деструктивно.

Митап по продуктовой разработке от Яндекс Go

1️⃣ Как проводить архитектурное ревью продуктовой фичи
2️⃣ Как забытые сценарии влияют на разработчиков
3️⃣ Как эффективно проектировать фичи

Митап пройдет в офлайне, в московском офисе Яндекса, 25 августа в 18:00.

Принципы построения команды, ориентированной на качество

Виталий Шароватов начал новую серию статей про различные аспекты организации команды, которые значительно влияют на качество итогового продукта. Одна из таких причин – потеря информации при общении внутри команды. Чем больше потери, тем больше вероятность того, что выпущенный продукт не будет соответствовать потребностям пользователей.

Основной принцип борьбы с проблемой – уменьшение количества звеньев в цепи передачи информации. Вот как этого можно достичь:

1️⃣Команды разработки должны быть максимально близки к пользователю
2️⃣Команды должны быть настолько маленькими, насколько возможно
3️⃣Команды должны быть кроссфункциональными
4️⃣Области знаний участников команды должны пересекаться

Огромный гайд по инцидент-менеджменту

- Как организовать on-call программу
- Основные принципы процесса инцидент-менеджмента
- Как реагировать на инциденты и обрабатывать их
- Как обучаться на инцидентах и улучшать систему со временем
- Рекомендации книг и статей по теме

Звёзды в команде – зачем нужны, как нанимать и удерживать

- Автор делит всех инженеров на A, B и C категории, вне зависимости от грейда. А – это самые проактивные, самостоятельные и ориентированные на конечную пользу.
- Обсуждайте с такими сотрудниками истинную продуктовую задачу, не сводя ее к технической реализации.
- Помогайте им создавать горизонтальные связи в других командах и функциях.
- Собирайте банк челленджей, который сможет удерживать таких людей.
- Не нанимайте звёзд, если в вашей команде только типовые задачи.

Высшее образование в формате онлайн обучения! 🎓

Ведущий цифровой университет страны НИУ ВШЭ продлевает набор до 20 сентября❗️на онлайн-программу Магистр по компьютерному зрению 💥

Получите самые современные и востребованные компетенции в области компьютерного зрения от НИУ ВШЭ и ведущих технологических компаний, формирующих индустрию Computer Vision 💪

Более подробно о программе по ссылке 👈

Студенты НИУ ВШЭ получают доступ ко всем привилегиям: от информационных ресурсов до отсрочки от армии, а выпускникам выдают диплом НИУ ВШЭ государственного образца и приложение к диплому на английском языке.

Стань студентом лучшего ВУЗа России*💪
Набор ведется до 20 сентября включительно!


* 1 место в рейтинге ТОП-100 вузов России по версии Forbes

Баланс положительного и негативного фидбэка

У вас есть крутые коллеги или сотрудники, которых вы цените. Но иногда они косячат, и вы даете им обратную связь про это. Хороший повод задуматься – а соответствует ли баланс положительного и отрицательного фидбэка тому, как вы их на самом деле оцениваете. Несколько советов про то, как давать положительную обратную связь:

- Будьте очень конкретны. Вместо «ты очень клевый» лучше сказать «ты научил меня многому в том, как парсить JSONы»
- Используйте фреймворк Situation, Behavior, Impact для конкретики
- Перед тем, как критиковать какие-то компоненты понравившейся вам идеи, не забудьте похвалить ее в целом
- Не ждите выдающихся вау-моментов, чтобы дать обратную связь

DivKit — фреймворк для ускорения разработки приложений

- В статье рассказывают про новый инструмент для техлидов в мобильной разработке. DivKit помогает управлять интерфейсом приложений с сервера, не тратя время и ресурсы на выкладку новых релизов в Google Play и App Store.
- Штука очень гибкая: можно внедрить server-driven ui на уровне отдельных элементов, раскатывать изменения сразу на все версии приложения и все платформы.
- Раньше DivKit использовался только в Яндексе, теперь исходный код и библиотеки открыты для всех.