Post #434

В выступлении Димы Безуглого на ЛАФ (посвященного, как обычно, переходу к продуктовому мышлению и переходу задач аналитиков к разработчикам) мне больше всего понравился вопрос из зала: а как же разделение труда, ведь по экономическим законам для повышения производительности каждый работник должен стать специалистом в своем деле, а смежные операции отдать другим. Почему же тогда не усугубляется разделение на аналитиков разных видов и разработчиков, а наоборот — исключение и объединение ролей? (если, конечно, такой эффект действительно наблюдается). Вопрос интересный и заслуживает отдельного исследования, а не коротокого ответа. Во-первых, разделение труда в разработке явно есть — как внутри отрасли, так и внутри отдельных компаний. Интересны примеры отраслевого разделения труда — когда часть работы может быть легко заказана у другой компании. Это мы видим повсеместно в части эксплуатации, очень часто — в дизайне, в создании документации, иногда — в тестировании. Очень редко встречается аутсорсинг системного или бизнес-анализа (а вот аутстаффинг бывает чаще), и почти никогда — аутсорсинг архитектуры. Вот что есть всегда и в любой разработке — разделение труда между авторами библиотек и фреймворков, и авторами конечных решений. Это в чистом виде разделение труда, сюда же можно добавить производителей средств производства: языков, редакторов, средств отладки и мониторинга и т.п. Так что с разделением труда в разработке всё в порядке. Местами. Улавливаете точки, в которых промежуточные рабочие продукты могут быть легко переданы? Там, где они формальны и имеют хорошую изоляцию абстракций. Дизайнер передаёт разработчику макет — он формален, его реализацию легко проверить, и он абстрактен — дизайнеру не нужно пояснять, как именно сверстать и запрограммировать код, чтобы на выходе получилась именно эта картинка. Инженерам по эксплуатции не нужно знать — как именно написан код (только его внешние зависимости, в лучшем случае) и что он вообще делает. Тестировщикам не обязательно знать внутреннее устройство программы, чтобы её протестировать. С аналитиками это тоже срабатывает, если результат формализован. Если на выходе у вас спека в сваггере — вашу работу можно вычленить и отделить от разработки. Наверное. Вся проблема в протечке абстракций. Они текут и у дизайнеров, и у девопсов, и у QA. Но у аналитиков это просто дырявый зонт. "Закон дырявых абстракций" говорит, что любая нетривиальная абстракция дырява, то есть не может игнорировать способ реализации. А системные аналитики находятся очень близко к реализации, и граница абстракции вообще начинает плыть. Извечный вопрос: что давать на вход разработчикам? Не слишком абстрактно, чтобы для них вообще было понятно, что делать; и не слишком конкретно, чтобы они не говорили "а на самом деле удобнее и правильнее сделать не так а вот так". Поэтому в этом месте разделение труда противоестественно, материал сопротивляется. Этот пост во многом для тех, кто проектирует процессы и определяет шаблоны рабочих продуктов. Проверьте себя: какой уровень абстракции вы выдерживаете в документах? Какие аспекты реализации вы не учитываете? Это в СА не так естественно происходит, как в других областях, поэтому стоит зафиксировать в явном виде: до какого уровня ещё имеет смысл прописывать, а где уже изолируемся от реализации. Какие формализмы вводим? Хинт: чем их больше, тем легче изолироваться и разделять труд. Формальный текст всегда лучше, чем свободный текст, а ещё лучше — формальная таблица или диаграмма. DSL с проверяемым синтаксисом — ещё лучше. OpenAPI, TypeSpec — вот такие штуки. Vanessa Automation для 1С. Я даже видел, как в некоторых проектах сначала придумывают DSL, а потом все требования и спецификации фиксируют на нём — высокий класс. В принципе, DDD тоже про это отчасти.