1d • General discussion
Define Done Before You Build
Command note: "it's built" and "it's done" are not the same claim, and treating them as one is how obvious gaps make it to launch.
Every build needs a definition of done written down before you touch the account — not a feeling you check for at the end.
What "done" should name, in writing, before you start:
• Which objects must exist — pipeline, stages, fields, tags, calendars, workflows
• What each one must actually do, not just that it exists (a workflow that fires vs. one that's merely published)
• Who signs off — you, a second set of eyes, or the client
• What a passing check looks like for each piece, specifically
Do this on the next build, before you open the account:
1) Write the definition of done on one page — one line per object, plainly stated
2) Build against that list, not against memory or a template you half-remember
3) When you think you're finished, read the account back against the same list
4) Only call it done when every line checks out — not when the build finished without an error
A build that ran without errors and a build that's actually done are two different claims. Decide which one you're promising before you start, and you'll stop mistaking the first for the second.
0
0 comments
Define Done Before You Build
Suggested communities
Powered by