Netlife Research (company website in Norwegian) has done it again. Their 2008 Bad Usability Calendar is here and it is great. So great that it is hard to pick a favorite. Download it here. 2007 has more great examples.

[Note: This is a short post- just got back from the Velvet Revolver concert at Stubb's. Living in Austin rocks!]

[photo by Henkster]

Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. Insight springs from understanding, and insight leads to great requirements and ultimately great products.

A look back at the best from this week in the past.

When we’re part of a team creating software for the enterprise - an internally focused, IT initiative, we usually don’t think about product managers. Business analysts, systems analysts, and architects (of all varieties) are all commonplace. But not product managers. Product managers bring a perspective and a strategic focus that can influence the success of an IT enterprise initiative.

A look back at the best from this week in the past.

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.

A look back at the best from this week in the past.

We’ve written before about several characteristics of well written requirements, and one of those characteristics is testability. Ahamad has written an list of 10 tests of requirements, with an emphasis on assessing the testability of the requirements. The testability of the requirement determines if the resultant product can be tested to determine if it meets the requirement.

A client at a large company with large development teams and a long history of waterfall development made a comment: “The only people who are talking about doing this project in Agile are developers who think it will allow them to avoid responsibility.” My client may have been right (that people were saying that) but the developers who were saying it were wrong. Agile increases responsibility - it doesn’t absolve it.