Архив рубрики ‘управление проектом’

Системный аналитик и управление хаосом на проекте. Часть 2: Методика структурирования требований

Диагностика хаоса — первый шаг. Об этом мы говорили в предыдущей статье. Но сама по себе она ничего не меняет. Это лишь осознание проблемы. Настоящая работа начинается на этапе структурирования требований. Это тот момент, когда вы берёте множество разрозненных данных, противоречий, записей в Telegram, Excel-таблиц, каких-то старых писем и превращаете всё это в рабочий артефакт: […]

Системный аналитик и управление хаосом на проекте. Часть 1: диагностика хаоса

Представь, что ты пришел на новый проект, который находится в состоянии глубокого информационного хаоса. Требования разбросаны по десяткам файлов, нет протоколов встреч, идеи Product Owner’а меняются слишком быстро, а ключевая информация теряется между переписками в мессенджерах и электронной почтой. К сожалению, так бывает! И попытки сразу перейти к структурированию в текущих условиях — очень большая […]

Дневники пиэма. Заметка 01: Ловушка эскалации

Ты что-то ждёшь от коллег из другого подразделения / продукта. Попросил раз. Попросил два. Написал в чат — тишина. Напомнил ещё раз — снова молчание. Знакомо? Что делать дальше? Самый очевидный путь — эскалация. Но точно ли он лучший? Дисклэймер: заметка написана со стороны вендора, который работает с большим корпоративным заказчиком. В организациях поменьше есть […]

Ищем ментора для стартапа: кому писать, что говорить и чего ждать

За годы менторинга я встречался примерно с 1500 фаундерами, при этом с 20+ стартапами работал по несколько лет. И всегда уговаривал фаундеров найти кроме меня еще менторов или эдвайзеров. Я покажу на конкретных примерах, какая от этого большая польза.  Расскажу, как искать хороших менторов, сколько им платить и как можно им не платить. И ещё […]

Зачем переписывать сайт с нуля?

Первые признаки необходимости переписывания сайта Ниже приведу несколько примеров из жизни, которые явно указывают на, что сайт находится в зоне риска и требует переписывания с нуля. В одном месте починили — в двух других отвалилось При оформлении заказа некорректно применялся промокод «ВЕСНА2025». Завели баг, разработчик нашел проблему, пофиксил, выкатил фикс — промокод заработал, все довольны. Через […]

Управлять неуправляемым: как мы придумали метод отслеживания прогресса на масштабной ИТ-трансформации

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

Аналитика требований: SMART, INVEST, MoSCoW — пытаемся систематизировать хаос

Аналитик живёт в мире противоречий. С одной стороны — методологии, которые обещают навести порядок: SMART, INVEST, MoSCoW. С другой — реальность: брифы, скользкие бизнес-цели и коммуникации в духе “Ну тыжаналитик! Разберись!” Инструменты вроде SMART, INVEST и MoSCoW помогают систематизировать хаос, структурировать требования, сделать их понятными, оценимыми, удобными для команды. Но если применять их бездумно, то […]

Как использовать японские подходы в IT. Часть 4: почему?

И один падающий лист предвещает наступление осени. Японская пословица. (こんにちは) Конничива! Я Виктор, менеджер проектов в Selectel. Это четвертая часть цикла про применение TPS/TBP (Toyota Production System/Toyota Business Practice) на практике в IT. Под катом разберемся с фундаментальными вопросами. В частности — о том, как вообще понять, что есть проблема, и нужно ли с ней […]

5 ошибок фаундеров в начале пути — и как их избежать

Вся информация ниже основана на личном опыте, которым я делюсь в своем канале. В моих компаниях не пользовались OKR и бирюзовыми принципами. Только хардкор – KPI и NorthStar Metric (NSM), потому что это работало. Я давно занимаюсь эдвайзингом стартапов и насмотрелся, как фаундеры создают себе проблемы на старте. В начале же все на драйве: идея […]

Тимлиды бывают разными. Иногда очень неожиданными

Что делает тимлид? Руководит командой? Делегирует задачи? Пишет код? Отвечает перед заказчиком? В книгах всё чётко: тимлид — это лидер, вдохновляющий команду и ведущий её к успеху. В жизни всё немного иначе. Одни тимлиды тянут весь проект на себе и не доверяют никому. Другие ходят по митингам и в коде не разбираются. А кто-то просто […]

123.5