Работа в Paragon Software: unexpected end of story

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

Начни я писать подобный анализ чуть раньше, был высокий риск сорваться на типовую историю в жанре «тут все дураки, один я непонятый Д’Артаньян».

Нет, определённо в компании достаточно не просто умных, а очень умных людей, неплохо выстроены некоторые процессы, которые и в более известных компаниях только учатся строить (например, Continuous Integration). Есть и ряд «человекоориентированных» бонусов, в т.ч. уникальных — кофемашины, гибкий график работы, возможность удалёнки, пять «бесплатных» отгулов в год. И Scrum.

В общем, выглядит всё достаточно гибко и инновационно.

 

Первое, с чем довелось столкнуться — декларируемый компанией Scrum на Scrum похож разве что очень отдалённо. В принципе, меня ещё при приёме озадачило, что моя планируемая роль — менеджер релизов — в концепцию Scrum никак не вписывается. Но на момент трудоустройства про данную гибкую методологию управления разработкой я знал только в теории, а теория (особенно в вопросах управления) нередко расходится с реальностью. И именно практики мне хотелось. Тем более раз уж всё таки менеджер — значит смогу влиять на процесс. Думал я.

Scrum, который не Scrum

Итак, о расхождениях. Для начала, Scrum, как и прочие гибкие методологии делает упор на самоорганизации команд и людей. Типа собрать профессионалов и не мешать им работать, периодически лишь поправляя курс в нужную сторону. Различные определённые в Scrum, XP, Crystal Clear или даже Kanban церемонии, ритуалы, инструменты и приёмы — лишь методологически описанные способы сформировать процесс самоорганизации и поправки курса.

Scrum предполагает всего три роли:

1. Scrum Master — человек, который знает, что и зачем в Scrum и помогает команде настроить процесс, глядя на него со стороны.
2. Product Owner — человек, который знает, что нужно бизнесу от разрабатываемого командой продукта и определяет приоритеты и курс развития.
3. Development Team — автономная команда, которая обладает всеми необходимыми возможностями для достижения цели (навыки, умения, технические средства). Автономная — это ключевое слово, все задачи по развитию продукта команда должна решать сама. Если кто-то привлекается извне — то с целью перенять опыт (особенно если процедура регулярная).

Отдельно стоит упомянуть о команде два требования:

1. Все члены команды считаются разработчиками (никакого деления на тестеров, саппорт и программистов). Не потому что все делают всё, а потому что все делают, что могут, неся общую ответственность за результат. Избегание ситуации перекидывания мячика, когда «мы свою часть сделали, это тестеры тормозят».
2. Команда не должна быть меньше 3 и больше 9 человек.

 

Scrum также определяет 5 time-boxed  events (ограниченных по времени события):

1. Sprint — период от 1 до 4 недель в течение которого делается определённый объём работы, и в конце которого должен получиться работоспособный кусок продукта.
2. Planning — в начале спринта планируем объём работы на спринт.
3. Scrum (daily, standby) meeting — ежедневная 15-минутная встреча для синхронизации работы членов команды. Требует только членов команды (dev team). Обычно включает три вопроса: «Что было сделано вчера? Что планируется сделать сегодня? Есть ли препятствия?»
4. Review — в конце спринта показываем, что сделали владельцу продукта и заказчикам и получаем фидбек (туда ли копаем вообще, обсуждаем новые идеи).
5. Retrospective — в конце спринта анализируем, что сделали хорошо, и это стоит запомнить, что вышло не очень хорошо, и как этого можно избежать впредь, а также, что можно улучшить в рабочем процессе. По итогам ретро вносится 1-2 задачи по улучшению процесса в следующий спринт.

 

Реальность в компании такова, что команды не имеют стабильного состава, её члены жёстко делятся по функционалу (программисты, тестеры, автоматизаторы, DevOps и CI-инженеры (это разделение и именование вообще сломало мой мозг) и аналитики). Команда зачастую не включает все нужные ей роли, так что даже для регулярных задач приходится привлекать «варягов». «Варяги», как правило, круты, как специалисты, но перегружены из-за участия в нескольких параллельных проектах, не видят картины конкретного проекта в целом и не особенно ответственны за дальнейший результат («мы сделали, что описано в заявке»), а продукт их труда — автотест, кусок кода или конфиг в системе сборки — становится чёрным ящиком, поддерживаемым с помощью молитв и бубна.

Scrum-ивенты формально выполняются, но…

• Спринтов нет. Вместо них есть релизные циклы, непредсказуемой длительности с промежутками между ними, в которые доделывается часть работы.
• Дэйли митинги есть. Но их цель не синхронизация. Потому что коллегам, как правило, всё равно, чем ты занимаешься, да и не понятно. В проектных командах — из-за функционального разделения, а также потому что задачи назначаются менеджментом и имеют заранее определенного исполнителя. В функциональных командах (есть и такие) — потому что задачи обычно из разных проектов и просто непонятны. В итоге встреча сводится к тому чтобы убедить менеджера, что ты «не занимался хернёй вчера и не планируешь сегодня».
• Ревью почему-то проводится не для заказчика, а для команды. Зачем команда час-другой смотрит результаты того, что она месяц делала — неясно. Никакого фидбэка нет, идей тоже.
• Ретро проводится редко. По простой причине. Обычно задаётся только один вопрос: «Какие у нас проблемы?». Команда в ответ изливает стену плача. Проблемы в лучшем случае фиксируются, но по ним непонятно, что делать. Ничего чаще всего и не делается. В итоге менеджмент избегает ретро чтобы избегать негатива, а команда привыкает, что жаловаться бессмысленно.

Выученная беспомощность — отдельная песня. Долгое время я не мог понять, чем вызвано исходящее от коллег настроение безысходности и равнодушия к проблемам рабочего процесса.

В общем, Scrum в Paragon хорошо описывается определением

неукоснительное, но чисто внешнее, формальное или даже показное исполнение каких-либо религиозных либо социальных нравственных правил

DevOps, который не DevOps

Что такое DevOps? Почему, спустя столько лет, даже в гибких и современных компаниях «внедрить DevOps» предполагает «переименовать часть сисадминов в DevOps-инженеров»?

Что, мать твою, такое DevOps-инженер? Человек, который умеет всё?

DevOps — это подход, который охватывает всю область ИТ компании, достаточно крупной, чтобы включать в эту область и разработку и поддержку.

Грубо говоря, DevOps — это то же, что частично включено в Agile, то есть культура плотного взаимодействия разработки и эксплуатации (Development and Operations), только если второй подход развивался со стороны разработки и её управленцев, то первый — со стороны эксплуатации и поддержки всего того, что наразрабатывали. Кто-нибудь слышал про Agile-инженеров? А вот DevOps есть.

Лучшее всеобъемлющее, но краткое описание подхода DevOps я нашёл на нижеприведённой картинке.

Что из этого можно увидеть в компании Paragon? Где-то около половины того, что в жёлтом контуре. И DevOps-инженеров. При этом эти самые инженеры не отвечают за Continuous Integration. Это к специальным CI-инженерам вам надо. Также они, конечно, не отвечают за  Continous Testing. Это к QA и Автоматизаторам. Ну и к CI опять же, чтобы интегрировать тесты в сборочный процесс. В чём же уникальная роль DevOps-инженеров компании Paragon, отличающая их от сисадминов? Вот и для меня осталось загадкой.

А вообще,  DevOps это не только и не столько про инструменты и технологии, сколько про культуру и коммуникации. Технологии и инструменты приложатся.

Анализ и изменение

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

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

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

Для начала пришлось ещё тщательнее изучить Scrum, Agile, DevOps, CI, CD и прочие скрываемые за модными словами процессы стабилизации и ускорения производственных циклов. Чтобы перевести интуитивный дискомфорт «какую-то хрень мы делаем» в ясное понимание, как и что можно улучшить. Потом влиять на людей (influence without formal authority) чтобы в нужную сторону менять убеждения, подходы и привычные действия.

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

Определил проблемную ситуацию я следующим образом.

Симптомы:

• У людей недостаточно навыков и знаний для решения повседневных задач и возникающих проблем. И они не обретают эти навыки и знания.
• Менеджмент, пытаясь достичь результатов, привлекает новых людей к проекту для выполнения определённых задач, перемещая их между командами или вовлекая в несколько проектов параллельно.
• Команда демонстрирует отсутствие инициативы, низкую вовлечённость и интерес.
• А также избегает ответственности и принятия решений.
• Огромное количество времени тратится в очередях ждущих задач (идеи и решения, ожидающие утверждения; тикеты в эксплуатацию; тестеры, ждущие критичных фиксов, блокирующих процесс тестирования; разработчики ждут проверки фиксов, чтобы замёрджить изменения и т.д.).

 

Проблема:

Всё вышеописанное приводит к непредвиденным задержкам и низкому качеству выпускаемых релизов.

Анализ:

Под впечатлением Теории Ограничений Голдтратта, оформил анализ в виде дерева текущей реальности. Получилось развесисто, поэтому кому интересно, могут посмотреть по ссылке, а тут приведу основные тезисы.

• Ограничение в рамках узкой специализации ведёт к тому, что для того чтобы покрыть все потребности команды в скилах, надо либо слишком много людей (ручные тестеры, автотестеры, CI, разработчики, инженеры эксплуатации, аналитики), что избыточно, либо часть областей в команде остаётся непокрытыми. В итоге для решения задач из этих областей постоянно привлекаются исполнители со стороны. Люди воспринимаются как взаимозаменяемые ресурсы, перемещаемые между командами по необходимости.
• Нестабильные команды затрудняют коммуникации (к новым людям надо приспосабливаться), переключение контекста приводит к задержкам. Кроме того, постоянное изменение состава команды приводит к тому, что она не накапливает знание, в том числе то, которое относится к взаимодействию (от кого и чего можно ожидать — transactive memory). Люди меньше общаются — люди меньше развиваются.
• Опять же нет смысла сильно вникать в проект, если ты готов к тому, что тебя в любое время перепнут в другую команду.
• С другой стороны, ротация людей между командами приводит к тому, что полную картину видит разве что менеджер, и он вынужден принимать решения преимущественно централизованно. А команда уже только выполняет максимально конкретные задачи (по SMART, все дела).
• Однако работа в режиме исполнителя ограничивает креативность, навык самостоятельного мышления и инициативность. В такой области, как разработка ПО это особенно не вдохновляюще. Более того, такой централизованный подход приводит к тому, что менеджмент «забывает» делиться с командой информацией о, например, перспективах проекта или замечаниях к последнему релизу, так что и без того «со слабой памятью» команда вообще теряет какое-то цельное и общее видение.
• Низкая вовлечённость, скучные задачи, отсутствие понимания целого, нестабильность, фрагментарное и ограниченное развитие в рамках узкой специализации ведут к ошибкам и задержкам в работе. Что в свою очередь вызывает гнев менеджмента, публичные порки и закручивание гаек, что опять же не добавляет морали и инициативности.
• Другая петля — кучи потраченного в тикетах и очередях времени уменьшают продуктивное время плановой работы, что даёт в результате низкое качество, тушение пожаров опять отнимает время и.. «нет времени автоматизировать, делаем вручную». Изучать что-то новое тоже нет времени.

 

План действий по разрешению ситуации довольно прост — а давайте попробуем, всё таки, сделать то, что предлагает настоящий Scrum не в части инструментов, а в части принципов. Хотя бы для одного проекта. Чисто посмотреть.

• Зафиксируем состав команды.
• Введём культуру развития новых навыков и вообще изучения смежных областей.
• Децентрализуем принятие решений с менеджера на команду.

 

Это было проверено на команде моего проекта. И это работает. По итогам:

• удалось стабилизировать команду с бесформенной динамической сущности «от 10 до 16 человек» до стабильных 7 (хотя я понимаю, что именно тут не столько моя заслуга, сколько тот факт, что в середине прошлого года высшее руководство решило забить на проект и оттянуло от него все ресурсы);
• при этом с момента стабилизации продуктивность команды выросла, как и качество продукта;
• избавились от большей части человеческого фактора, автоматизировав большую часть процессов деплоя. Развёртывание продукта, внесение изменений в конфиги стало занимать минуты, а не дни. Релиз стал занимать дни, а не недели;
• дэйли митинги стали похожи на дейли митинги. Улучшились коммуникации в команде. Вообще команда стала ощущать себя командой, а не временно собранной группой лиц для выполнения набора задач;
• разобрали и пофиксили всю помойку найденных багов, включая мелкие;
  тестировщиков удалось убедить начать изучать Python без боязни, что их будут бить нагружать задачами по написанию автотестов для всех подряд проектов, и автоматизировать часть своих операций;
• несмотря на ощущение бессмысленности работы (проект-то руководством решено было забросить), закончить на позитивной ноте и с желанием от всей команды продолжить работу над чем угодно в том же составе.

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

Поражение и исход

There’s nothing to see here,
I don’t wanna be here,
Get me out of here right now
I cannot sit around and wait for you to drive me insane

Pain — Bye/Die

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

Правда, заказчик как раз решил начать продавать наш продукт и ожидал стабилизации и более отзывчивой поддержки.  Хотя «новая версия» на новом движке не была готова для продуктива не то что в январе, а даже апреле. MVP? Спринты? Нет, не слышали.

Многократно декларировалось, что в новый продукт мы перенесём весь опыт, полученный от разработки первоначальной версии. На этом убеждении, собственно, подписывался энтузиазм последних месяцев проекта. Возможно, у нас с руководством разные представления об опыте. Команда нашего проекта (помните, все хотели продолжить работать в исходном составе?) лёгким движением руки была распущена и растащена по другим проектам. Выученная беспомощность? Я понял откуда она у людей, которые по 5-7 лет работают в среде, в которой они привыкли к тому, что ничего не решают и ни на что не влияют. Особенно если это их первая работа после учёбы.

В новый «главный проект компании», контролируемый лично CEO, ввиду сурового отставания и важности, было набито столько людей, что они уже не влазили ни в какой разумный Scrum и дэйли митинг. В итоге был сделан гениальный ход — разбить всю толпу на субкоманды по функционалу (команда архитекторов, команда разработчиков, команда тестеров, команда, прости господи, девопсов, плюс немножко команд, которые делают отдельные компоненты и где-то отдельно живёт аналитик). У субкоманд свои спринты и дэйли, а делегаты от них ходят на встречи верхнего уровня. И это назвали Scrum of Scrum (фреймворк, который запрещает деление на функциональные субкоманды, ага).

Что, интересно, могут натестировать QA или наразворачивать девопсы, если никто из них уже не видит целостной картины, точки, в которой находится проект и куда всё движется.

Не говоря уж о трудностях коммуникаций такой массы людей и потерь времени на это.

Я же, практически «не приходя в сознание» обнаружил себя переведённым в команду девопсов. Интересно, что со мной никто не счёл нужным это обсуждать. Самое интересное оказалось, что непонятно, что с этим делать — в компании нет линейных менеджеров, а назначен я оказался лично CEO, так что без его воли я теперь и выйти, вроде как, не могу.

Роль девопса, как она представлена в Paragon, я перерос ещё 10 лет назад, вдобавок, я всё ещё допускал вероятность, что опыт преодоления проблем проектной продуктивности первого проекта прошёл мимо CEO ввиду суеты со вторым. Как и моя роль в этом.  И ему просто кажется, что в проекте не хватает людей. А кроме того, он неоднократно говорил, что открыт к разного рода предложениям и обсуждениям. Так что я решил написать директору письмо, в котором:

1. Сказал, что не вижу, чем я могу помочь, как девопс в текущих условиях проекта (да и не в восторге от такой идеи вообще, признаться).
2. Изложил анализ проблемных ситуаций, приведённый выше.
3. Предложил взять ответственность за какой-нибудь компонент или часть процесса, если мне выделят ещё хоть пару человек.

Ничего вразумительного я в ответ не получил. Но из команды девопсов меня вывели.

А спустя какое-то время предложили «переехать» по адресу основного рабочего места, согласно трудовому договору — г. Долгопрудный.

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

Тут надо пояснить, что жил я в Подольске, до текущего места добирался 2 часа, а до офиса в Долгопрудном путь занимает часа 3,5. В одну сторону. Так что я честно ответил, что готов ездить туда, если а) компания мне снимет там жильё или б) будет засчитывать мне время пути как рабочее.

В ответ получил вот такое формальное уведомление и неформальные намёки о возможности увольнения за прогул.

При этом в прямом диалоге директор по персоналу утверждает, что команды увольнять меня не было. Просто «собственник вправе принимать решения, кому и где работать».

Но как, интересно, иначе это можно расценивать.

Через третьи руки до меня дошла информация о том, что исходная причина всей этой катавасии в том, что «никому из директоров не понравится, когда им указывают, что они что-то неправильно делают».

 

Ситуация, прямо скажем, неприятная, так как Долгопа — не вариант вообще, а чего ждать дальше — неясно. Конечно я мог бы компании подпортить репутацию в случае попытки меня как-то негативно уволить привлечением трудовой инспекции, прокуратуры и поста на Хабре, но…

а на кой чёрт тут задерживаться при таком раскладе? Подумал я.

И пошёл искать новую работу, а заодно форсировать свои релокационные и карьерные цели.

А те, кто уже/ещё работает в Paragon’е или планирует, может принять эту информацию во внимание.

Post Scriptum

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

И конечно я почерпнул там просто гору опыта и знаний.

Искренне желаю успехов всем бывшим коллегам.

А буквально на днях Мичиганский университет прислал письмо следующего содержания:

FROM: Leading People and Teams Capstone Course Team

Dear Konstantin Kasachev,

Congratulations! We have reviewed your Capstone submission and your paper was among the very best submissions. It demonstrated strong knowledge of the course material, a thoughtful application of that material to address the Capstone assignment, and clear and concise writing. We are pleased to offer you the opportunity to choose up to 2 options among the following awards for your exceptional performance in the Specialization:

• office hours with Prof. DeRue or Prof. Sytch,
• 1 credit toward Michigan Ross Distinguished Leader Certificate,
• a waived application fee to Michigan Ross graduate programs,
• or a LinkedIn recommendation/endorsement by Ross faculty.

Ну хоть где-то пригодилось :)