Есть шутка, что каждый уважающий себя разработчик однажды писал свою систему управления проектами. Может по-этому их так много и они настолько похожи.
Список задач не информативен. Чтобы поднять контекст, придется собирать картинку у себя в голове, долго гуляя по задачам в древовидной структуре с бесконечной вложенностью. Общаться в так организованных задачах сложно, диалоги постоянно отрываются от задачи и перетекают в мессенджеры.
Диаграмма Ганта не соответствует времени по гибкости, ведь это чистая waterfall модель, а большинство компаний декларируют, что они agile. Продолжая при этом пользоваться Гантом. Кроме того, на Ганте большие проекты теряют читаемость, а настолько точное планирование на долгий срок создает нереалистичные ожидания. Но я понимаю, почему она нравится — она пытается дать картинку проекта в графическом виде.
Канбан доски же — это отличный инструмент! Для спринта или маленького проекта. Ни о каком удобном долгом планировании на Канбане речь не идёт. Это система из серии «давай-давай» — она подстёгивает групповую активность, но на больших масштабах она несостоятельна.
Сегодня мы поговорим о новой, четвёртой модели, которая лишена этих недостатков.
Карта проекта на основе доски для User Story Mapping
С чего все началось
Первый ресёрч систем управления я провёл ещё в 2011 году, работая PM’ом в студии. Позже пришлось попользоваться многими из них на разных проектах и уныние моё только росло. Люди не ходят в трекер инициативно, их приходится затягивать туда с усилием. И их можно понять, ведь он не помогает видеть полную картину, общаться или анализировать затраты своего времени — он лишь фиксирует обязательства и исполнение. Ещё один начальник. Усугубляет картину необходимость держать зоопарк решений под разные задачи, будь то общение, ведение задач, документации или саппорта, поскольку крупные all-in-one решения не способны вызывать ничего, кроме депрессии.
В большинстве своём, они пошли по пути модулей, чтобы каждый клиент мог собрать такой набор возможностей, который ему нужен. С таким подходом невозможно добиться необходимой пользователю целостности и связанности, а насколько они важны, мы чувствуем каждый раз, когда пользуемся яблочными устройствами.
Основные деньги таким системам приносят B2B клиенты, так что и вектор смещается на покрытие требований компаний, а не отдельных людей, которые, в конечном счете, ими пользуются. Важнее становится факт наличия функции, вместо возможности ей комфортно пользоваться. Парадокс в том, что сами компании тоже страдают от такого положения дел — это сжигает через неэффективность сотни и тысячи часов. Но их никто не может посчитать, а значит нет и проблемы.
Под шагами рождаются дороги
Однажды мне нужно было наглядно, с хронологией и зависимостями, разложить проработанный проект на полгода вперед по категориям работ. Каково было моё удивление, когда для этого отлично подошёл инструмент для User Story Mapping’а. Ну, подошёл условно — вести проект с командой там было бы практически невозможно, но наглядность, доступность и лаконичность информации для анализа и планирования были ровно такими, как я искал.
Развить эту модель под комплексное управление проектами и командную игру получилось не сразу, но после нескольких переосмыслений и переделок все сошлось. Так родился Resulty. Он вводит новый инструмент управления задачами — Карту проекта. Она потрясающе наглядна, так как объединяет далекий и средний масштаб наблюдения в единую картину, позволяя в пару кликов получать необходимые срезы. Такая организация задач имеет всего 2 уровня вложенности и позволяет одинаково комфортно и планировать в долгую и вести текущие задачи. Познакомиться с этой моделью ближе можно на сайте краудфандинговой кампании Resulty.
Я начал искать инвестиции, но в этот момент меня пригласили в большой проект в области маркировки товаров массового потребления и я не смог отказаться. До этого, у меня был доступ только к небольшим и средним командам, теперь появился к крупным с целой экосистемой продуктов. Ещё и на C-level позиции, когда видны все процессы в компании.
И знаете, в больших командах все те же проблемы, но они возведены в степень из-за количества участников и параллельно выполняемых задач. Все живут в своих пространствах и редко знают в достаточной мере, чем заняты коллеги. Приходится синхронизироваться на созвонах, после которых, в лучшем случае, остаётся часовая запись без описания темы разговора и таймкодов.
У меня до сих пор хранится скриншот календаря с 82 созвонами в течение одного февраля. На каждом из них присутствовало не меньше 7 человек, а на некоторых больше 50. Это полторы тысячи часов, которые можно было бы сократить на 2/3, если бы команда имела доступ к полной картине происходящего с нормальными инструментами для взаимодействия.
Но мой самый любимый и говорящий пример: сколько времени у вас уйдёт, чтобы поднять контекст и все обсуждения любой задачи, которая была закрыта пол года назад? В Resulty счёт бы шел на минуты.
Окей, а если усложнить задачу и представить, что весь контекст проекта с помощью закрытых задач поднимает новый CTO? Несколько недель — ответ полученный эмпирическим путем на реальном проекте.
Хорошо слаженная команда предупреждает 80% всех проблем, связанных с внутренними факторами.
Человек, имеющий аналитику своей продуктивности, имеет возможность с ней работать.
Оценка задачи становится объективнее, если учитывать профессиональный уровень, точность предыдущих оценок и количество вернувшихся багов.
Команда становится эффективнее, если видит цели компании, проекта и коллег.
Но мы живём в мире, где задачу видит только ответственный, где в погоне за результатами используют KPI, где на основе замеров времени дают по шапке и штрафуют, и где задачи отображаются тупыми списками.
Я пришёл это поменять.
