Метка: команда
-
Скраммастер и владелец продукта — один человек. Почему нет?
Почему совмещение ролей скраммастера (SM) и владельца продукта (PO) — плохая идея. У них разные задачи: PO определяет стратегию, SM улучшает работу команды. Совмещение приводит к конфликтам интересов, перегрузке и снижению эффективности. Исключения возможны в малых компаниях, но в целом роли требуют разделения.
-
Системный подход к планированию проекта
Статья Владимира Бычко разбирает планирование сложных IT-проектов: выявление проблем, определение целей, анализ выгод и ограничений, составление плана, управление рисками и командой. Подчёркивается важность вопросов «Почему?» и «Что нужно?», RACI-матрицы, проектного треугольника и коммуникации со стейкхолдерами для минимизации ошибок и достижения бизнес-целей.
-
Минимизируем сопротивление при вводе новых процессов
Внедрение новых процессов в команде осложняет сопротивление из-за привычек и страха перемен. Минимизировать его можно, собирая обратную связь, объясняя цели, привлекая авторитетов, действуя поэтапно и прозрачно. Презентация результатов (меньше конфликтов, лучше задачи) убеждает команду. Будьте старшим товарищем, а не чиновником, и изменения заработают.
-
Кто такие токсики и как с ними работать
Токсичный сотрудник в разработке ПО — это тот, кто вредит команде негативом, эгоцентризмом, плохой коммуникацией или нарушением процессов. Ворчуны могут быть полезны, если направить их экспертизу в конструктив. Нытики, не дающие решений, подлежат замене. Слушайте, управляйте, фильтруйте — и токсичность не разрушит проект.
-
Разработчик врёт. Что делать?
Разработчики могут скрывать проблемы из-за страха, выгорания, недоверия или привычки тянуть. Симптомы: расплывчатые ответы, минимум кода, отмазки. Решения: честная коммуникация, демо, таймбоксинг, 1:1, парное программирование, ревью. Создавайте культуру декриминализации ошибок, мотивируйте и помогайте, чтобы выявить правду и двигать проект вперед.
-
Как построить команду из сотрудников на удалёнке
Удалённые команды сталкиваются с высокой текучкой из-за слабой сплочённости. Проблемы: отсутствие неформального общения, низкая дисциплина, слабое понимание целей. Решение: выстраивать доверие и вовлечённость через регламенты, базу знаний, KPI, бадди, ретроспективы, митапы, 1-2-1. Это формирует устойчивую команду, эффективную не хуже офисной.
-
Как снизить BUS-фактор
Bus-фактор — риск остановки проекта из-за потери ключевого сотрудника. Признаки: отсутствие документации, сложный онбординг, концентрация знаний у одного человека. Для снижения: внедряйте напарничество, упрощайте вход новичков, документируйте действия, проводите ревизию «серых зон» и регулярные 1-2-1. Системность минимизирует риски и обеспечивает устойчивость проекта.
-
Почему на разработчиках лучше не экономить
Статья Владимира Бычко объясняет, почему экономия на разработчиках — плохая идея. Дешёвые специалисты создают код с техническим долгом, усложняющим масштабируемость и поддержку. Опытные разработчики пишут архитектурный, поддерживаемый код, снижая затраты в будущем. Экономия приводит к багам, демотивации и текучке.
-
Фильтрация входящих задач
Стейкхолдеры бесконтрольно сыплют доработками, каждая из которых важная и срочная. Учимся работать с этой проблемой, выправляя её в свою пользу.
-
Мониторинг проекта
Мониторинг проекта — ключевая задача руководителя, включающая отслеживание прогресса, финансов, качества и рисков. Используются автоматизированные инструменты (Jira, системы отчётности) и ручной контроль. Этапы: определение KPI, сбор данных, анализ, корректировка. Эффективный мониторинг выявляет проблемы, минимизирует риски и обеспечивает успешное выполнение проекта.
-
Штатная структура технологической компании
Что-то вроде штатного расписания для типичной технологической компании.
-
13 «Законов подлости» в разработке ПО
Разбор 13 «законов подлости» в разработке ПО: Паркинсон, Хофштадтер, Брукс, Конвей и другие. Они про дедлайны, бардак в командах, переоценку сроков и фич. Всё из опыта.
-
Закон Литтла
Статья про закон Литтла (L = λW) учит, что многозадачность — зло. W (Lead Time) — сколько задача висит в системе, λ (Throughput) — сколько задач команда выдаёт за время. Суть: меньше WIP — быстрее релизы, выше фокус, меньше выгорания. Оптимизируйте процессы, и будет вам счастье.
-
Пять инсайтов руководителя проектов
Пять инсайтов, которые помогут вам стать хорошим пиэмом, особенно на ранних стадиях карьеры.
-
Техническое собеседование на руководителя проектов в Ригла
Техническое собеседование на руководителя проектов в одну из основных российских аптечных сетей. Этапы проекта, критерии успешности, выбор подрядчиков и другие вопросы.