Почему индустриальный подход к качеству важнее Agile-ритуалов

[Ilusha]

Agile manifesto - это короткий список принципов.

Agile - это про гибкость процессов с целью достижения оптимального результата в оптимальное время.

Гибкость - это значит, что вы все время производите ретроспективный анализ и пробуете что-то менять.

Agile - он про запутанный домен.

Фреймворки - это лишь базовая структура, которая должна тюнится под себя.

Знаю случаи, когда компания строится компания по agile-принципам, но никто про agile никогда и не читал и с ним не работал. А некоторые - даже против него.

P.S.: уже все давно описано, уже все копья сломаны, но люди по-прежнему не хотят понимать, что выстраивание процессов - это отдельная дисциплина.

[ArtemMotovilov]

Согласен: Agile manifesto - действительно набор принципов, а не набор ритуалов. И в своей изначальной форме он как раз про гибкость, адаптацию и работу в условиях неопределённости.

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

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

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

Было бы интересно услышать, как вы в своей практике измеряете гибкость процесса ? Через какие метрики и показатели?

[Ilusha]

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

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

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

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

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

Но все имеет свою цель и цену.

Гибкость кушает ресурсы. Но нужна зачем? Чтобы иметь потенциал очень быстро реагировать: появился потенциальный контракт на условие 100млн$, но нужно поработать, перестроиться: Кому-то это просто не нужно.

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

Говорить можно много и дальше, но суть, надеюсь, я передал.

[ArtemMotovilov]

Спасибо за развёрнутую позицию.

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

Возможно, это действительно повод для отдельного материала - о том, как культура и вовлечение соотносятся с архитектурой процессов.

[MEGA_Nexus]

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

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

Как будто работяге на заводе интересно каждый день в 6 утра просыпаться, топать на завод и работать там с другими такими же работягами. В тысячный раз вытачивать одну и ту же детальку и прочее. Как будто работяга в свободное от работы время изучает труды Деминга, Шухарта, Тайити Оно, Исикавы, чтобы улучшить качество своей работы, а не лежит на диване и под пивасик смотрит футбол.

о том, как часто теряется системное мышление, когда сложные управленческие модели упрощаются до ритуалов.

Вот это как раз-таки про вас написано. Каша в голове и отсутствие всякой системности.

Есть 3 системы производства: ремесленничество, массовое производство и бережливое производство.

Большинство IT компаний относятся к ремесленному типу, большинство промышленных компаний (фабрики и заводы) - к массовому производству. Отдельные промышленные компании используют в работе методы бережливого производства.

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

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

Спросите у любого консультанта и он вам расскажет, что любая ошибка в IT - это убытки на миллион долларов и прочее. Безопасники это также подтвердят.

Поэтому и есть сверхприбыль в IT, ведь вы сделали продукт в 1 экземпляре, но при продаже этот продукт умножается на столько копий, на сколько нужно и нет необходимости «создавать сотни автомобилей для склада впрок».

Популярное заблуждение тех, кто в IT особо не работал.

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

DevOps не ставят задачу тестировщикам, тестировщики - разработчикам, а разработчики аналитикам не ставят задачи.

Работяга на заводе тоже не ставит задачи своему начальнику, руководителю производства или директору компании.

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

В IT чаще производство по методу выталкивания, от начала и до конца.

Открою вам секрет, метод выталкивания (впихивание работы на следующий этап) - это характерная черта массового производство, т.е. его используют все компании массового производства.

Нельзя иметь готовый сайт, готовый код, готовый user story и ждать клиента, чтобы моментально ему это вручить и сразу делать то же самое, что мы только что отдали - в этом вся принципиальная разница, это относится ближе к push-системам.

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

В индустрии с серийным производством многие процессы повторяются, а значит, стандартизированы и вариативность там небольшая, и все же, если бывает- её можно оптимизировать и отладить.

Ну хоть тут всё верно.

Подводя краткий итог: статья бесполезная, зря потратил на неё своё время.

Если по существу, то имеются 3 системы производства: ремесленничество, массовое производство и бережливое производство.

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

Чтобы повысить свою производительность и маржу, IT компании могут у себя внедрять принципы массового производства со всеми плюсами и минусами (впихивание работы, большие очереди задач, минимальная кастомизация и прочее).

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

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

Но автор не должен заблуждаться на этот счёт, т.к. внедрение принципов бережливого производства на промышленных предприятиях проходит ещё хуже. Там уровень сопротивления выше и качество самого внедрения хуже. Так что в IT бережливое производство внедряется намного проще, чем на производстве.

[ArtemMotovilov]

Спасибо за развернутый комментарий! Судя по объёму комментария, тема всё же оказалась небезразличной - а это уже хороший знак для профессиональной дискуссии.

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

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

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

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

"Работяге неинтересно качество" - хорошая попытка подмены уровня анализа, но при всем желании - сомнительный тезис, где смешивается мотивация одного конкретного человека и системная организация производства. Сравниваем красное с твердым. Я о системе, вы о бытовой мотивации. Lean явно строился не на подобных вещах, а стандартах, потоках и структуре ответственности. Точно такой же случай про типы производства: если IT - ремесло, то сравнение с массовым или lean некорректно. Lean исторически применялся не только к массовому производству, и даже ремесленные системы имеют потоки, очереди и узкие места. Мы снова о разных плоскостях.

Ещё раз отмечу, что статья не о том, что «в IT всё плохо» или «в промышленности всё лучше». Я как раз писал о том, что и там, и там внедрение бережливых принципов часто деградирует до ритуалов. Разница лишь в том, какие ограничения среды делают эти искажения более заметными.

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

Благодарю за содержательную дискуссию, вы поднимаете важные вопросы! Пишите еще)

[Dashan_hr]

Интересная точка зрения для IT-сообщества, где чаще обсуждают фреймворки, а не поведение системы в целом.
Отдельно понравилось читать про акцент на различии между инструментом и контекстом его применения. Статья не академическая и не претендует на статистическую модель, но вполне неплохой аналитический лонгрид с авторской позицией. Именно такие тексты и запускают профессиональные обсуждения 100%. Было бы интересно увидеть продолжение!

[ruster85]

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

И как фича прошла все верификации эти, то передаётся уже в Industrial design и development