1

For a report with 25 fields, there are a lot of decisions to be made for every column. Tracking them in a wiki, like what's below, drew complaints that the final field values couldn't be scanned rapidly and it was hard to tell what were open questions (despite using red text for the word "Question").

Column A
Question: ....
Answer: ...
Decision from meeting 2019-03-28: Field will be equal to fooValue.
Question: ...
Decision 2019-03-30 from stakeholder Y: ...
Final answer: Field will be fooValue concatenated with the current date.

Column B
Final answer: Field will be the current date.

I really like being able to see the historical discussion that led to the current state of each field, but I like reading. My teammates would prefer a spreadsheet with 25 rows and questions in a column beside each field, despite the lack of ability to @ people or see who decided what. What kind of design document format would let me have the complete context available when I code, but managers and designers don't have to sift through it?

Improve this question
4
  • The best way to trach the history of a document is to put it under version control. Most of the time, the latest status will be sufficient, but the history function of the vcs will allow you to reconstruct what happened in the past and why (if the commit messages are any good).
    – Bart van Ingen Schenau
    Mar 30, 2019 at 21:13
  • I think that would work best if you had 25 documents, one for each field, so you could track changes to that one field. Otherwise it would be tough to do a diff and find the four commits that affect that one field.
    – Noumenon
    Mar 30, 2019 at 21:32
  • Utilizing tools for tracking user stories/tasks in some form of a dashboard could be a good first-pass solution (a basic example being something like Trello). As new/updated columns come up, the stories/task could include information on what report the update is tied to, the reason the change is needed, what is the intent of the change, when it is/was supposed to be implemented, and so on. For some tools, each story/task include a comment section with no explicit restrictions. I typically see it used for posing questions/updates to how the task description was originally interpreted.
    – eparham7861
    Mar 30, 2019 at 22:04
  • Comments on a jira issue would be scattered about, so that you'd have to read the whole thread to find comments pertaining to field C. The wiki version of this discussion is 2700 words long which is too big for comments on one issue. 25 subtasks on one Jira issue would solve that, but seemed weird -- and some of the fields are grouped together, later split apart.
    – Noumenon
    Mar 30, 2019 at 23:49

1 Answer 1

Reset to default
1

A spreadsheet is fine for this, especially when it is programmable.

You could try to design one using standard filter capabilities to switch between a "detailed" and a "managers" view. If that is not sufficient, give each of those 25 fields its own worksheet inside one spreadsheet document, with a rigid structure for field name/type, type of comment (Question/Answer), comment text, relevant person and date. Then build a simple program or script (in MS Excel I would probably utilize a VBA macro) to generate a new aggregated sheet as "managers view" from those 25 worksheets, where each field gets just one row entry, as described in your question.

Pros:

  • simple
  • can be made mostly self-explanatory
  • "email friendly", after each new meeting, you can easily send around a new version of the document as one attachment
  • "manager friendly"
  • no need to shoehorn something like an issue tracker into a use case it was not designed for
  • the spreadsheet document as a whole can be put under version control and versioned together with other documentation belonging to the project

Cons:

  • everyone involved has to know how to use a spreadsheet, and at least one person needs to manage it and implement the programmatic parts

  • does only scale up to a certain point (especially number of people involved). Number of reports or fields, I guess, is unlikely to become a problem for your case.

Improve this answer
3
  • "Manager friendly" is good. "Email friendly" is bad -- you have to search your email all the time instead of having a single wiki link that's always up to date.
    – Noumenon
    Mar 31, 2019 at 15:21
  • 1
    @Noumenon: a spreadsheet can be put on a common network share as well, or one could use something like "Google sheets" to have shared access. It depends all on the common infrastructure available for all stakeholders. Another idea is to put the whole spreadsheet document under version control together with the source code of the project - try that with a Wiki.
    – Doc Brown
    Apr 1, 2019 at 5:04
  • 1
    ... or try to email a Wiki to someone who does not have access to it.
    – Doc Brown
    Apr 1, 2019 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.