Developer Relations - bcgov/common-service-showcase GitHub Wiki
Areas of Impact
- Ability to scale our services without needing to linearly scale the number of people on our team
- Organizational awareness of the value our team is providing
- Connecting with other product teams, and having them engage with us, making noise
- Having a clear strategy that shows how we are measuring impact
Developer Experience Research
Problem Statement Definition
- Helps PO to create the roadmap
- Who are the stakeholders and user personas?
- What problems do they want us to solve?
Marketing Publication about the vision for
- Common Services that a team hosts for others to make API calls to and request access to,
- Common Components for teams to run themselves,
- Shared Libraries for teams to reference in their code,
- Examples Applications to demo capability,
- Code Template to show implementation
- Teams creating their own common services and contributing back to the community (public, bcgov, etc)
- The mindset and architectural decision to build it to share
Measure Value of features
- Operations, continuing to support
- User group that we could reach out to, to check in on how we are doing
- Score/metrics for feature health, accessibility, reading level (best practices)
Acceptance Testing
- For new features that we are building
- Formal user engagement sessions (demos, observation testing)
- Task completion success rate, time to complete, experience
- Identify acceptance tests that could be automated (each acceptance test should have a business case for its existence)
AAARRRP
Awareness, Acquisition, Activation, Retention, Referral, Revenue, Product
"Pick work that has a high AAARRRP score" See the Introduction to AAARRRP for an example of how to score your efforts.