Thursday, February 5, 2009

The customer factor

DSCN12581 One of the greater challenges, I‘ve observed in the lifecycle of software development lay not in the technology, or in the method of solution, but with the interaction with the customer. The less fortunate case would be the lack of any interaction with a customer all together, resulting in a peculiar situation of over development.

An “Over development”, as I see it, happens when product features don’t match the majority use cases and no customer would be willing to pay for their development. Things that seem awfully cool to have, but don’t actually assist in the selling process.

I’ve been involved in many corporate development projects. These were huge projects, with large groups of developers, all working for functionality defined by a single customer. The past two years, I've been managing the development of a leading product for the paper press industry. This product is an “off the shelf” reporting solution for the production process of a commercial printing house.

The product tracks and accumulates data in any provided format. It produces a wide range of analyses and diagnostics, regarding the production line of a printing house operation.

Although the two development scenarios may seem different, I consider them to be quite similar, with a slight variation: in the development of an “off the shelf” product, the customer is the sales department.

For both development scenarios, the one big issue that stands out is having the application go into production. As obvious as it may seem, it is the least trivial, and to my mind, the hardest.

I’ve started out with a product that was extremely over developed, and not a single customer. The first thing I did was to set a goal for myself (i.e. my group), to push the product into production as fast as I could while shrinking the development cycles.

The sale department managers helped me come up with a bare bone requirement list of features. I used this “can’t go without” list to determine the entry point of the product. I used this leverage to get the sales department to arrange the first beta customer. Once there was a real life customer in the development cycle, crucial information began flowing back, requesting features and functionality.

There are two good things that a customer may give the application developer. One is money for the product; the other would be rejects on the product. The latter, when provided from a customer is worth more than any internal brainstorming process within the development group. To my opinion it is the best way to have the product pushed forward and to make it robust and usable.

Development war room

military_sleep_by_marcheshvan I had a friend over the other day, one of the smartest people I know and an extraordinary talent. We were reminiscing about the olden days, and we were reminded of the principles we have learnt in the army so long ago. Actually, he was the one being reminded because I was never even close to anything like combat myself. As he was reciting his lines I came to think that some of the guidelines may apply to software development. I’ve listed them with some relevant modifications

1. Pursuing on the task at hand, in light of the goal. Goals have the awful habit of changing all the time: the market is prone to change; your boss might have a sudden change of heart. Thus tasks may become irrelevant. I found it a good policy to check every once in a while whether what I am doing, is still in concordance with the goal. Another term that might pop into mind would be the word adaptation. Yet, I don’t feel from it the conviction of getting the task done.

2. The customer is my supreme commander. The customer in this case may range from the actual person or company that makes use of the product, to the sales department. All in all, my customer has a wider angle of view on things than I do

3. Creativity and innovation. While creativity is thinking out of the box, innovation is the yoking of it to the purpose of the product. It’s a tipsy tread, balancing between both. Creativity without innovation is a waste of time, but there is no innovation without creativity.

4. Never fall in love with your own creativity. I keep forgetting that one.

5. Keeping it stupid and simple. Might make the difference when you are showing the product to a customer. Letting go of this principal, may also cost a fortune in application maintenance. Keeping up with simplicity is a task for no fool. Some Damoclesien solution is needed to chop off the unnecessary.

6. Logistics. The average developer, like me, has a thread timeout of half a minute. Any logistic task I have to do that might exceeds that, waiting for coffee, or a long walk to the little boys room, has an overhead of reengaging the lost thread of thought when arriving back to the seat (oh, caffeine enriched coffee may help as well)

7. Standardization vs. opportunism. For me, the key word here is balance. Before the agile love affair, we used to call it the quick and dirty approach, i.e. having things done the fast way, when a customer is at the door. The difference between quick and dirty and plain old sloppy is the set of guidelines and standards that the course of production is built upon.

8. Mapping the critical paths. Pretty obvious where this is going. While mapping tasks, it’s not that difficult to make estimation about dependencies. Once that’s figured out, any project management software provides tools to visualize the critical path

9. Reserve management. Each developer manages his own buffers. This is important when you want to deliver within the time frame you are committed to. This behavior backfires when buffers aren’t properly manages and instead, layers upon layers of time buffers are created. When a developer asks for 3 days on a 2 day job, on average, he or she would only start working on it on the second day. In most cases, the product would be ready on time, in some it would actually take worst case of 3 days, summing up in a 4 day total. The best practice for me is to club all buffers to a single pool. Each developer is assigned with a best case time table, and the development manager controls the pool of time buffers. The probable outcome would be that only a fraction of the tasks are delayed and exceed the time assigned, then pool reserve time is given. No time is spared to be abused.

10. Task breakdown; autopilot.

special thanks to Uri Holtzman