Content
View differences
Updated by Niels Lindenthal about 2 years ago
# User Problem
## User
_What persona, persona segment, or customer type experiences the problem most acutely?_
* Project manager
* Project member
* Product owner
* Release manager
* Project controller
* Project steering board
## Problem
_What problem or job does the user have?_
> Currently we can only fetch all the work packages per day (using baseline):
>
> `https://community.openproject.org/api/v3/projects/openproject/work_packages?filters=[{"version": {"operator": "=", "values": ["1486"]}}]×tamps=2023-01-01T00:00:00Z`
>
> Currently need * Wants to do it per day to know when the status/version was changed. We can do something similar by filtering for the current status and then iterating over of the different status that exist: project.
>
> `https://community.openproject.org/api/v3/projects/openproject/work_packages?filters=[{"version": {"operator": "=", "values": ["1486"]}}, { "status": {"operator": "=", "values": ["1"]}}]×tamps=2023-01-01T00:00:00Z&pageSize=0` * Wants to understand risks as early as possible.
>
> That way you wouldn't have * Wants to do understand the counting in excel but could just take the value from the `total` property at the cost velocity of having to fetch the information per day and status (n \* m).
>
> Depending on the number of days this would quickly result in a very large number of requests which our infrastructure would block. team.
## Pain
_What is the primary workaround that users perform that we could remove or replace? Why is it painful?_
* Currently project teams that want to illustrate the progress over time have to regularly export their data to a spreadsheet and build the charts there.
* It is to possible to flexibly get past data.
* Very time consuming and error-prone.
* Sharing of those charts is difficult.
* Other applications such as XWiki can not get those data from our API to draw graphs.
# Solution
_How do we solve the user’s problem. What is our “pain killer”? What must we achieve in the first version of the solution in order to achieve value for the user?_
* Building an API that allows to draw two-dimensional graphs
* X-Axis: time
* Y-Axis:
* Number of work packages grouped by: status, type, project.
* Sums: work, remaining work, spent time
## Out of Scope for the MVC
_What should NOT be in the minimal viable change, and can be considered for future iterations? Why? Please order them by importance._
* Charting (separate work package)
* Replacing the existing burndown chart that is used in the Backlogs module (separate work package)
## Differentiation
_What do you believe will differentiate us from the current experience or competitive experiences?_
* No differentiation - it is a hygiene feature.
## Next iteration
_What is the next solution that would allow us to release meaningful customer value quickly?_
* Building the charts
* Integrate the charts into:
* Wiki macro
* Selectable widget for the Project Overview
* Version details page
# Launch and Growth
## Measures
_How will you know you solved the problem? Please list measurable, quantitative indicators (preferred) or qualitative ways you plan on assessing the solution?_
* Number of SaaS users that activate this feature.
* Access numbers
## Messaging
_If you were to write a press release, how would you describe the value to customers?_
<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><tbody><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Headline</p></th><td class="op-uc-table--cell"><p class="op-uc-p">API to provide project progress over time </p></td></tr><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">First Paragraph</p></th><td class="op-uc-table--cell"><p class="op-uc-p">The OpenProject API now has an endpoint to request progess data over time. This allows the integration with other collaboration tools such as XWiki or BI tools</p></td></tr><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Customer Quote</p></th><td class="op-uc-table--cell"><p class="op-uc-p">Ludovic: "Customers of XWiki want an alternative to proprietory solutions. With the new API endpoint we can now provide our customers an excellent alternative.</p></td></tr></tbody></table></figure>
## Go to market
_How are you planning on getting this into users' hands?_
## User
_What persona, persona segment, or customer type experiences the problem most acutely?_
* Project manager
* Project member
* Product owner
* Release manager
* Project controller
* Project steering board
## Problem
_What problem or job does the user have?_
> Currently we can only fetch all the work packages per day (using baseline):
>
> `https://community.openproject.org/api/v3/projects/openproject/work_packages?filters=[{"version": {"operator": "=", "values": ["1486"]}}]×tamps=2023-01-01T00:00:00Z`
>
> Currently need
>
> `https://community.openproject.org/api/v3/projects/openproject/work_packages?filters=[{"version": {"operator": "=", "values": ["1486"]}}, { "status": {"operator": "=", "values": ["1"]}}]×tamps=2023-01-01T00:00:00Z&pageSize=0`
>
> That way you wouldn't have
>
> Depending on the number of days this would quickly result in a very large number of requests which our infrastructure would block.
## Pain
_What is the primary workaround that users perform that we could remove or replace? Why is it painful?_
* Currently project teams that want to illustrate the progress over time have to regularly export their data to a spreadsheet and build the charts there.
* It is to possible to flexibly get past data.
* Very time consuming and error-prone.
* Sharing of those charts is difficult.
* Other applications such as XWiki can not get those data from our API to draw graphs.
# Solution
_How do we solve the user’s problem. What is our “pain killer”? What must we achieve in the first version of the solution in order to achieve value for the user?_
* Building an API that allows to draw two-dimensional graphs
* X-Axis: time
* Y-Axis:
* Number of work packages grouped by: status, type, project.
* Sums: work, remaining work, spent time
## Out of Scope for the MVC
_What should NOT be in the minimal viable change, and can be considered for future iterations? Why? Please order them by importance._
* Charting (separate work package)
* Replacing the existing burndown chart that is used in the Backlogs module (separate work package)
## Differentiation
_What do you believe will differentiate us from the current experience or competitive experiences?_
* No differentiation - it is a hygiene feature.
## Next iteration
_What is the next solution that would allow us to release meaningful customer value quickly?_
* Building the charts
* Integrate the charts into:
* Wiki macro
* Selectable widget for the Project Overview
* Version details page
# Launch and Growth
## Measures
_How will you know you solved the problem? Please list measurable, quantitative indicators (preferred) or qualitative ways you plan on assessing the solution?_
* Number of SaaS users that activate this feature.
* Access numbers
## Messaging
_If you were to write a press release, how would you describe the value to customers?_
<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><tbody><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Headline</p></th><td class="op-uc-table--cell"><p class="op-uc-p">API to provide project progress over time </p></td></tr><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">First Paragraph</p></th><td class="op-uc-table--cell"><p class="op-uc-p">The OpenProject API now has an endpoint to request progess data over time. This allows the integration with other collaboration tools such as XWiki or BI tools</p></td></tr><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Customer Quote</p></th><td class="op-uc-table--cell"><p class="op-uc-p">Ludovic: "Customers of XWiki want an alternative to proprietory solutions. With the new API endpoint we can now provide our customers an excellent alternative.</p></td></tr></tbody></table></figure>
## Go to market
_How are you planning on getting this into users' hands?_