Задача сделана и нет одновременно – или как мы устраняли квантовую неопределённость на проектах
Личный опыт наведения порядка в проектах по заказной разработке.
Простота лучше воровства
На заре создания нашей компании в качестве системы управления проектами мы выбрали Redmine. Сакрального смысла в таком выборе не было: один из основателей, работавший в ИТ-гиганте, притащил из своего корпоративного мира best practice в виде использования этой системы.
У других основателей компании, в том числе и у меня, такое предложение никаких возражений не вызвало. Особенно нам нравилось, что Redmine бесплатный.
По началу мы стали использовать возможности системы «из коробки». Во-первых, в разработке и процессах мы тогда понимали сильно меньше, чем сейчас. Во-вторых, масштабы и количество проектов, а также размер коллектива это позволяли: всё у всех было перед глазами, процесс разработки контролируемым, а результат прогнозируемым.
К слову и для понимания исходного состояния: в начале мы использовали только одну сущность – Задача (трекер task), для которой было предусмотрено всего пять статусов: новая, в работе, выполнена, отменена, приостановлена.
Сейчас даже стыдно от такой наивности. Самому удивительно, но тогда этого хватало.
Хотя если задуматься, то ничего поражающего воображения нет. Видимо интуитивно, мы выбрали правильный путь внедрения: исходить из текущих процессов и на них накладывать подходящую систему. Другими словами: инструменты для процессов, а не наоборот.
Как мы закопались
Со временем проектов стало больше, они усложнялись и удлинялись. Вместе с этим рос коллектив, появлялись новые роли в команде. Вслед за изменениями мы настраивали и Redmine.
Хотя «настраивали» – это громко сказано. В основном это сводилось к добавлению новых статусов задач, переходов между ними и пользовательских ролей. Так, например, в статусной модели трекера task появились «на тестировании», «протестировано» и «на приёмке».
Плюс к этому мы пробовали не менять исполнителя у задачи, а её жизненный цикл отслеживать только по статусам.
Казалось бы, это должно добавить прозрачности ходу разработки, но случилось ровно наоборот – контроль по проектам стал уползать.
Из-за нагромождения и плохой продуманности таких изменений очень скоро узнать из Redmine о статусе проектов нельзя было ровным счётом ничего.
Например, статус “на тестировании” не давал чёткого понимания, тестируется ли задача в данный момент или только ожидает своей очереди на проверку. А то, что задача всегда была закреплена за одним человеком, вводило лишь путаницу - зачастую нельзя было однозначно сказать, кто же ей занимается именно сейчас.
Чтобы прояснить ситуацию приходилось связываться с исполнителями, уточнять реальный статус задач, и проводить дополнительные планёрки.
При достижении критического значения количества проектов и, как следствие, задач в Redmine такого микроменеджмента стало непомерно много. Тут же захромала эффективность работы команды, что сказалось и на экономических показателях компании.
В довесок к этому из материалов, описывающих процесс, у нас были только регламенты в текстовом формате, из которых разобраться, как всё устроено, было затруднительно. А уж запомнить и применять почти невозможно. Наглядной блок-схемы и автоматизации процесса явно не хватало.
Ситуация осложнялась ещё и тем, что у нас были и есть разные типы проектов: где-то мы реализуем проект полностью «под ключ», где-то работаем с готовыми требованиями, а где-то занимается только сопровождением. Одни и те же статусы задач на разных проектах означали разное их состояние! Были даже шутки про задачи Шрёдингера, которые одновременно сделаны и нет. Смех сквозь слёзы.
Стало понятно, что так продолжать нельзя, иначе захлебнёмся и уже не выплывем.
Целеполагание
Осознав проблему, мы поставили себе цель изменить производственный процесс и сделать из Redmine реальный инструмент управления проектной деятельностью, а не просто todo-list. Чтобы этого добиться мы наметили следующие задачи и требования:
- проработать и визуализировать процесс в виде подробной блок-схемы;
- сделать процесс разработки и работу в Redmine прозрачными; причём с двух сторон: как для руководства, так и для всех членов команды;
- автоматизировать насколько это возможно работу в Redmine;
- исключить микроменеджмент;
- унифицировать процесс под разные типы проектов.
Попутно мы ещё хотели улучшить качество тестирования. И поскольку это часть производственного процесса, то изменение подхода к работе на этом этапе также нужно было учесть при разработке нового workflow.
Далее о том, как мы воплощали намеченное в жизнь.
Сила визуализации
Сперва наперво мы провели ряд собраний рабочих групп: отдельно с менеджерами, разработчиками и инженерами по тестированию.
На них мы до косточки разобрали процессы: обсудили каждый статус в модели, все переходы по матрице, как построены взаимоотношения с клиентами на разных типах проектов, выявили путаницу и неразбериху, обдумали, как их устранить.
По итогу таких обсуждений разработали новую схему рабочего процесса и визуализировали её. Получилась она довольно объёмной, поэтому выкладывать сюда не представляется разумным. Кому интересно - напишите мне в личку, сброшу.
Нарисовав блок-схему, мы сразу почувствовали два сильных положительных эффекта:
1. Получили хорошо представленный и поэтому понятный всем участникам процесс разработки. Все ребята стали однозначно и единообразно воспринимать значения статусов и корректно пользоваться матрицей переходов между ними. Так мы добились прозрачности процесса изнутри.
2. Увидели «напряжённые узлы» – этапы, где процесс слишком сложный и неэффективный. Так, например, мы сообразили, что можно снять с и без того загруженных ведущих разработчиков функции контроля оценок задач, заменив их покером-планированием.
Эпическая автоматизация
Развязав такие «узлы» в процессе, мы принялись за настройку Redmine: удалили устаревшие статусы, поменяли логику оставшихся и добавили новые в соответствии с изменённой схемой.
Главным нововведением были новые трекеры, логику которых мы очень глубоко проработали. Так у нас кроме task появились epic, test, bug и checklist.
Трекер epic используется для блока работ, отражающих то или иное функциональное требование. Задача с трекером epic включает в себя всё, что связано с реализацией данного функционального требования, начиная от оценки и заканчивая приёмкой. Грубо говоря, epic – это контейнер для всех задач других трекеров.
Трекеры test и checklist используются для задач тестирования. При этом последний, как можно понять из названия, содержит чек-лист того, что требуется протестировать в рамках реализации epic.
Трекер bug, очевидно, используется для ошибок и имеет специальное поле «Баг от заказчика», с помощью которого мы теперь можем разделить ошибки, выявленные нашими тестировщиками в ходе разработки и те, что вернулись к нам после приёмки или во время эксплуатации.
Кроме того, мы стали использовать такую сущность Redmine, как «Версия». С помощью версий мы объединяем эпики, соответствующие законченной части проекта или этапу работ.
Всю эту красоту мы приправили автоматизацией. Например, запретили создание задач без привязки к эпику, добавили автоматическое создание подзадачи на тестирование при создании эпика, добавили автоматическое заполнение полей дочерних задач, созданных внутри эпика, реализовали автоматическую привязку Merge Request в GitLab к задаче в Redmine.
Также мы добавили ряд обязательных полей при смене статусов задач: Срок завершения, Оценка временных затрат, Согласованные часы, Баг от заказчика и Закрыта в срок. Данные из этих полей мы используем для анализа проектной деятельности и принятия управленческих решений.
На этом этапе мы добились следующих положительных эффектов:
- Сделали процесс прозрачным снаружи. Теперь из Redmine видно актуальное состояние проекта: по статусам, срокам, а также соотношению оценок и трудозатрат эпиков можно судить в целом о ситуации на проекте, а “проваливаясь” внутрь эпика – о том, что происходит по конкретным задачам.
- Устранили микроменеджмент. Благодаря прозрачности и продуманности схемы процесса больше нет необходимости в индивидуальном порядке уточнять подробности статуса задач у исполнителей или просить заполнить какие-то поля в задачах. Также сократилась продолжительность планёрок: обсуждаем только проблемы, а статусы и так видны из Redmine.
Важной особенностью нового процесса является разделение зон ответственности. Например, эпик всегда закреплён за менеджером. Это означает и демонстрирует, на ком именно лежит ответственность за его сдачу заказчику.
Дополнительным бонусом к описанным выше эффектам стало упрощение формирования и повышения достоверности отчётов, которые можно создавать в Redmine с помощью гибкого функционала запросов.
У нас стало больше данных по работе команды и тому, как выполняются задачи. На основе собираемой статистики и её анализа можно а) принимать управленческие решения и б) дальше улучшать процессы.
Жаркое внедрение
Очевидно, такие резкие и глубокие преобразования не проходят гладко. Сразу после внедрения посыпались вопросы от исполнителей, обнаружились нехватка переходов между статусами и другие нестыковки.
Еженедельно мы докручивали процесс и Redmine, выпуская обновления и проводя разъяснительные планёрки.
Спустя месяц ситуация стабилизировалась. Процесс заработал, и мы оказались в Нирване.
Итого
Проведя титаническую и болезненную работу по улучшению внутреннего процесса разработки, мы добились своего:
- сделали работу по проектам прозрачной и контролируемой: руководству достаточно заглянуть в Redmine и получить адекватное представление о состоянии дел на проектах без микроменеджмента;
- сделали рабочий процесс понятным для всех участников команды:спасибо вдумчивой проработке нашей проектной деятельности и её визуализации в виде блок-схемы, что особенно ценно для новых сотрудников;
- за счёт автоматизации упростили работу в Redmine, сделали её понятнее для исполнителей, а также сократили места, где часто возникали ошибки из-за человеческого фактора, что также способствовало избавлению от микроменеджмента;
- устранили размытие зон ответственности: сейчас чётко ясно что, от кого и когда ожидать;
- унифицировали работу в Redmine по проектам разных типов; да, возможно мы заплатили за это монструозностью схемы рабочего процесса, но, как мы сейчас видимо, оно стоит того;
- получили наглядный инструмент в виде блок-схемы, анализируя который можно продолжать улучшать процесс.
И ещё один важный вывод, который хочется оставить себе в виде татуировки: улучшать процессы и внедрять нововведения лучше постепенно, по мере необходимости и с глубокой проработкой.
Что дальше
Завершив описанное, мы вошли во вкус. В наших ближайших планах:
- добавить дашборды с наглядным представлением ключевых показателей проектной деятельности;
- ещё улучшить текущий производственный процесс: автоматизировать оставшиеся участки, расшить узкие места, отрезать лишнее и тестировать новые методики проектного управления;
- затащить в Redmine и другие внутренние процессы компании: документооборот, исполнение платежей, обработку запросов и даже рекрутинг; частично это уже сделано и сейчас проходит пилотирование.
На VC ещё есть ретрограды, которые используют Redmine?
Ну, поздравляю! Можно озвучить конкретику (если не секрет, конечно)
1.Сколько времени занял процесс (календарно) от идеи и выбора RM до начала работы (внедрение, когда уже не стояло колом все)
2. Сколько внутренних ресурсов (в FTE на эту систему потрачено было)
3. Привлекались ли внешник эксперты (интеграторы\консультанты)?
И последний вопрос, если бы вы повторно сейчас проходили этот путь, взяли бы вы RM или уже видите альтернативы?
Альтернативы RM есть и мы их рассматривали, но понимаю, что во всех инструментах есть ограничения. И затраты по переезду на новый инструмент пока что не соизмеримы с профитом от него.
Если вы обошлись 60 FTE это нормально вполне для вас, как для новичков + вы эксперта по QA привлекали (не уточнила на какое время)
Я чисто прикидываю, как профессионал, что я бы взялась внедрять подобный проект за 30-40 FTE включая QA. Но я ваши процессы не знаю и пришлось бы погрузиться. Так что вы более чем достойно. Искренне поздравляю.
Вы занимаетесь внедрением именно РМ или каких-то других инструментов?
мы занимаемся оптимизацией операционки и внедряем те инструменты, которые наиболее оптимальны заказчику, часто те, которые ему уже впарили настраиваем
можно посмотреть amiveo.com
Ну, спасибо!
1. Идея появилась примерно в сентябре 2019, внедрили примерно в конце года, стабилизировали к марту. Redmine в качестве таск трекера используем с 2013 года.
2. Суммарно порядка 40 - 60 FTE.
3. Привлекался консультант по QA, но заодно она поучаствовала и в доработке worflow в целом.
QA имелось ввиду процессно, на всю компанию описать\согласовать процессы? Достойно
Надеюсь, вы не тестировщиков а РМ затолкали и QA и привлекали ))
Вы проделали долгий путь, это интересный опыт, следует полагать, но без цифр оценить масштабы сложно. Сколько было людей на старте? Сколько людей было, когда возникла потребность в пересмотре подхода к управлению проектами? И сколько людей и отделов сейчас? И как вы считаете, ваша модель управления, насколько она пригодна к мастабированию, если команда увеличится в 2 раза, не приведёт ли это к пересмотру модели? Отдельно хотел бы попросить кинуть ссылкой на модель:) Спасибо.
Борис, на старте было человека 2-4. Когда людей стало больше 12 и проектов порядка 5-7, то проблема проявилась в полной мере. Но она была не только в количестве сотрудников, но и в разном подходе к разным проектам/заказчикам: с госами нужно одним образом работать, со стартапами - другим. Это разнообразие отражалось и в Redmine, что добавляло хаоса. Сейчас именно процесс разработки стандартизирован насколько это возможно.
Что касается масштабирования. Думаю, что модель вполне готова к росту компании, но она регулярно дорабатывается и, возможно, какие-то отдельные вещи потребуют апгрейда.
Описание скину в личку.
Денис, (если не секрет) а в чем бизнес смысл такого контроля?
Сейчас ведь проекты практически не бывают конечными: постановка-прототип-разработка-доработки-сопровод , все это циклично, со спринтами и релиз-циклом и до бесконечности.
Т.е именно 'сделано и работает' актуально по-сути на момент завершения спринта, сдачи этапа и развертывания на инфраструктуре.
Это крайне мимолетное явление в нынешних потоково-спринтовых реалиях.
Фиксировать именно реальное текущее положение дел это чудовищный объем работы, я бы понял еще если бы вы в Роскосмосе ракеты запускали к Марсу, но ведь это не так.
Контроль со стороны заказчика? Это вообщем-то просто отчетом решается, по итогам спринта/цикла. Отчет красивый, с картинками и графиками - работает на ура.
Для бизнеса смысл не столько в контроле, сколько в том, чтобы дать разработке адекватный инструмент управления процессом. Т.к. мы на 100% распределенная команда, то, например, на банальный вопрос от заказчика/менеджера "Какой статус по задачам спринта/этапа?" без такого инструмента тяжело ответить без дополнительных телодвижений.
А отчет для заказчика или кого-то еще как раз можно выгрузить из системы в актуальном виде в любой момент времени.
Мне кажется, современная разработка все же вертится вокруг репозитория, коммитов и процесса слияния. Social coding, git flow и все такое, как в github например.
Отвязывание постановки от результата в виде кода ( jira + хуки на коммиты и связывание с таском ) это все несколько устарело, как раз по причине невозможности понять что происходит и почему.
Аплодирую автору.
Начинаю повторять такой же путь. После утери доступа к Атлассиану, и проведя изучение Яндекс-трекеров, Ютраков, Юджайлов, Кайтенов, и еще ряда подобных, с ограничениями и "оно не свое" .. я вдруг вспомнил про RM, в котором мы вели разработку несколько лет и мне в нем было вполне комфортно. А еще вспомнил что (когда-то публиковал пару сайтов) на beget есть кроме других CMS-ок есть и Redmine. Слово за слово.. накатил, развернул. Всё. Я есть одмин.
Теперь нужно нарезать проекты (их 5) в них нарезать эпики, разбить на юзер-сторя, задачи, и т.д. Есть wiki, гантт, куча понятных настроек, связка задач и отслеживание статусов, настройка логики и все прочее.
И всё это свое. Можно перетащить потом куда хочешь. Настроить крон на архивацию и т.д. И пользователей делай сколько хочешь за стоимость хостинга..
Почему ретрограды? Вовсе нет!
Так что +1, я автора поддерживаю.