Difference between revisions of "WestCoast2008:The MoveOn Process for Translating Technology Visions to Reality"
Jump to navigation
Jump to search
| (5 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
05/20/08<br> | 05/20/08<br> | ||
| + | |||
'''Assumptions:''' | '''Assumptions:''' | ||
| Line 21: | Line 22: | ||
* How do you want the campaign to work | * How do you want the campaign to work | ||
* Before you do specs/coding | * Before you do specs/coding | ||
| − | |||
'''Outline''' | '''Outline''' | ||
| Line 39: | Line 39: | ||
* Identify needs for reporting/performance measures (do you need to do statistical analysis? What kind? Etc.) | * Identify needs for reporting/performance measures (do you need to do statistical analysis? What kind? Etc.) | ||
| − | Test and test and test again | + | |
| − | * | + | '''Test and test and test again''' |
| + | |||
| + | * Don't roll something out that hasn’t gone through several iterations of testing | ||
* Programmers are good to ask in terms of where it’s likely to fail | * Programmers are good to ask in terms of where it’s likely to fail | ||
* Sometimes these things can’t be predicted; there will always be bugs | * Sometimes these things can’t be predicted; there will always be bugs | ||
| Line 52: | Line 54: | ||
* What needs to be protected (privacy issues, etc.) | * What needs to be protected (privacy issues, etc.) | ||
* Define policies ahead of time, think through how people might misuse the tools | * Define policies ahead of time, think through how people might misuse the tools | ||
| − | |||
'''How to manage these projects remotely?''' | '''How to manage these projects remotely?''' | ||
Latest revision as of 22:44, 15 January 2016
Like many organizations, MoveOn needs to translate the technology needs and desires expressed by their staff in the field into practical and implementable designs for software and websites. MoveOn project manager Tanya Africa will talk through their process and lead a discussion about techniques and tips to understand and document technology needs so all involved can participate in the process.
Notetaker: Tanya
05/20/08
Assumptions:
- Volunteer-based
- Grassroots
Start with a concept
Look at what has been effective
- Studies
- Stories
- Historically
Nail down the plan first
- What is your output?
- How do you want the campaign to work
- Before you do specs/coding
Outline
- One sentence about each of the features you want in the tool
- Enables you to go to your programmers to get feedback (yes/no/need more specs)
Plan
- What should the tool be able to do/what should users be able to do with the tool?
- Timeline
- Budget
- Prioritizing functions, enforce discipline from the organizing side
* Everything that is a priority one pushes down another priority * No features are free; each great feature means you don’t get something else * This is one of the hardest things to do, to get people to understand trade-offs
Specifications
* Identify needs for reporting/performance measures (do you need to do statistical analysis? What kind? Etc.)
Test and test and test again
- Don't roll something out that hasn’t gone through several iterations of testing
- Programmers are good to ask in terms of where it’s likely to fail
* Sometimes these things can’t be predicted; there will always be bugs * Lots of different testing groups means coming across lots of different use scenarios
Other issues
- Paranoia team
* Think of how people might try to misuse the tool * Security issues * What needs to be protected (privacy issues, etc.)
- Define policies ahead of time, think through how people might misuse the tools
How to manage these projects remotely?
- Collaboration can be difficult remotely
- Define what your collaborators are comfortable with (tech-wise) and then tailor your use of tools to help fit that, and plan for training on those tools
- Create a paper trail for every stage of the process
- Have a bucket/list for ideas you can’t use (Tanya calls it “Tier 6”)