Когда надо слушать пользователей

Первое, чему учат начинающего разработчика — это не слушать хотелки своих пользователей. Умение игнорировать чужие идеи даже важнее урезания фич, не говоря уже о какой-то там монетизации. Начнёте потакать им (или менеджменту, хе-хе) и всё, считай нет продукта, вместо него адская химера.

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

Так кого и когда необходимо слушать при разработке ПО?

Внезапная мудрость: прислушиваться нужно к мнению экспертов в соответствующей предметной области.

Только необходимо понимать, что экспертов в широких областях мало, обычно про таких есть статья на википедии. Если человек говорит вам, например, что он является «экспертом в компьютерных играх» и про него не написано на вики, то он точно не эксперт. Он может быть экспертом по монетизации мобильных HOG на iOs, или экспертом по балансировке боёв в TBS, или даже экспертом по ИИ противников в 3D шутерах с закрытыми пространствами. Но экспертом по «компьютерным играм вообще» он точно не будет.

Важно чётко понимать, что единственные и самый осведомлённые эксперты по вашему продукту — это вы и ваша команда. Только вы в курсе всех его особенностей, конечной цели разработки и её краткосрочных и долгосрочных планов. Только у вас есть целостное видение результата (оно же есть, правда?).

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

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

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