По сути редукционизм – это объяснение свойств и поведения сложных объектов или систем через свойства и поведения их простых составных частей.
Вроде звучит логично. Поэтому одно время философы активно культивировали эту идею.
Однако несколько позже маятник философии качнулся в другую сторону (к холизму) и сказал нам, что «целое больше, чем сумма его частей».
Бытовой пример
Вот есть у вас механические часы. Они являют собой набор пружинок и шестеренок.
Если перед вами рассыпать все эти детали, то изучив по отдельности каждое колесико, его размер, состав, скорость вращения, вы вряд ли сможете понять, как эти часы работают.
Еще из того, что шестеренки могут крутиться, совершенно не очевидно, что из этого получится прибор, показывающий время.
А если усилить пружинку и увеличить диаметр у двух колесиков, то это не значит, что часы будут показывать время «еще лучше».
Да и совершенно не обязательно, что именно время будет показывать прибор, собранный из шестеренок.
К чему это я
К тому, что в работе нас зачастую окружает подобный редукционизм сплошь и рядом. Он ловко зацепляется за карго-культ бездумного повторения за кем-то другим и мы получаем абсолютно бестолковые практики, которые не только не помогают, но и мешают.
Рабочий пример №1
Приходит к вам менеджер и просит оценить срок у вот этих трех задач.
Вы оцениваете (про то, как оценивать, поговорим в другом посте) и отдаете 3 цифры. Менеджер складывает 3 цифры и радостно убегает к заказчику докладывать, когда будет закончен проект.
Где тут редукционизм? Менеджер не учел, что у него есть сложная система, где есть вы, 3 задачи, еще другие проекты, еще другие непредвиденные дела, текучка, каждая задача может ненароком зацепить что-то еще, а вас может зацепить более сложный проект или более интересная работа с более дальновидными менеджерами.
Рабочий пример №2
Приходит к вам эйчар и говорит, что с завтрашнего дня надо ввести грейды.
Где тут может крыться редукционизм?
Например, грейды вводятся, но при этом дальше ничего не меняется. Нет понятной системы пересмотра грейдов, нет прозрачной тарифной сетки по каждому грейду, нет системы развития людей от грейда к грейду. Просто грейд ради грейдов.
Получается, что человек не понимает, что там, где грейды существуют и как-то свою функцию выполняют, они являются лишь частью более сложной системы, и только в комплексе система будет работать. А если просто вы накидали пару шестереночек в коробку, то время эта коробка показывать не будет.
Где тут еще редукционизм?
Сами грейды описать – очень и очень сложная задача. Я видел много таких таблиц, где написано, что джуниор должен знать такие-то функции языка, уметь сякие линукс команды, а мидл всё это, плюс еще фреймворк, а сениор плюс еще один фреймворк и тесты умеет писать.
Ну разве это говорит нам о том, насколько действительно велика ценность каждого разработчика? Там же много еще всякого того, что обычно в инженерной сетке грейдов мало кто прописывает. Как человек с другими технарями и менеджерами взаимодействует, насколько проявляет инициативу и ответственность в работе, как обучается и обучает других, как в целом на команду влияет в моральном плане, в плане производительности, насколько он в конце концов может генерить какие-то альтернативные креативные решения.
Да и в целом человек – слишком сложная система, чтобы взять и однозначно сказать, какие его «качества и свойства» ценны для работы, а какие нет. А система, состоящая из таких человеков, еще сложнее.
Кстати, я не отрицаю систему грейдирования целиком и полностью, просто это тема для отдельного большого поста. А сегодня я вам просто показал реальную историю, когда бездумно заносят грейды ради грейдов в отрыве от всей социотехнической системы.
Итог
Я считаю, что внедрение новых инструментов и практик должно оцениваться по комплексному влиянию на всю систему. Но об этом редко хотят задуматься, потому что это сложно, не всегда возможно свести к какой-то конкретной цифре и ненароком можно получить неожиданные неприятные факты, говорящие, что вы занимаетесь ненужной чепухой. А ведь job security никто не отменял🙂