A lot of talking with the team yesterday, and I have a sore throat because of it – but we covered some pretty key concepts, stuff that is hard to reconcile in many tech staffers’ minds, but must be dealt with.
One conversation covered this person’s desire to be thought of / leveraged as “more than a programmer”. “That’s great!” was my response -“… then close the issues that are getting assigned to you – without programming!”. Recently, I am a bit frustrated with some of the issues in our tracking system because they seem to take a very long time to get resolved. More often than not the tech staff is telling me that the system is working exactly as designed – there is no “bug” to fix. The problem lies with folks that are not aware of the business policy / decisions that had been made as part of this design, and do not understand what going on! Nothing to “fix” here, except the level of understanding / knowledge of the people involved.
But therein lies the difficulty for most techs. The real solution is to force a meeting with the business process owners, the folks who were involved with / understand the original design decisions, and the folks reporting the issue – and review in detail. If the design needs to be changed, so be it – let’s just get to a common understanding already. The tech makes the huge contribution to the company, not by programming away the issue, but by getting the process owners to share knowledge, to think things through – to make a decision.
Also, I tried to point out to this person that they have the power and ability to do analysis / demonstrate domain knowledge / be more than a programmer – so just do it! No anointment necessary.
Another platform, another issue, another tech … same day, same basic concept. I am exhorting them to get issues closed, not simply for the sake of closure, but things really do take longer than they need. Testing is great, and I don’t mean to imply that we want to push stuff into production without testing. Key is that we need to get the user community to test stuff, that we need to push them to test stuff, and get the fixes / resolutions into production, and move on.
However, a key concept that came up with this person was was the need to stop automatically going the custom programming route as the solution for everything. We are trying to quickly resolve an issue where folks in one area of the company are using a maintenance application to do status inquiries. Problems result with locked records on the screen and inadvertent changes to important data – so the process owner is asking for a custom, inquiry-only version of this program.
My push back is – don’t ask what they want, try to find out what they need / what they are trying to accomplish. Key question that the tech must ask – can we deliver with standard product? The best approach will be to something that’s already available, even if it delivers 80% of the “need”. We must always keep in mind long-term cost of maintenance for proliferating customizations!
Last point for today – a critical piece of this process must be a does of humility – are you telling me that standard product cannot do this thing, or that you do not know how to do this thing in standard product? No shame in not knowing, but that is not an excuse to go to the custom programming well. We must prove that the requirement is not possible with standard product before we commit to the customization.
This Post Has 0 Comments