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

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

Как все было?

Все начиалось совсем обычно. Некий программист устроился работать в крупную компанию. Компания Билл Шифр - американская сеть магазинов электрического инструмента. В 2014 году занимала 9 место в составленном Forbes списке крупнейших онлайн-магазинов. Компания работает по модели франчайзинг, магазины компании работают во всей на территории всей Америки. Магазин Билл Шифр есть почти в каждом городе. Головной офис компании находится в Питсбурге. Там же находится проектный офис и центр разработки.

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

На следующий день он уже подписывал в отделе кадров трудовой контракт и прочие документы, устанавливал на новый рабочий компьютер свежую ubuntu и разворачивал проект. Получал корпоративные учетки, пароль от wifi и список задач на ближайшие дни.

А что, собственно, за проект?

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

Компания Билл Шифр возникла в 2002м году. Когда деревья были зелеными, небо - голубым. Веб разработка была не очень развита, а сайты писались на Perl. Шел 2018 год, а старый сайт продолжал работать. Дизайн поменялся, но не сильно. Не соответствовал многим стандартам UI. Любое незначительное изменение в сайте давалось с большим трудом. Желающих разрабатывать на Perl в 2018 тоже найти довольно сложно. Типичный legacy проект.

Руководство компании приняло решение разработать новый сайт. Сайт должен быть красивым, современным, многофункциональным, поддерживаемым и т.д. Для этого собрали отдельную команду. В нее и попал наш герой.

Ну и как команда?

Команда неплохая. Помимо команды разработки нового сайта, в компании Билл Шифр был довольно мощный IT отдел.

• Команда микросервисов. Или скорее просто сервисов среднего размера на java, c#, go. Возможно, какие-то еще технологии.

• Команда Perl, поддерживающая старый сайт.

• Команда Python. Выделенная из команды сервисов. Разрабатывает сервисы на python. А также вспомогательные инструменты. В частности, логистику и парсинг цен.

• Команда 1S - разрабатывает ERP систему на базе 1S. По сути, на ней завязан весь оффлайн ритейл. Но во многом и интернет-магазин также.

• Команда DevOps.

• Отдельный отдел IT инфраструктуры.

Возможно, что-то еще.

Ну и? Что дальше?

Новый сайт решили разрабатывать на PHP, конкретно - на Magento 2. Тут практически у всех разработчиков возникал вопрос: "А почему именно Magento?".

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

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

Ок, почему же тогда Magento?

Это требование маркетинга. Magento - это стандарт. Во всем мире тысячи магазинов работают на Magento. Есть куча модулей, платных и бесплатных.

В Magento большая многофункциональная админка. Там есть аналитика, куча маркетинговых инструментов и т.д. Jean Quick, один из директоров очень заинтересован в использовании Magento.

В результате, была куплена недешевая Magento 2 EE. Все, расходимся. Отступать некуда, позади Нью-Йорк.

А что же все-таки не так с Magento?

Это тема для отдельной статьи. Вот один из примеров такой статьи. Но если коротко:

• Производительность - слабое место. Система тормозит из коробки. Частично это решается кучей cache и reindex.

• Сложность. Попробуйте разработать простейший модуль и вы поймете о чем я. Огромное количество модулей. Огромное количество слоев абстракции. Огромное количество кода. Запутанность системы в целом. Многие простейшие вещи делаются очень сложно.

• Связанность. Весь функцонал уже разработан. Разработчик только пишет свои модули, встраивается в работу системы. И меняет ее поведение. Такой подод удобен, если в целом система подходит под задачи бизнеса и нужны небольшие изменения.

• Модули, темы. Либо сильно платные. Либо откровенно сырые. Либо и то и другое. Реально качественных модулей мало. В результате, почти под каждую задачу команда писала свои модули. Вместо стандартных тем - кастомное приложение на Vue JS. В последствии, для него пришлось серьезно расширять REST Api.

• Документация, поддержка, работа с community. Документация вроде есть, но, как правило, не совсем то, что нужно. Реально нужная информация есть на stackoverflow. Либо нужно искать ответы на все вопросы в исходниках ядра Magento. В процессе изучения тикетов на github, сложилось ощущение, что команда на них тупо забивает. Еще есть ощущение, что в команде разработки magento лютая бюрократия. И они решили выложить ее на github.

В итоге, у части команды сложилось впечатления, что Magento не совсем подхдит для данного проекта.

И что же делать?

Пилотный проект! У комнады недостаточно экспертизы с Magento. Ребята просто не поняли суть навязанного технологического решеня! Не постигли дзен!

Для постижения дзена предлагается за пару месяцев сделать интернет-магазин на Magento. Заодно команда сработается. Решено дать новому проекту кодовое имя "NUDAI". Сразу после сдачи пилотного проекта команда начнет делать основной сайт Билл Шифр.

Проект планировалось запустить в начале февраля. Но команда чуть-чуть не успела. В итоге с трудом запустились в конце мая. Во многом, проблемы возникли из-за сложности разработки под Magento. В остальном - противоречивость требований и постоянное их изменение. В итоге пришли к тому, что это в основном управленчские ошибки. С разработкой все нормально, можно продолжать делать основной сайт Билл Шифр. Учесть предыдущие ошибки, больше внимания уделять планированию. и т.д. Продолжается работа над проектом. Решено дать новому проекту кодовое имя "MULAN". Все идет по плану, проект будет сдан вовремя!

Ну теперь то по плану?

А то как же! Релиз назначен на 3е сентября. Календарь перевернули. На момент релиза имеется работающий сайт. Но есть довольно много багов и недоработок. Часть функционала не реализована, либо реализована неполностью. Сайт работает нестабильно, команда постоянно его ломает и чинит. При этом, в целом, сайт работает и сделан не так уж плохо. Просто в рамках работы бэкенд команда столкнулась с огромным количеством проблем. Это также сказалось и на работе frontend команды. Часть из них - проблемы в работе Magento. Другая часть - проблемы, пришедшие из архитектуры старого сайта. Проект получается противоречивый. Но тем не менее.

Этот объезд должен быть построен и он будет построен! Это же ведь объезд! Объезды должны строиться!"

Руководство выделяет дополнительный месяц на доработки. Указанные проблемы исправляются, зато появляются новые. И, что инересно, новые функциональные требования.

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

Команду слегка штормит. Уходит в запой сисадмин. Уходит ведущий frontend разработчик. Через некоторе время по собственному увольняются менеджер проекта и техлид.

Ну да, это все интересно... А бухать то когда?

Ну, имейте терпение! Всему свое время! Чтобы бухать, обычно нужен повод. Успешная сдача пректа могла бы быть хорошим поводом собраться всей командой в баре и выпить!

Но, как выяснилось, повод нужен не всегда. Примерно через полтора месяца компания Билл Шифр находит нового руководителя разработки. Человек серьезный, настроен серьезно. Немедленно приступает к серьезным мерам. В текущей ситуации новый руководитель начинает внедрять SCRUM. Предыдущая методология была тоже SCRUM, но "неправильный". Начинаем внедрять методологию "Пьяный SCRUM". Эта инновационная методология включает в себя несколько особенностей.

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

• Больше плакатов! Весь офис обклеивается плакатами, которые объясняют невежественным людям ценности методологии "Пьяный SCRUM".

• Разрабатывать в принципе не обязательно. Не важно что и как делает команда. Важно, чтобы карточки тасок максимально красиво перемещались из колонки в колонку. И важно, чтобы в следующий спринт было перенесено больше карточек, чем в предыдущий.

• Больше стикеров! В принципе, трекер задач неудобен и неинформативен. Да и вообще не нужен. Лучше под каждый спринт заводить бумажную доску. Клеить стикеры с названиями задач. и т.д.

• Аналитики, менеджеры проектов и тимлиды не нужны! Разработчики должны сами выяснять что им делать. Самостоятельно ставить себе задачи. Самостоятельно общаться со всеми представителями бизнеса.

• Больше игр! Бизнес и разработчики говорят на разных языках. Не очень хорошо друг друга понимают. И вообще мало знакомы. Им нужно подружиться! Давайте играть в игры!

В итоге вся работа превращается в один большой корпоратив. Руководитель web-разработки по факту превращается в Тамаду.

Хороший тамада и конкурсы интересные. Так и прилипло к нему — «Тамада»

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

Новый срок сдачи проекта тоже сорван. Но тут все понятно. Перестройка команды, перестройка всех процессов под "Пьяный SCRUM". Назначен еще один срок сдачи проекта MULAN - 31 января.

А если я не пью?

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

Как говорит наш дорогой шеф, за чужой счёт пьют даже трезвенники… и язвенники!

Но, конечно, кто-то не согласится. Это - лишние люди. Они не подходят по духу. Им не место в команде.

"Нет, ребяты-демократы, — только чай!"

И так вот вы и пробухали всю команду?

Да, примерно так. Фактически, разработка встала. Новые сроки опять сорваны. Но в этот раз - окончательно. Команда занималось переклеиванием стикеров с доски на доску. Некоторые еще пытались что-то разрабатывать, но уже не благодаря, а вопреки.

Тамада увольняет аналитика одним днем. Практически в этот же день увольняются тимлид frontend, тимлид backend и несколько разработчиков. Увольнение аналитика было не причиной, а скорее тригером.

В течении ближайшей пишет по собственному большая часть python команды. Увольняются остатки frontend команды. Также увольняются почти все менеджеры проектов. Многие менеджеры вне IT команды. Через некоторое время увольняются все тестировщики. Никто никого не выгоняет. Все сами встают и уходят.

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

При этом те, кто увольнялся, в основном ходили на собеседования в одни и те же компании в Питсбурге. Город большой, но не очень. Мир разработки все же достаточно тесен. О ситуации в компании Билл Шифр узнают многие разработчики и HR из других компаний. Если работу захочет поменять сам Тамада, то, возможно, ему придется освоить новую для себя профессию. Впрочем, он наверняка сможет сделать неплохую карьеру в шоу-бизнесе. Конкурсы довольно интересные!

Кто-нибудь все же остался?

Осталось несколько backend разработчиков, 1 frontend, часть команды java, 1 python разработчик. Осталась вся команда Perl и вся команда 1S. Уход Perl и 1S разработчиков скорее всего означал бы полный крах онлайн бизнеса Билл Шифр. Но Тамада и их тоже пытается заставить клеить стикеры. Поэтому неизвестно, на сколько их хватит.

В целом тенденция такая, что почти все сильные разработчики покинули компанию. Тамада заморозил проекты NUDAI и MULAN. Вместо них начал новый проект - HUEROS.

"Но работать без подручных - может, грустно, может - скучно..."

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

"В любой непонятной ситуации КЛЕЙТЕ СТИКЕРЫ!)"

"Пьяный SCRUM" никуда не делся, наоборот. Его внедрение продолжается. Досок со стикрами становится все больше и больше. Тамада начал обклеивать ими стены, вероятно, скоро доберется до окон и потолка. Также нанял отдельного Scrum мастера. Человек отвечает за рисование картинок, наклеивание стикеров и проведение игр.

Ну и что в итоге?

В итоге компания Билл Шифр осталась со старым сайтом. За год компания потратила на IT десятки тысяч долларов. Не получила взамен ничего, кроме методологии "Пьяный SCRUM" и Тамады с интересными конкурсами.

Окончательно испортила HR бренд. Снова с нуля собрать команду может быть не так просто. Да и мало кто захочет работать в подобной обстановке.

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

Год назад в Билл Шифр был неплохим местом работы, там был относительно интересный проект, мощная инфраструктура, сильная команда.

Теперь остался "Пьяный SCRUM", атмосфера постоянного испорченного корпоратива, Тамада и неподходящие для разработки технологии. Постоянные совещания, и доски со стикерами вместо тасктрекера. Вся суть работы заключается в имитации разработки.

Парень из начала статьи среди прочих поменял работу и не советует другим разработчикам идти в компанию Билл Шифр. Это путь в никуда. Уважающему себя разработчику нечего здесь делать. Впрочем, сам опыт работы был полезным и помог сделать некоторые выводы.

• Хороший тамада не равно хороший руководитель. Руководитель должен хотя бы понимать, что делает сам. И хорошо бы еще немного понимать, как работают его подчиненные и чем он, собственно, руководит. Можно предположить, что менеджмент везде одинаков. Но, на самом деле, есть специфика. Управлять магазином автозапчастей, командой разработчиков и цирком - не совсем одно и тоже.

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

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

• Атмосфера в компании играет важную роль. Представим, что Тамада пришел бы работать, скажем, в JetBrains. Каким-то чудом его туда взяли, и он начал внедрять стикеры. Скорее всего, Тамада бы и недели не проработал. Атмосфера есть во многих(далеко не всех) IT компаниях. Иногда есть в офлайн бизнесе. Она не появляется сама, ее нужно культивировать. Ее сложно поддерживать и легко разрушить. Лес невозможно вырастить за 2 дня. Это сложный и долгий процесс. Те, у кого Лес есть, будут его беречь.

На этом поучительный рассказ окончен. Спасибо за внимание!