Граница халтуры, зазор посредственности, дефицит старания - это всё мои попытки перевести «Crap Gap»
Еще одна интересная мысль Карла Вигерса, которую он доносит не только в
https://youtu.be/aYOrd1uCqXo?si=i9X_HDQiPiGAlQKr, рассказывает о ситуациях, когда небольшие усилия могли бы привести к намного лучшему результату.
Сам термин используется для описания минимальной разницы в усилиях между созданием качественного и некачественного продукта. Чтобы лучше передать смысл слова «сrap», сохранив при этом некоторую литературность, будем использовать далее слово «халтура».
Карл призывает избегать халтуры на каждом этапе работы, подсвечивая, что для превращения «плохого» продукта в «хороший» часто достаточно приложить немного дополнительных усилий. Это немного Карл показывает вот таким жестом 🤏
Куда и какие усилия стоит прикладывать 🤔
✅ Можно задать дополнительные вопросы при выявлении требований, вместо того, чтобы опираться на собственные допущения.
✅ А еще можно продумать поведение системы, чтобы пользователь не видел на экране «Индекс находится за границами массива», а получал информацию о том, что произошло и как с этим быть в доступной форме.
✅ Ну и протестировать чуть больше, чем просто позитивные сценарии.
Если все так просто, то почему не все так делают 🫥
Одна из обозначенных причин - спешка, ее могут дополнительно сопровождать незнание и небрежность.
Например, мы можем сэкономить время на коммуникациях с пользователями и сформулировать неверные предположения о необходимых возможностях и сценариях использования. Или можем просто не знать, как провести интервью и придумать сами, что пользователям/заказчику нужно именно это.
Или разработчики в спешке и разработают решение, которое функционирует только в идеальных условиях. Успеем в срок, но при первой же нештатной ситуации, скорее всего, будем жалеть.
😐 Во всех перечисленных случаях мы экономим время и когнитивный ресурс, но создаем риски и потенциальные расходы в будущем. А когда спешка оказывается еще и необоснованной, то обидно вдвойне.
Есть и более сложные в починке причины. Например, сложившаяся в компании культура, когда на словах все за качество, а на деле надо экономить ресурсы и сроки горят. В такой ситуации команда будет вынуждена халтурить.
Еще один неочевидный момент - неверный фокус внимания. Наши усилия могут быть направлены на чистоту кода и правильность документирования требований, пока пользователи страдают от неудобных интерфейсов и уже сформировали не самое лучшее мнение о продукте и работе команды разработчиков.
😳 Интересный факт, что рассказывая об этом явлении Карл вспомнил пословицу «Measure twice, cut once», которую дословно можно перевести «Отмерь дважды, отрежь один раз».
В русском варианте «Семь раз отмерь, один раз отрежь» уже заложены дополнительные проверки, поэтому остается только придерживаться этой мудрости и стараться не халтурить 😎
