Сказки с двумя концами

Новый год, как известно, время сказок. Ну а сказки бывают очень разными. Добрыми и злыми, с хорошим или печальным концом. Вообще-то новогодние сказки имеют тенденцию к хеппи-энду — но то сказки, а вот быль многовариантна с точки зрения концовок... и концовки не всегда такие, как нам бы хотелось. Нет, они не злые и не добрые — они просто другие. Потому что жизнь обычно богаче любой сказки по форме и содержанию.Мы попробуем рассмотреть несколько типичных для ИТ-сказок. Сказок с двумя концами: сказочным и наиболее вероятным. Будет, почти как у Джанни Родари в «Сказках, у которых три конца». И для полноты картины с комментариями вместо послесловия.

Важное замечание: все приведенные ниже сказки-кейсы не имеют реальных прототипов и все совпадения с действующими компаниями случайны.

Сказка про то, что все понимают друг друга. Без слов

Жил-был в обычной фирме обычный ИТ-отдел. И правил той фирмой житейски мудрый Директор. Правда, в ИТ разбирался Директор слабо, справедливо полагая, будто каждый должен заниматься своим делом. Однажды пришли к нему верные его Заместители и поставили Вопрос об автоматизации. Пора, мол. А то товар на склады приходуют не так, и расходуют неэкономно. Ну еще про Бережливое производство вспомнили, про Лучшие Мировые практики... и понял Директор, что хотя без этих премудростей обходились неплохо, с ними жизнь станет значительно более правильная. Чтобы все точно получилось, написали они бумагу — требования. А требования дали составлять всем, кто участвует в процессе. Почитай, вся фирма и отметилась. Ну, кроме ИТ и хозблока. Впрочем, и они кое-что не напрямую ухитрились протащить. А ИТ дали требования в последний момент. Так, чтобы ознакомились и реализовали. Ну и срок поставили — месяц. Чтобы, значит, за месяц всё сделать — и в новую жизнь. Директор документы утвердил, назначил пару ответственных, от бизнеса и ИТ, и сообщил об этом всем, кого вспомнил.

Конец 1. Сказочный

ИТ повздыхали-повздыхали, а после взяли и сделали. Частично на 1С, частично на портале, частично сами написали, что успели. Запустили, полгода правили ошибки, наконец, систему стабилизировали, за это время ИТ выросли, требования «похудели» и конкретизировались, но продукт в целом получился ничего так. Уникальный, конечно. Местами с «костылями», но бизнес доволен: маленькая управляемая революция принесла свои плоды, хоть и не такие обильные, как ожидалось. И на примере этого спонтанного проекта все сделали выводы, и мир стал чуточку лучше.

Конец 2. Более реальный

Получив требования и сроки, ИТ-руководитель схватился за голову. Попытался сделать хоть что-то: конкретизировать требования, договориться о реальных сроках. Сроки «пробить» удалось — дали полгода, но чтобы первые результаты были уже через три месяца. Требования — да, пожалуйста, собирайте с тех, кто подавал. Чудо случилось лишь отчасти: половину требований прояснили, половину — нет, вскрылись противоречия... Попытка провести толковый выбор системы, которая бы решала задачу, — провалилась, поскольку время стремительно уходило. В итоге начали делать, что понятно, чтобы показать хоть что-то. В результате к сроку удалось осуществить лишь часть намеченного, но возник конфликт интересов, потому что реализация требований «в лоб» влекла за собой не только оптимизацию процесса, но и перераспределение сил... Словом, потом, нервами и кровью, проект завершили — «перебрав» по срокам в два раза и реализовав 50% запланированного изначально (то есть описанного в «требованиях») функционала, да и то при личном вмешательстве Директора, который спустя два месяца поставил проект на личный контроль с еженедельным докладом...

Комментарии

К сожалению, типичная ситуация для небольших компаний. В принципе, всё могло быть чуть «красивее», если бы требования изначально собирали ИТ, были бы определены приоритеты, намечен план реализации и внедрения... Но, увы, зачастую ошибка именно в том, что все начинают верить в то, что «оно само». И в некую волшебную магию: мы решили, они сделали. И никаких сложностей.

Сказка про реинжениринг. Который, как известно, спасет мир

В обычной фирме жил да был ИТ-отдел. Жили не тужили, горя не знали, службу несли исправно, и всё было у них хорошо. Не шатко, не валко — система управления заявками, какая-то база знаний и оборудования... И было в том отделе специалистов четверо, да начальник. Да и, кстати, сотрудников в компании было немного — около 50. Но вот решено было на самом высоком уровне, что нужен компании реинжениринг: мол, растем, растем — а работаем по-старому. Непорядок. Надо устранить! И устранили, что характерно — с толком для дела. Только вот напасть сия не обошла стороной и ИТ, в виде внедрения лучших практик — ITIL и иже с ними. Для начала решили внедрить 10 процессов — повысить управляемость. Ну а дальше можно и до 40 догнать. Потому что непонятно же, чем там айтишники занимаются. Вроде за компьютерами весь день, а вот как измерить результат? В общем, начали внедрять...

Конец 1. Сказочный

Внедрение было успешно. Были назначены роли, ответственные, точки контроля... Да, ИТ стали работать чуть медленнее. Ну если совсем честно, то это «чуть» варьировалось от двух до трех раз по сравнению с тем, как было «до». Зато всем понятно, как это сделано, и процесс полностью контролируем на всех стадиях... Через некоторое время в ИТ взяли еще нескольких сотрудников — чтобы не нарушать SLA. Но все равно время от времени случалось.

Конец 2. Более реальный

Прикинув объем текущей работы и того, что требовал проект реинжениринга, ИТ-руководитель схватился за голову. И на очередной летучке, посвященной внедрению, высказался в том духе, что «ребят, на улице и так кризис, давайте не будем играть во все это. Вам нужен SLA? Ок, давайте его сюда. Обсудим, заключим. Но внутрь — не стоит лезть, процессы в данном случае все только усложнят. Давайте так, по-простому: для пользователей будет понятный вход, а уж что внутри — просто не будем трогать». Такой подход со скрипом, но прошел — бюджетные аргументы в конце концов никто не смог опровергнуть. Дальнейшая жизнь, кстати, показала жизнеспособность такого решения: ИТ работали как «черный ящик», но с понятными для пользователей параметрами.

Комментарии

Далеко не всегда процессы могут быть полезны. Особенно, когда физически нет ресурсов для их исполнения. В таком случае работа по принципу черного ящика едва ли не единственный выход. Но при этом надо отдавать себе отчет в том, что по большому счету черный ящик — построение достаточно ненадежное, поскольку обладает несколькими существенными недостатками: вероятна высокая человекозависимость и слабый контроль. Создавать черный ящик стоит, когда другого выхода нет. Если есть возможность, лучше всего вводить в черный ящик хотя бы элементы управления — от разграничения зон ответственности между сотрудниками до схем преемственности и эскалации. Тогда черный ящик будет чуть менее «черным» и «на выходе» давать некие гарантии того, что заключенный SLA будет выполнен.

Сказка про большую красную кнопку. Которая способна вывернуть мир наизнанку

Жила-была на свете вполне себе успешная компания. Нет, как и всех, ее коснулся и кризис своими кривыми лапами, и заказы то появлялись, то пропадали. Но в целом и в среднем всё было относительно неплохо. Но вот услышал Бизнес, что есть чудесная суперпрограмма, которая и жизнь наладит, и клиентов приток обеспечит за счет того, что в ней-де сошлись лучшие практики в сфере бизнеса Компании. То есть буквально кнопка «Сделать хорошо» — и автоматически «хорошо» по всем направлениям. Стоила программа, кстати, денег немалых, а их-то как раз и не было. В общем, решили делать самопис. Благо один такой уже был, и его требовалось лишь «немного доработать». И получилось так, что руководитель ИТ недавно сменился — старый пошел на повышение... А новый взял задачу практически «не глядя» — ситуация не та, чтобы привередничать. Прикинул, что ресурсов хватает, — и «понеслась».

Конец 1. Сказочный

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

Конец 2. Реалистичный

На самом деле система была частично готова к времени Ч. И даже к Ч плюс месяц была «почти готова». Запустились на ограниченных процессах — через полтора месяца, да и то частично, на «заглушках», интеграция подкачала. Потом, по ходу выяснили: что-то успело измениться («за время пути собака могла подрасти»), что-то изначально не так поняли, но в целом — работает. Просто появились некие временные трудности. Которые, конечно же, можно и нужно мужественно преодолеть.

Комментарии

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

Сказка про нового волшебника, который летает в вертолете и всех одаривает эскимо. Причем безвозмездно

Жила-была фирма. Не большая, не маленькая, а точнее росла она — от крохотной к маленькой, от маленькой к той, что побольше... Вместе с фирмой рос и ИТ-отдел. И так получилось, что начальник этого самого отдела тоже рос — от единственного специалиста до начальника нескольких бравых парней... И всё бы было хорошо, но пришел кризис, потом еще один. Требования к ИТ повысились, а финансирование —наоборот. Понятно, ребята делали что могли. Но вот незадача: по мнению бизнеса делали мало, вяло, и вообще «не успевали» буквально везде. В итоге руководством компании решено было, что рыба гниет с головы и лечится это тоже — заменой головы. То есть сменой ИТ-лидера.

Конец 1. Сказочный

Смена руководителя прошла на ура. Старый ушел с хорошими рекомендациями и довольно быстро занял должность тим-лидера в крупной компании, которая занималась разработкой ПО. Новый, пришедший с рынка, оказался взвешенным, мудрым, с хорошим кругозором — так что достаточно быстро были определены «больные точки» и сделаны шаги по улучшению ситуации. После был составлен план по переводу ИТ на сервисную модель. Все были счастливы, даже рядовые ИТ-специалисты, которые сначала принимали нового руководителя достаточно настороженно, — прониклись духом перемен и признали, что «так оно лучше».

Конец 2. Реалистичный

Со старым руководителем договорились по-хорошему: выходное пособие и плавный уход. Нового руководителя искали долго: кандидатов было немного, те, что нравились — отказывались. В конце концов нашли разумный компромисс. Руководитель приступил к работе. Было проведено анкетирование пользователей, составлен план, выполнена реструктуризация. Тем не менее основные горящие вопросы были сняты буквально в первый месяц работы нового ИТ-начальника, да и с руководителями от бизнеса он нашел общий язык достаточно быстро...

Комментарии

Изначально ситуации с «делали мало, вяло и вообще» можно было бы не допускать, если вовремя выстроить коммуникации между руководителем ИТ и представителями бизнеса. Коммуникация с внутренним заказчиком — это очень важная составляющая работы ИТ. Нельзя недооценивать ее значение и важность, даже если «всё работает». Вообще тема коммуникаций в жизни ИТ-руководителя зачастую является если не основной, то определяющей. Бизнесу нужен тот, кто будет на его стороне, говорить на его языке и поддерживать его инициативы.

***

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