Пользовательские истории. Искусство гибкой разработки ПО (Паттон) - страница 171

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

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

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

Достаточно

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

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

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

 Заказчики. Для них может быть достаточно добавления функциональности, которая обеспечит им реальную выгоду, когда они или сотрудники их организации начнут использовать обновленное приложение.

 Пользователи. Для них может быть достаточно добавления функциональности, которая обеспечит достижение ими одной из их целей.

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

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