30 лет назад технологическая индустрия попыталась внедрить бережливые практики, но потерпела неудачу. Вместо «постоянного улучшения» прогресс остановился. Agile несовместим с исследованиями UX, проектированием и масштабируемой разработкой. Так будет всегда. Пришло время создать новые стандарты.
Поскольку стартапы переключаются на «операционную эффективность», давайте подчеркнем, что эффективность — это про способ работы, а не про численность персонала.
Agile-разработка уже более 20 лет является принципом работы № 1 в технологиях, не проверяемым и не подвергаемым сомнению. Тем не менее у него есть фундаментальные недостатки, которые бросались в глаза нам все это время.
Недостаток № 1: Люди — это не машины.
Недостаток № 2: Проектирование — это не переучет.
Недостаток № 3. Продукт не может быть определен тем, что может быть сделано произвольным количеством людей с произвольными навыками и опытом за двухнедельный спринт.
Давайте взглянем назад на то, как мы ограничивали себя во времени:
- 2001 — Agile
- 1995 — Scrum
- 1988 — Lean
- 1960’s — Toyota Production System (TPS)
Начнем с начала
Система TPS развивалась десятилетиями, с 40-х по 70-е годы, что позволило Toyota достичь и сохранить свое доминирующее положение среди мировых автопроизводителей. Эти блестящие начинания были сосредоточены на устранении муда (напрасных трат), мура (непоследовательности) и мури (перегруженности).
Наиболее тщательно документировали устранение отходов. Среди восьми видов отходов наиболее вредными оказались излишки товарных запасов — как готовой продукции, так и сырья, а также простаивающее оборудование. Другими словами, вещи, на которые вы потратили деньги, не приносящие вам денег. Решения Toyota были связаны с материально-техническим снабжением и стали известны как «производство точно в срок».
«Получите материалы вовремя, чтобы сборочная линия обработала их вовремя, чтобы готовый продукт соответствовал требованиям клиентов».
Партнером в совершенствовании TPS был «Путь Тойоты». Эта философия призывала к постоянному совершенствованию, включая преодоление трудностей на пути к долгосрочному виденью, кайдзен (инновациям в операциях) и моему личному фавориту – генти генбуцу. Дословно означая «реальное место, реальную вещь», этот принцип гласил: «пойди и посмотри сам», т. е. принимай соответствующие решения. Он также поощрял подход к улучшению «снизу вверх», сбор информации от каждого сотрудника, независимо от его уровня.
Америка сотворила свое волшебство и превратила «Путь Тойоты» в аналог быстрорастворимой лапши. Ладно, может быть, я несправедлив. Производство «точно в срок» хорошо применялось в США для… производства. Он был переименован в Lean в статье 1988 года «Триумф системы бережливого производства (Lean)» — однако было понятно его происхождение.
Бережливое производство и его предшественники идеально подходят для производства физических товаров, особенно при наличии устоявшегося рынка и зрелого продукта. В основе лежит предсказуемость как спроса, так и цепочки поставок. Когда дело доходит до создания нового продукта, производители полагаются на разные процессы в своих отделах исследований и разработок. Будь то Genentech, разрабатывающая синтетический инсулин, или Proctor & Gamble, разрабатывающая Swiffer, процесс был долгим и довольно линейным. Он включал в себя глубокие исследования и анализ рынка перед разработкой продукта.
Как Waterfall сделали козлом отпущения
Развивающаяся индустрия программного обеспечения в значительной степени следовала этим процессам; применительно к цифровым продуктам они стали известны как методология Waterfall. Термин Waterfall стал универсальным для описания линейного процесса разработки, кульминацией которого являлся полностью реализованный выпуск продукта. Справедливая критика заключается в том, что выпуск большого дорогого продукта все еще может быть неудачным. Таким образом, Waterfall используется для того, чтобы доказать, что итерация, тестирование и реакция на рынок необходимы в более короткие сроки.
В 1990-х специалисты-практики в технологической отрасли изучали способы применения бережливого производства к цифровым продуктам. К сожалению, с самого начала они неправильно диагностировали проблему. Время выхода на рынок важно, но я считаю, что только с точки зрения денежного потока, особенно для стартапов. Сторонники бережливого производства отказались от ненужного, лишившись также полезного. Обратите внимание, что в литературе по Scrum и Agile практически не упоминаются исследования или стратегия. Проектирование получило плохую репутацию из-за того, что в Waterfall тратится много времени. Основы бережливого производства — это сборка и выпуск.
Примерно в это же время произошла битва в стиле Kaiju vs. Mecha (прим.пер. файтинг между монстрами и роботами) между сторонниками бережливого производства и теми, кто практиковал разработку Waterfall. И монстр, и робот не смогли учесть потребности пользователей, а вместо этого растоптали их и уничтожили мир.
В чем разница? Если представить как диаграмму — Agile представляет часть, Waterfall — целое.
Практика повторения существующего продукта на рынке — это роскошь для программного обеспечения — обновления могут быть запущены в любое время; сборочные линии и инструменты не нуждаются в реконструкции. Каждый технологический продукт должен создаваться поэтапно, но он также должен быть создан для достижения конечной цели и полностью реализованного продукта. Успех требует стратегии, исследований, проектирования и генти генбуцу, как и предполагалось в «Пути Тойоты». Аргумент Agile против Waterfall — это ложная дихотомия: компания может иметь долгосрочную стратегию и реализовывать ее, продолжая выпускать продукт постепенно, итеративно.
Ошибка 30-летней давности
Когда владельцы продуктов и инженеры пытались применить принципы бережливого производства к разработке программного обеспечения, они нашли способы имитировать сборочную линию. Требования будут определены как раз вовремя, а затем кросс-функциональная команда будет спешить, чтобы выпустить работающее программное обеспечение. Термин «Scrum» был удачным — он пришел из регби, когда ряд парней мчатся по полю, перебрасывая мяч туда-сюда. Подход к разработке программного обеспечения имеет тот же уровень изящества и стратегии.
Вам всем приходилось иметь дело со Scrum, вот причины, почему он такой, какой он есть:
- Должно быть ограничение по времени спринтом (Sprint), чтобы убедиться, что программное обеспечение может быть выпущено на рынок в «итеративном» цикле.
- Планирование спринта (Sprint Planning) происходит прямо перед спринтом, потому что именно тогда у вас будет понимание того, на чем нужно сосредоточиться.
- Проведение ежедневных заседаний (Daily Standup) для того, чтобы на лету проводить «оперативные улучшения». (Выступать разрешено только разработчикам, дискуссии не допускаются, так как в этом случае техника простаивает.)
- В конце спринта проводить ревью (Review) для просмотра работающего программного обеспечения и определения того, что не было завершено или что нуждается в улучшении.
- Также предполагается проведение ретроспективы (Retrospective) для обсуждения того, что получилось хорошо, а что не очень, в интересах увеличения количества выпускаемой продукции.
- Незавершенные задания (Backlog) не являются основой практики Scrum, это артефакт побочного ущерба и обломков всего, что было выброшено за борт во время спринта.
Вы можете заметить, что Scrum уже довольно нелогичен, но дальше все становится намного хуже.
Несколько создателей Scrum объединились с другими парнями, которые разработали другие методы бережливого производства. Объединив свои усилия, они создали Манифест гибкой разработки программного обеспечения. Марксистский подтекст, вероятно, преднамеренный: они заявляли, что рабочие будут владеть средствами производства.
Манифест хрупкого Agile
Что касается манифестов, то это один из самых жалких документов, когда-либо созданных. В нем перечислены четыре «ценности» и двенадцать «принципов». Возможно, вначале у них были благие намерения — относиться к разработчикам как к людям, а не как к винтикам в машине, — но теперь мы прошли полный круг и уже стало понятно, что принципы превратились в нечто едкое для организаций. Если смотреть сейчас, они представляют собой вариации на тему того, как скрам-группа может снять с себя какую-либо ответственность.
Основные моменты (с моими переводами):
- Люди и взаимодействия важнее процессов и инструментов. (Да, мы будем делать все, что захотим).
- Приветствуется изменение требований, даже на поздних стадиях разработки. (Мы также можем передумать в любое время).
- Проекты строятся вокруг целеустремленных людей, которым стоит доверять. (Оставь нас в покое, бери что есть).
- Работающее программное обеспечение является основным мерилом прогресса. (Тот факт, что мы что-то произвели, имеет значение).
- Простота — искусство минимизации лишней работы — крайне необходима. (Мы собираемся сделать как можно меньше).
- Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами. (Не говорите нам, что делать).
Это не нападение на наших друзей-инженеров. Большинство разработчиков, с которыми я работаю, заботятся о том, чтобы делать работу хорошо, и чувствуют себя обязанными производить качественную работу, основываясь на сроках спринта и обещанных результатах. Тем не менее некоторые техлиды, приобщившиеся к культу Agile, чувствуют себя вполне свободно, следуя вышеуказанным принципам. Требования — это больше предложение, чем правило, проектирование требует интерпретации, все можно вырезать, если конечный результат все еще «работает».
Сочетание принципов Agile и практики Scrum губительно для стартапов. Это оперативные указания руководства; дизайнеры, продакт-менеджеры и инженеры не самоорганизуются и не выбирают такой способ работы. Это все во имя MVP и времени выхода на рынок. Вот что происходит. Каждый. Раз.
Исследования и проектирования создают решения для решения проблем клиентов, но то, что создается, всегда меркнет по сравнению с ними.
Менеджеры по продукту торопятся создать следующий блестящий объект в дорожной карте… только как можно меньше.
С инженерами обращаются как с машинами на сборочной линии, от них всегда ожидают, что они будут производить и поставлять, их поощряют срезать углы, чтобы «сделать это».
Руководству остается только ломать голову, почему продукт такой шаткий и неэффективный.
Далекие от устранения муда, Agile и Scrum создают только потери. Это грязная смесь выгорания, технического долга, долга за проектирование, раздувающийся бэклог, жестко закодированная логика интерфейса и постоянная угроза полного рефакторинга.
Как мы можем выйти из этого цикла?
Просто остановитесь.
Вы не можете впихнуть ориентированное на клиента решение в спринт.
- Определите, что нужно создать.
- Определите лучший способ создания, который позволит в будущем совершать масштабирование и проверки.
- Затем создайте его, сколько бы времени это ни заняло. (Это не займет два года, но и не займет две недели. Релизы можно нарезать на кусочки, пока продукт создается в соответствии со спецификацией.)
- Поощряйте создание продукта превосходного качества, а не «срезание углов».
- Инвестируйте в фундаментальную работу, такую, как системы проектирования и стек чистых технологий, чтобы будущие усилия могли быть более эффективными.
- Инвестируйте в UX и глубину, а не в широту набора функций.
- Правильно инвестируйте в операционную эффективность, а не сокращайте численность персонала и ожидайте того же количества продукции.
Agile можно любить и ненавидеть, но она живет и будет жить. Как вы к ней относитесь?