В течение последнего года я мало писал, так как был занят разработкой нового средства для ведения дискуссий. Если вы, вслед за моими инвесторами, хотите знать, почему это заняло целый год, мне стоит объяснить, как именно я делаю программы, или, как минимум, как мы сделали Stack Overflow, Stack Exchange и, теперь, Discourse:
1. Проведите крайне подробное исследование всего, связанного с вашей тематикой. Успехи: в чем они ошиблись? Провалы: что они сделали правильно? Никто не должен знать об этой теме больше вас. У вас должна быть осмысленная история, в которую вы верите и, что еще более важно, в которую могут поверить другие.
2. На основании исследования соберите команду и сделайте минимально жизнеспособный продукт, который будет делать что-то полезное. Если вам нужно начальное финансирование, самое время найти его — надеюсь вы выполнили все указанное в шаге 1 очень хорошо и возможно еще и знамениты, а в идеале еще и успешны, в противном случае вы в заднице.
3. Начните использовать этот продукт вместе со всей командой, каждый день, весь день. Это не просто разработка: это вся ваша жизнь. Если вы не живете разрабатываемой программой каждый день, целый день… проект неизбежно ждет плачевный исход. И, честно говоря, если мне приходится вам это объяснять, то знаете что? Вы в заднице.
4. Запустите кратковременную закрытую бету и посмотрите на отзывы ваших Специальных Друзей из Интернета ™ о уже сделанной работе. Я знаю что вы думаете: «Друзья! Черт побери! Я знал, что когда-нибудь они мне пригодятся!» Внимательно и непредвзято выслушайте все их отзывы, какими бы тупыми они ни были. Найдите и исправьте все серьезные недостатки. Ваш продукт все еще ужасен, но немного менее ужасен чем раньше и вы будете в немного менее глубокой заднице, чем были бы в ином случае. (Бизнес-эксперты называют это «конкурентным преимуществом». Поищите информацию про него.)
5. Стремительно перейдите к публичному запуску. Продукт будет отстоем, но вы все равно его выпустите. Не провалите сам запуск. Вы знаете о чем я говорю, так как не раз видели весьма убогие запуски. Не будьте этими компаниями. Не будьте этими командами. Не беспокойтесь, у вас еще будет великолепная возможность все провалить на следующем шаге.
6. Эй, помните все те гениальные идеи, которые вы придумали на основании тщательного, подробного исследования, сделанного вами в шаге 1? Как только вы представите их настоящим, кристально честным пользователям из реального мира, внезапно выяснится, что все они… были… совершенно… ошибочными. Теперь потратьте весь следующий год на исправление всех своих идиотских провалов и ошибок.
7. ???
8. Прибыль!
Я никогда не говорил, что это был хороший план, но знаете, это все-таки план!
Каждый из этих шагов сам по себе достоин статьи, но сегодня я сосредоточусь на шаге шесть, потому что, по моему мнению, это самая важная часть всего «плана». Мне нравиться называть его разработкой через жалобы:
- Представьте свою программу как можно большему количеству реальных пользователей
- Выслушайте все жалобы. Их будет… много.
- Определите и исправьте три основные проблемы, которые вызывают постоянные жалобы
- Повторите
У нас есть не совсем честное преимущество, потом что Discourse — это программа для обсуждений. Мы размещаем все обсуждения недостатков Discourse… на самой Discourse. Но именно поэтому мы и разрабатываем программу с открытыми исходниками для общения — я твердо уверен в том, что для вашего бизнеса важно на самом деле слышать клиентов.
Если у вас есть средства для общения с клиентами, разработка через жалобы не особенно сложна. Перед составлением многолетних планов разработки займитесь вполне очевидными и легко исправимыми жалобами от пользователей. Как сказал Стив Круг в "Не заставляйте меня думать":
Нет необходимости искать все проблемы. На самом деле вы никогда не найдете все проблемы, чтобы вы ни тестировали. И все равно это не поможет вам по следующей причине:
За половину дня вы можете найти больше проблем, чем сможете исправить за месяц.
Вы всегда найдете больше проблем, чем можете исправить, так что крайне важно сначала сосредоточиться на исправлении наиболее серьезных. И три пользователя скорее всего обнаружат многие из самых серьезных проблем, связанных с тестируемыми вами задачами.
Мы, например, запустили Discourse с ограничением на минимальную длину заголовка и текста сообщения, потому что мы были уверены, что очень короткие записи и в особенности заголовки не способствуют нормальному общению. Это так же крайне важно для нас с философской точки зрения, так как тесно связанно с нашей миссией построения программ, которые помогают развитию осмысленного общения в интернете.
К несчастью пользователи возненавидели его:
Меня сильнее всего раздражает то, что нигде не показано, сколько символов надо ввести. Видно только выключена ли кнопка «Ответить» или нет и не все пользователи вообще понимают, что она выключена. И даже после этого она может не работать, если ваша запись состоит в основном из пробелов. Это просто бесит.
Это был один из самых ярких примеров ранних отзывов. Так что в течение первых 7 дней после запуска мы быстро добавили работающий в реальном времени счетчик необходимого количества символов.
Я думал это поможет. Не помогло. Жалобы по поводу нашего ужасного, омерзительного и кабального ограничения на количество символов в заголовке и тексте сообщения продолжали поступать. Мы попробовали сделать эти ограничения более понятными, добавив красную рамку или фон на поля для ввода текста:
Мы установили все это и многое другое. Жалобы не прекращались ни на секунду. Теперь это было одной из настроек и вы могли изменить ее для вашего сообщества прямо в браузере, всего за несколько секунд. В итоге я просто устал от жалоб на эту настройку.
Мы применили термоядерное оружие: всплывающие сообщения об ошибках прямо справа от поля, как только оно теряло фокус.
С этого момента я не услышал ни одной жалобы на наше ужасное, отвратительное, кабальное ограничение на количество символов в тексте и заголовке сообщения. Ни одной. Ни единой. Жалобы.
Вот такими вещами мы и занимались каждый день, каждую неделю, в течение последнего года. Потребовался целый год разработки через жалобы, чтобы наша программа стала пригодной к использованию. И хотя сейчас мы осторожно принимаем клиентов, мы все еще занимаемся разработкой через жалобы каждый день, возможно слегка сместив внимание в сторону людей, платящих нам деньги.
Сбор отзывов от вашего сообщества может быть крайне тяжелой работой. И 90% отзывов могут быть ужасными по целому ряду причин. Намного проще вообразить, что какой-то герой-эксперт внезапно благословит вас правильным ответом. Ну что же, удачи вам с этими фантазиями. По моему опыту единственный работающий метод — погрузиться глубоко в грязную работу вместе с вашими пользователями, общаться с ними и развивать взаимоотношения. Только так вы можете выявить те 10% ценных пользовательских отзывов, которые действительно потрясают и ведут к преобразованиям. Только так вы можете построить сообщество, которое будет действительно заинтересовано в том, что вы делаете — действительно слушая их и внося изменения, которые им нужны.
Примечания переводчика:
1. Разработка через жалобы — в оригинале complaint driven development аналогично test-driven development
2. В заднице — в оригинале you are screwed, более вежливый аналог fuck. Совсем вежливые варианты вроде «у меня проблемы» явно не отражают смысл термина, очевидный «поимели» в русском языке обязательно подразумевает наличие другой стороны.
Complaint-Driven Development — Coding Horror
Автор: Vedomir
