Разработка на основе жалоб

discourse
программирование

(Андрей Белов) #1

Перевод: Complaint-Driven Development, 18 Feb 2014
Автор: Jeff Atwood
Блог: https://blog.codinghorror.com/


Если за последний год я писал мало постов в блог, так это потому, что я был занят созданием Civilized Discourse Construction Kit (букв. "Набор для ведения цивилизованной беседы"), о чем рассказывал ранее.

(Да, компания действительно так называется. Вот что происходит, если мне разрешают что-нибудь назвать. Машины для пинбола, люди - в чем разница? Я уже извинился перед Биллом Баджем.)

Если вам, как и моим инвесторам, интересно, почему на этот процесс ушел целый год, мне стоит объяснить, как я занимаюсь разработкой, или хотя бы рассказать о создании Stack Overflow, Stack Exchange и Discourse.

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

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

  3. Вместе со своей командой используйте этот минимально жизнеспособный товар каждый день, 24 часа в сутки. Это не просто обычная разработка ПО - теперь это ваша жизнь. Если вы не живете программой, которую создаете, каждый день, постоянно… все неминуемо закончится слезами для всех участников проекта. Честно говоря, если мне нужно еще и это объяснять, то знаете что? Вы попали впросак.

  4. Запустите сжатую закрытую бета-версию и получите отзывы от своих интернет-товарищей о том, что вы уже смогли сделать. Знаю, о чем вы думаете: "Друзья! Черт побери! Так и знал, что они когда-нибудь окажутся полезны!" Примите их отзывы спокойно, несмотря на то, что они могут быть глупыми. Найдите и исправьте все крупные ошибки, которые возникнут. Ваш товар все равно будет ужасен, но уже гораздо в меньшей степени. Теперь вы будете в не такой большой беде, чем если бы не проделали этот шаг. (Бизнес-эксперты называют это "конкурентоспособность". Изучите этот вопрос.)

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

  6. Помните все те прекрасные идеи, которые у вас возникли во время кропотливого, детализированного исследования в шаге №1? Оказывается, если преподнести их настоящим честным пользователям со всего мира, то они все будут… полностью… неверными.

  7. ???

  8. Пора получать доход!

Я не говорил, что это хороший план разработки ПО, но… Знаете, это же все-таки план.

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

  • Пусть ваше ПО будет доступно максимально большому количеству реальных пользователей со всего мира.

  • Выслушайте все их жалобы. Их будет… много.

  • Вычислите 3 вещи, о которых люди чаще всего жалуются.

  • Повторите эту последовательность заново.

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

Если у вас есть оснащение для того, чтобы слушать потребителей, то разработка на основе жалоб не так трудна. До того как вы погрузитесь в многолетние разработки, вы будете иметь дело с очевидными жалобами от пользователей, и их будет легко исправить. Главное - слушать. В “Don’t Make Me Think” Стив Краг сказал:

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

За полдня можно найти больше проблем, чем можно исправить ошибок за месяц.

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

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

К сожалению, пользователи возненавидели это требование:

"Мне кажется, больше всего раздражает отсутствие индикатора, который бы показывал, сколько еще символов нужно напечатать. Вы можете понять это только по тому, высвечивается ли кнопка "Ответить" серым цветом или нет. Но даже тогда при нажатии кнопки "Ответить" может высветиться запрет, если пост в основном состоял из пробелов. Это чертовски раздражает".

Это одна из самых частых проблем в ранних отзывах, которые мы получали. В первые 7 дней после запуска мы быстро добавили в нижний правый угол редактора счетчик символов, который работает в реальном времени.

1

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

2

3

Мы использовали все упомянутое выше и не только. Жалобы ничуть не утихали. Теперь мы добавили такие настройки: если вы хотите, чтобы в вашем сообществе минимум для заголовков и постов составлял 1 символ, то вы можете установить такую настройку в веб-браузере за 15 секунд. Честно говоря, мне уже надоело выслушивать жалобы об этой настройке.

Наконец, мы включили в работу термоядерную опцию: рядом с полями появлялись окна-ошибки.

4

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

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

Да, собирать отзывы от пользователей - трудная работа. 90% собранных отзывов будут ужасными по множеству причин. Гораздо проще представить, как какой-нибудь герой-эксперт появляется и магическим образом предоставляет вам ответ. Ну, удачи вам с этой фантазией. Работает лишь такой способ: много общаться со своими пользователями, развивать отношения. Только так вы сможете получить те редкие 10% отличных, прогрессивных отзывов. Именно так и нужно строить коммьюнити, которому важно то, что вы делаете: вы должны быть неравнодушны настолько, чтобы по-настоящему выслушивать пользователей и делать такие изменения, которые будут им небезразличны.


Добро пожаловать на официальный форум Discourse:

P.S. опубликовано с разрешения Jeff Atwood

November 18, 2018 3:23 PM


Чем хочет стать Stack Overflow, когда вырастет?