Моя главная ошибка в разработке
С уверенностью бульдозера по 1/7 части суши, которая еще совсем недавно была 1/6, шли демократические 90-е. Производство постепенно загибалось, торговля становилась рыночной, хотя больше походила на базарную. И только фондовый рынок рос со скоростью бамбука в тропиках. Моей первой работой был депозитарий (организация, ведущая реестры акционеров акционерных обществ). Главный клиент, а фактически хозяин депозитария, чековый инвестиционный фонд, решил выплатить людям, вложившим свои ваучеры, небольшие заслуженные дивиденды. Но учетная система рассчитала суммы с ошибками округления. Молодому программисту с горячим сердцем и горящими глазами необходимо было исправить ситуацию...
Еще немного конкретики... Деньги тогда были странными. Минимальной разумной единицей было 1000 рублей. Моя зарплата вчерашнего студента была 400000, а счастливые сотрудники головного фонда получали минимум в два раза больше. Ну то есть деноминация была впереди. И вот загадочная компьютерная система выдала значительное количество начислений по 1 рублю. То ли это какие-то остаточные хвосты тех, кто продал свои акции, то ли еще какая напасть, было неведомо. Задача стояла простая, написать программу, которая откроет текстовый файл сформированных почтовых переводов и вырежет те из них, у которых сумма равна 1 рублю. Сказано - сделано. Все же элементарно, больше времени ушло на оптимизацию записи выходного файла на тогдашнем очень медленном железе. Результат готов, сроки соблюдены, заказчик доволен, почтовые переводы заветных дивидендов отправлены получателям.
И вдруг, откуда не возьмись, гневная обратная связь. Оказалось, многим пришли переводы по 2 рубля, по 3, 4, 5 и другие мизерные суммы. Люди сочли это издевательством и даже не пошли на почту позориться. Почему-то никто не догадался проверить, могут ли встретиться еще какие-нибудь ошибки. А можно было даже и не проверять, всего-то, в программном коде нужно было на всякий случай заменить условие "= 1" на "< 1000". Меня никто не ругал, скорее было самоедство (как же мог так накосячить). Но этот случай стал для меня незабываемой прививкой.
Именно поэтому, сейчас, будучи старым ворчуном, я беспощадно критикую современные стандарты разработки: ТЗ, сроки, системы контроля версий и прочие шашечки. Масла в огонь добавляет околоайтишный штат (менеджеры, аналитики, тестировщики), которые иногда, своими ритуалами, вместо помощи, мешают разработчикам. Ну какое, нафиг, ТЗ... В рассматриваемом случае оно было, правда устное, но очень точное, и все было сделано как требовалось, а результат получился обидным и даже смешным. Поймите меня правильно, все вышеперечисленное нужно. Но суть (понимание задачи) гораздо важнее инструментов, подходов и этапов.
Друзья, запомните главное: заказчик никогда, слышите - НИКОГДА, не знает, чего он хочет на самом деле. Составлять подробное техническое задание без возможности уточнения, разрабатывать и даже тестировать исключительно по нему - это абсолютная глупость. Только эксплуатация является настоящей проверкой результата. А все участники процесса, причем с обеих сторон должны прилагать большие усилия для уточнения всех нюансов и быть готовыми к исправлению ошибок, допущенных в том числе на этапе проектирования.