Записки автоматизатора. Профессиональная исповедь
Шрифт:
Перед началом внедрения вы должны быть убеждены, что не только вы, но и ваше начальство и коллектив, с которым вы собираетесь работать, отчетливо понимают, что неправильные решения на этом этапе могут превратить процесс в бесконечный.
Пример. Пересчитав остатки на складе, вы начинаете вводить их в систему. Склад в это время продолжает работать: товары привозят и развозят по торговым точкам. В результате к моменту окончания ввода остатков состояние склада в системе уже отстает по времени от текущего состояния склада, и вам нужно ввести в систему ворох накладных, накопившихся с момента снятия остатков. Теперь,
Учтите при этом, что скорость ввода информации при смене системы падает из-за изменения технологии, форматов данных, кодов и наименований.
Понятно, что набор дополнительного персонала никого не радует: мало того, что приходится платить дополнительные деньги, еще и неясно, куда девать этот персонал после окончания внедрения. Но нужно трезво относиться к обычному в таких случаях предложению сверхурочно поработать штатным оператором, пусть даже и за дополнительную оплату. При увеличении продолжительности рабочего дня производительность персонала падает, а количество ошибок возрастает так, что иногда бывает проще очистить базу данных и снова начать все с самого начала, чем найти и исправить все эти ошибки.
И руководители всех звеньев, и рядовые сотрудники должны ясно представлять причины, приведшие к необходимости замены одной автоматизированной системы на другую. Первое время тяжелее работать станет всем, а потом (да и то лишь в лучшем случае) выгоды от использования системы получат только некоторые.
К некоторым почти всегда относится руководство, которое станет получать более точную и оперативную информацию, и почти никогда не относятся операторы, которым придется переучиваться, привыкать к новым правилам ввода информации (может быть, не худшим, но другим, что раздражает неимоверно), а потом еще и обрабатывать большие, чем раньше, объемы информации.
Желание операторов вернуться к старой системе может приводить к саботажу новой и, в исключительных случаях, к диверсиям против нее. Мягкие методы противодействия саботажу не всегда дают эффект, и иногда приходится идти на полную замену операторского персонала.
Есть еще одно очевидное требование, выполнения которого не так-то просто добиться в наше время. Как минимум за две недели до начала внедрения (большего срока вам все равно не дадут) надо наложить мораторий на все изменения в технологии работы и на требования срочно разработать дополнительный отчет или печатную форму.
К сожалению, кроме субъективных причин типа хозяев и начальников «с шилом в одном месте» («Я не могу ждать! Это приносит мне ежедневные убытки в пять тысяч долларов!» – про отказ срочно изменить способ сортировки товаров в отчете), существуют еще и объективные (введен или отменен очередной налог; Мосалкогольконтроль в пятый раз изменил форматы данных, которые ему нужно передавать еженедельно; сделалось 17 августа 1998 года, и остатки склада в рублевых закупочных ценах превратились в полную абстракцию, не связанную с реальной жизнью, а формирование цен реализации как функции от закупочных стало верным способом разорения).
Не со всем из перечисленного можно бороться, но еще один совет я все-таки могу дать: не привязывайте начало внедрения к отчетным датам (начало года, квартала,
В нашей стране понятие подвига не вполне однозначно. Даже в детстве меня удивляло, что подвигами объявлялись ситуации, в которых человек погибал, а задание его оставалось невыполненным.
Военный подвиг, конечно же, всегда связан с риском гибели. Но если двое сделали что-то выдающееся, при этом один из них погиб, а второй – нет, то славы достойны оба, а в пример лучше ставить второго. Камикадзе все-таки не слишком эффективны.
В нашей отрасли, конечно, жизнью обычно не рискуют, только здоровьем. Это попадает под стандартное определение подвига трудового. И в некоторых случаях без подвига в нашем деле не обойдешься.
Восстановление информационной системы, обеспечивающей предприятия с круглосуточным циклом работы, должно производиться ровно с того момента, как она обрушилась, независимо от того, произошло это днем или ночью, и продолжаться до ее восстановления, полного или частичного. Я даже не говорю про системы, обслуживающие энергетику или банк крови. И компанию – дистрибьютора скоропортящихся продуктов или ежедневных газет сейчас можно легко разорить, отключив от информационной системы на несколько торговых дней. Понятно, что лучше от таких ситуаций защищаться, но иногда они все-таки происходят.
Бывают и плановые подвиги. К примеру, система у вас работает круглосуточно и ежедневно, а вам нужно внести в нее существенные изменения. Остановка функционирования будет, конечно, запланирована заранее, но работы придется проводить, пока они не закончатся, а это может растянуться на несколько суток. А число сотрудников, способных такие изменения произвести, не убив систему окончательно, всегда минимально. Никто не будет держать их на работе ровно для таких случаев. Мне и штатным-то количеством персонала, оговоренным с руководством, последние десять лет укомплектовать свои подразделения не удавалось ни разу.
В перечисленных случаях приходится работать по несколько суток подряд, иногда отключаясь непосредственно на рабочем месте на время длительных операций, оставив у монитора оператора, готового разбудить тебя словами «оно закончилось» или «оно сломалось».
Никуда не деться и от подвигов помельче. Если со складов в магазины товар развозится по ночам, то вас иногда будут будить ночью по производственным вопросам. Если в выходные магазины компании продают товара в три-четыре раза больше, чем в будни, то не удивительно, что к вам будут приставать и по выходным.
Но подвиги в ИТ распространены гораздо больше, чем это необходимо. Связано это как с менталитетом самих айтишников, все еще жаждущих романтики от своей работы, так и с менталитетом хозяев и начальников, очень благосклонно относящихся к жертвам в собственную пользу. Но есть ли от этого польза на самом деле?
Много ли вы знаете программистов, способных эффективно работать более двенадцати часов подряд? Я лично знал ровно одного, который переставал делать в коде даже синтаксические ошибки на 26-м часу непрерывной работы. Но, когда эта работа все-таки заканчивалась, он сначала отсыпался, а потом уходил в недельный запой.