WMF product development process

From MediaWiki.org
Jump to: navigation, search
Change@WMDE.jpg

Overview[edit]

Wikimedia Foundation Product Development has a set of phases that centers on tasks and potential stakeholders involved. The high level draft presented is a set of tasks and stakeholders involved in our current and future development.  This was evolved from an earlier draft review that incorporated feedback from multiple processes and expectations.

The tasks and stakeholders presented are a general guideline and potential checklist.  Each team may have its own mix of responsibilities or stakeholders, and some phases may not apply.  Community involvement or interaction is expected throughout the phases, ideally through established team or feature feedback mechanisms and in collaboration with our Community Liaisons.

What problems does this solve[edit]

We support many types of development, which involve stakeholders inside and outside of the Wikimedia Foundation. Product development process within WMF teams is highly variable. Projects vary according to the length of their timelines, software complexity, resource allocation, and development methodologies used. Different projects also require the involvement of different stakeholder groups at different points.

All of this variation can lead to failures of due diligence at different stages of development: key stakeholders may not be included at relevant points in the process, decisions may not be communicated effectively, and the project status may not be publicly documented and kept up-to-date.

The framework is intended to reflect how we will evaluate, review and release software going forward, in order to enhance stakeholder confidence in our methods, ensure legal and security compliance, increase code quality and performance, and ensure overall product quality and timely release. It provides a general set of development checkpoints that may be useful for ensuring a transparent, inclusive, and consistent process that is flexible enough to accommodate the needs of different projects.

Product checkpoints[edit]

These checkpoints are used both for development of whole products (months to years) and features within products (days to weeks), so this chart represents an agile software development process. Once a product or feature enters the maintain phase, new understanding, concepts or features may be identified and start the whole process again. The key element is analyzing and learning from both user feedback and quantitative data to inform product development.

Iteration <---- Bugs, Analysis & Feedback <---- Bugs, Analysis & Feedback
Checkpoints Understand > Concept > Plan > Develop > Release > Maintain
Tasks

Define Problem
Research
Understand Users
Analyze/Synthesize

Evaluate
Define Impact
Analyze Technical Debt
Mission Alignment
Consult Stakeholders

Output
Outcomes (Metric)
Resources & People
Milestones
Dependencies
Maintenance

Prototypes
Mockups & A/B Tests
Surveys
User Sessions
Workflow Backend Development
Frontend Development
Performance Checks
Code Quality

Stakeholder go/no go
Announcements
Community Events
Analysis
Triage Issues

Retrospective
Feedback
Metric (Impact)
Improvements

WMF Stakeholders

Product Manager
User Experience
Engineering
Community Liaisons
Communities
Design Research
Research & Data
Partnerships
Communications

Product Manager
User Experience
Engineering
Community Liaisons
Communities
Design Research
Research & Data
Partnerships
Communications

Product Manager
User Experience
Engineering
Community Liaisons
Legal
Security
Communications
Team Practices
Release Engineering
API/Services

Product Manager
User Experience
Community Liaisons
Design Research
Research & Data
Data Analysts
Engineering
Operations
API/Services
Performance
Team Practices
Architecture

Product Manager
Community Liaisons
Release Engineering
Legal
Security
Communications
Operations

Product Manager
Community Liaisons
Design Research
Research & Data
Data Analysts
Performance
Security
Operations

To illustrate a better model of iteration across the whole set of checkpoints we include this additional element. The table above is used to talk to the data points involved and that is hard to include in a cyclical design like below. There are still many chances for iteration in each of the checkpoints. We also provided an additional diagram to show how time may factor in for each checkpoint.

Iterative Cycle of Development
Understand
Maintain Concept
Release Plan
Develop
Time Scale Development
U C P D R U C P D R U C P D R U C P D R M
M
M
M

Understand[edit]

Generative research and a checkpoint where you get to know users and their context. This is where you define problem & opportunities and analyze and synthesize (see patterns, gain insights) understanding. Understanding could come from our communities, Community Liaisons, internal Product Audiences, Design Research, Research & Data, Partnerships and Communications.

Concept[edit]

New feature proposals and submissions for current problems or new ideas.  These items could involve or be generated from areas like general discovery or ideation, research, technical debt and/or strategy.  Submissions could come from our communities, Community Liaisons, internal Product Audiences, Design Research, Research & Data, Partnerships and Communications.

Plan[edit]

Planning and prioritization involve defining the inputs (people, forecasting, resources), outputs (tasks), outcomes (metrics), defining milestones, dependencies and maintenance tasks. These tasks are driven by Product Managers, Engineering and User Experience and may include participation, validation or checkins with Communications, Team Practices, Security, Community Liaisons, API/Services, Release Engineering and Legal teams.

Develop[edit]

Backend and front-end development takes place and carry the selected concept forward to implementation.  Quality and performance are important checks.  If any issues or bugs are found the feature may roll back to Design depending on the severity of issues found. Testing via labs, prototyping, a/b tests, surveys, flow analysis, user sessions, and community validation of progress. The tasks are driven by Product Managers, Engineering and User Experience and could include participation, validation or checkins with Research & Data, Architecture and Operations, Data Analyst, Community Liaisons, Operations, Team Practices, API and Services, Performance and Architecture. Bugs, analysis and feedback in this round can send features back to the design phase.

Release[edit]

Reviews by dependent stakeholders from the concept stage to validate concept completion. Community review and initial feedback on the development may influence release & rollout timing.  Teams will be analyzing performance and adoption.  If any issues or bugs are found the feature may roll back a stage or two depending on the severity of issues found. Announcements or events may also be created around releases.  These tasks could apply to alpha, beta and production level feature releases. The tasks are driven by Product Managers, Communications, Community Liaisons, Release Engineering and could include participation, validation or checkins with Operations, Legal, and Security. Bugs, analysis and feedback in this round can send features back to the build phase.

Maintain[edit]

After a feature is released ongoing maintenance is measured through feedback loops and analysis, retrospectives, metrics and impact reviews and identification of improvements. Community review and feedback on real usage and interaction is measured and teams will be analyzing performance and adoption.  Improvements or new features restart the process and planning and milestones will be created. The tasks are driven by Product Managers, Performance, Data Analysts, Design Research, Research & Data, Community Liaisons and Security. Any iterations to the product will result in the process restarting.

Current product roadmap[edit]

Related projects[edit]

Comments[edit]

  • (Please don't move this comment to a talk page unless it's a wikitext talk page. Of course, please keep discussion on the wiki.) Why are terms like "Community members" capitalised and sometimes written "Community Members" even? Is the uppercase referring to some special definition of the term for the purpose of this document (I don't see one)? I'd be interested in understanding why the "Understand" part doesn't mention end users, maybe they are included in a special definition of "Community member" but we don't know. Nemo 07:40, 29 January 2016 (UTC)
  • The "generally are" and "are generally driven" sentences are unclear, for instance how can you Plan and Release without coordinating with the end users/target wikis and how can Develop not consider volunteer developers and developers of other areas? Worse than that, the phases are of little use if you don't describe how to (not) proceed from one to the next. The most common need is to halt an idea at the "Understand" phase, avoiding that it ever reaches the "Concept" or "Plan" phase. How do we kill bad ideas on time? Nemo 07:51, 29 January 2016 (UTC)
  • As of May 2016, we still see projects which are in the implementation phase and even in quarterly goals without ever being even described in public (a description may be, or not, in the private Google Doc linked from the task). Nemo 19:56, 25 May 2016 (UTC)

See also[edit]

Subpages: