Ура JIRA!

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

Три принципа хорошей службы поддержки

Недавно мне пришлось общаться c отечественными службами поддержки, и меня сильно “впечатлил” подход специалистов, отвечающих на телефон. Не буду называть компании и имена, поскольку это не важно - явление слишком распространено.

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

Я: Как мне настроить XXX для работы с вашим подключением - мне нужны параметры сети
Поддержка: А мы не занимаемся настройкой XXX!

или так еще

Я: Здравствуйте. У меня такая-то проблема.
Поддержка: А какой у вас клиентский номер?
Я: 12345
Поддержка: А вот и не угадали!

%-)

Меня отфутболить очень трудно - я знаю, как говорить с поддержкой.  Однако для  людей не из ИТ задача практически нерешаемая.

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

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

Служба поддержки - это лицо компании, которое видят ее постоянные клиенты, которые уже заплатили и заплатят вам завтра. Если вы их конечно удержите. Хотите их удержать? Тогда подумайте о том, как у вас организована служба поддержки.

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

Первый принцип:

Главная задача поддержки - это довольные клиенты. Конечно, важно помогать им решать проблемы, но как ни странно - это вторая задача! Первое - это довольные клиенты. Клиент хочет, чтобы его выслушали и поняли проблему, поэтому саппорт должен уметь слушать.  И они ждут ответов. Сообщайте им о том что проблема решена. Если она не решена, сообщите об ожидаемом времени, когда она будет решена. Когда у клиентов проблемы, им нужно общение на эту тему больше, чем само решение проблемы.

Второй принцип:

Сисадмины и разработчики не могут выполнять эту работу. Во-первых потому что их собственная работа требует сосредоточения и погружения в поток.

А во-вторых, в ИТ очень много людей “со странностями”, которые прекрасно выполняют технические задачи, но с людьми не всегда в ладах. Кроме того эти небожители часто просто не умеют разговаривать на языке, понятном простым смертным. Поэтому никогда не “вешайте” звонки клиентов на перегруженных сисадминов или разработчиков.

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

Третий принцип:

Заводите тикеты на обращения клиентов. Каждое первичное обращение с проблемой должно быть задокументировано или иметь номер и идентификатор, который должен сообщаться клиенту.  Это дает возможность

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

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

Я рекомендую использовать HESK или JIRA.

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

JIRA  - это профессиональный инструмент, который легко масштабируется, интегрируется с  системами контроля версий,  дает менеждменту наглядную статистику, позволять связывать одни типы тикитов с другими (например, инциденты с проблемами или багами, которые их вызывают) и дает много других возможностей, которые могут понадобиться службам поддержки. Сегодня лицензия на JIRA для небольших команд стоит всего 10$.

Талантократия

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

Предлагаю текст Интервью с Павлом Гореньковым, управляющим компании Гарс Телеком,  для ток-шоу  Цена Вопроса.

(Оригинальная видеозапись интервью длится ~ 8 минут,  см. здесь - http://talentocracy.ru/project/ )

-Павел, расскажите каким образом вы подбирали для себя команду?

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

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

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

- Но все равно ведь есть лидер, который ведет за собой команду?

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

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

Такой подход не создает даже почвы для интриг, подсиживания, корпоративных футблов и перевода стрелок - в отличие от тех компаний, где существует жесткая корпоративная культура с четко разграниченными должностными обязанностями, рассчитанная на “среднего” человека.

- Если в компании возникает конфликт,  вы пытаетесь его решить?

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

- В чем особенность работы руководства талантливыми людьми?   Они капризы, вы сказали. Наверное, они вечно опаздывают и имеют проблемы с дициплиной.  Они вечно пребывают в своем мире?

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

Мы культивируем модель корпоративного управления, которая называется know-why - дословно “знаю зачем” .  Есть некий скелет бизнес-процессов.  Каждый человек четко понимает  цели и стратегию компании и свою роль в их достижении.  А вот путь он выбирает сам,  это не регламентируется. И поверьте, каждый человек на своем месте может быть гораздо более эффективен, чем тот менеджер  по бизнес-процессам, который придумал ему роли и ему описал.

- Насколько вы дорожите своей командой?

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

Легкая беседа (small talk)

Сочетание small talk во многих языках не переводят  с английского.  Google Translate дает такие варианты перевода на русский:

  1. бессодержательный разговор
  2. пустой разговор
  3. светский разговор
  4. легкая беседа

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

Назначение

Зачем же нужно говорить ни о чем, да еще учиться этому и без того занятым менеджерам?

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

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

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

Однако не всякая болтовня является “легкой беседой”.  Между профессиональным владением этим инструментом групповой работы и кухонной болтовней существует большая разница.

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

Не перебивайте собеседника, чтобы рассказать свою историю. То что вы сами можете рассказать, вы уже знаете.

Рекомендуемые темы Неприемлемые темы
Погода

Спорт

Позитивный опыт и переживания

Отпуск, отдых, выходные

Мнения собеседника

События текущего дня

Критика

Конфликты

Личные и семейные проблемы

Политика

Деньги

Религия

Слухи

Проблемы

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

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

Полезные приемы

  • Задавайте открытые вопросы о причинах, реальных вещах, связях и мотивах. Типичные вопросы - “почему…” , “как…”, “для чего…”  оживляют диалог, тогда как закрытые вопросы,  на которые возможны краткие ответы “да” или “нет”, делают разговор суше и напряженнее
  • Давайте развернутые ответы на вопросы - это поможет  вашему собеседнику поддерживать дальнейший диалог

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

  • Обращайте внимания на косвенный смысл фраз

Мы попали в шторм на озере и чуть не перевернулись - О, так вы,  должно быть,  хорошо управляйте яхтами?

  • Добавляйте немного информации о себе

- Мне нужно уйти с  собрания во время. В семь часов у меня урок французского

Формат поста в блоге не позволяет описать все секреты мастерства ведения легкой беседы.  Этой теме посвящены десятки или сотни книг (изданных, увы,  пока только на иностранных языках).


Мягкие навыки

В последнее время все чаще можно услышать сочетания  мягкие навыки (от англ. soft skills), социальная компетентность и социальный интеллект.

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

В мире и в России намечается тенденция требовать “наличие мягких навыков” или “социальную компетентность” от кандидатов на руководящую работу. Низкий уровень мягких навыков у руководителя или тимлида - это теперь вполне реальный повод его уволить или сместить.

К мягким навыкам обычно относят следующие качества :

  • Персональные качества
    • Способность принимать решения и решать проблемы
    • Умение четко ставить задачи и фомулировать цели
    • Позитивное мышление, оптимизм
    • Ориентация на результат, на клиента
  • Коммуникативные качества
    • Умение ясно формулировать сообщения
    • Умение взаимодействовать и строить отношения с различными типами людей
    • Хорошие манеры, дружественная форма общения
    • Умение вести легкую беседу (small talk)
    • Умение структурировать и модерировать совещания и обсуждения
    • Умение выслушивать и принимать во внимание разные точки зрения и мнения членов команды
    • Умение отвечать на возражения своевременно, обоснованно, вежливо и ясно
    • Умение подготавливать и проводить качественные презентации
  • Административные качества
    • Умение играть в команде
    • Способность объединять и мотивировать команду
    • Способность обучать и развивать членов команды
    • Способность предвидеть и предупреждать риски
    • Видение, способность планировать и управлять временем
    • В интернациональных командах - понимание культурных различий

Жизнь есть игра

Причем не всегда честная.

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

Цели у таких  производственных  игр бывают разные.  Есть игры конструктивные, а есть деструктивные.  Есть игры без  проигравших, а есть игры с проигравшими. И если вы вовремя не распознали такую игру, то вы играйте вслепую и ваш шанс не остаться в дураках не превышает  1 %.  Особенно если игра нечестная и правила ее сообщаются только избранным.

Реальные правила игры не всегда озвучиваются. Вы никогда не выиграете, если вы не знаете, во что вы играете.

Как играть и выигрывать в нечестные игры, или как не давать себя в них вовлечь?  Без купюр, без цензуры, в прямом ночном эфире, Александр Орлов  и Слава Панкратов рассмотрят теорию командных игр на примерах из  ИТ-индустрии.

Вебинар проходит с 3 по 6 августа 2009 г. Читайте подробности …

9 ошибок управления проектом

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

1. Слабый анализ исходной ситуации

Хочется уже поскорее начать проектировать. Изменения  делаются на основе субъективных ощущений.  Данные отсутствуют

2. У проекта нет четкой цели

Цель необоснована, субъективна, неструктурирована и  недокументирована

3. Мало внимания уделяется поиску альтернативных решений

Отдается предпочтение “излюбленным” решениям,  не хватает мужества отставить их в сторону, чтобы изучить  альтернативы

4. Нет четкого распределения ответственности

Области ответственности не распределены,  руководящий состав о них не проинформирован,  компетентные специалисты не определены

5. Слишком мало выделено персонала

Мало специалистов,  которые компетентны в технологиях, методах и в работе с людьми (т. н. Soft Skills - “мягких навыках”). Для достижения целей проекта мало  экспертных ресурсов

6. Непрофессиональный подход к изменениям

Изменения не отслеживаются и не оцениваются, их обсуждать кажется неловко и неуместно

7.  Недооценка рисков в ходе проекта

Риски не определены, не оценены и  не предупреждены. Альтенативные стратегии  отсутствуют

8.  Отсутствует структура и организация проекта

Нет представления о составе и продвижении проекта.  Импровизации по поводу участников проекта,  менеджменте  и  заказчиках

9.  Для закрывшегося проекта не проводится “разбор полета”

О закрытии проекта не объявляется. Менеджеры проекта не обмениваются своим опытом, нет желания чему-то научиться

А для тех, у кого есть желание учиться:

Упражнение 1

Выберите пожалуйста ТРИ САМЫЕ ГРУБЫЕ ошибки:

Результаты

Loading ... Loading ...

Упражнение 2
Приведите в комментариях  пример  одной-двух проектных ошибок из вашего опыта