Обзор
Я решил проверить на заземлённость и конкретность текст, который родился из моей фрустрации по поводу низкой скорости и трудоёмкости релизов одного из ключевых программных компонентов. От этого компонента зависит много других, но при внесении в него изменений, быстрой обратной связи о качестве и интегрируемости нет. Интегрирование происходит вручную при подготовке к релизу. Тогда и выясняется, что многое сломано, и нужно переделывать что-то, над чем “поработал” кто-то другой какое-то время назад.
В тексте я предлагаю перейти к модели Continuous Delivery / Continuous Integration для
этого компонента, с автоматической проверкой изменений, в том числе в составе использующих его систем.
Разбор LLM
LLM/FPF раскритиковала текст по делу. Она посчитала его близким к ProblemCard.
The document is directionally specific but operationally underspecified, and closely motivated but weekly evidenced. It is strong enough to initiate the dependency discovery, baseline measurement, and ownership negotiation; it is not yet strong enough to authorize or coordinate implementation as a complete WorkPlan.
Согласен, что я пишу “релизы недостаточно частые” – но не пишу что это значит конкретно. То же самое про “релизы трудоёмкие”, “требуются частые переделки”.
Также согласен, что текст смешивает проблемы и решения, навязывая решения как необходимые без обоснования (“медленные релизы, значит нам нужно Continuous Integration”), тогда как должен говорить о возможных решениях как о гипотезах.
LLM также предложила хороший план переделки документа, включающий проработку следующих пунктов: System and scope, Measured baselines, Acceptance criteria, Candidate architecture and validation, WorkPlan.
Сомнения
LLM показала как качество моего текста далеко от приемлемого, и чтобы его улучшить, придётся сделать замеры (и ещё много о чём подумать). От этого опускаются руки, и кажется, что проще потратить пару дней на подготовку релизов чем даже просто написать хорошее обоснование. Думаю всё равно попробовать конкретизировать текст, даже с неидеальными оценками/замерами. Может оказаться не так всё страшно.
Ещё, размышляя над ситуацией, понял, что меня особо фрустрирует то, что изменения в компонент вносят одни люди (которые не думают о всех “потребителях/пользователях” их кода), а интегрировать/чинить приходится мне. Здесь вижу две проблемы
- Признаю, что это потенциально разбалансирует мою оценку ситуации. Мне не хочется чинить сломанное другими (то есть заниматься интеграцией), но может быть мы бы просто могли найти кого-то, кому бы такая работа нравилась, и проблема была бы решена.
- Вероятно, проблема даже глубже чем отсутствие быстрой обратной связи об изменениях. Этот компонент ключевой, но “бесхозный”. Поэтому в него вносят изменения все кому не лень, для решения их сиюминутных проблем, без оглядки на потребности других пользователей компонента или на архитектуру. Мне кажется более важным найти этому компоненту хорошего хозяина перед тем как думать о Continuous Integration, но все мои попытки не увенчались успехом. Когда я спрашиваю шефа, чей это компонент, он говорит “наш”, имея в виду несколько команд, которые над ним работают – для меня это всё равно что сказать “ничей”.