Я высоко ценю открытость команды Discourse к предложениям от новых людей, как на этом форуме, так и в других местах.
Я наблюдал эту проблему на Meta на протяжении многих лет, но именно этот случай побудил меня высказать свои мысли в целом. Меня тоже это расстраивало, но я не знал, как поднять этот вопрос. Поэтому я попробую написать об этом сейчас:
Контекст
Иногда на Meta я замечал тенденцию: новые предложения от новых пользователей относительно функций или изменений в Discourse встречают немедленную критику. Вместо того чтобы выслушать и понять опыт людей, только начинающих работать с этим ПО, — чьи идеи могут быть полезны даже тем из нас, кто использует Discourse уже более 10 лет, — некоторые участники сообщества заранее отвергают эти идеи.
Часто это происходит, если идея ранее была отклонена командой Discourse, или если было выбрано определённое значение настройки по умолчанию вместо других конфигураций, и так далее.
Даже в таких случаях я хотел бы поделиться своими мыслями о том, почему не стоит заранее отмахиваться от идей или жалоб на ПО, даже если они уже обсуждались ранее.
Команда Discourse принимает окончательное решение. Многое изменилось. То, что было актуально раньше, может не работать сейчас.
Во-первых, мы, как участники сообщества, не являемся продукт-менеджерами Discourse. Если мы сразу говорим кому-то, что его идея уже была отвергнута в прошлом и почему, это не обязательно отражает текущие решения команды продукта Discourse.
Иногда даже сама команда Discourse может принять решение работать над функцией, которая ранее считалась невозможной. Долгое время чат был именно такой функцией.
Поэтому никогда нельзя со 100% гарантией сказать, что прошлые решения останутся такими же и в настоящем.
Даже внутри команды Discourse могут возникать разногласия относительно того, что должно быть приоритетом для проекта.
Например, я часто следил за блогом @erlend_sh, где он рассказывает, что его взгляды отличались от взглядов остальной команды относительно того, каким должен быть чат в Discourse — жирным шрифтом выделено моё:
Большинство проектов с открытым исходным кодом не имеют выделенного форума, но те, у кого он есть, почти наверняка также имеют групповой чат. Мой последний период работы в Discourse был попыткой объединить эти два режима с помощью введения Discourse Chat.
Я действительно горжусь этим MVP (который с тех пор перешёл в ядро), но направление, в котором я хотел двигаться дальше, было, понятно, несовместимо с ДНК проекта Discourse как традиционного форума: я предложил сделать чат основой нашего опыта взаимодействия сообщества. Сообщество начинается в чат-комнатах, думал я. Команда Discourse так не считала, поэтому мы расстались на дружеской ноте.
Спустя годы моя позиция осталась неизменной. «Групповой чат» и «форум» должны означать примерно одно и то же. На самом деле мы движемся именно в этом направлении, поскольку Discord, правитель наших сообществ, теперь поддерживает различные функции потоков и досок, которые органично вписываются в парадигму форума.
Поэтому нам не следует заранее решать, что не должно попадать в Discourse, поскольку это также может измениться со временем.
Те из нас, кто был с Discourse в его ранние дни, помнят, когда в CDCK работало менее 10 человек, и управление продуктом часто определялось соучредителями Discourse. Но сегодня CDCK насчитывает 100 сотрудников, и у CDCK есть целая продуктовая команда!
Сам Discourse имеет гораздо, гораздо большую базу пользователей, потребности и способы использования которых вышли далеко за рамки первоначальных ранних последователей проекта. В более широком смысле изменился ландшафт социальных платформ (мощность переместилась с Facebook на Discord и другие площадки, и так далее), а также изменились общие ожидания людей.
Поскольку команда сейчас намного больше, чем в ранние дни Discourse, у неё больше возможностей работать над другими функциями, которые в прошлом были гораздо менее приоритетными в период ранней разработки продукта.
Поэтому то, как они рассматривают запросы на функции сейчас, вероятно, сильно отличается от того, как это было в начале. Продуктовая команда имеет собственный процесс принятия решений и определения того, над чем и когда работать.
Больше точек данных — лучше
Во-вторых, команде Discourse обычно полезно услышать больше точек данных, а не меньше.
На Meta существовала идея, которую неформально назвали «Правилом трёх» (минимум три человека должны пожаловаться на что-то, прежде чем запрос на функцию будет рассмотрен). Даже с этим правилом нужно позволять людям делиться своим опытом и жаловаться, чтобы услышать три разных человека, указывающих на одну и ту же проблему.
Помимо этого, популярной стала концепция «разработки, управляемой жалобами» (Complaint Driven Development). И в этом случае также необходимо слушать мнения людей:
Единственное, что я когда-либо видел работающим, — это глубокое погружение в работу вместе с пользователями, общение с ними и построение отношений.
После повторного прочтения я также твёрдо убеждён, что исходная идея «правила трёх» на самом деле НЕ означает, что ваше мнение не имеет значения, если никто другой не жалуется на ту же проблему.
Суть в том, что (особенно если у вас небольшая команда) выявление проблем, на которые жалуются чаще всего, — это эффективный способ найти самые болезненные точки для пользователей, чтобы сначала исправить их.
Как говорит Стив Круг в книге Не заставляйте меня думать:
Вы всегда обнаружите больше проблем, чем сможете исправить, поэтому очень важно сосредоточиться на исправлении самых серьёзных из них в первую очередь. И три пользователя с высокой вероятностью столкнутся со многими наиболее значимыми проблемами, связанными с задачами, которые вы тестируете.
Таким образом, только потому, что не так много других людей жаловались на то же самое, не означает, что это не важно. Больше точек данных всё ещё полезно для команды Discourse при оценке текущих основных и второстепенных проблем пользователей.
Можно ценить обратную связь людей, даже если вы не будете её реализовывать
В-третьих, всё ещё можно поблагодарить людей за их обратную связь, даже если вы не можете реализовать все их предложения или если вы решили этого не делать.
Я научился лучше работать с обратной связью таким образом после изучения дизайна игр, где отдача и получение обратной связи были огромной частью процесса. При итерациях каждого уровня игры, документа дизайна или чего-либо ещё мы давали обратную связь как минимум по трём работам других людей и получали обратную связь как минимум от трёх других. Я часто пытался давать обратную связь для 4 или 5 человек, чтобы компенсировать отсутствие других или их опоздания с заданиями и т.д.
Часто чья-то обратная связь очень проницательна и полезна, но есть более 10 важных пунктов, а у вас сейчас есть время реализовать только 1–3 из них.
Так было и когда я профессионально работал программистом, часто взаимодействуя с сообществом в составе небольшого стартапа. Может быть 10+ важных отчётов об ошибках, но в следующем обновлении у вас есть время исправить только 1–3 из них.
В любом случае я всё ещё считаю, что мы обязаны поблагодарить людей за их наблюдения, поблагодарить за то, что они поделились своими мыслями, поблагодарить за то, что они нашли время описать шаги для воспроизведения ошибки, и извиниться за неудобства.
В большинстве случаев пользователи/игроки ничего не говорят, если их что-то действительно не беспокоит. Поэтому почти все письменные отзывы, запросы на функции и отчёты об ошибках исходят от людей, которые нашли время поделиться своими мыслями о чём-то — о вещах, о которых многие другие, возможно, думали, но ещё не осознали или не сказали ничего, о вещах, которые вы, вероятно, упустили, и так далее.
Поэтому, даже если вы не можете реализовать всё, что говорят все (что может происходить 90% времени), это не означает, что нужно сразу же отмахиваться от всей этой обратной связи. Обратная связь всё ещё важна, даже если у вас нет ресурсов действовать по ней прямо сейчас или даже если вы решили не действовать по ней.
В любом случае, именно поэтому я считаю, что нам, как участникам сообщества, стоит дать возможность новым людям поделиться своими мыслями и не сразу же отмахиваться от их предложений для Discourse. Это связано с тем, что позиция команды Discourse по поводу функций может меняться со временем, а обратная связь всё ещё полезна как точки данных для команды Discourse, даже если они могут не реализовать её прямо сейчас.