Последние несколько недель мой запас оправданий делать ерунду растет как на дрожжах. Радует только одно – не я один этот запас пополняю. Более того – я один из самых пассивных пополнятелей. В идеальном мире с идеальными программистами и идеальными процессами, разумеется, никто ерунду не делает. Одна проблема – мы живем не в идеальном мире. Я уже писал о причинах тут и тут почему так происходит системно (ну в рамках высоты своей колокольни и своих компетенций). Теперь хочется поделиться - как это оправдывают коллеги, когда им задают вопросы об их работе.
Начнем с простенького – «У нас сжатые сроки». Ну ок, а клиент здесь причем? Вообще в подобной ситуации, на мой взгляд, руководитель должен проявлять себя и говорить, что так выдавать нельзя. Или это что-то из разряда – если на меня польётся дождь из грязи и отходов жизнедеятельности, то лучше я буду знать откуда? Мне сложно представить, что это за жизненно необходимый функционал, который так сильно нужен клиенту, что должен выдаваться не сделанным хорошо и удобно, а лишь бы выдаться. Но на практике – такое встречается сплошь и рядом. Самое интересное, что если автору подобного в ресторане подать не доготовленную еду или разбросанную или размазанную по тарелке – он оставит свое фи и вряд ли подумает «ну наверное у повара запара и он решил выдать вот так».
Идем дальше – «Это функционал для ограниченного круга лиц». Это такой изящный эвфемизм, который иногда формулируется и проще. «Для техподдержки», «Для конкретного клиента». Т.е. мы сделаем плохо и неудобно, но вроде как у нас будет некий механизм для того чтобы объяснить как этим инструментом пользоваться. Сразу вспоминается магазин на диване с продажей какого-нибудь зашивателя колготок, который великолепен, но как им пользоваться понимает весьма ограниченный круг лиц. Сравнение с магазином на диване не спроста – как правило, решение задачи могло быть исполнено в разы проще и понятнее, но авторы пошли по странному пути изобретения даже не велосипеда, а колеса и выдали это на публику. А для оправдания сложности процесса – готовы чуть ли не лично консультировать и показывать, как этим пользоваться.
Одно из моих любимых оправданий – «Так было написано в задаче». С вариациями «в аналитике», «заказчик так попросил». Я сейчас нарушу закон Годвина. Такое оправдание худо бедно работало только в нацистской Германии в отношении пыток. Автор совершенно точно не в нацистской Германии и, я надеюсь, не собирается никого пытать. Поэтому вопрос решается отрыванием «спины» от стула и согласованием решения получше.
Последнее из разряда необычного – «У конкурентов также». Моя любимая аллегория на это – серия Южного парка про новый вид транспорта. Мы не знаем, почему автор принял такое решение. Мы не знаем, доволен он им или нет. Мы не знаем работает оно или нет. Мы просто взяли и сделали так же. Без учета корпоративного стиля, без учета нюансов. Взяли и сделали. Даже особо не задумываясь, можно ли сделать лучше.
Что в итоге? Да ничего. Сколько-нибудь ответственный разработчик всегда сможет дать объяснение плохому решению. Будет ли это хорошее объяснение? На мой взгляд – нет. Даже лучшее объяснение не сделает плохое решение хорошим. Решение останется плохим. Остается только надеяться, что авторы осознают, что сделали ерунду. В противном случае пользователи рискуют привыкать к «новому виду транспорта».