Commentaire négatif le plus utile
Web development's central challenge: not speed but diversity
le 13 novembre 2000
(Reviewer's note: since this review was first written, Ashley Friedlein's "Web Project Management" has arrived on the market. It outshines "Collaborative Web Development" in almost every way.)
As new dot.coms joing the late-2000 not.coms, it's becoming more and more obvious that parts of the Web development industry are remarkably badly run. The stories of mismanagement at Boo.com were just the start. After ditching a quarter of its staff, Iam.com has sued its Web development firm, Razorfish, for producing an unusable site. Ex-employees of Digital Entertainment Network are swapping tales about the weirdness of trying to get anything done there. Web sites need to be managed, and the evidence suggests the task is harder than it appears.
Why so tough? Analysts often claim that the defining characteristic of Web project management is speed - that famous "Internet time" we heard so much about before the April 2000 tech-wreck.
But Jessica Burdman doubts that time is the essence of the Web development challenge. She notes the often similarly aggressive schedules in fields like software creation. (She could just as easily cite television and print production guidelines.)
Burdman's book suggests instead that the central challenge of Web development is the sheer breadth of the Web development task. That task encompasses everything from application programming to direct marketing copywriting to Internet security to video production. The people who perform these tasks will arrive with different backgrounds, different expectations, different requirements for a work environment. Burdman expands on 20 different types of core, extended and special team members. One site manager comments to her that development managers "become more like an orchestra conductor than a project manager".
In smaller projects - typical of the environment in Australia, from where I'm writing - team members must often play multiple roles. That elevates the demands both on the assembler of the team, and on the team members themselves.
The diverse nature of the Web team also poses a substantial communications challenge. In a family, notes Burdman, everyone can communicate almost intuitively. The same holds for families of designers, programmers or sales professionals. Assemble people from these different families for a project, and the non-verbal, implied communication must be reconstructed.
But the broad nature of the Web team brings rewards as well. In a world of narrow specialisation, Web development provides a rare haven for the talented generalist who can think in structures and processes.
And if your project involves high-level coding, your development team will contain a rich pool of structured intelligences - good programmers, who can bring rich insights to a project. Burdman quotes one technology director as saying that "(software) engineers must participate in every step of the process ... They're smart people and if you have them all in the room, great things can happen."
If you're new to Web project management, then Burdman provides an informal checklist for managing Web projects. Her book whisks you across the little-mapped territory of Web project management in just over 200 pages. And it concentrates on the team-intensive aspects of the task, which necessarily occur later in the development cycle.
Burdman spent time as a technical writer before she "stumbled into Web project management". Perhaps as a result, her book suffers a little from the classic shortcoming of the technical writer's product: overview without authority. A better book might not only list the challenges, but draw attention to the challenges that matter most. A better book might draw less on the author's small group of sometimes disorganised-sounding friends. A better book might embrace more fully the rigor of established fields like software development, where effective methodologies such as use cases have grown up over time. A better book might avoid telling slips, such as calling "requirements" a layman's term for "specifications". A better book might even include higher-quality documentation templates than the lightweight efforts on this volume's obligatory CD.
But if you're wondering why Web development management seems so tough, there are worse places to start.