Записки автоматизатора. Профессиональная исповедь
Шрифт:
Как ни печально, на работе люди используются утилитарно. Единственная задача, которую я выполняю в роли начальника, это техническое обслуживание, наладка и ремонт механизма под названием «отдел» для того, чтобы он мог выполнять свои функции. Люди при этом соответствуют деталькам, совместная работа которых как раз и приводит к тому, что механизм работает. Если с одной из деталек происходят какие-то изменения, я ее должен осмотреть, отремонтировать или изъять, после чего переналадить механизм так, чтобы он мог продолжить свою работу.
Поскольку я до некоторой степени человек
В армии механизмы-подразделения строятся на принципе абсолютной взаимозаменяемости деталей, и это объективная необходимость, поскольку во время боевых действиях детали выходят из строя достаточно часто. Поэтому в процессе подготовки деталей их все сделают или одинаково круглыми в профиле, чтобы одинаково катились, или одинаково квадратными, чтобы можно было в любую часть стены вставить. Буратино в армии (подчеркиваю: в любой, а не только в нашей) лишится носа и других выступающих частей и нарастит шею, чтобы ничем не отличаться от других бревен. Иначе он будет сломан.
По счастью, в моем отделе это не так. Я могу несколько раз переставить деталь, пока она не встанет на место, где ее взаимодействие с другими деталями будет наиболее эффективным для функционирования механизма в целом, могу даже подыскать нишу для длинного носа, прослежу, чтобы ручки и ножки не выломались из суставов при частых контактах с соседними арлекинами, но все это тоже имеет пределы. Если для носа такой длины ниши в отделе нет, то его придется укоротить. Туловище я обработаю шкуркой, чтобы окружающие мальвины не пострадали от заноз. В худших случаях придется заменить деталь на такую, которая не будет ломаться и приведет к повышению эффективности работы механизма. Я все сказал. Ты умный. Все остальное зависит от тебя.
Формулирование задач
В соответствии с российскими (и, кстати, американскими) стандартами составление технического задания (ТЗ) возлагается на разработчика. Это естественно, так как обычно клиент сам не знает, чего хочет, что можно реализовать и как.
Однако зачастую сотрудники разработчика если и умеют писать программы, то совершенно не в состоянии сформулировать свои мысли на русском языке. В качестве компенсации этого недостатка в договор на разработку вставляется фраза «Если какие-либо положения технического задания могут быть интерпретированы неоднозначно, правильной считается интерпретация, использованная разработчиком».
Посмотрим на примерах, к чему это приводит.
Невинная фраза из ТЗ «Все количество распределяется по всем покупателям поровну с округлением до 1 шт. Погрешность округления относится на последнего покупателя» приводит
Итак, на 100 покупателей поступило 40 штук. Поровну означает 40/100 = 0,4 штуки. С округлением до одной штуки получается 0, то есть все 40 штук получит последний покупатель.
Еще веселее, если на 100 покупателей поступило 60 штук. Тогда все покупатели, кроме последнего, получат по одной штуке, а последний… – 39 (минус тридцать девять) штук.
Программа соответствует ТЗ.
Вообще ошибки округления – это бич современных систем учета, особенно в России, где правила бухгалтерского учета про них просто не упоминают, якобы у нас все всегда точно. Как следствие, в России их никаким способом нельзя обрабатывать правильно. У меня сформировалось стойкая убежденность, что наши налоговые органы вполне умышленно никогда не отвечают на такие вопросы и не дают необходимых разъяснений: так удобнее сделать нарушителем любого, кто отчитывается перед налоговиками. Следующий пример из приказа МНС я могу воспринимать только как издевательство:
«По коду строки 100 указано 5 месяцев, в течение которых транспортное средство было зарегистрировано на организацию в 2003 году, следовательно, коэффициент, который следует указать по коду строки 110, составит 5/12 = (5: 12)».
Ясно? 5/12 равно 5:12, так МНС приказал. А уж сколько знаков после запятой оставить – это ваша проблема: сколько ни укажите, будете не правы.
Значит, тем более все вопросы, связанные с округлениями, надо подробно описать в техническом задании и по возможности разъяснить руководству (с примерами на конкретных цифрах).
Про программиста, написавшего программу для банка, добавлявшую все ошибки округления на его банковский счет и ставшего миллионером (на время, пока его не посадили), я читал еще в начале семидесятых (книжка называлась «Кибернетическая смесь»). Теперь обязательно пытаюсь рассказать эту историю боссам, а потом уже показываю, как после получения груза на сто тысяч долларов тысяча долларов растворяется в системе.
Одним из самых крупных подводных камней разработки ТЗ является недоформализация тех задач, которые кажутся совершенно очевидными бизнес-заказчику. По всей видимости, нужно иметь специальную голову, чтобы всегда понимать, что записанные требования нельзя запрограммировать однозначно.
Про полтинники. Я уже писал, как в компании, продававшей периодическую печать, киоскеры, работавшие в метро, взмолились, чтобы мы округляли розничные цены на газеты до полтинника. Руководство нас на это благословило, и я программисту ровно так задание и сформулировал: «В поле PriceMetro поместить значение из поля PriceRetail, округленное до 0,5».
Звонит программист:
– А каким способом округлять?
– Обычным.
– Андрей, я не знаю обычного способа округлять до 0,5. Пожалуйста, опиши.