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.