Система отслеживания проблем — одна из важнейших составляющих любого открытого проекта. Именно она является связующим звеном между двумя крупными сообществами: пользователей и независимых разработчиков. В настоящее время для её организации может применяться несколько различных инструментов, обеспечивающих должную функциональность, но много проектов предпочитают ничего не искать, а решают задачу при помощи встроенного средства GitHub.

Несмотря на то что система отслеживания проблем GitHub достаточно хороша и проста в применении, без определённых усилий со стороны руководителя проекта список задач со временем станет громоздким и неудобным для практической работы. Собственным опытом оптимизации этой стороны открытого проекта делится Мэтт Батлер — основатель и главный исполнительный директор ZenHub, чьё решение для совместной работы успешно применяется в NASA, Docker и Rackspace.

Эксперт выделил несколько основных вопросов, которые следует решить в первую очередь.

Формат пользовательских сообщений

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

Автор знаменитого труда «The Art of Community» Джоно Бэкон считает, что на момент формулирования вопроса пользователь не имеет должного терпения или заинтересованности, чтобы внятно описать все детали. Таким образом, ему следует помочь передать разработчикам всю необходимую информацию, причём в кратчайшие сроки.

Самостоятельная разработка оптимальной структуры пользовательского сообщения «с нуля» может занять слишком много времени, поэтому проще применять готовое решение, которое можно немного модифицировать с учётом специфики проекта. В общем случае оно должно состоять из трёх частей: кто, что и зачем.

Например, если говорить об интерфейсе для интернет-магазина, то на практике пожелание пользователя может выглядеть следующим образом: «Как клиент, я хочу создать учётную запись, чтобы делать покупки». Тут в одном предложении изложено всё: тип пользователя (клиент), что он хочет (создать учётную запись) и зачем ему это нужно (делать покупки).

В данном случае разработчикам значительно проще выполнить поставленную задачу, поскольку они сразу могут идентифицировать аудиторию, желательное действие и его результат. Остальная информация будет избыточной, поскольку потребует тщательного осмысления для выделения из неё «сухого остатка».

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

Фильтр пользовательских сообщений

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

Хорошо сформулированная проблема должна отвечать нескольким критериям. Разумеется, не все они подойдут любому проекту, поэтому не нужно копировать эти принципы «один в один» — ими следует только руководствоваться при создании собственной концепции фильтрации.

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

Во-вторых, в сообщении о проблеме не должен использоваться жаргон, понятный только узкому кругу специалистов. Даже если изложенная в нём проблема важна, разработчики всё равно не смогут разобраться в её сути.

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

В-четвёртых, проблема должна быть относительно независима от других. Связанные вопросы накладывают серьёзные ограничения на гибкость решения.

В-пятых, проблема должна иметь несколько решений и способна быть предметом для дискуссии. Очевидные ошибки так или иначе всё равно будут исправлены в рабочем порядке, нет никакого смысла заострять на них особое внимание.

В-шестых, задача должна быть решаема с учётом имеющихся ресурсов. Конечно, теоретически интересней ставить перед собой глобальные проблемы мирового значения, но ими уже занимаются крупные научно-исследовательские учреждения, конкурировать с которыми всё равно бессмысленно.

В-седьмых, результат решения проблемы должен быть измеряем. То, что невозможно проверить, для проекта не существует.

Работа с ограничениями

Тем не менее, даже если проблему трудно измерить или решить в какие-то разумные сроки, не стоит сразу исключать её из рабочих планов. Возможно, она всего лишь нуждается в некоторых ограничениях.

Мэтт Батлер поясняет это на простом примере. Допустим, пользователи хотят, чтобы продукт был более быстрым. Очевидно, что при такой постановке за задачу даже браться не стоит — требования слишком расплывчаты.

Но задачу можно изменить. Например, так — каждая страница сайта должна загружаться за полсекунды. Условия вполне конкретны и результат проверяем.

Структурирование проблемы

Любая сложная проблема может быть разбита на ряд относительно простых задач, результат решения которых легко проверить. Этот приём следует использовать на практике.

Эксперт предлагает использовать т. н. контрольные списки, состоящие из задач, на которые разбивается проблема. При этом все задачи ранжированы по приоритетам с учётом не только важности, но и очерёдности их решения.

GitHub, кстати, включает в себя готовый инструмент для этой цели. Его применение позволит лидеру лучше представлять текущее состояние проекта в любой момент времени, определять проблемные места и оценивать вклад участников сообщества.

Составление ReadMe.md

Хороший открытый проект должен привлекать потенциальных участников. Поэтому надо позаботиться о том, чтобы они могли максимально быстро принять решение и влиться в существующую команду. Лучше всего для этой цели подойдёт файл ReadMe.md — идеальное место, чтобы поделиться в том числе и своими руководящими принципами.

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

Тем не менее важно понимать, что всё это — не процесс ради процесса. Речь идёт о создании структуры, которая позволит участникам проекта действовать более эффективно. Джоно Бэкон утверждает, что лидер должен сосредоточить усилия не только на росте числа программистов, но и привлекать людей, заинтересованных в определении проблем и постановке задач. Именно такое подход будет максимально продуктивным.