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