Year (or more) in the life. Part 5. Luxoft experience
Leadership is doing the right things, Management is doing things right
Я очень долго хотел попасть на полноценную должность конфигурейшн-менеджера для того, реализовывать на практике свои идеи, набраться больше практического опыта. Тренинги - это, конечно же, хорошо, но теория без практики мертва. Поэтому я был очень рад своей новой позиции в одной из компаний (лидеров отрасли) в сравнительно большом проекте, использующем смесь интересных технологий. Наличие большого количества людей, занятых в проекте автоматически означало, что configuration manager - это не просто роль, а полноценная позиция. И это то, что мне было нужно. Я решил закрыть глаза на то, что заказчик - крупный инвестиционный банк (сама предметная область мне не очень по душе), ведь мне должны были платить хорошие (как мне на то время казалось) деньги.
Но первые дни работы в Люксофт заставили меня кое о чем задуматься. К примеру, на следующий день после моего прихода (1 апреля) в проектную рассылку от QA-лида поступило сообщение о том, что наш проджект-менеджер больше с нами не работает, а отправляется в ротацию (для тех, кто не курсе, ротация - это «запас», «бенч», поиск других вакансий внутри компании) и ему планируют вскоре найти замену. Всеми это было воспринято как первоапрельская шутка. Посмеялись и утихли. Но не до шуток было, когда рабочее место проджект-менеджера на следующий день опустело, а его чашка с логотипом компании оказалась в мусорнике (по-моему, кроме меня в мусорнике чашку никто не видел - мое рабочее место находилось в непосредственной близости). Меня это повергло, мягко говоря, в шок. Потом уже я начал потихоньку вспоминать, что перед уходом проджект-менеджера все его документы прошли старательную обработку шредерами, а он, рассказывая мне о проекте и моих обязанностях, вел себя несколько странно. Факт такого внезапного увольнения свидетельствовал о том, что какие-то явные перекосы где-то были. Сложно было понять, где именно - со стороны уволенного подчиненного или со стороны вышестоящего руководства проекта. Это мне и предстояло выяснить во время испытательного срока.
В итоге, с первого дня работы я был немного озадачен и занял оценивающую позицию:
- Баз всего три, к какой приложение должно коннектиться, а к какой - нет?
- Не знаю, это твоя задача, ты ж конфигурейшн-менеджер.
- Я знаю, что это моя задача! Потому и спрашиваю о том, соединение с какой именно базой «отваливается»? Их у нас, как минимум 3 (причем я знаю, что всё настроено правильно или по-крайней мере мне было дано указание настроить работу таким образом).
- Сейчас выясню.
Проходит время.
- Я там тебе логи прислал, посмотри плз
- В логах ничего не понятно. Может это вообще не соединение с базой?
- (вместе анализируем логи) Ах да, это мы забыли прикрутить фичу БББ!
- ?!
Другой эпичный пример. Подходит коллега и говорит:
- Я не могу зайти в корпоративный instant messenger.
- А ты проверял, почта у тебя вообще работает? (аккаунт корпоративного instant messenger’а привязан к почтовому аккаунту)
- А как это сделать? (это на самом деле нормальный вопрос, просто не все пользуются почтой заказчика)
- Заходи на http://customer-wiki.project/manual. Это ссылка на руководство, там много букв, но нужно прочитать. Если что-то не понятно - спрашивай.
Проходит 10 мин.
- Прочитал, кажется у меня аккаунт заблокирован (это значило, что нужно было в лепешку расшибиться для того, чтобы его разблокировали).
- Звони в саппорт (согласно руководству) и объясняй им суть проблемы. Говори, что аккаунт заблокирован, и проси разблокировать (процедура ужасная, на самом деле, в любой момент может что-то пойти не так).
- А на каком языке там нужно общаться?
- На английском.
- У меня плохо с разговорным английским.
- ?!
То есть мне нужно было звонить сейчас в саппорт, слушать «одинокую песню пастуха» 20 мин для того, чтобы сказать что я “Vasya Pupkin”, “unlock my f**cking account please” в то время как у меня своих задач полно?!
С п о к о й н о. вдох… выдох… Может мне его послать к чертовой матери, пусть ищет кого-то, кто знает английский или учит сам в боевых условиях?! Но ведь я добрый человек… Да и коллега не виноват в том, что заказчик - ЭТО ДОЛБАНЫЙ БАНК и они блокируют аккаунты когда им заблагорассудится. Он всего лишь виноват в том, что знание английского хромает… А программист он хороший (вон, даже scite использует, который я тоже люблю). Ладно, я могу это сделать. Всего один раз. Мне нужно понравиться коллегам, он будет помнить, что я ему помог (хотя он, гад, может сказать, что я помогаю всем с разблокировкой аккаунтов, а это будет очень плохо). Ну что ж, будем надеяться, что это хотя бы не затянется на 20 мин.
Звоним. Слушаем обычную корпоративную чушь о том, что звонок очень важен для них, а также кучу сопутствующей «важной» инфы об изменениях в политике безопасности.
- Hello, my name is Linda. How can I help you?
- Hi. My corporate account is locked. Could you please unlock it?
- Could you please spell your first and last name, sir?
- Sure. V A S Y A. That’s the first name. And the last name is P U P K I N.
- Let me check…
- Your account is locked and I cannot unlock it.
- Sorry?
- Your account is in the state which I’m not capable to change.
- How comes you cannot change the account state? I had similar situation before and only thing I should have done is calling support and saying “unlock my account”.
- Record says that you’re no longer a corporate employee.
(?????!!!!!!!!!)
- But the thing is that I work for a contractor company. I always had an account and suddenly it turns out that I’m fired? What should I do then?
- Contact your VP and request creating new account for you.
- Is there any other way?
- No, sir.
- Ok, thanks. I’ll contact my VP.
- Always glad to help! Have a nice day! Bye.
- Bye.
Это, пожалуй, худшее, что могло произойти. Теперь нужно связываться с вице-президентом (он же и заказчик) и заказывать у него новый аккаунт для сотрудника. Вкратце объясняю суть разговора коллеге (он с трудом понимал, о чем идет речь) и расстраиваю тем, что в ближайшие 3 (как минимум) недели доступа к корпоративному инстант-мессенджеру не будет.
Мануал http://customer-wiki.project/manual, в котором описаны все подводные камни работы с разными видами аккаунтов писал я сам С НУЛЯ методом проб и ошибок (похожие мануалы уже существовали, но они многих важных вещей не затрагивали). Таки оказалось что это, черт побери, моя обязанность (менеджер настоял на том, чтобы этим занимался именно я) - ходить и настраивать почту (для тех, кто знает, что такое Lotus Notes, мне посочувствуют), инстант-мессенджеры, проверять, не заблокированы ли аккаунты и помогать, если вдруг пользователи делают что-то не так! Причем типов разных аккаунтов только на стороне заказчика насчитывалось (внимание) целых 8 штук! Для работы/блокировки/разблокировки каждого была предусмотрена отдельная процедура. А заблокирован аккаунт мог быть в любой момент по совершенно непонятным причинам. Чаще всего нужно было звонить в саппорт на стороне заказчика и выяснять с ними отношения. Но иногда всё было не так просто, иногда нужно было использовать change management систему (о боги!). Самое ужасное, что после объединения проектов в один "аккаунт" (senior configuration manager должен был поддерживать несколько проектов одновременно), у меня оказалось под опекой ~50 сотрудников. У каждого по 8 аккаунтов (иногда меньше, но это отнюдь не упрощало жизнь), нужно было вести актуальный статус каждого аккаунта (знать хотя бы, работает или не работает). 50 умножить на 8 равно... 400 (!). Это количество аккаунтов, за статусами которых нужно было следить. НО! некоторые аккаунты могли иметь несколько статусов, не только заблокирован/разблокирован но и что-то типа "в процессе" или "удален" как в описанном мной эпичном случае общения с представителями саппорта.
Не кажется ли вам, что для таких задач должен был быть выделен отдельный человек? Хм... Я тоже думаю, что это довольно большой объем работы. А вот менеджер так не считал. Он считал, что если написать мануал, то все сами начнут автоматически во всем разбираться. Я тоже по своей наивности и добродушию допустил такую мысль и в последствии был удивлен, как плавно от задач настройки continuous integration серверов и настройки инфраструктуры я переключился на написание пользовательских мануалов для поддержки пользователей тратя на это громадную кучу времени.
При всей моей дотошности и приверженности доступному изложению (чтобы уборщица могла при желании решить возникший вопрос), мануал вышел настолько громоздким и запутанным, что людям приходилось все равно ко мне обращаться, так как подводных камней было масса. В попытке обеспечить функционирование всех аккаунтов, случай каждого пользователя так или иначе становился уникальным и описать каждый такой уникальный случай в мануале было практически невозможно.
Вот примерный список того, чем мне, как оказалось, нужно было заниматься:
Что уж говорить, команде толком представлен я не был. Область моей ответственности, как уже стало понятно, была размыта. Прямо как в анекдоте «отсюда и до обеда». Работать приходилось с 10-00 и до 22-00. Я всегда себе говорил, что уйду вовремя (здоровее и счастливее я от овертаймов не стану). Но иногда, черт побери, от моей работы зависела работа всей команды! Я ведь не могу тупо свалить, если нужно тестировать релиз, который по каким-то причинам (в том числе, возможно, конфигурационным) не работает на целевой платформе? И овертаймить приходилось постоянно, так как некому было больше заниматься некоторыми важными вещами. В силу каких-то нелепых обстоятельств, оказывалось, что лучше всех определенный вид задач могу выполнять только я. Ради справедливости стоит отметить, что овертаймы иногда (когда были согласованы с заказчиками) оплачивались.
А еще, помимо всего прочего, накладывалась инертность мышления коллег, дескать, бывший конфигурейшн менеджер нам это всё настраивал! Общее понимание того, чем должен на самом деле заниматься конфигурейшн менеджер напрочь отсутствовало. Я, между прочим, планировал, что смогу организовать тренинги для того, чтобы изложить свое видение конфигурейшн-менеджмента. Также у меня был другой выбор - объяснять всем и каждому то, чем я считаю я должен заниматься (предварительно согласовав и обсудив это с менеджером для того чтобы не возникало путаницы). Но как раз в этом пункте мы с менеджером разошлись, особенно в части change management и user support (я считал, что нужен отдельный человек, который бы этим занимался). До момента, пока эти вопросы решены не были, мне казалось что людей как будто с улицы набрали и посадили за компьютер (хотя это, конечно же, было не так; важен был каждый, каждый выполнял свою часть работы и я это прекрасно понимал). Так или иначе, всё походило на «Дилбертовскую реальность». Никогда не думал, что я с ней столкнусь непосредственно в жизни, надеялся на то, что это всё бывает только в комиксах.
Кстати, выяснилось, что моего предшественника так же, как и проджект-менеджера уволили. Причем это случайно всплыло в переписке, в которой я стоял в копии. Еще потом оказалось, что до меня на проекте работало 3 (!) других конфигурейшн-менеджера. Никто долго не выдерживал. Еще потом выяснилось, что конфигурейшн-менеджер со смежного проекта, который меня собеседовал, ушел работать в ЕПАМ (Barclays) на должность релиз-инженера после того, как я проработал в Люксофте около 3-х недель! Я был, мягко говоря, обескуражен. Ведь я искал подобные возможности внутри ЕПАМ когда собирался уходить и никаких подобных встречных предложений мне не делали. Это еще один факт, свидетельствующий о том, что рекрутерам не выгодно брать людей на новые позиции внутри компании. Следствий из этого безобидного факта на самом деле чуть больше, но я пока что не хочу углубляться в детальный анализ. И так есть над чем поразмыслить, не правда ли?
В итоге, все мои ожидания касательно долгожданной желанной работы конфигурейшн-менеджером свелись все к тому, что я выполнял функции администратора проекта с эпизодическими функциями релиз-менеджера. Еще на меня повесили задачи, которыми должны были заниматься отдельные люди на стороне заказчика касательно предоставления прав доступа к ресурсам.
Налицо был мисменеджмент (mismanagement) во всех проявлениях (как со стороны Люксофта, так и со стороны заказчика). О типичных ошибках известных уже 30 лет (нарушении закона Брукса) в виде классического труда «Мифический человеко-месяц» я и вспоминать не хочу (ведь книги - это для задротов). Что уж говорить, о гибких методологиях речи не шло, только пучеглазый waterfall с изменениями требований чуть ли не во время каждого ежедневного статус-колла с бизнес-аналитиками, находящимися onsite. Но дело было как будто даже не в методологиях. Что-то в корне было не так. Казалось что всё остальное, за чем мне приходилось наблюдать - лишь проявления каких-то более глубоких проблем, о которых я не знал и не мог знать.
Зачем вообще Люксофт берется за такие проекты?! Неужели менеджмент не в силах просчитать риски и определить неэффективность реализации тех или иных проектов? Это, вероятно как раз тот случай, когда бабло побеждает зло. Всё стало ясно, когда прошел слух о том, сколько получает рядовой VP (vice president, вице-президент) при успешном деливери (delivery - сдача проекта) в конце года. На смежном проекте (более успешном чем наш) VP (собственно, заказчик) имел неосторожность обмолвиться, дескать, если вы вдруг зафакапите проект, то мне придется отдать обратно в автосалон свой Ferrari, за который я уже внес залог.
Работа в Люксофт - это был кошмар. Нет. Это был АД! Я ненавидел эту работу. До ручки меня довела внутренняя change management система, написанная индусами (с кучей багов), которая ужасно тормозила. Самая большая печаль заключалась в том, что только посредством этой change management системы должны были выполняться некоторые банальные рутинные mission critical задачи, от которых зависит работа всей команды, в частности выделение production-ресурсов. Я вскипел, когда из-за бага в этой системе важные изменения касательно production базы данных не были реализованы вовремя (я бился над этим 2 или 3 недели) и написал письмо об увольнении. К тому времени испытательный срок я почему-то автоматически прошел. Всегда удивлялся практике компаний устанавливать время испытательного срока, а потом не выполнять никаких формальных действий (банального разговора с менеджером или HR) касательно его окончания. Вероятно, это тоже как-то связано с рекрутерскими бонусами.
Уволиться после испытательного срока я не мог, так как начальник был в отпуске. Пришлось терпеть 3 недели, потом еще 2 недели искать замену, проводить собеседования, смотря людям в глаза и с горьким сожалением представлять, что их ждет, если вдруг они пройдут собеседование успешно. Но извне человека так и не взяли. Замена мне нашлась внутри компании - коллега, с которым мы непосредственно работали, решая бюрократические вопросы с заказчиком.
Однажды программ-менеджер как-то обмолвился касательно коллеги проджект-менеджера, дескать, тот зафакапил проект. У меня сразу же возник вопрос. Как можно о коллеге (пускай и потерпевшем неудачу) так отзываться? Кто вправе решать, чья вина лежит на провале проекта? Ведь сегодня потерпел неудачу он, завтра - ты! В любом случае, нужно проводить детальный анализ в случае неудачи (postmortem) с целью недопущения подобных ошибок в будущем. Мой вопрос касательно этого тонкого этического момента в работе проджект-менеджера на pm.stackexchange.com стал своего рода «хитом». Несмотря на откровенную лажу, которую часто порол программ-менеджер (несколько некорректное общение с подчиненными, навязывание решений, авторитаризм), работе он отдавался полностью (очень много работал), возможно, просто концентрируясь не в нужном направлении (не имея фокуса) и не в достаточной мере отстаивая позиции Люксофт перед заказчиком, который и был, по моему скромному мнению, причиной бедственного положения проекта. Кстати, он (заказчик), вскоре устранился (или его устранили) от руководства проектом, поставив во главе вице-президента индуса. Какого либо «покращення» в связи с этим я, увы, уже не застал. Как я ни старался, ни лидерства (doing right things), ни менеджмента (doing things right), работая в Люксофте (про всю компанию я ни в коем случае не сужу) я не увидел. Кроме того, быть лидером (вдохновлять своими идеями) и менеджером (внедрять лучшие практики конфигурационного управления) у меня также не получилось, слишком уж велика была пропасть. Ну что ж, не судьба.
Ради справедливости стоит отметить, что некоторые вещи в Люксофт мне нравились:
Учавствуя в проекте и просто работая в Люксофте, я познакомился со многими замечательными людьми. С некоторыми мы до сих пор общаемся. Хоть это был горький, но опыт. По прошествии времени я теперь еще больше осознаю, чего мне не хватает как лидеру, просто как человеку, каковы мои личностные, психологические и профессиональные ограничения, над чем мне все еще нужно упорно работать. Также я еще больше осознаю свои ценности. Ну и самое главное состоит в том, что я утвердился в хранении верности выбранному профессиональному пути, насколько сложным и тернистым бы он ни был.
Какие выводы делаю для себя я, основываясь на горьком опыте работы в Люксофт:
Я очень долго хотел попасть на полноценную должность конфигурейшн-менеджера для того, реализовывать на практике свои идеи, набраться больше практического опыта. Тренинги - это, конечно же, хорошо, но теория без практики мертва. Поэтому я был очень рад своей новой позиции в одной из компаний (лидеров отрасли) в сравнительно большом проекте, использующем смесь интересных технологий. Наличие большого количества людей, занятых в проекте автоматически означало, что configuration manager - это не просто роль, а полноценная позиция. И это то, что мне было нужно. Я решил закрыть глаза на то, что заказчик - крупный инвестиционный банк (сама предметная область мне не очень по душе), ведь мне должны были платить хорошие (как мне на то время казалось) деньги.
Но первые дни работы в Люксофт заставили меня кое о чем задуматься. К примеру, на следующий день после моего прихода (1 апреля) в проектную рассылку от QA-лида поступило сообщение о том, что наш проджект-менеджер больше с нами не работает, а отправляется в ротацию (для тех, кто не курсе, ротация - это «запас», «бенч», поиск других вакансий внутри компании) и ему планируют вскоре найти замену. Всеми это было воспринято как первоапрельская шутка. Посмеялись и утихли. Но не до шуток было, когда рабочее место проджект-менеджера на следующий день опустело, а его чашка с логотипом компании оказалась в мусорнике (по-моему, кроме меня в мусорнике чашку никто не видел - мое рабочее место находилось в непосредственной близости). Меня это повергло, мягко говоря, в шок. Потом уже я начал потихоньку вспоминать, что перед уходом проджект-менеджера все его документы прошли старательную обработку шредерами, а он, рассказывая мне о проекте и моих обязанностях, вел себя несколько странно. Факт такого внезапного увольнения свидетельствовал о том, что какие-то явные перекосы где-то были. Сложно было понять, где именно - со стороны уволенного подчиненного или со стороны вышестоящего руководства проекта. Это мне и предстояло выяснить во время испытательного срока.
В итоге, с первого дня работы я был немного озадачен и занял оценивающую позицию:
- Следил за тем, чтобы конфигурейшн-менеджер, который работал до меня, передал мне все свои дела и рассказал обо всех тонкостях проекта. Все детали я старательно конспектировал в виде ментальной карты (mindmap). Трансфер знаний он выполнял крайне неохотно (нужно было постоянно допытываться о конкретных вещах), почитывая одним глазом новости на «украинской правде». Не могу сказать, что дела были в ужаснейшем состоянии, но довольно таки запущенном. Тем не менее, четкая картина архитектуры системы и моих областей ответственности после двух недель у меня уже была (как мне казалось).
- Следил за поведением менеджмента, которое тоже, мягко говоря, настораживало. В частности, работая всего неделю и занимаясь своей непосредственной на тот момент задачей (структурированием знаний о проекте и его архитектуре), я как-то неожиданно для самого себя попал под раздачу программ-менеджера. Дескать, я «сопли жую» вместо того, чтобы выпытывать у моего коллеги «как всё устроено и работает». Ведь через неделю его не будет, и я останусь наедине с оравой разработчиков, тестировщиков и бизнес-аналитиков! Посыл мне был понятен и, в целом, мотивировал к более активным действиям с моей стороны, но меня насторожил тон общения. Непонятно было к каким именно действиям меня побуждал начальник - я и так делал всё что мог на данном этапе и всегда мог предоставить результаты работы, если это было нужно. Кроме того, сложившаяся на предыдущем месте привычка вести дневник запланированных и выполненных задач в формате onenote (можно отправить начальству письмо со статусом работ в любой момент «дня и ночи») я принес с собой на новое место. Волей неволей вспомнались дилбертовские комиксы:
Мог ли мой менеджер сделать декомпозицию глобальной задачи, выделить приоритеты и заставить команду работать слаженно “doing things right”? У меня были по этому поводу сомнения. - Следил за поведением заказчика, которое тоже настораживало. Это был человек всецело “in charge”. Ему нужен был контроль над всем и всеми. Складывалось ощущение, что доверять ему нельзя (и он в свою очередь никому не доверяет) и конструктивный диалог «на равных» с ним невозможен в принципе. Многие вещи обсуждению (несмотря на внешние признаки диалога) не подлежали - нужно было только выполнять. С другой стороны, это был умнейший человек, имеющий за плечами многие годы опыта в сфере и знанием многих подводных камней, связанных с работой в отрасли. Также мне было не столь приятно общаться с ним из-за производимого впечатления «ложного лидера» (false leader) или псевдо-лидера, рассказывающего о каких-то банальных вещах, но совсем не веря в них. Он был не лидером (или не вполне лидером), поэтому казалось что приверженности к “doing the right thing” у него не было. Также он был похож на многих американцев, менеджеров среднего звена (но, стоит заметить, что это все-таки был россиянин, уехавший работать в штаты). Для него важны были результаты, неважно какой ценой - расшибитесь об стену, дайте «взятку», наобещайте золотых гор, делайте что угодно (всё это я, конечно, образно выражаюсь), но проект должен быть выполнен в срок. И это было, пожалуй, самой БОЛЬШОЙ проблемой. Потом уже я выяснил причины такого поведения, а также цели, которые обычно стоят перед вице-президентом банка. Я узнал об этих причинах примерно в то же время, когда собирался писать письмо об увольнении, и это послужило дополнительным стимулом к принятию решения. Но об этом чуть позже…
- Следил за мотивацией коллег. Она была на нуле. Все (или практически все) работали за деньги. У некоторых, впоследствии уволившихся, уровень мотивации, можно сказать, был отрицательный! Как такое может быть? Да очень просто! Люди перед увольнением сознательно коммиттили в репозиторий неудобоваримый код с кучей хардкода просто потому что по-другому выполнить поставленную задачу было невозможно. Если бы у меня просто не было мотивации, я бы, наверное, отказался коммитить какой либо код. Хотя, анализировать этику программиста, принимающего участие в уже практически мертвом проекте - это, наверное, все-таки, гиблое дело. Каждый член команды был важен, каждый выкладывался как мог (по-крайней мере я не видел чтобы кто-то откровенно забивал). Особенно много работали программ-менеджер и тим-лиды. Отдельно стоит отметить QA-лида, который, по моему мнению, проделывал огромную работу. Но складывалось такое ощущение, что задолго до меня что-то пошло в корне не так. И мне было непонятно что. И многим коллегам тоже было непонятно. В итоге многие искали «козлов отпущения», иногда находили их, иногда - нет. Иногда им оказывался я (иногда - аргументированно, но чаще всего - нет), очень часто им оказывался программ-менеджер (так же, иногда - аргументированно, часто - нет), иногда им оказывался кто-то другой. Да что говорить, даже я допускал эту ошибку. Я неожиданно для себя начинал считать, что программ-менеджер мог бы сделать больше (тогда как он и так очень много делал, зачастую у него просто были связаны руки), девелоперы могли бы быть поснисходительней и повнимательней, а заказчик мог бы решить все без исключения бюрократические вопросы на своей стороне одним мигом. Это был плохой знак. Я всегда считал, что можно хотя бы попытаться наладить конструктивный диалог. Но ведь я находился на испытательном сроке, и прежде чем начинать такой конструктивный диалог со своей стороны, я должен был дать себе ответ, хочу ли я продолжать работать. Затем последовал бы вопрос о том, возможен ли такой конструктивный диалог в принципе. Для меня ответы (в силу массы причин) на оба вопроса были «скорее нет, чем да».
- Следил за проактивностью. Не удивительно, но всё нужно было «на вчера». Релиз нужно было выкатить вчера вечером (хоть об стену убейся), а тестировщики должны уже утром писать репорты о найденных в релизе багах. В итоге по вечерам я засиживался для того, чтобы выкатить релиз (это было не такой уж тривиальной процедурой), а когда случались оплачиваемые овертаймы по выходным, то писал скрипты автоматизации деплойментов (развертывания релизов) для того, чтобы хоть как-то упростить себе жизнь и свести к минимуму человеческий фактор при деплойментах.
- Следил за областями ответственности. Они были настолько размыты, насколько это было возможно. Складывалось впечатление, что никто ни за что не отвечал, несмотря на громкие тайтлы и постоянные митинги (в которых я иногда участвовал). Потом я неожиданно для себя вспомнил, что описания вакансии и формальных требований к позиции при моем трудоустройтве не было. Я проходил собеседование, расписывал себя во всех мыслимых и немыслимых ярких красках, дескать, я - отличный configuration manager, а если будут проблемы - решим! Но перед глазами у меня списка обязанностей не было. Это был БОЛЬШОЙ ПРОСЧЕТ с моей стороны, а также свидетельство недобросовестности:
- менеджера
- рекрутера, которая меня нанимала на работу
- собеседующего
- Вел дела таким образом, как будто меня могут попытаться уволить в любой день, а мне нужно будет отбиваться фактами и весомыми аргументами (как будто я должен буду предстать перед судом):
- Я вел mindmap при трансфере знаний.
- Я вел статус выполненных/запланированных/стратегических задач в удобном (для себя и для других) формате onenote.
- Отдельно сохранял важные письма, в которых мне были поставлены «важные» задачи.
- Я распечатал свои любимые диаграммы потока разработки и повесил их у себя на рабочем месте для того, чтобы дать понять, что у меня есть личное видение и стратегические задачи - идеал, к которому я стремлюсь. А до этого идеала было ой как далеко, несмотря на то, что, казалось бы, все ресурсы мне были для этого предоставлены.
- Следил за восприятием того, чем должен заниматься configuration manager с точки зрения рядового участника проекта. Оказалось, что меня воспринимали как обычного системного администратора (как в The IT Crowd). Администрирование серверов и платформ входило в мои обязанности, это мне всегда было интересно, и я был очень даже не против задач организации и настройки инфраструктуры для разработчиков (настроить виртуализацию, continuous integration сервер, application-сервер, поднять базу и сконфигурировать, чтобы всё работало правильно, итд), но я должен был заниматься (мне поначалу было непонятно, все-таки должен или не должен) еще и поддержкой пользователей, а также решать проблемы ко мне вообще не относящиеся! Типичный диалог из жизни Configuration Manager в ODC (Offshore Development Center) некоего инвестиционного банка, иллюстрирующий отсутствие/размытость областей ответственности:
- Баз всего три, к какой приложение должно коннектиться, а к какой - нет?
- Не знаю, это твоя задача, ты ж конфигурейшн-менеджер.
- Я знаю, что это моя задача! Потому и спрашиваю о том, соединение с какой именно базой «отваливается»? Их у нас, как минимум 3 (причем я знаю, что всё настроено правильно или по-крайней мере мне было дано указание настроить работу таким образом).
- Сейчас выясню.
Проходит время.
- Я там тебе логи прислал, посмотри плз
- В логах ничего не понятно. Может это вообще не соединение с базой?
- (вместе анализируем логи) Ах да, это мы забыли прикрутить фичу БББ!
- ?!
Другой эпичный пример. Подходит коллега и говорит:
- Я не могу зайти в корпоративный instant messenger.
- А ты проверял, почта у тебя вообще работает? (аккаунт корпоративного instant messenger’а привязан к почтовому аккаунту)
- А как это сделать? (это на самом деле нормальный вопрос, просто не все пользуются почтой заказчика)
- Заходи на http://customer-wiki.project/manual. Это ссылка на руководство, там много букв, но нужно прочитать. Если что-то не понятно - спрашивай.
Проходит 10 мин.
- Прочитал, кажется у меня аккаунт заблокирован (это значило, что нужно было в лепешку расшибиться для того, чтобы его разблокировали).
- Звони в саппорт (согласно руководству) и объясняй им суть проблемы. Говори, что аккаунт заблокирован, и проси разблокировать (процедура ужасная, на самом деле, в любой момент может что-то пойти не так).
- А на каком языке там нужно общаться?
- На английском.
- У меня плохо с разговорным английским.
- ?!
То есть мне нужно было звонить сейчас в саппорт, слушать «одинокую песню пастуха» 20 мин для того, чтобы сказать что я “Vasya Pupkin”, “unlock my f**cking account please” в то время как у меня своих задач полно?!
С п о к о й н о. вдох… выдох… Может мне его послать к чертовой матери, пусть ищет кого-то, кто знает английский или учит сам в боевых условиях?! Но ведь я добрый человек… Да и коллега не виноват в том, что заказчик - ЭТО ДОЛБАНЫЙ БАНК и они блокируют аккаунты когда им заблагорассудится. Он всего лишь виноват в том, что знание английского хромает… А программист он хороший (вон, даже scite использует, который я тоже люблю). Ладно, я могу это сделать. Всего один раз. Мне нужно понравиться коллегам, он будет помнить, что я ему помог (хотя он, гад, может сказать, что я помогаю всем с разблокировкой аккаунтов, а это будет очень плохо). Ну что ж, будем надеяться, что это хотя бы не затянется на 20 мин.
Звоним. Слушаем обычную корпоративную чушь о том, что звонок очень важен для них, а также кучу сопутствующей «важной» инфы об изменениях в политике безопасности.
- Hello, my name is Linda. How can I help you?
- Hi. My corporate account is locked. Could you please unlock it?
- Could you please spell your first and last name, sir?
- Sure. V A S Y A. That’s the first name. And the last name is P U P K I N.
- Let me check…
- Your account is locked and I cannot unlock it.
- Sorry?
- Your account is in the state which I’m not capable to change.
- How comes you cannot change the account state? I had similar situation before and only thing I should have done is calling support and saying “unlock my account”.
- Record says that you’re no longer a corporate employee.
(?????!!!!!!!!!)
- But the thing is that I work for a contractor company. I always had an account and suddenly it turns out that I’m fired? What should I do then?
- Contact your VP and request creating new account for you.
- Is there any other way?
- No, sir.
- Ok, thanks. I’ll contact my VP.
- Always glad to help! Have a nice day! Bye.
- Bye.
Это, пожалуй, худшее, что могло произойти. Теперь нужно связываться с вице-президентом (он же и заказчик) и заказывать у него новый аккаунт для сотрудника. Вкратце объясняю суть разговора коллеге (он с трудом понимал, о чем идет речь) и расстраиваю тем, что в ближайшие 3 (как минимум) недели доступа к корпоративному инстант-мессенджеру не будет.
Мануал http://customer-wiki.project/manual, в котором описаны все подводные камни работы с разными видами аккаунтов писал я сам С НУЛЯ методом проб и ошибок (похожие мануалы уже существовали, но они многих важных вещей не затрагивали). Таки оказалось что это, черт побери, моя обязанность (менеджер настоял на том, чтобы этим занимался именно я) - ходить и настраивать почту (для тех, кто знает, что такое Lotus Notes, мне посочувствуют), инстант-мессенджеры, проверять, не заблокированы ли аккаунты и помогать, если вдруг пользователи делают что-то не так! Причем типов разных аккаунтов только на стороне заказчика насчитывалось (внимание) целых 8 штук! Для работы/блокировки/разблокировки каждого была предусмотрена отдельная процедура. А заблокирован аккаунт мог быть в любой момент по совершенно непонятным причинам. Чаще всего нужно было звонить в саппорт на стороне заказчика и выяснять с ними отношения. Но иногда всё было не так просто, иногда нужно было использовать change management систему (о боги!). Самое ужасное, что после объединения проектов в один "аккаунт" (senior configuration manager должен был поддерживать несколько проектов одновременно), у меня оказалось под опекой ~50 сотрудников. У каждого по 8 аккаунтов (иногда меньше, но это отнюдь не упрощало жизнь), нужно было вести актуальный статус каждого аккаунта (знать хотя бы, работает или не работает). 50 умножить на 8 равно... 400 (!). Это количество аккаунтов, за статусами которых нужно было следить. НО! некоторые аккаунты могли иметь несколько статусов, не только заблокирован/разблокирован но и что-то типа "в процессе" или "удален" как в описанном мной эпичном случае общения с представителями саппорта.
Не кажется ли вам, что для таких задач должен был быть выделен отдельный человек? Хм... Я тоже думаю, что это довольно большой объем работы. А вот менеджер так не считал. Он считал, что если написать мануал, то все сами начнут автоматически во всем разбираться. Я тоже по своей наивности и добродушию допустил такую мысль и в последствии был удивлен, как плавно от задач настройки continuous integration серверов и настройки инфраструктуры я переключился на написание пользовательских мануалов для поддержки пользователей тратя на это громадную кучу времени.
При всей моей дотошности и приверженности доступному изложению (чтобы уборщица могла при желании решить возникший вопрос), мануал вышел настолько громоздким и запутанным, что людям приходилось все равно ко мне обращаться, так как подводных камней было масса. В попытке обеспечить функционирование всех аккаунтов, случай каждого пользователя так или иначе становился уникальным и описать каждый такой уникальный случай в мануале было практически невозможно.
Вот примерный список того, чем мне, как оказалось, нужно было заниматься:
- Решать проблемы пользователей с аккаунтами. Также писать подробный мануал касательно попыток самостоятельного решения проблем с аккаунтами.
- Развертывать приложение на целевые платформы и правильно его конфигурировать на разных платформах.
- По возможности автоматизировать процесс развертывания.
- Держать актуальной информацию по поводу того, какие платформы как сконфигурированы (что куда «смотрит»). Более формально это называлось Configuration Identification.
- Выбивать из заказчика разрешения на открытие портов для доступа к разного рода ресурсам. Эта процедура выносила мозг похлеще всех остальных. Начал я этим заниматься, когда приступил к работе в апреле, но так за 4 месяца (до августа) и не закончил. Не потому что забивал. Наоборот, поднимал всех на уши! От этого зависела работа нескольких проектов! Просто никто ничего не мог сделать (я в том числе) ввиду тяжеловесности и бюрократичности процедуры. Я очень обрадовался, когда узнал, что сменивший на должности меня человек таки добился финального аппрува. Вложенные в это дело усилия не стоили того, чтобы ими заниматься. Печально, но приобретенные «тайные знания» не принесут пользу ни мне, ни кому-либо еще, кроме, может быть проектов, которые все таки имеют возможность использовать нужные ресурсы.
- Заниматься проектной инфраструктурой и ресурсами (application-серверами, базами данных, а также кучей других неведомых сервисов, которые наше приложение использовало) как локально, так и удаленно (на стороне заказчика). Причем управлять ресурсами на стороне заказчика было ОХ КАК СЛОЖНО. Для каждого телодвижения предусматривалась change management процедура (как потом выяснилось, это было реализовано согласно ITIL), для выполнения которой нужно было использовать change management систему полную багов, собирать кучу аппрувов и молить Бога чтобы изменения были реализованы вовремя и в согласии с требованиями. А если что-то пошло не так, то ответственных никогда не было, потому как изменения обычно реализовывали индусы. А они по определению никогда ни за что не ответственны!
Что уж говорить, команде толком представлен я не был. Область моей ответственности, как уже стало понятно, была размыта. Прямо как в анекдоте «отсюда и до обеда». Работать приходилось с 10-00 и до 22-00. Я всегда себе говорил, что уйду вовремя (здоровее и счастливее я от овертаймов не стану). Но иногда, черт побери, от моей работы зависела работа всей команды! Я ведь не могу тупо свалить, если нужно тестировать релиз, который по каким-то причинам (в том числе, возможно, конфигурационным) не работает на целевой платформе? И овертаймить приходилось постоянно, так как некому было больше заниматься некоторыми важными вещами. В силу каких-то нелепых обстоятельств, оказывалось, что лучше всех определенный вид задач могу выполнять только я. Ради справедливости стоит отметить, что овертаймы иногда (когда были согласованы с заказчиками) оплачивались.
А еще, помимо всего прочего, накладывалась инертность мышления коллег, дескать, бывший конфигурейшн менеджер нам это всё настраивал! Общее понимание того, чем должен на самом деле заниматься конфигурейшн менеджер напрочь отсутствовало. Я, между прочим, планировал, что смогу организовать тренинги для того, чтобы изложить свое видение конфигурейшн-менеджмента. Также у меня был другой выбор - объяснять всем и каждому то, чем я считаю я должен заниматься (предварительно согласовав и обсудив это с менеджером для того чтобы не возникало путаницы). Но как раз в этом пункте мы с менеджером разошлись, особенно в части change management и user support (я считал, что нужен отдельный человек, который бы этим занимался). До момента, пока эти вопросы решены не были, мне казалось что людей как будто с улицы набрали и посадили за компьютер (хотя это, конечно же, было не так; важен был каждый, каждый выполнял свою часть работы и я это прекрасно понимал). Так или иначе, всё походило на «Дилбертовскую реальность». Никогда не думал, что я с ней столкнусь непосредственно в жизни, надеялся на то, что это всё бывает только в комиксах.
Кстати, выяснилось, что моего предшественника так же, как и проджект-менеджера уволили. Причем это случайно всплыло в переписке, в которой я стоял в копии. Еще потом оказалось, что до меня на проекте работало 3 (!) других конфигурейшн-менеджера. Никто долго не выдерживал. Еще потом выяснилось, что конфигурейшн-менеджер со смежного проекта, который меня собеседовал, ушел работать в ЕПАМ (Barclays) на должность релиз-инженера после того, как я проработал в Люксофте около 3-х недель! Я был, мягко говоря, обескуражен. Ведь я искал подобные возможности внутри ЕПАМ когда собирался уходить и никаких подобных встречных предложений мне не делали. Это еще один факт, свидетельствующий о том, что рекрутерам не выгодно брать людей на новые позиции внутри компании. Следствий из этого безобидного факта на самом деле чуть больше, но я пока что не хочу углубляться в детальный анализ. И так есть над чем поразмыслить, не правда ли?
В итоге, все мои ожидания касательно долгожданной желанной работы конфигурейшн-менеджером свелись все к тому, что я выполнял функции администратора проекта с эпизодическими функциями релиз-менеджера. Еще на меня повесили задачи, которыми должны были заниматься отдельные люди на стороне заказчика касательно предоставления прав доступа к ресурсам.
Налицо был мисменеджмент (mismanagement) во всех проявлениях (как со стороны Люксофта, так и со стороны заказчика). О типичных ошибках известных уже 30 лет (нарушении закона Брукса) в виде классического труда «Мифический человеко-месяц» я и вспоминать не хочу (ведь книги - это для задротов). Что уж говорить, о гибких методологиях речи не шло, только пучеглазый waterfall с изменениями требований чуть ли не во время каждого ежедневного статус-колла с бизнес-аналитиками, находящимися onsite. Но дело было как будто даже не в методологиях. Что-то в корне было не так. Казалось что всё остальное, за чем мне приходилось наблюдать - лишь проявления каких-то более глубоких проблем, о которых я не знал и не мог знать.
Зачем вообще Люксофт берется за такие проекты?! Неужели менеджмент не в силах просчитать риски и определить неэффективность реализации тех или иных проектов? Это, вероятно как раз тот случай, когда бабло побеждает зло. Всё стало ясно, когда прошел слух о том, сколько получает рядовой VP (vice president, вице-президент) при успешном деливери (delivery - сдача проекта) в конце года. На смежном проекте (более успешном чем наш) VP (собственно, заказчик) имел неосторожность обмолвиться, дескать, если вы вдруг зафакапите проект, то мне придется отдать обратно в автосалон свой Ferrari, за который я уже внес залог.
Работа в Люксофт - это был кошмар. Нет. Это был АД! Я ненавидел эту работу. До ручки меня довела внутренняя change management система, написанная индусами (с кучей багов), которая ужасно тормозила. Самая большая печаль заключалась в том, что только посредством этой change management системы должны были выполняться некоторые банальные рутинные mission critical задачи, от которых зависит работа всей команды, в частности выделение production-ресурсов. Я вскипел, когда из-за бага в этой системе важные изменения касательно production базы данных не были реализованы вовремя (я бился над этим 2 или 3 недели) и написал письмо об увольнении. К тому времени испытательный срок я почему-то автоматически прошел. Всегда удивлялся практике компаний устанавливать время испытательного срока, а потом не выполнять никаких формальных действий (банального разговора с менеджером или HR) касательно его окончания. Вероятно, это тоже как-то связано с рекрутерскими бонусами.
Уволиться после испытательного срока я не мог, так как начальник был в отпуске. Пришлось терпеть 3 недели, потом еще 2 недели искать замену, проводить собеседования, смотря людям в глаза и с горьким сожалением представлять, что их ждет, если вдруг они пройдут собеседование успешно. Но извне человека так и не взяли. Замена мне нашлась внутри компании - коллега, с которым мы непосредственно работали, решая бюрократические вопросы с заказчиком.
Однажды программ-менеджер как-то обмолвился касательно коллеги проджект-менеджера, дескать, тот зафакапил проект. У меня сразу же возник вопрос. Как можно о коллеге (пускай и потерпевшем неудачу) так отзываться? Кто вправе решать, чья вина лежит на провале проекта? Ведь сегодня потерпел неудачу он, завтра - ты! В любом случае, нужно проводить детальный анализ в случае неудачи (postmortem) с целью недопущения подобных ошибок в будущем. Мой вопрос касательно этого тонкого этического момента в работе проджект-менеджера на pm.stackexchange.com стал своего рода «хитом». Несмотря на откровенную лажу, которую часто порол программ-менеджер (несколько некорректное общение с подчиненными, навязывание решений, авторитаризм), работе он отдавался полностью (очень много работал), возможно, просто концентрируясь не в нужном направлении (не имея фокуса) и не в достаточной мере отстаивая позиции Люксофт перед заказчиком, который и был, по моему скромному мнению, причиной бедственного положения проекта. Кстати, он (заказчик), вскоре устранился (или его устранили) от руководства проектом, поставив во главе вице-президента индуса. Какого либо «покращення» в связи с этим я, увы, уже не застал. Как я ни старался, ни лидерства (doing right things), ни менеджмента (doing things right), работая в Люксофте (про всю компанию я ни в коем случае не сужу) я не увидел. Кроме того, быть лидером (вдохновлять своими идеями) и менеджером (внедрять лучшие практики конфигурационного управления) у меня также не получилось, слишком уж велика была пропасть. Ну что ж, не судьба.
Ради справедливости стоит отметить, что некоторые вещи в Люксофт мне нравились:
- Парковка и, в частности, мое личное платное место на парковке. Правда, оплачивал его я сам. В отличии от бесплатной, мест на платной парковке всегда было предостаточно. Про бесплатную парковку сотрудники шутили: «Кто рано встает, тому Бог место на парковке дает!».
- Работа отдела СПД. Всегда девушки все платежи оплачивали сами, лишний раз не отрывали от работы и подробно консультировали, если это было нужно.
- Вводные тренинги. Позитивен уже тот факт, что они проводились (конечно же, намного хуже, поверхностней и менее интерактивней чем проводил их я в ЕПАМ ;). Еще более позитивный факт касательно вводных тренингов заключался в том, что одну из сессий (включающую знакомство с сотрудниками) проводил лично Дмитрий Кушнир - директор «Люксофт Украина».
- Тренинговый центр, в котором работали не два человека (как в ЕПАМ до моего ухода) а 6 (или больше) с четким распределением областей ответственности.
- Корпоративная газета, которая выходила по пятницам и в которой можно было найти информацию об основных новостях/изменениях в компании. Газета была разделена на несколько рубрик, одной из которой был раздел интервью с коллегами. Непосредственно перед увольнением я также осмелился дать интервью корпоративной газете. На мой взгляд (редактор тоже это признавала), получилось достаточно неплохо.
- До окончания испытательного срока начальник отправил меня на тренинг “Эффективная письменная коммуникация” формально ссылаясь на то, что нужно «правильней» составлять письма (по сути, я мог подготовить и провести хоть 10 таких тренингов, если было нужно). Но на самом деле, подозреваю, он хотел, чтобы я немного отвлекся от проектных задач, которые мне просто выносили мозг. И это было приятно.
- Компенсация. Я был недоволен практически всем, кроме зарплаты, которая приходила всегда вовремя. Никаких задолженностей у компании передо мной не осталось. Если кто-то задаст вопрос, стоили ли деньги вложенных усилий и нервов, отвечу что нет, не стоили. Я бы лучше прочитал «Процесс» Франца Кафки. Хотя, если я прочитаю эту книгу сейчас, есть чувство того, что буквально каждая прочтенная строчка будет вызывать у меня ощущения, близкие к дежавю.
Учавствуя в проекте и просто работая в Люксофте, я познакомился со многими замечательными людьми. С некоторыми мы до сих пор общаемся. Хоть это был горький, но опыт. По прошествии времени я теперь еще больше осознаю, чего мне не хватает как лидеру, просто как человеку, каковы мои личностные, психологические и профессиональные ограничения, над чем мне все еще нужно упорно работать. Также я еще больше осознаю свои ценности. Ну и самое главное состоит в том, что я утвердился в хранении верности выбранному профессиональному пути, насколько сложным и тернистым бы он ни был.
Какие выводы делаю для себя я, основываясь на горьком опыте работы в Люксофт:
- Работать в банке или с банком в виде заказчика (сколько бы это денег не приносило) я НЕ БУДУ.
- Всегда буду обращать внимание на описание позиции и ее наличие :)
- По возможности буду знакомиться со всей командой и заказчиком.
- Обращать внимание на используемую методологию разработки.
- Буду оставлять за собой право уйти из компании в любой момент.
- Буду более тщательно консультироваться с инсайдерами касательно проекта и менеджмента.