Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон Страница 19

Книгу Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон читаем онлайн бесплатно полную версию! Чтобы начать читать не надо регистрации. Напомним, что читать онлайн вы можете не только на компьютере, но и на андроид (Android), iPhone и iPad. Приятного чтения!

Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон читать онлайн бесплатно

Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон - читать книгу онлайн бесплатно, автор Джефф Паттон

Почему мы его создаем? Если мы создадим этот продукт и он будет успешным, что это нам даст?

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

Первое обсуждение истории нужно для формирования структуры потенциала.

Подтвердите наличие проблемы

Эрик, конечно, доверял интуиции своего руководства, но твердо знал: любая грандиозная идея – это только гипотеза. А гипотезу об успешности идеи можно проверить только одним способом – своими глазами увидеть ее успешную реализацию.

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

Убедитесь, что проблема, которую вы собираетесь решить, на самом деле существует.

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

Фактически на этой стадии действовал не только Эрик. Он работал с небольшой командой других людей, которые много обсуждали эту проблему со своими заказчиками и в конце концов пришли к тому, что проблему решить непросто – имелись и другие проблемы, которые нужно было решить в первую очередь. Очень важно понять следующее: чем больше они узнавали, тем сильнее менялась оригинальная идея – вплоть до неузнаваемости. Счастье, что они не начали с разбегу воплощать в жизнь изначальный замысел! Эта работа оказалась бы не нужной ни заказчикам, ни их организации.

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

Прототипируйте, чтобы исследовать

Эрик начал работать как владелец продукта. Сначала он рассмотрел свое решение как набор простых несложных историй – пользовательских историй. Затем перешел к визуализации идеи, превратив ее в простые наброски интерфейса. А после этого создал высокоточный прототип. Это еще не было работающее программное обеспечение – всего лишь простой электронный прототип, созданный с помощью несложной программы наподобие Axure или даже PowerPoint.

Для Эрика все это было исследовательскими этапами, которые помогли ему детально рассмотреть свое решение. Разумеется, ему хотелось скорее выдать продукт пользователям, чтобы узнать их мнение, но он знал: нужно быть твердо уверенным в том, что продукт решит проблемы пользователей, прежде чем выпускать его.

Создавайте прототипы и эскизы, чтобы детально представлять себе свое решение.

Между прочим, я скрыл от вас важную деталь: Эрик был дизайнером взаимодействия. Для представителей этой профессии вполне естественно проводить много времени в общении с заказчиками и пользователями, а также создавать простые прототипы. Но для нового продукта он выступил также в роли владельца – человека, который несет полную ответственность за успех всей работы. Другие владельцы продукта в компании, где работал Эрик, не имели навыков дизайна, но они работали в тесной связке с дизайнерами, которые помогали им проводить интервью с пользователями и визуализировать решения.

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

Разрабатывайте прототипы и проверяйте с реальными пользователями, насколько полезно и пригодно к использованию ваше решение.

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

Критически относитесь к тому, что люди говорят о своих желаниях

Эрик прототипировал то, что считал хорошим, жизнеспособным решением. Но он не был полностью уверен в том, что оно минимально, ведь он продемонстрировал людям множество крутых идей. А когда вы показываете людям такие идеи, неудивительно, что они в восторге. Но Эрик знал, что его работа состоит в уменьшении объема разработки, притом что люди должны остаться довольными. Что же можно отбросить, сохранив при этом жизнеспособность решения?

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

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

Перейти на страницу:
Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.
Комментарии / Отзывы

Comments

    Ничего не найдено.