Мало кому из разработчиков удается пройти «тест рыжего кота» — и вот почему

Жаль, что нас не учат игнорировать предположения (Себастьян Трун)

Solution Architect Бен Хоскинг считает, что проблемы с программным обеспечением возникают не из-за ошибок в коде. Просто разработчики создают не то. Он уверен, что, к сожалению, большинство людей понимают, чего они хотят, только после того, как получают свой заказ. Вот тогда они и отдают себе отчет, что им нужно было что-то совсем другое. 

Но разработчики все же могут повлиять на ситуацию: стоит задавать больше вопросов и пройти «тест рыжего кота». 

Плотники измеряют древесину дважды, прежде чем отпилить. Разработчики обычно не настолько внимательны .

Что ж, передаем ему слово.

Тест рыжего кота

Благодаря «Дому дракона» драконы снова в моде, поэтому я читаю книгу «Игра престолов».

Итак, поговорим о «тесте рыжего кота» от Сирио Фореля, мастера меча, которого наняли, чтобы научить Арью Старк фехтованию.

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

Сирио рассказывает Арье, как он стал первым мечом Браавоса:

«Послушай меня. Корабли Браавоса доплывают везде, где дуют ветры, к землям странным и замечательным, и когда они возвращаются — их капитаны приводят причудливых животных в зверинец Морского Лорда. Животных, которых ты никогда не видела: полосатых лошадей, огромных пятнистых тварей с шеями длиной с ходули, мохнатых мышосвиней размером с корову, жалящих мантикор, тигров, которые носят своих детенышей в сумке, ужасных двуногих ящуров. Сирио Форель видел их всех.

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

“Видел ли ты когда-нибудь нечто подобное?” — спросил он меня.

Я ответил ему: “Каждую ночь я вижу тысячи таких, как он, в переулках Браавоса”. Морской Лорд засмеялся, и в тот день меня назвали Первым Мечем».

Арья поморщилась: «Я не понимаю».

Сирио щелкнул зубами: «Тот кот был самым обычным. Другие ждали сказочного зверя и видели его. “Какой он большой”, — говорили они. А он был не больше, чем другие кошки, только толстый от лени, потому что Морской Лорд кормил его со своего стола. “Какие интересные маленькие ушки”, — говорили они. На самом деле его уши были отгрызены в кошачьих драках. И это явно был кот. Но Морской лорд говорил “она” — и другие видели кошку».

Команды разработчиков должны видеть, что перед ними, а не полагаться на то, что им говорят.

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

В первые три месяца мы видели лишь половину задачи.

Откройте глаза

«Открыть глаза — это все, что нужно. Сердце лжет, ум выдает номера, и только глаза видят так, как есть. Смотри глазами, слушай ушами. Пробуй ртом. Нюхай носом. Чувствуй кожей. Затем придет понимание, и таким образом ты узнаешь правду» (Сирио Форель).

Нужно понимать, с чем мы имеем дело. А это не то, что люди говорят команде разработчиков или как разработчики видят работу программного обеспечения. Из начальных требований остается 50-70%, и они постоянно меняются.

Предположения — это баги, созданные самими разработчиками, которые предположили, что знают, как разработать программное обеспечение. 

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

Внести правки всегда получается быстрее и проще, если это делается до написания кода.

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

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

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

Разработка программного обеспечения

Смотреть — это не то же, что видеть. Так же и требования высокого уровня не равны детальным требованиям.

Значение слов часто зависит от того, как они интерпретируются. Презентации часто оптимистичны или небеспристрастны.

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

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

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

Для создания ПО необходимо иметь полную картину.

Выводы

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

Автор: Бен Хоскинг

Перевела Евгения Козловская