Оцифрованная ответственность: как мы создали систему управления IT-проектами, которая работает
Как правильно организовать работу команды — вечный вопрос в IT. Но способен ли в принципе софт собрать процессы в систему, работающую как часы? Наш ответ — нет. Вот почему мы сфокусировались не на сложности ПО, а на придумывании правил. И это сработало. Сейчас расскажем, как именно.
С чего всё началось
Система управления проектами, которую мы теперь зовём KR Core, росла вместе с нами с самого старта в 2011 году. Началось всё с трекера и отметок времени — потом добавились истории с планами, финансами, бонусами.
Главной потребностью было повысить эффективность: мы понимали, что постоянные daily только отвлекают от самой задачи. Чувствовали, что не получается управлять процессом. На созвоне можно обещать что угодно, но при этом не сохраняется никакой истории.
Ключевая идея — создать порядок взаимоотношений по проекту. Не придумывать ещё одну методологию, а оцифровать ответственность. Можно вложить сколько угодно денег в проектный софт, поставить любые трекеры, но если у программиста нет никакой ответственности за непопадание в сроки и прочие косяки, он будет сдвигать сроки и плодить ошибки. Ответственность должна стать реальной — и это заставит всю систему работать.
Сейчас KR Core состоит из семи проектных модулей: мы описывали их подробно здесь. Ключевое здесь то, что все модули работают только во взаимосвязи друг с другом. Достань любой кубик — и всё сломается. Объясним, как это происходит на практике, на всех этапах работы с проектом.
Инициация проекта
Под каждый проект мы заводим договор, где отслеживаем несколько основных параметров: сроки, бюджет проекта, майлстоуны, отклонения от запланированных сроков. В общем, ключевой дашборд, куда стекается вся информация по проекту.
Принцип, который заставляет систему работать: без проекта у нас нельзя поставить задачу сотруднику. То есть нельзя прийти к разработчику сказать: "Вась, давай ты неделю будешь вот это делать, потому что я так решил". Постановка задачи разработчику связана с его отчётами по времени, бонусами, со всеми модулями. И если мы не привязали его работу к конкретному проекту — работы не будет.
Зачем это нужно? Наш главный ресурс — время команды. И вот мы абсолютно всё это время относим к какому-то проекту. Каждая задача вписана в бюджет, клиентский или внутренний.
Раньше у нас бывали истории, когда мы делали проекты в минус просто потому, что не следили за экономикой в процессе. Мы делали-делали, закрывали договор, а потом выгружали отчёты и понимали: если умножить потраченные часы на ставку, мы наработали на минус два миллиона. Да, в целом компания маржинальна, но конкретно этот проект — с жесточайшим минусом. И если просто выплатить деньги и бежать дальше, то следующий будет с таким же косяком, а может, два или три. Вот почему важно не допускать убыточных проектов ещё на стадии планирования.
Благодаря взаимосвязи модулей мы сразу понимаем, сколько заработаем, кто будет работать на проекте, по какому графику... Всё это мы узнаем ещё до заключения договора, что позволяет отсекать изначально болезненные проекты. Либо же понимаем, что мы инвестируем: потратим пять миллионов, получим три, а два инвестируем, потому что так надо. Но это уже осознанный выбор.
Отклонение от плана проекта
Как понять, что сейчас проект выйдет из запланированных границ? Всё просто: есть бюджет, есть сроки, есть трекер, в котором отмечается потраченное время команды. Умножаем время на ставку специалиста, которая считается по определённой методике, и получаем, сколько потрачено в деньгах. Второе действие: открываем модуль планирования, смотрим, сколько часов на какого разработчика по проекту запланировано, и тоже умножаем на ставки. Складываем эти две суммы — и сравниваем с бюджетом.
Из-за связанности модулей обновление времени происходит постоянно: каждую пару-тройку часов кто-то что-то отмечает в трекере, и план меняется. То есть вот это перетекание из запланированного в потраченное происходит в динамике, а менеджеру не нужно совершать никаких действий. Он смотрит: запланировано ещё 900 тысяч, потрачено 2 млн, а бюджет 3, 100 тысяч остается. А на следующее утро он видит: кто-то в оценку задачи не попал, закопался и “сожрал” эти 100 тысяч бюджета. И вот менеджер может что-то предпринять в момент, когда это произошло. Он понимает, что есть CEO, который тоже видит перерасход и может просто остановить работу по проекту. И менеджер или идёт к заказчику с просьбой увеличить бюджет, или к разработчикам — обсуждать, как можно оптимизировать работу.
Этой возможности повлиять в моменте не случилось бы без связки модулей. Нужно было бы садиться, выгружать отчёты, считать: естественно, никто этого не делает в течение проекта. Команды узнают о перерасходе, когда всё уже случилось — и это проблема. Потому что в этот момент все уже злые: собственник злой, потому что в минусе, менеджер злой, потому что не будет бонусов, а на заказчика вообще уже всем плевать.
Что, если заказчик приходит и просит — а давайте здесь на 20% больше работы сделаем? У нас вновь процедура: мы оцениваем сроки, вставляем в план и смотрим. Затем возвращаемся к заказчику и озвучиваем варианты: увеличиваем договор на Х и сдвигаем другие проекты, либо увеличиваем на меньшую сумму, но делаем позже.
Работа с обратной связью по ходу проекта
Во время проекта постоянно функционирует модуль опросов для заказчика и команды. Что, если убрать его? У нас ведь есть план, команда, бюджет. Всё распланировано — все работают. Но когда проект закончится, практически со 100% вероятностью заказчик будет недоволен. Почему? Сложно предвидеть и заранее заложить в техзадание всё, если мы говорим про создание нового цифрового продукта, интерфейса, услуги. В итоге начинается бесконечный процесс: итерацию за итерацией разработчики улучшают продукт, но по факту непонятно, когда всё закончится. В какой-то момент люди расслабляются: так всегда происходит, если у человека нет какой-то контрольной точки. А если менеджер понимает, что нет никакой контрольной точки по качеству проекта, он не прилагает усилия, чтобы удовлетворить заказчика.
Невозможно написать идеальное ТЗ и сделать по нему идеальный продукт. Нужно уточнять, искать, думать: с заказчиком нужно постоянно работать. Да, есть талантливые менеджеры, которые это делают на базовом уровне, но люди непостоянны. Чтобы сделать работу с обратной связью системной, нужна ответственность. И её получается создать благодаря связке модуля опросов с модулем оценки работы менеджера, которая, в свою очередь, завязана на оценке проекта командой и заказчиком.
Подытоживая, техзадание и экономика это важно, но ключевое для создание хорошего продукта — слушать и слышать заказчика. Нужен постоянный диалог. И этот диалог не должен оставаться только в словах и просьбах: он должен быть оцифрован. Обратная связь от заказчика работает только тогда, когда она фиксируется и влияет на процесс.
Хорошо, ну а зачем нужна оценка команды? Всё просто: можно сделать проект в бюджете, в сроках, с довольным заказчиком, но при этом извести команду. Разработчики сделают проект как ответственные люди, а потом все уволятся, потому что выгорят. А если вознаграждение менеджера зависит от результатов опроса, он понимает: если он выполнит все KPI , но замучает команду, бонусов не будет. И вот он пытается найти золотую середину: и заказчика удовлетворить, и в бюджет попасть, и людей не особо заморочить. Система замыкается – всё начинает работать.
Звучит сложно, но на практике это элементарная история: просто надо не забывать разговаривать с командой. Например, объяснить, почему пришлось работать в выходные. Как правило, все всё понимают.
Рабочий процесс: оценка сроков задач
Здесь работают два модуля: во-первых, трекер, откуда исполнитель берет задачу и отмечает время. Никто не любит отмечать время в задачах, и про это мы тоже писали, – но у нас есть модуль бонусов. Мы разработали определённый процесс и говорим: если ты работаешь по процессу, то получаешь до 30% бонусов к окладу. Это достаточно ощутимая история для разработчиков, и они вполне охотно всё отмечают.
Принцип, который заставляет всё работать: система позволяет менеджеру в каждом спринте поставить разработчику задач на такое количество часов, сколько у него реально в этом спринте есть. То есть нельзя на неделю поставить задачу на 50 часов – система просто не даст это сделать. В неё подтягивается информация из другого модуля, ресурсного, где мы отмечаем график работы по каждому сотруднику.
В итоге программисту не надо работать в выходные. Он отработал 32 или 34 часа в неделю (мы даём запас, потому что 40 часов в неделю кодить невозможно) и может идти домой. Никто не придёт и не скажет, а вот давай ещё задачу сделай. Соответственно, если он правильно оценил задачу, если он работает по процессу, он уходит с работы в пятницу в 18-00 — и при этом он красавчик, он всё сделал.
Конечно, к концу года мы тоже работали в выходные, но это была управляемая история: все понимали, что и зачем, система автоматически насчитала сверхурочные.
Другая сторона того же принципа: оценка времени — на стороне исполнителя. Причём разработчик не может потом эту оценку увеличить: это может сделать только менеджер проекта. Он поставил оценку, оценка помещается в спринт, поехали: здесь и возникает фиксация ответственности. Если он поставил оценку, он согласен с тем, что запрашивается в задаче. А если он открыл пустую задачу, в которой написано "делай хорошо, не делай плохо" и поставил оценку два дня, он согласился с тем, что ему будут пихать в задачу всё подряд, а он должен за два дня успеть. Или превысить оценку и недополучить бонусы.
Этому приходится учиться: мало кто попадает в оценки поначалу, но со временем разработчики начинают вполне успешно планировать свою работу. Всё максимально открыто: если ты хочешь получать бонусы за соблюдение процесса, будь добр соответствовать.
Что, если называть оценки в три раза больше? Мы не будем ходить и разбираться. Если менеджер и команда между собой договорились, и всё в рамках верхнеуровневой системы, нас это устраивает.
Но поскольку всё оцифровано, систематическое завышение оценок мы увидим. Поэтому мы сразу объясняем: не надо обманывать, надо просто делать хорошо — и всё будет хорошо. И, как правило, люди адекватно реагируют.
Оценка работы
У нас совершенно разная математика для каждой должности: для аналитиков, менеджеров, старших разработчиков, разработчиков, для всех своя логика. Для разработчиков ключевое — соблюдение порядка работы над задачами и попадание в сроки. Для менеджеров — соблюдение маржинальности сроков и оценка проекта как командой, так и заказчиком. Смысл в том, что мы постарались под каждую должность подобрать мотивацию, которая бы отражала запрос компании к этой должности.
Бонус: как система помогает отсечь лишнее в процессах
Система помогла нам избавиться от лишних процессов на уровне компании: избыточных совещаний и ежедневных созвонов, бесконечных отчётов для заказчиков и заполнений тайм-листов, бюрократии вроде процесса оформления отпусков.
Вновь вернёмся к началу: ключевая особенность системы в том, что только связав модули между собой, получается достичь результата. Если выкинуть модуль планирования — задачи будут ворохом. Выкинуть бонус разработчикам — они не будут соблюдать правила.
Возможно, это связано с тем, что каждый модуль вырастал из живых проблем: мы с ней сталкивались, отрабатывали как-то этот кейс и подкручивали систему. Понятно, что будет ещё десять тысяч кейсов, которые мы будем отрабатывать и вкладывать в систему. В этом и есть ценность KR Core: она может постоянно развиваться вместе с нами, потому что это не софт, а сочетание принципов. А мы, благодаря этой системе, находимся в целом на высоком уровне организации процессов.
Сейчас мы видим ту самую изначальную проблему хаоса в процессах у клиентов: особенно у крупных компаний во взаимоотношениях “бизнес- IT-отдел”. Мы понимаем, что у нас этих проблем нет, и считаем, что это из-за использования KR Core. Мы помогли нескольким партнёрам внедрить KR Core у себя: о первых результатах расскажем в следующем кейсе.
Как вам такая система управления, основанная на “оцифровке” ответственности? Хотели бы внедрить что-то такое у себя? Делитесь своим мнением в комментариях!