Today at our meeting I offered to coordinate development and management of documentation of the “DropCRM” project. The following list is what I have worked out as being my key goals for documentation.
In order to make this CRM project “not suck” from the get go it is vital that business use cases to be evaluated and considered and that documentation is a living process in order to make sure that we get a tool that people can use.
This means creating 4 key types of documentation.
Business spec and use cases that are used to form technical specs (this is item 1) and case studies to fully spell out a feature for example.
- The CRM should integrate with Twitter API and Messaging API to allow me to tweet to a specific user or group of users when I want or based on a specific action. For example Twitter is becoming a viable way for many to communicate and many people want to be able to get messages on Twitter or to share what they have done on Twitter. For example if a user updates their profile then they may want to Tweet - I updated my profile with Super Cool Company X you should do it to.
- Case studies need to take into account international uses.
- Cases need to, at their best, match for profit and not for profit organizations as well as different verticals in these areas.
- Technical specs that match business needs - Specs need to take into account current standards in order to make sure that those contributing code are matching existing standards and specifications.
- Wireframes should be created when possible so we can discuss from the get go the UI/UX to make this work.
Internal documentation - UI tips and help
- Every successfully adopted project that is easy enough for the end users to use has explanatory text in the UI
- We need help tips that will guide users to best practice
- We need to make sure that validation rules and forms match the internal documentation
- There needs to be clear extended help
Documentation Pages and or a Manual
This is more of a long term goal but there needs to be documentation pages and a manual of sorts.
Documentation pages need to be separated between technical how tos and any end user documentation we create
Comments
Great stuff, Steve. Maybe
Great stuff, Steve. Maybe tackle each of these separately with a request for comments and e.g. Use-case suggestions on the group, over time so people don't get overloaded.
It might also be good to document eventually what we think "done" will look like. What's our way of deciding whether to release the final umbrella feature? I'm happy to say we'll decide further down the line and not be hubristic now, as long as that doesn't become "we'll know it when we see it," or we'll never release!
I agree that we need to know
I agree that we need to know what done means. I will ask for use cases very soon. Talking to people from the BOF and getting the first sets of use cases before we just go open. If anyone wants to share ideas and use case suggestions that is GREAT!
Owner and Lead Consultant
Denver DataMan