[Sigia-l] 'Process+Tools+Guidelines' to do the right thing!

[Listera]

"prai at prady.com" wrote:

> Ziya's comment makes me feel that software engineering is runs in similar
> manner as Afganistan was by the Warlords :)

Which, of course, brings back memories for some of us of another image from
another war: "save the village by burning it". :-) An inordinate number of
corporate projects fail because of politics. Even those that look like
technology failures are often victims of bad (technical) choices made under
political pressure, turf conflicts, technological fundamentalism, etc. When
working in/for large corporations, it's crucial to understand this early on.
 
> I am trying to understand if there's any ethical reason, 'value' addition,
> etc. which can be addressed to build case for usability, without making it
> obvious that this is a fight 'for-the-survival' or
> 'you-comply-to-my-standards'...

There's a subtle but very important distinction here and it depends on
*when* you apply usability considerations during development.

A typical scenario is: select technology/vendor -> build around the
capabilities/limitations of that product (many CRM or CMS projects fall into
this category, for example). It may be too little & too late to graft some
sort of usability guidelines to a product/process already well defined by
other (mostly technological) considerations. How many times have you seen a
product getting a "review" by a usability expert mere days before it's
actually launched? And those people will proudly list usability as one of
their features in product descriptions; after all, they did hire a usability
expert. :-)

So the argument comes back to: can you define the product by how it's
used/perceived by its users? And not by how fast its app server runs or how
thick its UML documentation is or what bleeding technology it happens to
use. Can you, in fact, declare that if a given set of usability guidelines
aren't successfully met the product should be considered a failure? If you
can get people to buy into that then reverse engineering that goal becomes a
fairly straightforward process every member of the team (including the
developers) can follow.

Now there are a bunch numbers for ROI on usability, etc. You should find
some in the archives. But I suspect it'll ultimately come down to rhetoric:
how cogently, forcefully and credibly can you make the argument that the
product is how the users perceive it, and everything else follows from that.

You might think I'm being a bit aggressive here, but, hey, I'm from New
York. You don't have to be confrontational, but you need to be cognizant of
the nature of the beast. OK, think Mata Hari. :-)
 
> And I am already marching towards Kabul.

And don't drink the water ;-)

Ziya
Nullius in Verba