Photo from ineedmotivation.com
Every software developer has faced the situation where a client has a process that is completely human. Take the following example. The client make a request.
Ask 1
Hey Eliot… I would like to have a form on a page capture the user input. Also, can you send the input to me in an email? I can review the information and send it back to if it is wrong. Otherwise I will copy in paste it into the appropriate system.
Have you seen a request like this? It’s great that your customer is asking for clearly defined deliverables. However, the main problem is the customer is asking for a work-flow and including too many technical details. A better ask would have been.
Ask 2
Hi Eliot. I need to capture input from the user, be notified of this, and review it. If the information is not correct, the user has to resubmit their input. If the information is okay can it be persisted to the appropriate place?
Life would be so easy if customer requests were like this. We live in reality and our customer request are closer to ask number 1. If you are like me, as soon as you here email, review, and send, you start to think… that sounds very manual to me. Immediately I try to attack that. Why… because manual processes don’t scale. Our customer don’t realize this. It’s very easy to think about a process in an isolated way. I have one email in my inbox to review and I will take care of it immediately. They are not thinking about someone’s mailbox being full or when they are on vacation. Again, because we live in reality, try to keep the human out of the process as much as possible.
When asked for a solution similar to ask 1, here are some idea on how to attack this problem.
- Ask yourself and your customer, does a person really need to perform that task. The idea is to identify the rules surrounding the activity. You maybe able to identify three rule that can account for 80% of the cases and it can be automated. That process will be better than one where manual intervention is always required even when a person will just pass it through to the next step in the process.
- Emails are not reliable. They seem this way because you hardly hear that someone didn’t get an email, and when it doesn’t happen it’s not a big deal. Business processes shouldn’t be built around unreliable infrastructure. When an email is a critical point in any process you are asking for trouble.
- Delay critical decisions that will account anything above the 80% of the cases. 80% is the sweet spot. Have you ever heard the saying, 20% of your features will account for 80% of your time? Chances are the 20% that will take the most time to automatic will be edge cases and why it takes so much time to achieve. It’s better to put those 20% in the hands of the support staff and let them properly deal with them. Letting humans deal with the obscure 20% is delaying the automation effort but you probably never looked at it this way.
- Work to avoid saying I told you so. You are not five years old. As a developer it’s in your best interest not to waste your time or your customer’s. A better approach is to explain the benefits of automation and the penalties of manual processes.
I feel I only touch the surface on this topic. Stay tuned for more on this. Feel free to share your insight on the topic in the comments section.
