Impress your CTO (3)

Imagine the following conversation between a product owner and developer

Product Owner: “I want a CRM system”
Developer: “What does that do?”
PO: “It’s a customer database that lets me manage and report on my communications with my customers”
Dev: “That sounds easy, I’ll build you one this iteration”

One week later …

Dev: “Here you go. You log in here and here’s a screen where you can add a record for each customer. When you click into a customer record you can also add some notes for each time you’ve talked to them”
PO: “Wow, you did all that in a week, awesome. Now let’s add in the ability to make some notes for future calls that I need to do and a screen to show what tasks I have upcoming”
Dev: “No problem”

One week later …
PO: “This is so cool”

Brand new projects often start like this. But it doesn’t take long for fatigue to kick in. A few more iterations and all of a sudden you’re getting bogged down in details like:

  • Download to Excel
  • Upload from Excel
  • The fact that you should really be validating postcodes
  • And show the location on a map
  • And have better collaboration facilities
  • And handle customer segmentation
  • Ability to handle email templates
  • And initiate voice calls
  • And route incoming calls to an appropriate agent
  • And let someone apply a credit to a customer’s account
  • etc, etc, etc

At this point you start to realise why no-one sane would build their own CRM.

The Importance of Unspecified Requirements

You see you have functional requirements and you have non-functional requirements. But beyond all of these you have the unspecified requirements. These last ones are really important because your product owner considers them so obvious that they aren’t worth mentioning. Of course your CRM system has to handle loading records from Excel – only a buffoon would not know that!

The solution isn’t to insist on 100% detailed specifications before you start building. That way another type of madness lies. Nor should you consider your job well done because each week you have built what your customer asked for. The best developers are the ones who deliver the best working software, which is not as simple as building what was written down in the spec.

Worry about their unspecified requirements before you get too far down any path. It doesn’t have to involve much coding (if any). If someone asks you to build a CRM then do a sort of throwaway prototype first. Not one that involves any coding. (I’ve seen some great throwaway prototypes written using Excel). Why not get a one-month license to Salesforce (or whatever). This is a great way to get to see really what features they value, where their frustrations are etc. Then if you discover that Salesforce is the right answer for them then thank your lucky stars that you’ve had a narrow escape from attaching a massive bespoke millstone round your neck for the rest of the time with your company. And if you discover that there is something really special about your requirements, well, then you can build a truly great application that really addresses the real problems your users are facing.

 

Advertisements

One thought on “Impress your CTO (3)

  1. Pingback: Impress your CTO – Define your own NFRs – Alan Buxton's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s