Sometimes I feel surprised about how fast the technology affects the way we work, to a point where we need to re-define our current work statements and priorities in order to perform the same tasks with less time and people. I found this interesting because you can find a lot of tools to improve your daily challenges nowadays but sometimes the need of avoiding risks makes you proceed just as usual (or “how the things are done around here” if you now what I mean). Some common issues I’ve seen when working with projects planning and development are:
- Mismatches between Hours/resources assignment and planned schedule
- Functional inconsistencies between Wireframes and development releases
- Missing strings and “Lorem Ipsum” contents on QA stage
- Unplanned post-live fixes
Curiously I found the best example of resources and results optimization actually “out of duty”. Last weekend I was dinning at a restaurant with my family listening to the guys playing on the background, and I noticed that all songs sounded like it was the complete set (drums, two guitars, bass) but there were only two guys on stage, so at the end of the show I got to talk with the singer and asked if it’s cool to play with pre-recorded tracks and stuff. He replied that there were no additional tracks, they found a way to play all instruments (or at least the most relevant of each one) to take more control over the show and therefore improve the quality and of course, the profit (well, the fact of being an outstanding guitarist helped a lot).
So I thought “ooohhh right, if they have all the information they just evaluated their capabilities and tried to centralize all they needed before thinking on assigning tasks to more resources” and they got it. So I started working on how to improve the projects flow by gathering and sorting the project’s information with the less possible resources without getting out of the assigned schedule and the keeping resources “healthy”, sort of speak:
1. Support on semantics to understand the project’s nature
Helping our client to understand what the project is from the functional perspective helps us define what the project should not become at the end; that “mind blown app to make people win awesome prizes” could be just an animated register form for a sweepstakes or that “cool web game to make kinds have fun on the page” could reach the same interaction complexity as Grand Theft Auto; the simpler is to describe what needs to be done, the more accurate the functional specs will be.
2. The User Experience starts from home
We actually deal with different types of users along the project development, most of all when we need approvals from our client to finish/start the project stages. When creating documentation it’s important to first think how “friendly” the documentation is to allow our stakeholders approve what they are reading; they will reject your 500+ lines .xls file the same way they will reject your 250 pages fully commented Wireframes set just for the fact of being “too much to read”.
3. If you label it you can track it
It’s common to find missing “states” or strings when testing user flows due to these minor flows that appear when the user clicks on this new last-minute-GoLive-critical feature that our client requested a couple days before actually going Live. The fact of having everything labeled with a flexible naming system could help us out detect and sketch the component behavior before adding it to the code, giving us the chance to at least anticipate where are the potential issues (let’s be honest, unplanned features will have less time to implement them but require more time to make them work accordingly).
4. Your project is as flexible as your visitors
Let’s take into account that we didn’t have metrics, SEO, tablets, smartphones and behavioral targeting a couple years ago, therefore your main (for not saying “the only”) customers you had in scope were mostly local. Nowadays, since customers have the chance to buy, rate and comment what you sell from everywhere your contents should aim to support them the same way. Consider flexible contents management practices such as .xml based contents, multi-language contents moderation and legal disclaimers to make your visitors understand the game rules.
5. It’s up to you to reinvent the wheel
Seriously, after reading a little bit about CMS, object-oriented programming and re-usable contents you realize that a lot of functional components just need to be created once but flexible enough to be easily re-used in another project, optimizing the development times and assigning less time consuming tasks to resources (if everything was well programmed, adapting components should take less than creating them).