Привет! Меня зовут Ислам, я Project Manager.
Сегодня хочу поделиться своей историей о том, как мне удалось систематизировать полнейший бардак внутри IT-проекта, в котором не было ни трекинга задач, ни документации, ни прозрачности. Только разработчики, хаос и задачи, которые валились словно вода в водопаде.
Когда я проходил шестимесячную стажировку, подобных кейсов не было: всё было методично, задачи в трекере, понятные процессы, регулярные встречи. Но как только я вошел в реальный проект — реальность дала по голове.
Первая неделя: Добро пожаловать в хаос
Меня встретил проект, в котором:
Задачи сыпались в Telegram или прилетали устно;
Разработчики выкатывали фичи в прод без предупреждения — с багами;
Техподдержка писала гневные сообщения из-за сломанных функций;
Документации не было вовсе (да и я сам на тот момент только учился её правильно писать).
Типичный сценарий: тебе на словах объяснили задачу → ты написал док → отправил разработчику → он сказал «понял» → и без предупреждения выкатил это в прод. Через пару часов — прод сломался. Весело же?
Шаг 1. Первичная структуризация задач
Сначала я стал писать короткие документы по задачам и публиковать ссылки в общий чат, отмечая ответственного.
Потом пробовал завести Google-таблицу, чтобы как-то отслеживать статусы. Но метод оказался нежизнеспособным — команда была замкнута, никто не хотел коммуницировать. В таком режиме мы проработали два месяца. Статусы терялись, никто ничего не помнил, вся коммуникация — в личках.
Шаг 2. Внедрение трекера и процессов
Я думал, что если появился таск-трекер — всё, жизнь наладилась. Но на деле систематизация только началась.
Мы начали с Trello. Тогда я с канбаном ещё не дружил, но собрали доску с колонками:
Задачи на будущее
На этой неделе
Бэк
Фронт
QA
Готово
В проде
Процесс выглядел так:
Бэкенд брал задачу → завершал → перекидывал во фронт.
Фронт брал → делал → передавал в QA.
QA тестировал → при успехе — «Готово», при баге — возвращал обратно.
Это дало первый реальный эффект: команды бэка, фронта и QA начали работать как единое целое. До этого казалось, что они с разных планет.
Шаг 3. Коммуникации с бизнесом
Одна из самых больших проблем: бизнес мог выдернуть разработчика в любой момент. Это убивало все сроки.
Решение: договорился, что теперь все задачи от бизнеса идут через меня. Без этого невозможно было наладить поток.
Шаг 4. Один против семи
На тот момент:
Не было ни аналитика
Ни продакта
Ни второго проджекта
Я оставался один на 7 разработчиков. Пришлось выполнять все роли:
Собирать и документировать бизнес-требования
Переубеждать бизнес на реалистичные сроки и объемы
Следить, чтобы команда не перегорела и не захлебнулась в потоке
Шаг 5. Командное единство
Я договорился, чтобы разработчики сели вместе в одном пространстве. Это банальное действие дало нереальный буст коммуникации — вопросы стали решаться быстро, баги обсуждались на месте, фидбек — сразу.
Шаг 6. Появление продакта
Когда в команде появился продакт, мы разделили зоны ответственности:
Он:
Принимал требования от заказчика
Формировал и приоритизировал бэклог
Детализировал фичи
Я:
Планировал задачи и ресурсы
Оценивал сроки
Управлял рисками
Со временем он предложил внедрить Scrum. Мы решили попробовать.
Шаг 7. Scrum и переход на Jira
Мы адаптировали процессы под Scrum. Быстро поняли, что Trello не тянет наши процессы. В этот момент в компанию пришёл новый руководитель, который как раз продвигал Agile и фреймворки Scrum/Kanban. С его помощью мы быстро мигрировали в Jira.
Первые спринты были «учебными» — чтобы команда привыкла к инструменту. Потом я открыто рассказал команде о планах, объяснил, как будем работать и зачем это всё нужно.
Шаг 8. Ретроспективы и дейлики
Ретроспективы проводил в два этапа:
Сначала — Google-форма, чтобы собрать фидбек и заранее подготовиться;
Потом — неформальная встреча для обсуждения.
Дейлики — формат, к которому я сначала относился скептически. Но мы адаптировали их под себя:
Утром участники заполняют Google-форму (что делал вчера, что планируешь, есть ли блокеры)
Потом — короткий созвон на основе этих ответов
Все итоги фиксируются в общем чате
Шаг 9. Sprint Report
Чтобы поддерживать системность, я начал каждую неделю делать короткий спринт-отчёт в Google-формах: что сделали, что не успели, какие выводы. Это дало синхронизацию с продактом и помогало держать фокус.
Результаты за 6 месяцев
Настроили процессы и трекинг задач
Объединили разрозненные команды
Оптимизировали коммуникацию с бизнесом
Перешли на Scrum и Jira
Вышли из режима тотального пожара
Было тяжело. Грязно. Иногда — очень. Но при этом чертовски интересно.
Если вы сейчас на том этапе, где всё вокруг горит — это нормально. Главное — не сдаваться. Идти шаг за шагом. У вас всё получится.
Спасибо, что дочитали. Если откликнулось — напишите, рад буду пообщаться 🙌
