Что же такое системное мышление? Часть 3.
Паттерн 3: Система – это объект в постоянно изменяющейся среде.
Подход из моего предыдущего поста о том, что всегда есть большая система и в нее можно подняться, является одним из наиболее известных широкому кругу людей. Не зря мне в личку прелетело несколько высказываний о том, что я тут баяны наливаю.
Что же, теперь разберем подход не столь популярный.
Допустим, наша система – это некий механизм или сложный объект. Так вот, он всегда будет находиться в некой внешней среде, которая будет изменчива в той или иной степени. Проще говоря, с течением времени окружение нашей системы будет изменяться. Поскольку в качестве системы в данном случае мы рассматриваем некий механизм, то у этого механизма есть какая-то полезная задача для выполнения. И выполняться она будет с разной эффективностью, в зависимости от окружающей действительности.
Например, один и тот же автомобиль может ехать по автостраде со скоростью 150 км/ч, а вот по горному серпантину без асфальта не сможет сделать этого при всем желании.
В предыдущих постах я приводил примеры из сферы танкостроения. Тут тоже можно провести быструю аналогию. В первой половине 20-го века существовало огромное множество разновидностей танков (легкий, средний, тяжелый, штурмовой и так далее). Зачастую они изготовлялись различными производителями и их запчасти не подходили друг другу, да и агрегатные узлы могли иметь совершенно различное строение, что ужасно затрудняло ремонт и логистику поставок деталей на место ремонта, особенно на линию фронта.
Кроме того, было крайне сложно предсказать, в какие именно условия попадет та или иная техника на линии фронта. По этой причине легкие танки попадали в бой против тяжелых, а тяжелые были вынуждены делать затяжные маршброски для окружения группировок противника, где по пути из строя выходило около 30% от имеющейся техники.
Как итог, во второй половине 20-го века большинство стран приняли на вооружение новый вид танков, который стали называть средним или основным – то есть, некую универсальную модель, которая не имеет каких-то идеальных качеств для определенной ситуации, но достаточно универсальна, и самое главное, упрощена с точки зрения ремонта и взаимозаменяемости деталей.
Так как же применять этот паттерн в жизни?
Очень просто: когда вы делаете какой-либо продукт, вы должны попытаться понять, в каких условиях он будет применяться?
Например, в среде стартаперов есть устоявшийся принцип разработки: написать код, который будет работать уже через неделю (чтобы проверить гипотезу), и если идея окажется востребована, то при дальнейшем масштабировании этот первый набросок просто выбрасывают в помойку и делают с нуля уже качественный продукт.
В чем преимущество этого подхода?
Вы еще не знаете, будет ли ваш продукт вообще кому-то нужен, поэтому вы должны протестировать его с наименьшими усилиями. Чаще всего код будут писать 1-2 программиста, с кучей велосипедов внутри, не масштабируемый и вообще не очень стабильный. Зато быстро. А дальше уже по ситуации вы решаете, нужно ли делать из этого нормальный продукт с код ревью и прочими стандартами корпоративной разработки.
Люди очень часто не понимают этой особенности планирования и делают узкоспециализированную систему для широкого круга задач или наоборот, делают универсальную платформу для решения одной микро-задачки.
Прежде чем начать что-либо делать, подумайте, в каких условиях будет использоваться ваша поделка. Насколько они изменчивы во времени?
Насколько вы вообще уверены в том, что эти условия будут именно такими, как вы предполагаете? Стоит ли тратить огромные ресурсы на создание универсального механизма, если для начала вам нужно просто проверить гипотезу или заткнуть дырку в виде малюсенькой узкоспециализированной задачки?
Паттерн 3: Система – это объект в постоянно изменяющейся среде.
Подход из моего предыдущего поста о том, что всегда есть большая система и в нее можно подняться, является одним из наиболее известных широкому кругу людей. Не зря мне в личку прелетело несколько высказываний о том, что я тут баяны наливаю.
Что же, теперь разберем подход не столь популярный.
Допустим, наша система – это некий механизм или сложный объект. Так вот, он всегда будет находиться в некой внешней среде, которая будет изменчива в той или иной степени. Проще говоря, с течением времени окружение нашей системы будет изменяться. Поскольку в качестве системы в данном случае мы рассматриваем некий механизм, то у этого механизма есть какая-то полезная задача для выполнения. И выполняться она будет с разной эффективностью, в зависимости от окружающей действительности.
Например, один и тот же автомобиль может ехать по автостраде со скоростью 150 км/ч, а вот по горному серпантину без асфальта не сможет сделать этого при всем желании.
В предыдущих постах я приводил примеры из сферы танкостроения. Тут тоже можно провести быструю аналогию. В первой половине 20-го века существовало огромное множество разновидностей танков (легкий, средний, тяжелый, штурмовой и так далее). Зачастую они изготовлялись различными производителями и их запчасти не подходили друг другу, да и агрегатные узлы могли иметь совершенно различное строение, что ужасно затрудняло ремонт и логистику поставок деталей на место ремонта, особенно на линию фронта.
Кроме того, было крайне сложно предсказать, в какие именно условия попадет та или иная техника на линии фронта. По этой причине легкие танки попадали в бой против тяжелых, а тяжелые были вынуждены делать затяжные маршброски для окружения группировок противника, где по пути из строя выходило около 30% от имеющейся техники.
Как итог, во второй половине 20-го века большинство стран приняли на вооружение новый вид танков, который стали называть средним или основным – то есть, некую универсальную модель, которая не имеет каких-то идеальных качеств для определенной ситуации, но достаточно универсальна, и самое главное, упрощена с точки зрения ремонта и взаимозаменяемости деталей.
Так как же применять этот паттерн в жизни?
Очень просто: когда вы делаете какой-либо продукт, вы должны попытаться понять, в каких условиях он будет применяться?
Например, в среде стартаперов есть устоявшийся принцип разработки: написать код, который будет работать уже через неделю (чтобы проверить гипотезу), и если идея окажется востребована, то при дальнейшем масштабировании этот первый набросок просто выбрасывают в помойку и делают с нуля уже качественный продукт.
В чем преимущество этого подхода?
Вы еще не знаете, будет ли ваш продукт вообще кому-то нужен, поэтому вы должны протестировать его с наименьшими усилиями. Чаще всего код будут писать 1-2 программиста, с кучей велосипедов внутри, не масштабируемый и вообще не очень стабильный. Зато быстро. А дальше уже по ситуации вы решаете, нужно ли делать из этого нормальный продукт с код ревью и прочими стандартами корпоративной разработки.
Люди очень часто не понимают этой особенности планирования и делают узкоспециализированную систему для широкого круга задач или наоборот, делают универсальную платформу для решения одной микро-задачки.
Прежде чем начать что-либо делать, подумайте, в каких условиях будет использоваться ваша поделка. Насколько они изменчивы во времени?
Насколько вы вообще уверены в том, что эти условия будут именно такими, как вы предполагаете? Стоит ли тратить огромные ресурсы на создание универсального механизма, если для начала вам нужно просто проверить гипотезу или заткнуть дырку в виде малюсенькой узкоспециализированной задачки?