У Пирсига есть концепция статического и динамического качества. В основном это описано в Лайле (я считаю эту книгу одной из самых значительных в своей жизни). Я не буду вдаваться в глубокую философию, которую сам не до конца понимаю, но мне эта идея показалась очень интересной с точки разработки систем.
Под динамическим качеством понимается edge of chaos, кромка исследования действительности. Его невозможно определить и как-то формализировать. Это постоянный поиск нового. Статическое качество — это вся определяемая действительность, мы можем его именовать и рассуждать о нем.
Если это переносить на разработку систем, то можно сказать, что первый этап — это есть динамическое качество, когда исследуются границы решения и возникает что-то новое. А потом все превращается в статическое качество, которое хранит память о решении и закрепляет достижения. Давайте понизим градус абстракции, чтобы было понятнее.
Возьмем стартап, который пытается найти проблему и придумать решение этой проблемы. Очень вероятно, что проблему видит не только этот стартап, а еще 50 других стартапов. Из всего этого котла решений хорошими окажутся штук пять, и они выживут в эволюционной борьбе. Но как отдельно взятому стартапу увеличить свои шансы на успех? Как можно дольше оставаться в состоянии динамического качества, пока не будут получены четкие маркеры правильного направления. Это значит нужно сделать такую систему-газон, которая позволяет клиентам самим протаптывать дорожки-решения.
Сейчас мы практически всегда пытаемся решить эту проблему через анализ требований, гибкую разработку и удачу. К сожалению, все эти методы не особенно эффективны. Мы плохо понимаем требования пользователей, медленно меняем систему и часто ошибаемся. Какое же идеальное состояние? Оно заключается в том, чтобы переложить реализацию требований пользователей на самих пользователей. Дать им возможность собирать решение своей проблемы из понятных кубиков. Но эта задача пока не решена. Мы не пишем софт таким образом, чтобы пользователь сам собирал в нем решения. Мы пытаемся дать ему готовые решения, и это работает только благодаря эволюционному отбору всей мировой бизнес-экосистемы. У каждой отдельно взятой новой компании по умолчанию мало шансов.
Второе неплохое, но менее привлекательное решение — переложить реализацию требований на другие компании. Амазон блестяще использует эту стратегию. Он сделал газон и смотрит, где маленькие компании протаптывают дорожки. Если какой-то сегмент продается хорошо, они кладут там свою асфальтовую дорогу, быстро убирая всех конкурентов и независимых поставщиков. Может быть, не самый этичный подход, но с точки зрения бизнеса невероятно эффективный.
В этом месте очень хочется процитировать Щедровицкого:
Когда мы кладем асфальт, то мы определённым образом организуем процессы, канализируем, направляем их. Англичане делают так: они сажают газон в парках, люди ходят, протаптывают дорожки, потом через некоторое время протоптанную дорожку асфальтируют. Что здесь происходит? Я описал бы это так: сначала дают возможность процессуализировать материал, образуются естественные дорожки, после этого их организуют асфальтом. У нас же сначала организуется пространство, исходя из идей симметрии и ещё каких-то абстрактных принципов, а потом начинается борьба этой организации с соответствующим процессом.
Targetprocess — яркий представитель отечественного подхода к решению таких задач. Исходя из абстрактных принципов мы сделали довольно статическую систему и теперь ведем борьбу с процессами, которые люди в ней хотят делать. Мы постепенно подгибаем систему под эти процессы, но через огромную боль и очень медленно. Мы слишком быстро перешли из динамического качества в статическое.
Переходить в статическое качество имеет смысл только тогда, когда решение найдено и доказало свою нужность и правильность. К сожалению, в разработке систем мы практически всегда слишком быстро совершаем этот переход, увековечивая в коде неверные направления и решения. В результате, когда правильное решение будет обнаружено, потребуются неимоверные усилия для изменения системы, для адаптации ее к правильным решениям.
Одна из основных задач Fibery — сделать газон без дорожек (платформу), и посмотреть, какие тропинки (Apps) будут людям нужны, какими путями они будут ходить по системе, какие процессы пытаться использовать. А потом уже закрепить эти знания в конкретных Apps. Мы откладываем решение многих конкретных вопросов и даже откладываем стратегическое направление развития Fibery. Мы пытаемся оставить открытыми многие опции. Мы даем людям газон и показываем, как по нему ходить.
Вообще я считаю, что в будущем с повышением уровня абстракции простые люди все чаще и чаще будут собирать себе решения из кубиков. Сегодня эти кубики есть только у программистов. Но мы обязательно научимся делать кубики, которые понятны большинству knowledge workers. Это будет такая IKEA для юристов, аналитиков, проектировщиков, дизайнеров и далее по списку. Это сложно. Но достижимо.