EXECUTIVES.RU

25 ноября 17:40 CET.  Это большое событие в моей жизни – в корпоративной сети компании BPS Bavaria Property Services International GmbH, в которой я начал работать CIO пару дней назад, появилась живая JIRA для тестирования в качестве системы управления бизнес-задачами. Большое спасибо нашим партнерам из Группы компаний RACE за установку тестовой версии на одном из своих серверов.Впервые я встретился с JIRA, когда работал на 2-ой линии инженерной поддержки торговых площадок лондонского офиса Deutsche Bank.

В нашей команде из 3-5 человек, разбитой на две части пространством (Москва-Лондон) и политикой, работа над задачами и запросами пользователей очень часто дублировалсь различными людьми. Или даже одним и тем же человеком, который забыл, что он делал запрос, пролежавший полгода. А каждый большой сбой системы приводил всех в истерику.

Задач было много, и рабочего времени не хватало даже на половину из них. Постоянно возникали новые проблемы, а перспектива привыкнуть к сверхурочным 4-5 часам в день не радовала. Ясно было, что нужна хорошая система управления задачами.

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

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

Это была одна из самых горячих недель. Я параллельно работал над тестированием одного очень важного изменения в нашей банковской системе (Сама эта система заслуживает отдельного поста).

Кроме того эта система как раз дала нам тогда крупный сбой: 50 тысяч сделок с бирж Лондона, Амстердама и Франкфурта получили дубликаты идентификаторов, обязанных быть уникальными. Это повергло операционистов и контролёров бекофиса в истерику – они не могли понять, кому какие акции теперь принадлежат. Трейдеры, которые пользовались этой системой, не могли видеть свои реальные портфели и оценивать риски.

Паника передалась моим начальникам. Когда мой менеджер увидел, что я вместо того, чтобы отчаянно бросаться решать первые попавшиеся срочные запросы пользователей, сижу и спокойно завожу по тикету на каждую задачу, он решил, что я сабботажник, и пометил у себя в дневнике «расстрелять на PMO». Меня успокаивало лишь то, что терять мне было все равно нечего, поскольку под расстрел я бы попал в любом случае. Когда система рушится, а ИТ проявляет панику, это значит только одно – проблему решать некому, и пора искать кого-то для публичной порки и спасения собственного лица. Руководители, склонные к параноидальному менеджменту, предпочитают уходить от ответственности, прикрываясь командой, поэтому у меня был очень большой шанс оказаться в роли козла отпущения.

Мне и моему напарнику Саше (который тут-же поддержал эту затею) потребовалось в этой жесткой ситуации безмятежность и мужество, чтобы не поддаться общей панике и прессингу, а просто осуществить решение, которое казалось правильным только нам. Я настраивал JIRA по живому, параллельно разбирая все горячие заявки и занося их туда из почты Lotus Notes (кто работал с этим продуктом, знают каково это) .

Вечером того самого дня, когда мой начальник заточил на меня зуб, мне позвонил Грэм (в те времена наш большой начальник из Лондона) и попросил мне дать ему доступ к файлу со списком текущих задач. Этот файл наши менеджеры составляли в MS Excel, один раз в 2 часа устраивая 20 минутные прояснения статуса. Делали это они видимо в основном для того, чтобы лучше нас замотивировать и не сидеть сложа руки, и все это меня жутко бесило – занятие выглядело совершенно бесполезным, выбивало меня из потока и отнимало у меня время, которое я вынужден был затем компенсировать переработками и нарушением баланса работа-семья.

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

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

На следующий день стали видны результаты. Мы методично стали «закрывать тикеты», и пользователи и менеджмент увидели, что у команды все под контролем. На самом деле это все, что им было надо – понять что ИТ контролирует ситуацию.

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

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

JIRA мне понравилась еще и тем, что ее бекэнд оказался для меня очень прозрачным, несмотря на первое ощущение некоторой тяжеловесности. Она легко масштабируется (есть большая библиотека плагинов благодаря открытому API) и интегрируется (имеются порты для интерфейсов SMTP, POP, SOAP, XML-RPC, и т.д.).

Она позволяет

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

Имеющеюся возможность настройки workflow позволяет мне рассчитывать на то, что JIRA можно будет также использовать для построения бизнес-процессов (закупки, различные одобрения и утверждения, завершенная работа сотрудника, и т.п.)

См. также цены на JIRA