Проєктний менеджмент для Фаундерів та Соло-розробників

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Вітаю, спільното 👋

Вступ

Зараз працюю над одним власним проектом — платформа для керування середовищами, що орієнтована на розробників та тестувальників. У процесі виникла гостра потреба якось зафіксувати scope робіт.

Постійно кортіло додати нову фічу чи чергове «покращення», як то кажуть, «щоб було» , що породжувало купу нових багів, кількість яких росла в експоненціальному порядку. Прийшло розуміння, що в такому режимі продукт ніколи не побачить реліз.

Наш люб’язний друг Anthropic Claude 4.5 порекомендував зосередитись на MVP — сукупність 2-3, максимум 4 базових фіч, і довести їх до ідеалу.

Так і зробив: з поточного моменту заборонив собі додавати нові фічі.

Крок 1: Все є багом

Так як чітких requirements просто не існувало, лише приблизне уявлення в моїй голові що і як має працювати, я вирішив зосередитись тільки на багах, простіше кажучи

Тепер будь яку нову фічу можна вважати багом, якщо використовувати спеціальний синтаксис

Прийшла ідея додати режим «черги» для користування середовищем? Чудово, ось як запишемо:

As a user:

— I expect to be able to Queue my booking

— And to be able to set a desired duration for my booking entry in the queue

— When I’m on the «New booking page»

— And the values of the «Environment» and «End date» fields are valid

— And the value of the «Start date» field is valid or the «As soon as possible» switch has been set to «true»

— And the selected environment is currently being used

З’явився новий дефект? Ще краще:

As a user:

— I expect not be able to save my profile information

— When the values of the Full name or email fields are missing or invalid

Крок 2: GitHub Copilot + Markdown

Виникає, питання, де це все зберігати, як трекати баги/фічі etc? Не маючи бажання розбиратись з цими всякими Notion, Jira, Miro, Asana і так далі, зупинився на простому поєднанні Markdown + VS Code + Copilot. Ось як виглядає алгоритм:

  • Спочатку просто записуємо всі наші багофічі в форматі звичайного списку
  • Вводимо prompt та чекаємо фінального результату

> Calculate and set severity via heuristics and assign each bug its severity and ID, next group by severity, in each group then add common area badge, for example «Login Page», next add check boxes to track whether a bug has been fixed

Крок 3: Workflow

Щоб оновити статус баги, пишемо в чат :

> BUG 28 — fixed

Щоб додати нову багу:

> New bug (please strictly follow the existing specification conventions) — When I press left or right arrows I expect the current loaded bookings to be updated appropriately (only mobile version)

Щоб зрозуміти прогрес:

> How would you describe my progress? Am I moving as fast as I can towards the release point?

Крок 4, для особливо просунутих: Copilot + Playwright MCP Server

Не буду вдаватися в подробиці, як підключити MCP до свого ШІ-агенту, перейду одразу до справи: Playwright MCP дозволяє вашому ШІ — Claude, Copilot, Cursor — отримати повний доступ до веб-браузера. Він може робити Snapshot та бачити, що зараз відбувається на сторінці, натискати кнопки, заповнювати форми, робити знімки екрану etc. Таким чином, можна змусити ваш ШІ перевіряти баги в автоматичному режимі:

> Using Playwright tools, open my app example.com and verify all the bugs in the current document

Або на основі того, що він бачить на екрані, скласти тест кейси та тест плани для регресії (звісно, набагато краще було б написати автоматизовані тести з тим же Playwright, але їх буде легко згенерувати, щойно в нас є мануальні тест кейси):

> Using Playwright tools, open my app example.com and generate a comprehensive list of test cases and group them under test plans. Aim for 100% functional coverage

Крок 5: Burndown chart

Мабуть, найцікавіше — візуалізація:

> Apply some weighted heuristics, and draw a burn down chart , where X-axis represents a timeline from [date] and Y-axis represents remaining weighed severity points. Use python to visualize

Має вийти щось на зразок цього

Дякую за увагу.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Все вже вигадали до нас :)

Я так розумію мова йде про застосування та впорядкування вимог. Є така річ як SDD (Spec Driven Development)

Я б порадив подивитись на OpenSpec (openspec.dev) маю позитивний досвід з ClaudeCode але підтримує й багато інших агентів.

Також є й альтернативи, Сама методологія та деякі альтернативи розглядаються тут martinfowler.com/...​g-gen-ai/sdd-3-tools.html

Ви згенерували mvp, зарепортили 67 багів різної степені важливості — і воно просто почало баги фіксити денно і нощно?
Цікаво, а скільки коштує той ваш вайбкодинг за день чи як він там тарифікується?

Стаття почалася зі згадування Claude, на нього також витрачатися прийшлося?

Підписатись на коментарі