Уборка хаоса | Систематизация IT проекта глазами PM

Приветствую! Меня зовут Ислам, я Project Manager

Сегодня я хочу поделиться своей историей, как изнутри систематизировал полный бардак в IT проекте, где не было ни нормального трекинга задач, ни документации, ни прозрачности — вообще ничего, кроме разработчиков, задач и хаоса.

Когда я проходил 6 месячную стажировку, таких случаев даже близко не было. Там было методично, задачи в трекере, понятные процессы. Но реальность оказалась совсем другой.

Когда я зашел в проект, меня встретила реальность проектного управления, которая мне не снилась при стажировки.

  • Задачи, которые падают словно вода в водопаде нет ни начала ни конца

  • Разработчики, которые выкатывают фичи в прод без предупреждения и с багами

  • Техподдержка которая выносит тебе мозг за это

  • отсутствие документации (да и сам я тоже пока ее идеально писать не умею)

    Ситуация примерно такая: Прилетела задача в телеге или устно → ты ее изучил понял → написал док → скинул разработчику → он, ознакомился, сказал понял, через пол часика жди и тут тишина. Через пару часов, выясняется, что он ее выкатил в прод, и все сломалось. Весело же)

Первые шаги

Я начал описывать задачи в коротких доках, и после скидывал ссылки разработчикам в общей группе и отмечал ответственного за задачу

Позже я открыл гугл таблицу и пробывал внедрить таким подходом, но в моем случае был безуспешный метод. Т.к участники команды были закрытыми и не хотели коммуницировать

Таком ритме проработали месяца два может и больше. Самое больное в таком методе, сложно отслеживать статусы задачи, легко запутаться кому угодно, никто ничего не помнит.

Шаг второй — появление таск трекера

Изначально я думал, что если есть таск трекер, то все это успех, но на самом деле систематизация только только началась. Это был трелло таск трекер, канбаном в то время я был не особо знаком и дружелюбен. И у нас были такие колонки как «Задачи на будущее», «На этой неделе», «Бэк», «Фронт», «QA», «Готово», «В проде»

Порядок работы по задаче был таков

  • Бэк взял в разработку → сделал → переместил колонку для фронта

  • Фронт взял в разработку → сделал → переместил в колонку для QA

  • QA протестировал → если все ок → перемещал в колонку готово, если баг то с описанием обратно к фронту или бэку в зависимости от проблемы

    Этот процесс помог с объединение команд фронта, бэка, и qa. Сформировалось такое ощущение что как будто раньше работали на разных планетах.

Шаг номер 3

  1. Налаживание процессов взаимодействия с бизнесом

    1. Проблема: техподдержка могла выдернуть разработчика с задачи в любой момент. Это убивало сроки.

    2. Решение: договорился с бизнесом, что задачи идут через меня. Без этого — хаос не победить.

  2. Работа в одиночку на 7 разработчиков

    1. Проблема: Нет аналитика, нет Продукта, или нет прожекта который поможет

    2. Решение: Запросить в помощь у руководство, что бы наняли еще человека.

      1. Пока не было их, приходилось делать следующее

        1. Разбирать и документировать бизнес требования

        2. Переписывать и договариваться о более реалистичных требованиях

          1. Больно фантастические планы у бизнеса к команде

        3. Следить за фокусом команды, и что бы она не захлебнулась в этом хаосе

  3. Объединение команд

    Пришлось договариваться о посадке участников команд вместе. Посадив команду вместе друг с другом, результат не заставил себя долго ждать, улучшилась коммуникация среди участников команд. Вопросы и проблемы по задачам, значительно быстрее стали решаться.

  4. Появление продукта. Когда появился продукт в команде, мы распределили с ним пул зон ответственности

    1. Он взял на себя:

      • Прием требований от заказчика

      • Формирование бэклога

      • уточнение и детализация фич

    2. Я же взял на себя

      • Планирование

      • оценка сроков

      • Управление рисками

Через определенное время, продукт заговорил о внедрении scrum в наши процессы.

Мы решили, что почему бы и нет. И решили, сделать бизнес процесс более адаптированный к scrum. Адаптировали доску к scrum, и выяснилось, что таск трекер не позволяет покрыть наши процессы. В итоге решили, что нужен переход на JIRA. к счастью, пришел в компанию новый руководитель, который как раз токи, хотел полноценное внедрение в культуры Agile и фреймворков Scrum Kanban. Он адаптировал флоу под JIRA и переезд у нас достаточно быстро произошел.

Переехав на JIRA с командой начали мягкий переход на фреймворк scrum

Первые спринт у нас были формата dev среды. Это необходимо было, для того что бы команда привыкла работать в новом инструменте.

Второй спринт, собрав команду я открыто объяснил о планах, как мы будем отныне работать объяснил порядок внедрения фреймворка. Попробовав в таком формате проработать, провел ретроспективу в конце спринта, но в разделенной вариации. Сначала участники команды написали ответы на вопросы ретроспективы в гугл формах. (Это я делал, для того что бы предварительно подготовиться к возможным вопросам и проблемам на которые я вдруг не найду ответа) Во второй части мы с командой в неформальном варианте пообщались и определили плюсы и минусы.

Внедрение дейликов. Изначально я очень скептически относился к дейликам, но в итоге решил. Что буду проводить дейлики в другом формате. Участники команды перед началом дня заполняют форму в гугл доксах. После, мы с командой собираемся проводим дейлик, с разбором кто что будет делать, в основе вопросов и ответов которые заполнялись в гугл формах. А результаты дейлика я фиксировал в группе после его прохождения.

Sprint Report — для меня как проект менеджера была важна системность, раз уж команда пишет и применяет гугл формы в своей деятельности, то почему бы и мне тоже не делать это?! Я взял в привычку на еженедельной основе писать Sprint Report через гугл формы, в итоге это помогло мне и продукту сфокусироваться на понимании, что мы все совместно тут делаем и к чему идем.

Ну и наверное самое главное, что нужно сказать. Во всех этапах важно слушать и прислушиваться к команде, внедрять что уместно, облегчать рутину.

Обобщенный итог: За 6 месяцев мы прошли путь от анархии к структуре

  • Настроили задачи, коммуникации, процессы

  • Объединили команду

  • Оптимизировали работу с бизнесом

  • Перешли к фреймворкам Scrum

    Было тяжело, грязно, интересно.

    Если вы сейчас на том этапе, когда все везде горит — это нормально, главное не сдавайтесь! Двигайтесь шаг за шагов у вас все получится :-)

Благодарю вас за то что дочитали, спасибо :-)

Автор: OneTreyMore

Источник

Оставить комментарий