Закон Конвея и диалектика
Френд ailev навел на интересный "закон".
Закон Конвея:
"Организации, проектирующие системы, неизбежно производят системы, являющиеся копиями их организационных структур».
Забив это словосочетание в поиск, можно получить сколько-то вполне доступных разъяснений.
"Закон Конвея" не подразумевался как шутка или изречение в стиле дзен-буддизма, а как вполне обоснованное социологическое наблюдение. Оно основывается на простых фактах того, что два программных модуля А и Б не смогут нормально взаимодействовать между собой, если дизайнер и разработчик модуля А не в состоянии нормально общаться с дизайнером и разработчиком модуля Б; в следствии чего структура интерфейсов разработанной системы будет отражать некое совпадение с социальной структурой предприятия-производителя"
ailev вполне резонно замечает, что организации должны непрерывно изменяться, если они совершенствуют линейку своих продуктов, тут можно только согласиться.
Тем более, что первоисточник этого закона - книга «Мифический человеком-месяц» Ф. Брукса - содержит расширенную формулировку: «организационная структура первоначально отражает проект первой системы, который наверняка был ошибочным. Если проект системы должен допускать внесение изменений, то и организация должна быть готова к переменам».
Однако!
Непосредственными копиями структур организации создаваемые системы быть не могут. На лобовой броне танка не будет списочного состава тех мастеров, которые прокатывали эту броню в цеху. В современном автомобиле не может быть схемы организационной структуры ВАЗа или "Мицубиси", со списком менеджеров и уборщиц. Структура предприятия присутствует в продукте - но не в прямой, а в искаженной форме. Что же за характеристики этого искажения?
Тут в памяти всплывает несколько категорий диалектики: "форма и содержание", "сущность и явление", "историческое и логическое", еще хорошо себя показывает концепция челнока «идеально-реальное», не говоря уже о спиралевидном развитии, переходе количества в качество и прочих составляющих диалектического метода.
Диалектика содержания и формы, когда одно переходит в другое, прямо-таки бросается в глаза: есть содержание устройства предприятия, которое задает форму его продукта. Есть качественная сущность предприятия, явления которого чрезвычайно многообразны, и среди них - продукт. И обратный взгляд: содержание продукта задает структуры, которая должна обеспечивать его изготовление.
Если пропустить несколько итераций в рассуждениях, то получается следующая система:
- маятниковые движения отражающие изменение качеств продукта (абсорбирующие возможности материала подгузников, проникающая способность танкового снаряда) и его возможностей (спросом на памперсы данной модели, способностью артиллерийского снаряда пробить распространенную танковую броню). Эти движения - просто другая проекция спирали развития продукта;
- маятник между изменением необходимых затрат на введение нового продукта и затратами, необходимыми для трансформации системы - каждый из этих видов затрат становится то больше, то меньше другого. И если посмотреть на колебания «в профиль» мы опять-таки получаем спираль развития - развития управленческих структур компании, которые обеспечивают новые уровни рефлексии процессов производства.
Еще можно указать на понятие «качественного скачка»: при любом планировании развития своего продукта, организация, в идеале, должна оценивать пределы рационализаторских изменений в этом продукте. Когда можно сохранять прежнюю свою структуру, не тратиться на «перекраску стен и покупку мощной электронно-вычислительной машины». А когда необходимо радиально менять коммуникационную структуру компании. Если же у нас имеет место быть постоянная компьютерная революция, то любую оргструктуру надо рассматривать как объект в процессе становления.
С послесловиях к тому же самому «Мифическому человеко-месяцу» Д. Брукс через тридцать лет вполне откровенно пишет, что предложенная им модель каскадного программирования (несколько последовательных шагов от планирования, до эксплуатационной поддержки) проиграла модели итерационно-«пошагового» создания программ: когда идет непрерывный цикл отладки продукта, буквально ежевечерняя сборка программы - и этот цикл (который опять-таки спираль) ведь можно продолжать бесконечно. Его прекращают, когда спираль выходит на нужную высоту - возможность удобного использования и надежность в работе.
Собственно, главное требование, которые предъявляют владельцы фирм и начальник проектов к многочисленным «консультантам-системотехникам» это даже не сиюминутное снижение издержек, повышение эффективности (говорят о деньгах, но сводят все к деньгам только недалекие люди). Это требование замены стихийных процессов рынка, стихийных процессов развития - отбора наиболее востребованных товаров, остановки производств, банкротства фирм со старыми организационными моделями - планируемыми, управляемыми процессами. Вместо того, чтобы проигрывать конкурентную борьбу, фирма желает измениться сама.
Но как же медленно и наощупь приходили к вполне разумным (и диалектическим) формулировкам узкие специалисты!
Выводы: ко многим положением диалектики разработчики стихийно приходят в процессе отладки систем. Но насколько выгоднее было бы использовать диалектику при создании новой дисциплины…
Закон Конвея:
"Организации, проектирующие системы, неизбежно производят системы, являющиеся копиями их организационных структур».
Забив это словосочетание в поиск, можно получить сколько-то вполне доступных разъяснений.
"Закон Конвея" не подразумевался как шутка или изречение в стиле дзен-буддизма, а как вполне обоснованное социологическое наблюдение. Оно основывается на простых фактах того, что два программных модуля А и Б не смогут нормально взаимодействовать между собой, если дизайнер и разработчик модуля А не в состоянии нормально общаться с дизайнером и разработчиком модуля Б; в следствии чего структура интерфейсов разработанной системы будет отражать некое совпадение с социальной структурой предприятия-производителя"
ailev вполне резонно замечает, что организации должны непрерывно изменяться, если они совершенствуют линейку своих продуктов, тут можно только согласиться.
Тем более, что первоисточник этого закона - книга «Мифический человеком-месяц» Ф. Брукса - содержит расширенную формулировку: «организационная структура первоначально отражает проект первой системы, который наверняка был ошибочным. Если проект системы должен допускать внесение изменений, то и организация должна быть готова к переменам».
Однако!
Непосредственными копиями структур организации создаваемые системы быть не могут. На лобовой броне танка не будет списочного состава тех мастеров, которые прокатывали эту броню в цеху. В современном автомобиле не может быть схемы организационной структуры ВАЗа или "Мицубиси", со списком менеджеров и уборщиц. Структура предприятия присутствует в продукте - но не в прямой, а в искаженной форме. Что же за характеристики этого искажения?
Тут в памяти всплывает несколько категорий диалектики: "форма и содержание", "сущность и явление", "историческое и логическое", еще хорошо себя показывает концепция челнока «идеально-реальное», не говоря уже о спиралевидном развитии, переходе количества в качество и прочих составляющих диалектического метода.
Диалектика содержания и формы, когда одно переходит в другое, прямо-таки бросается в глаза: есть содержание устройства предприятия, которое задает форму его продукта. Есть качественная сущность предприятия, явления которого чрезвычайно многообразны, и среди них - продукт. И обратный взгляд: содержание продукта задает структуры, которая должна обеспечивать его изготовление.
Если пропустить несколько итераций в рассуждениях, то получается следующая система:
- маятниковые движения отражающие изменение качеств продукта (абсорбирующие возможности материала подгузников, проникающая способность танкового снаряда) и его возможностей (спросом на памперсы данной модели, способностью артиллерийского снаряда пробить распространенную танковую броню). Эти движения - просто другая проекция спирали развития продукта;
- маятник между изменением необходимых затрат на введение нового продукта и затратами, необходимыми для трансформации системы - каждый из этих видов затрат становится то больше, то меньше другого. И если посмотреть на колебания «в профиль» мы опять-таки получаем спираль развития - развития управленческих структур компании, которые обеспечивают новые уровни рефлексии процессов производства.
Еще можно указать на понятие «качественного скачка»: при любом планировании развития своего продукта, организация, в идеале, должна оценивать пределы рационализаторских изменений в этом продукте. Когда можно сохранять прежнюю свою структуру, не тратиться на «перекраску стен и покупку мощной электронно-вычислительной машины». А когда необходимо радиально менять коммуникационную структуру компании. Если же у нас имеет место быть постоянная компьютерная революция, то любую оргструктуру надо рассматривать как объект в процессе становления.
С послесловиях к тому же самому «Мифическому человеко-месяцу» Д. Брукс через тридцать лет вполне откровенно пишет, что предложенная им модель каскадного программирования (несколько последовательных шагов от планирования, до эксплуатационной поддержки) проиграла модели итерационно-«пошагового» создания программ: когда идет непрерывный цикл отладки продукта, буквально ежевечерняя сборка программы - и этот цикл (который опять-таки спираль) ведь можно продолжать бесконечно. Его прекращают, когда спираль выходит на нужную высоту - возможность удобного использования и надежность в работе.
Собственно, главное требование, которые предъявляют владельцы фирм и начальник проектов к многочисленным «консультантам-системотехникам» это даже не сиюминутное снижение издержек, повышение эффективности (говорят о деньгах, но сводят все к деньгам только недалекие люди). Это требование замены стихийных процессов рынка, стихийных процессов развития - отбора наиболее востребованных товаров, остановки производств, банкротства фирм со старыми организационными моделями - планируемыми, управляемыми процессами. Вместо того, чтобы проигрывать конкурентную борьбу, фирма желает измениться сама.
Но как же медленно и наощупь приходили к вполне разумным (и диалектическим) формулировкам узкие специалисты!
Выводы: ко многим положением диалектики разработчики стихийно приходят в процессе отладки систем. Но насколько выгоднее было бы использовать диалектику при создании новой дисциплины…