​Проект-менеджмент по дзену: Скрам, Канбан и наш реальный опыт

Скрам

Берет свое начало из 90-х из документа под названием "Манифест гибкого подхода к разработке программных продуктов", а кратко - Agile Manifesto. Эдакий ортодоксальный молитвенник для программистов, призывающий создавать качественный и востребованный продукт, один из постулатов которого - "Люди и взаимодействие важнее процессов и инструментов". Там еще много чего написано, но между строк можно прочесть, пожалуй, главное: "Сделать сложное - простым, а непонятное - доступным".

Если совсем кратко и по делу – это дисциплина, контроль, дробление больших кейсов на простейшие элементы, ежедневные кросс-митинги и жесткие временные рамки. Уложился – продолжай в том же духе; не успел – сам виноват.

Канбан

Японская философия менеджмента, популяризацией которой в 80-е годы минувшего столетия занималась корпорация Toyota. Цель Kanban – визуализировать рабочий процесс, представить его в виде логической цепочки от постановки задачи до выполнения и затем – релиза. Все задачи просто записываются на стикеры и крепятся к доске. В зависимости от того, в какой стадии проект – в таком разделе и расположен стикер. Такой подход позволяет объективно распределять нагрузку и работать параллельно над несколькими проектами.

Теперь подробнее о том, как развивался Займер. Наш проект разрабатывался с нуля относительно небольшой командой программистов. В то время преобладал каскадный метод разработки продукта: планировали, писали код, тестировали и выпускали на рынок.

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

Мы начали использовать систему управления задачами JIRA, в которой по умолчанию есть канбан-доска, и 90% работы стало проходить через данный продукт: сперва проект-менеджер прописывает и выстраивает логику задачи, и уже потом сотрудник может к ней приступать. Сами задачи стали подробными, понятными, четкими.

Поскольку наш продукт обладает своей спецификой, канбан-доска не утратила своей линейной логики, но расширилась парой новых статусов ведения проекта: "описание задачи в разработке" (это значит, что проект-менеджер в данный момент занят постановкой конкретной задачи), "решена" (требуется код-ревью, чтобы другой программист мог дать трезвую оценку проделанной работе), "ожидает сборки и релиза", "выложено на prod"(код прошел все проверки и опубликован на "боевом" сайте).

Канбан предписывает ограничивать количество задач на каждую из категорий. Но для дополнительного контроля объема входящих задач - кроме количества активных элементов - мы используем ограничитель нагрузки от каждого из отделов. Например, у каждого из наших программистов не более 1 задачи в работе и не более 5 в очереди, все они рассортированы по приоритету. Эти задачи могут быть выставлены разными отделами - разработчики, контакт-центр, служба PR, служба безопасности и др. И для того, чтобы работа продвигалась равномерно, мы просто следим за тем, чтобы какой-либо из отделов не перетягивал на себя слишком много суммарных трудозатрат, меняя приоритеты задач в очереди и поддерживая таким образом баланс.

Кроме того, каждый программист логирует свое время работы над проектом - так мы отслеживаем трудозатраты и планируем публикацию новых проектов на "доску". Если говорить цифрами, то примерно 50% времени задача имеет статус "в работе" и 30% ожидает своей очереди, остальные 20% размыты по остальным категориям. На следующем скриншоте - немного статистики по объемам работ в целом.

Теперь Скрам. До 2015 года подобными категориями мы даже не мыслили, продукт постепенно проходил стадии своего естественного роста, каждая из стадий имела некий дедлайн. Вот и весь аджайл:) Теперь же, с пониманием дальнейшей картины нашего развития и наличием сильной команды, мы морально подготовлены к тому, чтобы сформировать небольшой отряд спецназа и опробовать данную методику на части команды. Мы четко видим преимущества - это более плотная коммуникация и более осязаемый результат. Однако мы не хотим становиться теми, кто ради четких принципов станет терпеть неудобства, поэтому скорее всего результатом окажется некая комбинированная схема из описанных в этой статье методик. В любом случае, в обозримом будущем нам будет что вам рассказать.

Мы будем рады вашим вопросам и комментариям, подписывайтесь на наш блог и узнавайте больше о нашем опыте, а также самых актуальных новостях из мира финансов! Команда сервиса онлайн-займов “Робот Займер”