Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
(No, It’s Not Just Kanban)
? Why We Built Our Own Workflow
We didn’t borrow this process from some blog post.
We built it ourselves — as a team of engineers, PMs, QA, and designers at , after years of trying to force messy startup projects into rigid Agile templates that just didn’t fit.
Over the past five years, we’ve shipped 100+ products for early-stage startups — across fintech, healthtech, B2B SaaS, you name it.
We’ve worked with non-technical founders, legacy code, and ideas that pivoted five times in one sprint.
We tried Scrum. We tried Kanban. We tried “organized chaos.”
None of it worked out of the box. So we stopped trying to follow frameworks and started building a system that actually worked for how we build.
Since then, we’ve cut tech debt by 37%, reduced rework, and finally stopped hearing “wait, who’s doing QA on this?” at every standup.
Here’s how we run it — for real.
? What Actually Changed
We didn’t invent anything revolutionary — we just made the process impossible to ignore.
? Our Full Task Lifecycle
Open → Clarify Details → In Progress → Code Review → QA
→ Ready to Release → Release → Verified → Reopened → Completed
? Stage-by-Stage Breakdown
1. Open
Well-defined task with a clear goal, ready for devs to pick up.
2. Clarify Details
Blocked by missing input? Held until we fix that. Saves rework later.
3. In Progress
Actively being worked on. Time logged. Sub-tasks if needed.
4. Code Review
Peer-reviewed via GitHub. No solo merges. Feedback is logged.
5. QA
Tested on staging across flows, devices, edge cases. Real test cases — not vibes.
6. Ready to Release
Passed QA. PM signs off before deployment.
7. Release
Pushed to prod via standard checklist.
8. Verified
QA confirms post-release behavior in production.
9. Reopened
Returned from review, QA, or prod smoke test. Always with a comment.
10. Completed
Done = done. No open questions, no TODOs in code, no “we’ll test it later.”
? Tools We Use (and Why)
Everything is linked. Used daily. Tracked by default.
? What Helped Cut Tech Debt
? Clarify Before You Build
We don’t allow vague tickets into the sprint. If the goal isn’t clear, it sits in Clarify.
? Reopened = Tracked State
No shame. No ping-pong. Clear comments. Same assignee. Fast turnaround.
? Time Tracking ≠ Micromanagement
We log hours to forecast better. Not to police anyone.
? Want to Use This Setup?
We documented the whole system: statuses, transitions, responsibilities, and best practices.
?
Or — if you’re planning a product from scratch — generate a full tech plan (features, stack, deadlines, team roles) in 3 minutes:
?
? Why We Built Our Own Workflow
We didn’t borrow this process from some blog post.
We built it ourselves — as a team of engineers, PMs, QA, and designers at , after years of trying to force messy startup projects into rigid Agile templates that just didn’t fit.
Over the past five years, we’ve shipped 100+ products for early-stage startups — across fintech, healthtech, B2B SaaS, you name it.
We’ve worked with non-technical founders, legacy code, and ideas that pivoted five times in one sprint.
We tried Scrum. We tried Kanban. We tried “organized chaos.”
None of it worked out of the box. So we stopped trying to follow frameworks and started building a system that actually worked for how we build.
Since then, we’ve cut tech debt by 37%, reduced rework, and finally stopped hearing “wait, who’s doing QA on this?” at every standup.
Here’s how we run it — for real.
? What Actually Changed
Technical debt dropped by 37%- Onboarding time for new devs got 2× faster
- QA started catching edge cases before prod
- Fewer misunderstandings, more ownership
We didn’t invent anything revolutionary — we just made the process impossible to ignore.
? Our Full Task Lifecycle
Open → Clarify Details → In Progress → Code Review → QA
→ Ready to Release → Release → Verified → Reopened → Completed
? Stage-by-Stage Breakdown
1. Open
Well-defined task with a clear goal, ready for devs to pick up.
2. Clarify Details
Blocked by missing input? Held until we fix that. Saves rework later.
3. In Progress
Actively being worked on. Time logged. Sub-tasks if needed.
4. Code Review
Peer-reviewed via GitHub. No solo merges. Feedback is logged.
5. QA
Tested on staging across flows, devices, edge cases. Real test cases — not vibes.
6. Ready to Release
Passed QA. PM signs off before deployment.
7. Release
Pushed to prod via standard checklist.
8. Verified
QA confirms post-release behavior in production.
9. Reopened
Returned from review, QA, or prod smoke test. Always with a comment.
10. Completed
Done = done. No open questions, no TODOs in code, no “we’ll test it later.”
? Tools We Use (and Why)
- YouTrack – flexible workflows, fast UI, ideal for Agile structure
- GitHub – PR reviews, CI integration, task-linked commits
- TestRail – structured test cases, traceability, clean QA feedback
- Figma – organized design handoff, responsive previews
- Slack – only public channels. No DMs. Context matters.
Everything is linked. Used daily. Tracked by default.
? What Helped Cut Tech Debt
? Clarify Before You Build
We don’t allow vague tickets into the sprint. If the goal isn’t clear, it sits in Clarify.
? Reopened = Tracked State
No shame. No ping-pong. Clear comments. Same assignee. Fast turnaround.
? Time Tracking ≠ Micromanagement
We log hours to forecast better. Not to police anyone.
? Want to Use This Setup?
We documented the whole system: statuses, transitions, responsibilities, and best practices.
?
Or — if you’re planning a product from scratch — generate a full tech plan (features, stack, deadlines, team roles) in 3 minutes:
?