OTUS. Онлайн-образование

Много вакансий Agile-PM, а оффер всё уходит «тому самому кандидату»? Разберёмся, что именно проверяют работодатели — на живых примерах из урока. Что повторяется в вакансиях: — Методологии и инструменты. Agile/скрам/канбан, таск-трекеры (на уроке упоминали Jira и Project), понимание жизненного цикла продукта. — Декомпозиция и приоритизация. Умение разложить цель на задачи и выбрать очередность — обязательный пункт. — Техническая грамотность. Опыт со «сложными техническими проектами», понимание высоконагруженных сервисов — это часто прямо пишут...

Сегодня рассмотрим метод, который может стать для вас интересным инсайтом в стратегическом планировании разработки — Wardley Mapping. Если кратко, Wardley Map — это схема, где мы располагаем все компоненты нашего продукта или системы в двух измерениях: по оси «ценность для пользователя» (вертикаль) и по оси «эволюция/зрелость» (горизонталь). Вертикальная ось отражает цепочку ценности (value chain) — насколько компонент близок к конечному пользователю или, наоборот, скрыт глубоко в инфраструктуре...

Если вы ощущаете, что стали частью распределённой системы с бесконечными входящими — поздравляю, вы тимлид. И, скорее всего, вам не весело. Вы не пишете код. Вы не думаете стратегически. Зато вы таскаете ведро с пробоинами по палубе, где вечно течёт. У большинства тимлидов, особенно в условиях активного роста компании или распределённой разработки, есть общее ощущение перегруженности. Неважно, какая индустрия, стек, удалёнка или офис — ощущение одно: «весь день был занят, но результат размыт». Типичные симптомы: Это — не проблема «ленивой команды»...

Сегодня рассмотрим, как тимлиды сами, того не осознавая, убивают инициативу в команде. Делают всё сами, душат рост, превращают разработчиков в «ждущих» исполнителей — и потом удивляются, почему никто не предлагает решений. До тех пор, пока ты воспринимаешь себя как «старшего разработчика с полномочиями», ты не тимлид. Ты просто сеньор, который сидит ближе к рулю. Тимлидство начинается в тот момент, когда ты перестаёшь быть центром решений и начинаешь растить других. Типичный сценарий: горит фича, миддл завис, вы нервно вскакиваете, открываете VS Code, врубаете фокус‑режим, пишете за всех...

Внутренние продукты умирают чаще, чем живут. Причём гибнут не на проде, не из‑за кривого кода и не от того, что разработка пошла не по плану. Они разваливаются на самом старте — когда гипотеза ещё не успела обрести форму, но уже обросла Jira‑задачами. Где‑то я видел, что 9 из 10 новых инициатив не переживают первую встречу с пользователем. Почему? Потому что команды бегут в реализацию, не удостоверившись: а надо ли это вообще кому‑нибудь? Классический двухнедельный Scrum здесь не спасёт. Он хорош, когда вы уже уверены в направлении...