Рубрика: Менеджмент
-
8 стратегических менеджерских ошибок в IT
Владимир Бычко перечисляет 8 стратегических ошибок IT-менеджеров: зависимость от поставщика, неправильное использование облака, чрезмерный бизнес-кейс, наём токсичных сотрудников, продвижение неподходящих кандидатов, Agile для базовых систем, слишком частое согласие и сокрытие проблем. Избегайте их для успеха, диверсифицируйте, будьте ответственны и прозрачны.
-
Асинхронность в Agile на удалёнке
Agile на удалёнке страдает от перегрузки встречами, контроля и Zoom-усталости, превращая ритуалы в профанацию. Решение — асинхронная работа: дробление задач для независимости, письменная коммуникация по делу, скринкасты вместо созвонов. Плюсы: эффективность, меньше стресса, доступ к лучшим специалистам, прозрачность. Переход: подготовка, инфраструктура, правила, постепенное внедрение, оценка, поддержание культуры.
-
One-to-one, 1-to-1, 1-2-1, 1:1 встреча
Встречи 1-2-1 необходимы для мотивации и поддержки сотрудников, а не только контроля. Подготовьтесь: изучите заметки, задайте вопросы о самочувствии, приоритетах, фидбэке и росте. Проводите раз в 2 месяца, ведите заметки, выполняйте договорённости. Фокус на доверии и развитии усиливает вовлечённость и раскрывает скрытые проблемы команды.
-
Аудит проектного управления
Аудит проектного управления оценивает эффективность, зрелость процессов и управляемость. Проверяйте треугольник, бизнес-метрики, препятствия через анонимные интервью. Оценивайте регламенты, автоматизацию, отчётность, совещания, проектный офис и компетенции. Анализируйте поведение и мотивацию. Аудит выявляет точки роста, адаптируясь под компанию, а не становится формальностью.
-
Самоорганизующиеся команды
Самоорганизующиеся команды выбирают методы работы в рамках заданных целей, повышая инновации и скорость. Успех зависит от разнообразия специалистов, стабильности и лидера, создающего среду для самоорганизации. Лидер направляет, устраняет препятствия и поощряет ответственность.
-
Почему квалификация разработчика не гарантирует качество кода
Плохая среда разработки, а не низкая квалификация, часто приводит к некачественному коду. Хаотичные процессы, отсутствие CI/CD, спешка и игнорирование инициатив убивают мотивацию разработчиков. Давление ради скорости упрощает архитектуру и вызывает баги. Для качественного кода нужны стабильные процессы, нормализация среды и поддержка инициатив, даже с риском задержек релиза.
-
В чём разница между Product Manager и Product Owner
Product Manager (PdM) и Product Owner (PO) различаются: PdM — стратег, отвечает за видение продукта и прибыль, не привязан к методологиям. PO — тактик в Scrum, фокусируется на ценности продукта и бэклоге. PdM имеет больше вакансий (2983 против 506), но обязанности схожи: анализ рынка, работа со стейкхолдерами.
-
Метод Дельфи в управлении проектами
Метод Дельфи — прогнозирование через анонимные опросы экспертов в несколько раундов для достижения консенсуса. Применяется в IT для оценки рисков и принятия решений. Анонимность и структурированная обратная связь минимизируют предубеждения. Требует времени и качественных экспертов, но эффективен для сложных проектов с высокой неопределенностью.
-
20 вопросов, которые должен задать пиэм перед стартом проекта
20 ключевых вопросов для менеджера проекта перед стартом: от бизнес-целей и рисков до ресурсов, сроков и приёмки. Навык задавать вопросы и добиваться ответов критичен для успешного запуска. Чёткие ответы на эти вопросы обеспечивают понимание целей, минимизируют риски и гарантируют уверенный старт.
-
Скраммастер и владелец продукта — один человек. Почему нет?
Почему совмещение ролей скраммастера (SM) и владельца продукта (PO) — плохая идея. У них разные задачи: PO определяет стратегию, SM улучшает работу команды. Совмещение приводит к конфликтам интересов, перегрузке и снижению эффективности. Исключения возможны в малых компаниях, но в целом роли требуют разделения.
-
Допущения и ограничения
Владимир Бычко обсуждает проблему плохих постановок задач в управлении проектами. Заказчики часто предоставляют нечёткие цели, что усложняет работу. Неопытные менеджеры могут посылать заказчика, принимать размытые задачи или тянуть время. Метод допущений и ограничений помогает структурировать задачи, минимизировать риски и согласовать ожидания, превращая «галлюцинации» в подобие ТЗ.
-
Правильное завершение проекта по разработке ПО
Завершение IT-проекта требует ревизии задач, сверки с заказчиком и подписания документов. Важно проанализировать метрики (загрузка, velocity, NPS, финансы), организовать обучение клиента и поблагодарить за сотрудничество. Ретроспектива, обратная связь и архивация артефактов закрепляют уроки, улучшая будущие проекты и сохраняя доверие стейкхолдеров.
-
Системный подход к планированию проекта
Статья Владимира Бычко разбирает планирование сложных IT-проектов: выявление проблем, определение целей, анализ выгод и ограничений, составление плана, управление рисками и командой. Подчёркивается важность вопросов «Почему?» и «Что нужно?», RACI-матрицы, проектного треугольника и коммуникации со стейкхолдерами для минимизации ошибок и достижения бизнес-целей.
-
Минимизируем сопротивление при вводе новых процессов
Внедрение новых процессов в команде осложняет сопротивление из-за привычек и страха перемен. Минимизировать его можно, собирая обратную связь, объясняя цели, привлекая авторитетов, действуя поэтапно и прозрачно. Презентация результатов (меньше конфликтов, лучше задачи) убеждает команду. Будьте старшим товарищем, а не чиновником, и изменения заработают.
-
Кто такие токсики и как с ними работать
Токсичный сотрудник в разработке ПО — это тот, кто вредит команде негативом, эгоцентризмом, плохой коммуникацией или нарушением процессов. Ворчуны могут быть полезны, если направить их экспертизу в конструктив. Нытики, не дающие решений, подлежат замене. Слушайте, управляйте, фильтруйте — и токсичность не разрушит проект.