Release
- Consult everyone involved: release coordinators, infrastructure, documentation, QA, the project manager, other dev teams with dependencies, and marketing.
- Know the release type. A major release goes to every customer, is big, risky and coordinated across teams, and is the most important effort in the company while it happens. A minor patch goes only to the customers who need it and is coordinated by the teams involved.
- Documentation is your responsibility. Every product change should be documented: feature documentation, release notes and use cases. Capture screenshots and video as you go.
- Validate every requirement. For contract work, check that each requirement was met using acceptance test procedures, plus playtesting by use case. Validation can start early but must be re-confirmed at the end, because new work can break old work.
Maintenance and Support
- Customer acceptance testing. After delivery, customers test against the requirements and produce a list of defects. Attend if you can, and bring people who know the design; it’s far easier to resolve misunderstandings in person. The development team estimates each item and gives an opinion on whether it’s in scope.
- Unclear bugs. When it isn’t clear what the “correct” behavior is, it isn’t a bug yet. It needs investigation, design discussion and a product decision first.
- Support requests. As a rule, if you can solve it in under an hour, do it. If it’s bigger, get your lead’s approval. Either way, ask the question behind the question; people rarely explain their real use case unless you ask.
- Small paid requests are mini-projects: the same lifecycle on a much shorter timeline. Keep scope minimal and suggest alternatives.