Книга: Записки автоматизатора. Профессиональная исповедь

Финишная кривая

Финишная кривая

Давным-давно, когда я работал преподавателем, один из моих студентов отчитался по результатам своей работы так: «Программа уже работает, но пока дает неверные результаты». С тех пор эта фраза вошла в классику программистского фольклора.

Однако по сей день однозначного ответа на вопрос, что же такое работающая программа, на мой взгляд, не получено и вряд ли когда-нибудь будет получено. То, что во всех больших программах всегда содержатся ошибки, общеизвестно. Хотя неизвестно, что такое ошибка (этот вопрос долго и нудно приходится обсуждать с разработчиком при каждом составлении договора, а потом не менее долго и не менее нудно доказывать ему, что предъявленные результаты работы системы говорят об ошибке, и в тысячный раз выслушивать бред типа «Это не ошибка, раз вы не можете ее повторить…»).

На эту тему написаны сотни умных книг и тысячи еще более умных статей, в том числе с применением теорий вероятностей и массового обслуживания (вывод моей студентки, воспользовавшейся одной такой книгой, я прочитал в ее дипломном проекте: «Таким образом, еще через два часа эксплуатации в программе будет выявлена последняя ошибка»).

Не залезая в очередной раз в теоретические дебри, берусь утверждать, что в вашей системе ошибки есть сейчас и будут всегда. Хотя бы потому, что в качестве операционной системы хотя бы некоторых рабочих мест у вас стоит небезызвестный Виндоуз небезызвестной мелко-мягкой корпорации.

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

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

Итак, равнение на Гейтса, и – вперед!

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

Тем не менее женщины от мужчин все-таки отличаются. Например, у них гораздо лучше обоняние. Поэтому, чтобы внедрить что-либо в женских коллективах, вы должны обеспечить как минимум ежедневную чистку зубов, мытье под душем, смену носков и трусов всеми сотрудниками, которые обследуют и обслуживают соответствующие подразделения. Нужно также провести разъяснительную работу и с мужчинами, обливающимися пахучими лосьонами, поскольку с такими тоже очень трудно находиться в одном помещении долго.

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

Я умышленно не написал «опытную», потому как давно перестал понимать, что это такое. Этот термин, может, и был хорош – но только для внедрения автоматизированной системы «с чистого листа», взамен системы управления с бумажными документами и способами расчетов на калькуляторах или счетах, что сейчас можно встретить разве что в небольшом магазинчике, но уж никак не в крупной фирме.

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

До первой попытки я тоже считал, что это можно и нужно сделать. Но при внимательном изучении вопроса выяснилось, что:

1. Вычислительные мощности для обслуживания сразу двух систем нужно увеличить вдвое, а обслуживающий персонал – чуть ли не в три раза. После опытной эксплуатации лишний персонал нужно уволить так, чтобы у вас сохранилась информация хотя бы в одной из информационных систем. Что делать с лишней вычислительной техникой, мне совсем не понятно;

2. Результаты работы систем практически невозможно сравнить:

– в новой системе используется другой справочник товаров, а в результате инвентаризации, с которой начинается внедрение, были ликвидированы последствия пересортицы: некоторые товары, фигурировавшие в старой системе под разными названиями, признаны одним и тем же, а другие товарные позиции разделены на несколько;

– в старой системе товар при резервировании списывался со складского остатка, а в новой он остается на складе, но не может быть отпущен;

– в старой системе учет велся по товарам по средневзвешенной цене, а в новой учет ведется по партиям, на каждую из которых фиксируется своя цена;

– в старой системе услуги (например, доставка товара) включались в приходные и расходные накладные как товарные позиции, и теперь их на складе 2744 штуки;

– для управленческого учета используются другой план счетов и другая аналитика.

Что касается применения понятия «опытная эксплуатация» как критерия отлаженности технологии и отсутствия ошибок в программах, то в давно работающей системе обычно технология более отлажена и ошибок меньше. И то не всегда, потому что и технология, и программное обеспечение модифицируются постоянно.

Я могу предложить другие признаки, по которым можно определить успешность хода внедрения:

– вы снова ночуете дома;

– вам удалось увидеть своих детей не спящими;

– с задачи сняли дополнительный персонал, или сотрудники отдела автоматизации заменены штатными операторами;

– руководство сообщило вам, что больше не нуждается в сотруднике такой высокой квалификации, как ваша.

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

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

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

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

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

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

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

К сожалению, кроме субъективных причин типа хозяев и начальников «с шилом в одном месте» («Я не могу ждать! Это приносит мне ежедневные убытки в пять тысяч долларов!» – про отказ срочно изменить способ сортировки товаров в отчете), существуют еще и объективные (введен или отменен очередной налог; Мосалкогольконтроль в пятый раз изменил форматы данных, которые ему нужно передавать еженедельно; сделалось 17 августа 1998 года, и остатки склада в рублевых закупочных ценах превратились в полную абстракцию, не связанную с реальной жизнью, а формирование цен реализации как функции от закупочных стало верным способом разорения).

Не со всем из перечисленного можно бороться, но еще один совет я все-таки могу дать: не привязывайте начало внедрения к отчетным датам (начало года, квартала, месяца), потому что моменты введения в действие законов и постановлений тоже привязывают к ним. Исключением из этого правила служит подсистема официальной бухгалтерии, которую иначе как с начала квартала ввести в эксплуатацию не получается. Но это является и дополнительным аргументом для того, чтобы начинать эксплуатацию складских подсистем в другое время.

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

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

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

Восстановление информационной системы, обеспечивающей предприятия с круглосуточным циклом работы, должно производиться ровно с того момента, как она обрушилась, независимо от того, произошло это днем или ночью, и продолжаться до ее восстановления, полного или частичного. Я даже не говорю про системы, обслуживающие энергетику или банк крови. И компанию – дистрибьютора скоропортящихся продуктов или ежедневных газет сейчас можно легко разорить, отключив от информационной системы на несколько торговых дней. Понятно, что лучше от таких ситуаций защищаться, но иногда они все-таки происходят.

Бывают и плановые подвиги. К примеру, система у вас работает круглосуточно и ежедневно, а вам нужно внести в нее существенные изменения. Остановка функционирования будет, конечно, запланирована заранее, но работы придется проводить, пока они не закончатся, а это может растянуться на несколько суток. А число сотрудников, способных такие изменения произвести, не убив систему окончательно, всегда минимально. Никто не будет держать их на работе ровно для таких случаев. Мне и штатным-то количеством персонала, оговоренным с руководством, последние десять лет укомплектовать свои подразделения не удавалось ни разу.

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

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

Но подвиги в ИТ распространены гораздо больше, чем это необходимо. Связано это как с менталитетом самих айтишников, все еще жаждущих романтики от своей работы, так и с менталитетом хозяев и начальников, очень благосклонно относящихся к жертвам в собственную пользу. Но есть ли от этого польза на самом деле?

Много ли вы знаете программистов, способных эффективно работать более двенадцати часов подряд? Я лично знал ровно одного, который переставал делать в коде даже синтаксические ошибки на 26-м часу непрерывной работы. Но, когда эта работа все-таки заканчивалась, он сначала отсыпался, а потом уходил в недельный запой.

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

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

Я уже забыл, в какой книге в 1970-е годы я прочитал про этапы разработки любых больших систем, но на всю жизнь запомнил, что последние три этапа – это:

– поиски виновных;

– наказание невиновных;

– награждение непричастных.

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

Итак, не думайте, что вам за вашу работу ничего не будет. Будет, и еще как.

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

– Программное обеспечение готово, чтобы вести разные цены?

– Ну, готово.

– Я говорил, что, по моему мнению, цены должны быть разными?

– Ну, говорил.

– Так в чем же я виноват?

– А почему ты нас не убедил, что это правильно?!!

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

Оглавление книги