BD gr-product-dev-ops
Ваша команда разработчиков выпускает функции, которые никто не запрашивал, в то время как сообщенные пользователями ошибки накапливаются месяцами. Операционный отдел винит разработку в игнорировании пользователей; разработка винит операционный отдел в непонимании технических ограничений. Это дает вам полный SOP по согласованию продукта, разработки и операций — от единого бэклога до 10-дневного спринта и правил права вето. Что внутри: • Двухуровневая система Kanban (основной бэклог + доска спринта с унифицированной маркировкой) • Стандартный 10-дневный процесс спринта (День 1 разработка → День 6 сборка для тестирования → День 10 выпуск) • Шаблон задачи с требованиями к воспроизводимости (3 упоминания = авто-приоритет) • Трехсторонние совещания по согласованию (ежедневный стендап / планирование спринта / обзор спринта) • Право вето операционного отдела на релизы (ошибка P0 = блокировка выпуска) • Обратная связь от пользователей → замкнутый цикл итераций продукта (бета-тестирование + опрос) • Основная структура метрик (привлечение → активация → удержание → монетизация → рефералы) • Управление техническим долгом (резерв 20-30% мощности спринта) • Готовые шаблоны: Отчет об ошибке, Планирование спринта, Матрица ответственности. Создано на основе: Реальных совещаний по продуктовой стратегии + фреймворков бета-тестирования. Ссылки на модель спринта Supabase, коммерциализацию Manus/DeepSeek. Автор @WeiYipei. Триггеры: "product ops" | "engineering operations" | "product development SOP" | "sprint planning" | "iteration management" | "cross-functional alignment" | "product engineering ops" | "dev ops collaboration" | "产研运协同" | "迭代管理" | "产品研发运营" | "プロダクト開発運営" | "제품개발운영"
машинный переводПоказать оригиналСкрыть оригинал«🇺🇸 Your dev team ships features nobody asked for while user-reported…»
🇺🇸 Your dev team ships features nobody asked for while user-reported bugs pile up for months. Operations blames engineering for ignoring users; engineering blames operations for not understanding technical constraints. This gives you the complete Product × Engineering × Operations alignment SOP — from unified backlog to 10-day sprint cadence to veto power rules. What's inside: • Dual-layer Kanban system (master backlog + sprint board with unified tagging) • 10-day sprint standard process (Day 1 dev → Day 6 testable build → Day 10 ship) • Issue template with reproducibility requirements (3x reported = auto-severe) • Tri-party alignment meetings (daily standup / sprint planning / sprint review) • Operations veto power on releases (P0 bug = block shipping) • User feedback → product iteration closed loop (beta testing + interview SOP) • Core metrics framework (acquisition → activation → retention → monetization → referral) • Technical debt management (20-30% sprint capacity reserved) • Ready-to-use templates: Bug Report, Sprint Planning, Responsibility Matrix Built from: Real product strategy meetings + beta testing frameworks. References Supabase sprint model, Manus/DeepSeek commercialization alignment. By @WeiYipei. 🇨🇳 你的研发团队在做没人要的新功能，用户反馈的 Bug 堆了三个月没人动。运营觉得研发不听用户，研发觉得运营不懂技术。这份 SOP 给你从统一看板到 10 天迭代节奏到一票否决权的完整产研运协同框架。 🇯🇵 開発チームは誰も求めていない機能を作り、ユーザーから報告されたバグは何ヶ月も放置。このSOPは、統一バックログから10日スプリント、リリース拒否権まで、プロダクト×エンジニアリング×オペレーションの完全な連携フレームワークを提供します。 🇰🇷 개발팀은 아무도 요청하지 않은 기능을 만들고, 사용자가 보고한 버그는 몇 달째 방치됩니다. 이 SOP는 통합 백로그부터 10일 스프린트, 릴리스 거부권까지 제품×개발×운영 완전 협업 프레임워크를 제공합니다. Triggers: "product ops" | "engineering operations" | "product development SOP" | "sprint planning" | "iteration management" | "cross-functional alignment" | "product engineering ops" | "dev ops collaboration" | "产研运协同" | "迭代管理" | "产品研发运营" | "プロダクト開発運営" | "제품개발운영"
Ваша команда разработчиков выпускает функции, которые никто не запрашивал, в то время как сообщенные пользователями ошибки накапливаются месяцами.
Как процесс D 49/100 · Процесс не доведён — слабые места: результат и критерий готовности, когда включается, входы и предусловия
Как улучшить
- Сократите description до 1024 символов.
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 5. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
- ошибка
description-longdescription 1855 символов, лимит 1024 - заметка
description-budgetdescription занимает 1855 из общего бюджета ~15000 символов на все скиллы - заметка
frontmatter-keyнеизвестное поле фронтматтера "source"
Процессный рейтинг: все десять параметров 49/100
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 0Ошибки и развилки. Линейный процесс без обработки сбоев
- 0Отчётность по ходу. Скилл ничего не сообщает по ходу работы
- 20Когда включается. Не сказано, при каком запросе скилл включается
- 40Согласованность. Имя во frontmatter (gr-product-dev-ops) не совпадает с папкой (product-dev-ops-playbook)
- 100Инструменты и файлы. Внешние инструменты не нужны
- 100Шаги. Шагов: 14
- 100Стоимость исполнения. Тело инструкции 2189 токенов
- 100Повторный запуск. Изменяющих операций нет
- low Разделов верхнего уровня: 15. Похоже на несколько доменов в одном скилле
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Длина description 1854: рекомендуется 120–800 символов
- +3Формат ответа не описан: модель каждый раз решает сама
- +1Лицензия не указана
- +2Инструкции на одном языке
- +5В description 11 примера фраз-триггеров в кавычках
- +4Структура: 38 заголовков
- +3Пошаговые инструкции: 14 пунктов
- +4Есть примеры (7 блоков кода)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 57.