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

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

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

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

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

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

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

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

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

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

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

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

7. ???

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

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

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

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

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

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

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

Для бизнеса важно слушать своих заказчиков.

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

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

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

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

Читать далее: https://blog.codinghorror.com/complaint-driven-development/

Автор: Jeff Atwood, 18 Feb 2014