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

Часто тимлидов интерсует вопрс: как измерить продуктивность разработчиков так, чтобы это имело смысл? Часто можно наблюдать, как одни менеджеры пытаются оценивать работу команды количеством коммитов, другие — числом закрытых тасков, третьи искали «та самый единственная метрика», которая покажет продуктивность сразу всех и каждого. Такой метрики не существует, и погоня за ним часто приводит к курьёзным (а иногда и печальным) результатам. В этой статье я поделюсь свежим подходом к этой проблеме — фреймворком SPACE...

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

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

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

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

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

Применяем модель Херси — Бланшара Сегодня рассмотрим как практике использовать модель Херси — Бланшара в управлении людьми. Когда команда маленькая, ты реагируешь интуитивно: одному даёшь больше свободы, другого держишь под контролем. Но когда в команде 5–7 человек и задачи сложнее обычного CRUD, без осознанного подхода быстро начнутся проблемы: Проблема — не в людях. Проблема в том, что ты используешь один стиль руководства ко всем. А они — на разных стадиях зрелости. И вот тут работает модель Херси — Бланшара...

Иногда кажется, что команда вроде бы стабильная, спринты идут по плану — а под конец снова в панике жмёмся к дедлайну, выкидываем фичи и дорабатываем вечерами. Чтобы такого не происходило, я хочу рассказать про простую и очень рабочую модель — 3–3–3. Она помогает прогнозировать скорость команды без гаданий на story points и держать реалистичный фокус: сколько мы реально успеем, а не сколько хочется. Story points — это не метрика, а договорняк. В команде просто говорят: «Окей, эта задача — где‑то на пятёрку»...

Управление в сфере информационных технологий сопряжено с серьезными вызовами. Будь то навигация по сложной динамике стартапов или стремительное внедрение искусственного интеллекта и автоматизации — для неподготовленных руководителей это может оказаться непосильной задачей. Книги от ведущих экспертов предлагают рекомендации по решению распространенных в IT проблем, делятся ценными советами по лидерству и тимбилдингу, а также знакомят технических директоров с последними тенденциями. От признанных бестселлеров...

Мягкие навыки в эпоху искусственного интеллекта — это скрытые ценности рабочего места, но их сложно выработать, если вы работаете дома. Без ежедневного общения с коллегами лицом к лицу научиться тонкостям общения и сотрудничества становится гораздо сложнее. Так какие же практические шаги можно предпринять для развития «мягких» навыков, если общение в режиме Zoom — норма для вас? Автор выделяет семь стратегий, которые стоит попробовать. Вырабатывать «мягкие» навыки, вроде эмпатии, креативности и умения решать проблемы, — непростая задача, особенно при постоянной работе на дому...

Когда Ольга начинала карьеру, её должность называлась «специалист по подбору персонала на производстве». Сегодня она — HR-партнёр в IT-компании, участвует в разработке стратегии и влияет на ключевые процессы в бэк-офисе и инженерных командах. А за плечами — более 10 лет в HR, переход из логистики в IT, смена вектора карьеры и год поиска работы. Поворотным моментом стало обучение в OTUS. «Я чётко понимала: мне нужно углубиться в экспертизу больших компаний, где всё это уже реализовано. Но эти знания были закрыты...

Когда Александр Мельников пришёл работать системным администратором в одно из учреждений Федерального казначейства, инфраструктура была ещё в зачаточном состоянии. Многое предстояло сделать с нуля — от настройки мониторинга до вопросов безопасности. На тот момент у него уже был небольшой опыт Python-разработки, но именно администрирование на Linux стало точкой роста. Чтобы справляться с задачами, которых становилось всё больше, Александр пошёл на курсы OTUS — сначала базовый и продвинутый по Linux...