Назад

# Разделение на продукт, технологию и "экосистему/код/расходы" Tags: мысли, бизнес, разработка Решил структурировать и более внятно выразить свои мысли по поводу разделения разработки софта на слои. Как со стороны бизнеса, так и со стороны программиста, я выделил 3 слоя: 1. Продукты - продукры, которые развиваются в компании, либо которые разрабатывает программист. 2. Технология - экспертиза компании, либо методы, которые применяет программист в широком спектре своих проектов, которые упрощают/ускоряют развитие продуктов. 3. Экосистема/код/расходы - в общем, все остальное, относящееся исключительно к одному продукту, использующемуся в одном продукте, либо у одного программиста. Нужно вкладываться в первые две, из третьей категории стараться переместиться во вторую (без фанатизма, конечно). Вылизывать код, взять новый фреймворк в проект - 3 вариант. Развить свой фреймворк, внедрить фреймворк в компании - 2. Настроить сбор телиметрии - 3, универсальный мониторинг продуктов - 2, сервис мониоринга - 1. Пример перемещения: в двух проектах используются свои системы сборки, они заточены строго под продукт. Одну систему сборки (или обе, по необходимости) делают более динамичной, подходящей под большое количество продуктов. Теперь эта система сборки из "бремени" конкретного продукта превратилось в технологию компании, которая позволяет развивать другие продукты более эффективно, с меньшими затратами (затраты на платформу будут поделены на количество продуктов). Конечно, делать это следует, если сложность системы сборки не повысилась в разы, нивелировав пользу размазывания стоимости ее поддержки. Еще пример: в одном проекте (может даже одним программистом) используется статический анализ кода. Другим программистом используется другой анализатор. (для компании: программист уйдет, этого анализа не станет). Можно внедрить статический анализ на всех продуктах, сделать ее обязательной, либо начать пропаганду "хорошего тона в программировании" с использованием этого статического анализатора. Желательно при этом, остановиться в выборе на конкретном анализаторе (в случае компании <100 человек), чтобы более продуктивно развивать экспертизу по этому инструменту в компании. Стандартным средствам работы проще научить новых разработчиков, привить им привычки, даже если эти привычки будут осуждаться: "мне надоело постоянно запускать indent" - но раз все это делают и пользу это приносит, новый человек тоже захочет научиться и стать "более профессиональным", разбираться в технологиях компании. (тут хорошо подходит bash, php, mc) Для разработчика: используя дома vim, а на работе mc ты не концентрируешь свой навык. Применяя одно средство во всех проектах, пропагандируя его коллегам, объясняя вслух его преимущества в ожесточенных дебатах - ты максимизируешь свои знания в этом предмете, максимизируешь "полезный выхлоп" от этих знаний, структурируешь их, получая технологию, которой ты будешь пользоваться всю жизнь. Если "объем" тенологии позволяет перевести ее в продукт (на гитхабе в opensource, либо продавать клиентам за бабло) - повысит на порядок твою вовлеченность, повысит компетенцию, заставит учитывать мнения других, смотреть на конкурентов. Ну и денег заработать, если повезет. Третий вариант - это стандартная работа разработчиков продукта. Это все нужно делать, нужно делать это хорошо. Но нужно не забывать первые 2 слоя и стремиться к ним, как к возможному идеалу, критически оценивая, принесет ли это достаточно пользы. ----------- После написания статьи, ко мне пришел чувак, который в этом что-то понимает и сказал, что я опаздал лет на 5-10. Сейчас в компаниях ценятся мета-технологии и мета-менеджмент, который может под конкретную задачу максимально быстро создать, выбрать, внедрить и использовать технологии, даже принципиально новые. Создать команду, включая все: от офиса с чаем, до юристов и директоров. Посмотреть по этой тематике посоветовали [Германа Грефа, когда он вернулся из силиконовой долины](https://www.youtube.com/watch?v=Mg76y7N8Xn0) (надеюсь, видео нужное), где он вещает за Agile. Сам я еще не ознакомился с этим.