Трекеры проблем отлично справляются со своей задачей. А именно, отслеживание ошибок. Но использование их для отслеживания рабочего процесса разработки продукта имеет много проблем, возможно, не широко известных в техническом сообществе.

Большинство сред разработки продуктов, таких как Scrum и Kanban, сосредоточены на результатах и ​​результатах для клиентов. Руководство по Scrum фокусируется на этом как на «постепенном прогрессе». Канбан был построен на идее, что вы можете визуализировать свой рабочий процесс и обнаруживать узкие места, отслеживая, как исправления ошибок и развитие функций от начала до конца.

Любой, кто читал Empowered Марти Кейгана или следил за Гергели Орош, Джоном Катлером или почти за любым другим евангелистом в области разработки продуктов, знает, что команды, сосредотачивающиеся на оказании воздействия и на результатах, а не просто на том, что им говорят, что делать. do предлагает значительно более высокую ценность, они счастливее на своей работе и играют важную роль в том, чтобы помочь компаниям добиться успеха.

Но если вы посмотрите на трекеры ошибок большинства команд разработчиков программного обеспечения, они полны задач. За исключением тех случаев, когда результат невелик (например, ошибки или незначительные улучшения), проблемы не отражают результатов, которые мы хотим для наших клиентов; они представляют задачи для отдельных лиц. И они не используются для отслеживания всего потока разработки. Вся работа, выполненная до, становится инженерной задачей не отслеживается. Некоторые специалисты по отслеживанию проблем рекомендуют использовать эти антишаблоны в своих методах, и это неудивительно, поскольку именно для этого и был разработан их инструмент.

Джон Катлер — один из многих, кто заметил, что команды попадают в ловушки при визуализации своего рабочего процесса. Для большинства технологических компаний разработка программного обеспечения — это кросс-функциональное сотрудничество между управлением продуктом, дизайном и проектированием. Отличная команда разработчиков продукта не только создает функции, но также играет важную роль в выяснении того, что создавать, формировании дорожной карты и эксплуатации программного обеспечения, в дополнение к кодированию и исправлению ошибок.

Вот где ваша визуализация на уровне задачи или проблемы не работает. Мы должны сосредоточиться на том, что мы планируем предоставить нашим пользователям, независимо от их размера. Это в центре «результата» перед «выходом».

Можно легко спросить, почему проблемы не могут представлять результаты? Они могут, но они не предназначены для этого, и трекеры проблем не пытаются помочь вам в этом. У задач обычно есть только один правопреемник. Они не дают вам достаточно места для описания проблемы и решения, поэтому команды определяют или формируют вне инструмента, где они отслеживают прогресс. Трекеры проблем больше сосредоточены на метаданных и рабочем процессе, чем на поддержке команды в совместной работе, принятии решений и доставке нашим клиентам. Некоторые средства отслеживания проблем даже активно предлагают свести задачи к минимуму, что противоречит тому, что предлагает надежная структура разработки продукта.

Итак, что можно сделать, чтобы исправить это?

Во-первых, мы должны знать о недостатках системы отслеживания проблем. Уже используете один? Тогда вам, вероятно, следует переключить свое внимание на свои результаты и задачи и проблемы, которые у вас есть. Белая доска, Notion, Coda или Trello — это инструменты, которые могут дополнить ваш трекер проблем и гарантировать, что вы всегда будете следить за общей картиной. Проблема в том, что вам придется отслеживать работу в двух системах.

Некоторые средства отслеживания проблем имеют концепцию эпиков или проектов, которые могут помочь вам отслеживать вещи более высокого уровня внутри одного и того же инструмента. Это может быть полезно, но проблема по-прежнему в том, что они «сначала проблемы». Эти инструменты будут постоянно подталкивать вашу команду к тому, чтобы ежедневно сосредотачиваться на задачах или проблемах, а не на том, что нужно.

Мы посчитали, что должен быть лучший способ, и в результате создали Kitemaker. Насколько нам известно, это единственный инструмент, созданный специально для того, чтобы помочь командам разработчиков работать так, чтобы они могли сосредоточиться на результатах. Это позволяет нам создать инструмент, в котором спецификации, задачи и обсуждения находятся в одном месте. А с помощью наших интеграций члены команды могут видеть все соответствующие обсуждения и действия, независимо от того, происходят ли они в средстве коммуникации, в средстве проектирования или в инженерном инструменте. Для наших клиентов это позволило значительно изменить работу команд, заменив способ разработки, ориентированный на задачи/тикеты, на то, чтобы команда заботилась и сосредоточилась на доставке нужных вещей своим клиентам.

Итак, если вы ищете способ облегчить вашей команде участие в формировании продукта и перейти от работы, ориентированной на задачу, к способу работы, ориентированному на результат, почему бы не проверить Kitemaker и поделиться с нами своим мнением. ?