STAMM Lausanne - Do we still need heavy specs processes when developing web 2.0 sites ?
Posted April 8th, 2008 by sandrine@profes...
The least we can say, is that the subject on methodology for creating 2.0 website, created an animated discussion ;-)
On one side, those thinking old processes, long project definition, a full handset of written guidelines was still the only way and those using slightly more "agile" processes.
What is probably to be considered as a key question : do we develop website like we develop any IT application ?
From a skill perspective, I noticed, as I was defining the 40 different job descriptions of the web professionnals, that the skills and trainings and approach would vary from other IT domains. So why methods to produce sites would have to be absolutely identical ?
Experienced developers have also all mentioned that the specs most often looked like a shopping list rather than a real structured and realistic objective. Customers using the spec as a "nice to have" rather than strict & thourough minded working guideline.
A few people mentioned that far too technical-centric, the "cahier des charges" specs would tend to mislead customers. Concentrated as they are on the tool, the language, they often forgot to consider the site from a customer perspective, ending in endless misunderstandings once the site is being produced and potentially a lot of customer dissatisfaction. Customer use the specs to fill in all they expect the site does but to describe best, they use other sites comparison, wordings that often do not go far enough to be precise. Because it takes a long time to produce all they want, by the time they actually see the site, major changes tend to happen, as what they thought they had described was not what they see being developed.
Based on his experience, Manuel Spuhler tempted to share his methodology to create sites. More step by step and visuals based, he explained how by starting on some simple mockups and defining navigation first, he would end up more rapidly and efficiently to real needs and visible results.
More customer and usability centric this methodology should of course not hide the need for written instructions and structure, which comes in a second step.
This way of developping, highly inspired from the agile methodology, seemed, according to manuel, to avoid the gap between the needs and the realisation fo the project.
In the end the whole thing is ado about communication or mis-understandings, and well, if this methodology, checking at every step the progress, adapting, promoting quick wins rather than long development runs works, this could be worth using it...
Of course, two trends remain and one uses the one he feels the most comfortable with ;-)
Your feedback on this is really welcome, so let us know :
Which one do you use and why ?
On one side, those thinking old processes, long project definition, a full handset of written guidelines was still the only way and those using slightly more "agile" processes.
What is probably to be considered as a key question : do we develop website like we develop any IT application ?
From a skill perspective, I noticed, as I was defining the 40 different job descriptions of the web professionnals, that the skills and trainings and approach would vary from other IT domains. So why methods to produce sites would have to be absolutely identical ?
Experienced developers have also all mentioned that the specs most often looked like a shopping list rather than a real structured and realistic objective. Customers using the spec as a "nice to have" rather than strict & thourough minded working guideline.
A few people mentioned that far too technical-centric, the "cahier des charges" specs would tend to mislead customers. Concentrated as they are on the tool, the language, they often forgot to consider the site from a customer perspective, ending in endless misunderstandings once the site is being produced and potentially a lot of customer dissatisfaction. Customer use the specs to fill in all they expect the site does but to describe best, they use other sites comparison, wordings that often do not go far enough to be precise. Because it takes a long time to produce all they want, by the time they actually see the site, major changes tend to happen, as what they thought they had described was not what they see being developed.
Based on his experience, Manuel Spuhler tempted to share his methodology to create sites. More step by step and visuals based, he explained how by starting on some simple mockups and defining navigation first, he would end up more rapidly and efficiently to real needs and visible results.
More customer and usability centric this methodology should of course not hide the need for written instructions and structure, which comes in a second step.
This way of developping, highly inspired from the agile methodology, seemed, according to manuel, to avoid the gap between the needs and the realisation fo the project.
In the end the whole thing is ado about communication or mis-understandings, and well, if this methodology, checking at every step the progress, adapting, promoting quick wins rather than long development runs works, this could be worth using it...
Of course, two trends remain and one uses the one he feels the most comfortable with ;-)
Your feedback on this is really welcome, so let us know :
Which one do you use and why ?
Comments
agile methodology
Post new comment