47. Генотип и фенотип программных систем

Полгода назад, читая Лема, я набрел на генотипы и фенотипы. И конечно в голову полезли мысли, как это распространить на программные продукты.

Генотип и Фенотип

Если очень кратко, то генотип закладывает какие-то свойства в систему, а внешняя среда накладывает свой отпечаток и формирует фенотип на основе этих свойств и контекста. То есть отдельная живая особь содержит больше информации, чем генотип, потому что к информации генотипа добавляется внешняя информация среды. Под влиянием внешней среды происходит экспрессия генов. К примеру, под воздействием антибактериального мыла и заботливой мамы у вас развивается склонность к аллергии. В генах это заложено, но вот Васе мама разрешала копаться в грязи, и у него нет аллергии. А вы ненавидите апрель.

Возьмем для конкретики любой продукт. Ну, например, Targetprocess. Он имеет генотип (заложенные в него функции), но каждый клиент настраивает систему под себя, так что каждый отдельный аккаунт Targetprocess — это фенотип. Мы сейчас можем смотреть на ситуацию с эволюционной точки зрения. Генотип Targetprocess порождает множество своих экземпляров, которые сталкиваются с внешней средой (клиентами). В этой внешней среде экземпляры либо выживают (компания пользуется продуктом и все хорошо), либо умирают (компания отказывается от продукта).

Внешняя среда (контекст использования) может оказывать существенное влияние на конкретный экземпляр системы. Фенотип накапливает в себе информацию: домен компании, данные, недовольные пользователи и их фидбек, настройки, расширения, интеграции, и тп. В будущем эта накопленная информация по идее может вызывать мутации в генотипе. Фактически, это и есть задача Product Owner —собирать данные о фенотипах и закладывать нужные мутации в генотип продукта. От того, что заложено в генотипе, зависит выживаемость каждого конкретного экземпляра системы, который попал в свой специфический внешний контекст.

Однообразный контекст

Дальше самое интересное. При однообразии контекстов генотип может быть довольно однозначный, потому что ясно к чему стремиться и что оптимизировать. Продукт используют похожим образом и Product Owner будет получать большое количество одинаковых сигналов от разных экземпляров, поэтому легко понять, что нужно изменить в системе. В предельном случае, если вы делаете систему под одного заказчика, генотип = фенотипу. Вы просто делаете все, что нужно этому заказчику.

Чуть более сложный случай, когда все ваши клиенты очень похожи. Например, это софт для ведения бухгалтерии ИП. Единый стандарт с минимальными изменениями контекста использования делает жизнь PO довольно простой. Вам достаточно иметь несколько клиентов и поддерживать с ними контакт, чтобы реализовать всю нужную функциональность.

Разнообразный контекст

При разнообразии контекстов все становится гораздо сложнее. Каждый экземпляр имеет уникальный фенотип. Клиенты просят довольно разные вещи, и вы не можете делать однозначные выводы на основе фидбека даже сотни клиентов. Жизнь PO становится невыносимой. Принимать правильные решения невероятно сложно, потому что фича, решающая проблему 10% клиентов, совершенно не нужна оставшимся 90%. Что самое хреновое, очень мало таких фич, которые нужны почти всем. Каждая фича нужна немногим. И вы попадаете в ад.

Фактически вы приходите к тому, что при разнообразии контекстов генотип должен быть вариативный. Вы должны обеспечить возможность экспрессии генов. Это значит, что отдельные экземпляры системы должны иметь возможность приспособиться к очень разным контекстам и выжить в непредсказуемой среде. В софте эта вариативность реализуется через обширность настроек или платформу с приложениями. Если вы решили делать софт на рынке с большим разнообразием контекстов — нужно делать систему гибкой. Другого пути просто нет. Сразу скажу, что обширность настроек — очень стремный путь. Рано или поздно продукт просто умрет из-за внутренней сложности.

Если взять Fibery, то мы пошли от предпосылки большого разнообразия контекстов. На самом деле за годы эксплуатации Targetprocess мы выяснили, что компании работают очень разнообразно. Их процессы часто уникальны и выдвигаемые требования хрен реализуешь в рамках одного целостного продукта. Поэтому, если мы хотим быть на рынке систем управления проектами, мы должны заложить в генотип Fibery значительную гибкость.

Что интересно, сам факт закладывания этой гибкости приведет к тому, что Fibery будут чаще использовать в самых непредсказуемых и разнообразных контекстах. Мы получаем очень веселый positive feedback loop:

Гибкая система → неожиданное использование → требование еще большей гибкости.

Пока сложно представить, к чему это все приведет. Но кажется впереди у нас много веселых бесед об эволюции, сложности и качестве 🌶.