Существует множество готовых, проверенных временем фреймворков для организации рабочего процесса, в которых хорошо описаны методы и принципы.
Если собираем машину — используем Канбан, готовим пирог — Lean, разрабатываем сайт на заказ — PMBoK. Важно учитывать, что каждый проект уникален и требует адаптации подходов, но в целом для вашего случая, скорее всего, найдется достаточно полезных решений.
Выстраивая процессы для себя, я брал всего понемногу.
Был
Работал в стартапе.Один продукт, одна небольшая команда, никаких жестких сроков.
Мы использовали Scrum и Kanban, так сказать, в чистом виде.
Мы записывали задачи в Trello и растаскивали их по 4 доскам: идеи, нужно сделать, в процессе, готово.
Чтобы обсудить ход работы, мы каждый день созванивались и раз в неделю планировали задачи на следующий спринт. Все как у людей.
Стало
Немного изменив ход разработки, я отправился в веб-студию за новым опытом.Там меня в первую очередь удивила гибкость работы с клиентами, и, если без сарказма, отсутствие какой-либо системы.
Чтобы показать общую картину, приведу сильно упрощенный пример.
Заказчик А: Мне нужно разработать лендинг для мероприятия такого-то числа.
Менеджер проекта (МП): окей, к такому-то числу сделаем.
Клиент Б: срочно внести следующие изменения на сайт. МП: ок, добавим как можно скорее.
Далее МП согласовывает смету для заказчика А, записывает задачи в трекер, создавая отдельные проекты и несвязанные между собой доски.
Сообщает команде, что и кто должен сделать.
Разработчики приступают к резке, а по завершении менеджер показывает результаты клиентам.
Записи в системе выглядят так:
Проблемы
Подход к управлению вполне логичен, но возникают следующие проблемы:- Отсутствие видимой связи между задачами заказчика и команды
Бизнес-проблемы обычно обнаруживаются в электронной таблице и декомпилируются в Jira. Когда разработчик пишет очередной метод API, чтобы понять, кто будет его использовать, ему нужно пойти к менеджеру и уточнить это еще раз.
- Неправильная расстановка приоритетов
Дизайнер сообщает о преждевременном завершении макета (да, такое тоже бывает).
Спрашивает: что делать дальше? Депутат ставит задачу из четвертого проекта, первого в списке.
В конце концов он понимает, что четвертая задача первого проекта была более важной.
- Нет визуального представления объема работ.
Задачи в разных проектах.
Никто не хочет держать их в голове или искать в каталогах.
Проще, закончив, спросить: что делать дальше?
- Неравномерное распределение рабочей нагрузки по времени и между сотрудниками.
Понятно, чем сейчас занимаются Вася и Петя; сложнее сказать, кто чем будет занят через 2 недели и будут ли их задачи равноценными.
- При планировании сроков выполнения задачи из других проектов не учитываются.
Попросили меня изменить ссылку на сайте.
О, это легко, мы сделаем это сегодня.
Потом менеджер вспоминает, что на другом сайте есть суперкритические баги.
В результате, по словам заказчика, команда продлила смену звена на неделю.
Многие проекты были унаследованы от других менеджеров.
Доски, типы заданий и методики в них подбирались по настроению.
Конверсия дыни
Для создания системы сначала необходимо было привести данные к единому формату.
Преобразовав массу сущностей, переданных в мое распоряжение, мне удалось прийти к следующей концепции:
Думаю по картинке все понятно, но есть небольшие нюансы, связанные с реализацией в Jira. Давайте рассмотрим каждую сущность на примерах.
С концепцией проект все понятно и в сознании сообщества, и в сознании Atlassian. Это последовательность действий, направленная на получение результата за ограниченное время.
Например: разработать сайт, поддерживать приложение на протяжении всей его жизни, создать рекламную кампанию.
Эпики (релиз) — отдельные крупные части проекта: личный кабинет, корзина, каталог товаров.
Вот здесь и начинаются разногласия.
В Jira есть сущность под названием эпик, но я все равно использовал релиз.
Дело в том, что для реализации правильной структуры необходимо иметь 3 уровня вложенности; на момент написания статьи у Jira 2+1 (история и задача расположены на одном уровне).
+1 - это подзадача, я ее не учитываю, так как она имеет функцию дополнения, а не вложения из-за отсутствия гибкости и сильной привязанности к родителю.
Вместо релиза можно было использовать компонент или спринт, но для моих целей они выглядели менее удачно.
По этой же причине для записи историй используют эпос.
История (эпопея) в данной структуре это бизнес-задача (желание клиента).
Задача — четкие действия по решению бизнес-задач.
Также к сущностям были добавлены некоторые счетчики и поля.
Важнейшим из них является шкала оценки сложности задачи от 1 до 10 в условных единицах (сюжетных баллах).
Создание системы
Данные есть, дальше нужно решить, в каком виде и как их отображать.Я создал общий проект для команды и написал JQL-запрос, чтобы переносить в него проблемы из всех наших проектов (запрос можно легко сгенерировать в разделе «Проблемы»).
Я добавил в него канбан-доску и статусы, соответствующие нашему техпроцессу: Бэклог → Сделать → Делается → Обзор → Тестирование → Сопоставление → Готово.
В результате получается вот такая картинка:
Теперь все задачи проходят единый производственный цикл, который достаточно универсален (проект можно не тестировать, а сразу передавать на утверждение).
Если какой-либо этап не завершен, к задаче добавляется комментарий и она отправляется обратно в To Do. Каждая задача имеет видимые связи с проектом, клиентской историей (эпик) и эпопеей (релиз).
Используя тот же JQL-запрос с плагином BigGantt (или любым другим) для Jira, задачи можно просмотреть в виде диаграммы Ганта.
Меняйте сроки выполнения, сроки, прописывайте зависимости, смотрите нагрузку на исполнителей.
Сворачивайте задачи в истории, истории в эпопеи, т. е.
визуализируйте дорожную карту или подробный план работы.
Административная часть
Используемые методологии — Lean (определяется последовательность действий, при этом сохраняется возможность параллельного выполнения задач), Kanban (задачи переходят от специалиста к специалисту, «узкое место» легко выявляется).Из Scrum я взял ежедневные встречи, чтобы поддерживать понимание, кто чем занимается.
Они также оценивали сложность новых задач, используя очки истории.
Хотел, но не смог использовать спринты, потому что.
заказчик иногда менял приоритет задач, и регулировать объем работ после начала спринта уже невозможно.
После совещания задачи приоритезируются в бэклоге, назначается исполнитель и переводится в To do. Разработчик создает ветку в BitBucket, задача автоматически переходит в Doing. По завершении «разработчик» передает его на рассмотрение, исполнитель переходит к другому разработчику.
Если все ок, «ревьюер» выполняет слияние и код попадает на тестовый сервер.
Jira отправляет задачу тестировщику.
После проверки QA передает ее менеджеру.
Он показывает это клиенту.
Заказчик доволен — код отправляется на производственный сервер под пристальным контролем ежедневных автотестов.
Спасибо нашим Devops-инженерам за эту автоматизацию.
Я просто настроил смену статусов и исполнителей на основе событий из git. Это делается в настройках бизнес-процесса, если вы работаете в экосистеме Atlasian. А вот при использовании GitLab, Bitrix, Redmine придется повозиться.
Решения
Давайте посмотрим, чего нам удалось добиться:- Отсутствие видимой связи между задачами заказчика и команды
Бизнес-задачи записываются в Jira как истории (эпики), их можно просмотреть в списке с процентом выполнения и на диаграмме Ганта.
Когда разработчик выполняет задачу, он видит, к какой истории она относится, и может пойти и прочитать описание.
- Неправильная расстановка приоритетов
Выполнив задачу ранее, дизайнер берет новую из начала списка To Do, где они расставляются по приоритету по соотношению сложности (story point) к стоимости (бизнес-задачи в рублях).
- Нет визуального представления объема работ.
Задачи в одном проекте.
Каждый участник команды видит, как он движется по канбан-доске и общий прогресс работы.
Что уже сделано и что предстоит.
- Неравномерное распределение рабочей нагрузки по времени и между сотрудниками.
Диаграммы Ганта позволяют планировать работу на длительный период (с постоянным обновлением).
Есть проекция на исполнителей.
Это видно, когда у исполнителя одновременно есть 2 задачи, а у кого-то их нет.
- При планировании сроков выполнения задачи из других проектов не учитываются.
При добавлении новой задачи в любой проект она видна в общем бэклоге.
Приоритет относительно других задач ей присваивается с помощью единой метрики.
Планы
Некоторые процессы были сокращены или автоматизированы, но в планах осталось гораздо больше:Формирование смет для проектов по времени и материалам
Выполняя каждое задание, сотрудник отмечает время.
Зная почасовую ставку каждого человека, его должность и поправочный коэффициент (на сколько умножить, чтобы учесть затраты компании), можно сформировать таблицу со списком работ и затрат.
Автоматические расчеты между менеджерами
Если у меня есть задачи, но не хватает ресурсов для их выполнения, я прошу исполнителя у другого менеджера.Когда приходит время отчетности, я вношу потраченные сотрудником денежные часы в свой план как расходы и как доходы в план другого менеджера.
Каждый месяц мне приходилось забирать всю работу, сверять с менеджерами, умножать и вычитать без всякого творчества.
Если бы все сотрудники перешли на единый формат данных (способ управления проектами в Jira), все расчеты можно было бы проводить без вмешательства человека.
Теги: #Управление разработкой #Управление проектами #Управление персоналом #автоматизация #agile #scrum #kanban #управление задачами #Jira #lean
-
Ноутбук Portege-A600-158 От Toshiba
19 Oct, 24 -
Детектор Приседаний На Opencv И Tensorflow
19 Oct, 24 -
Обзор Систем Онлайн-Консультирования
19 Oct, 24 -
Не Только Шахиджанян...
19 Oct, 24
