SCRUM - светлая сторона

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

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

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

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

Вспоминая тот простой факт, что бюджет выделяется на год, и дополнительное выделение бабла между годовыми планированиями как правило не предусмотрено - получаем интересную ситуацию. Представим себе, что в отдел, который занимается обслуживанием чего-нибудь там в трейдинге - приходит новая команда, которая выгоняет ссаными тряпками личинок программистов и Садится Писать Нетленку со Spark, Akka, Twitter Storm и прочими RabbitMQ. Предположим, что им удается написать вот это все, оно уходит в продакшн, работает как минимум не хуже, требует минимум обслуживания и работает под каким-то говнолинуксом. Вот все вышеперечисленное - это то, что увидит нормальный человек. Но начальник этого самого отдела, если он совсем не выжил из ума, увидит следующее

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

От всего этого у условного начальника ойти отдела банка случается выпадение матки, потому как с одной стороны не хочется портить отношения с начальником операционистов - мы же с ним играем в гольф и ходим друг к другу на ужин! С другой стороны, не хочется ставить себя под риск проверки на профпригодность. С третьей стороны, не хочется чтобы сэкономленный бюджет уходил в соседний отдел, где эти говнюки с радостью освоят еще один дохулиард денег и поставят три серверные стойки для системы, написанной в 80-х годах на Cobol, с тучей сертифицированных виртуалок с MS-DOS, которые будут обслуживать всех 100500 тыщ клиентов в DBF файлах.

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

И вот здесь на выручку пришел гений мысли Кен Швабер, который сказал - пацаны, вся эта работа на результат - это хуита хует! На самом деле процесс должен быть ради процесса, и только ради процесса! Вот вам Agile, вот вам team decides, вот там отмена спринта по изменению требований, вот вам оценка в попугаях вместо человекочасов! Дедлайны для тру́сов! Ретроспекшн ретроспекшна! Итерации!

Теперь можно в отчеты аккуратно цеплять burndown charts, можно эффективность любой команды привести к какому-то нужному уровню в районе комнатной температуры, можно не делать ровным счетом ничего - и все равно будет о чем писать отчеты и с чем осваивать бюджет. Можно приглашать SCRUM-коучеров за сотни денег и обучать команды правильному раскладыванию покерных карточек и рисовать графики под линейку. Можно накупить тысячи досок и фломастеров. Можно ежедневно без риска выделять по 4-5 часов времени на митинги, а затем - целый день на анализ того, почему мы проебали этот спринт и как именно мы проебем следующий.

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

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

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

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