В книге “Пятая дисциплина”1 (очень, кстати, ее рекомендую в качестве краткого введения в системное мышление и комплексный подход к построению “антихрупких” человеческих систем) приводятся описания архетипов систем2, то есть некоторых повторяющихся шаблонов развития самых разных систем, в том числе и компаний по разработке ПО.
Один из таких архетипов называется “Подмена проблемы”, суть его в том, что есть проблема, для которой есть (1) сложное, неочевидное или дорогое фундаментальное решение и (2) быстрое, простое, симптоматическое “лечение”. И если система выбирает “снятие симптома”, то постепенно возможность фундаментально “излечиться” становится все меньше и меньше, а зависимость от “симптоматических решений” постоянно растет. Так происходит, потому что быстрые поверхностные меры быстро снижают давление решать проблему, это своего рода болеутоляющее, а если что-то не болит, то наверное, можно с этим ничего и не делать.
Почему система (читай, организация) может осознанно выбрать второй вариант решения? Возможно, потому что наше мышление, сформированное “линейным” языком, также линейно, поэтому размышления о циклах, лежащих в основе фундаментального решения проблемы, требуют слишком уж больших затрат мыслетоплива. Возможно, потому что зависимость от симптоматического лечения уже есть, такие решения уже “прокатывали” раньше и облегчали боль на какое-то время. А возможно, еще и потому что горизонт оценки принятых решений и получения обратной связи у многих организаций слишком мал, и эта краткосрочность управленческого видения не дает увидеть долгосрочные последствия.
Как бы то ни было, по ряду причин многие команды разработки и организации в целом идут по пути симптоматического лечения, тем самым постепенно ухудшая ситуацию в целом.
Например, у многих команд разработки ПО есть проблема несоблюдения сроков выпуска версий или каких-то подобных договоренностей с заказчиками. Фундаментально ее можно решить путем, например, выстраивания других отношений с бизнесом (заказчиком) или построения хорошего agile-процесса разработки, но это трудно. Проще всего прямо здесь и сейчас налепить костылей, чтобы “сохранить лицо” и успеть в срок. Со следующим релизом успеть будет еще сложнее, потому что костыли мешают, но и фундаментально решать проблему становится еще труднее, поэтому появляется зависимость от “костыльных методов”, которые (чтобы самооценка у руководителей не падала) выдаются за героическое решение проблем.
Почему архетип называется “Подмена проблемы”? Потому что костыли часто приобретают вполне определенные черты, одинаковые для самых разных систем, и цель этих костылей - не в решении проблемы, а во временном обезболивании. Внимание команд фокусируется не на фундаментальной проблеме (плохой процесс, мутные взаимоотношения, бюрократия), а на текущей краткосрочной задаче - успеть выпустить версию в срок. А костыли превращаются в двух постоянных спутников этого архетипа - “Размытие цели” и “Понижение планки”.
Я, например, сталкивался со следующими предложениями по краткосрочным решениям:
- Давайте не будем проводить код-ревью
- Давайте не будем писать юнит-тесты (и любые другие автотесты)
- Давайте выкинем редкие сценарии из регресс-тестирования
- Давайте просто расширим существующую абстракцию/сущность/таблицу (хотя новая функциональность в нее никак не ложится)
- Давайте не будем править баги с приоритетом ниже Critical
- Давайте выйдем поработать в выходные
- Давайте наймем толпу дешевых студентов или отдадим часть задач на аутсорс
Ну, вы поняли, куда это все ведет…
И что со всем этим делать?
Прежде всего - найти те самые фундаментальные способы решения существующей проблемы. Надо, правда, отметить, что шкала “симптоматическое - фундаментальное” - это спектр, а не бинарное значение, поэтому “фундаментальность” решения всегда относительна.
Затем нужно привлечь внимание команды и особенно руководителей к тому, что существует этот порочный цикл зависимости от симптоматических решений. Проследить и озвучить влияние ранее принятых решений на текущее состояние, дать понять, что проблема краткосрочными мерами не решается.
Ну и затем обсуждать / разрабатывать / применять найденные фундаментальные решения, если команда и руководство к этому готовы.