No, I'm not going to share ideas about how to make customer successful. If you are here looking for that, sorry you are at the wrong place. What I'll try to share here is how I can help as a developer. Be patient for the next couple of minutes to understand my view and I'll keep the comments section open for anyone to suggest or correct my view.
What am I talking about then?
Maybe it is in-line with being a consultant and not just a normal "yes sir" or "donkey" developer who just follows by the instructions and says - it's not in design or wireframe or maybe says "this is not mentioned in the requirements".
My take is - we are given a job to build a tool which will allow the customer to earn something out of it. It could be more customers, sell products or spreading the word around their cause (NGO's) to reach more people. To do this I need to do anything possible which is helping achieve their goals.
- Does this mean I don't ask for extra hours or extra money for changes?
- Does this mean I suggest them the best solutions in the world?
- Does this mean I do shit in code and deliver faster to help them get online ASAP?
Answer to all of these and any such questions is NO. No, we don't do wrong, we still do what is right and we also have every right to charge for any additional service we provide (time, consultancy, work, etc.). So, what am I trying to say here? We have to accept the person giving the requirements is a human. Most of the time more experienced in the domain but still - a HUMAN.
- share suggestions to make things better even if it means it costs more (time or money - justifying the gain)
- suggest better solutions or solutions to achieve things in steps to achieve the needs in defined timeline if time is crucial
Also, ensure the focus is not on making developer life easy, it should be balance between Client goals and maintainability
Automation, dev tools, helper scripts - none of this is going to bring any value to the customer unless it is a repetitive job. I shouldn't spend time writing a lengthy script which is required only one time and we don't for-see it's re-use anytime in future. So all the migration scripts useless? We shouldn't write scripts?
NO - but they should be investment of the developer or development company as they are going to help them in next project. They might be useful for a big sized client who may have 10s to 100s of sites, yes but than their requirement would be to build a script to migrate and not to migrate a site from may be CMS1 to CMS2 or likewise.
Readable code, code following standards - do you really think Customer is going to read the code? Does he even care if you use $a or $temp or $amount? Is it going to help in any way to achieve the goals?
No - but they still need it to be maintainable and easy to change. So, it is very important to do this but there should be a clear line drawn between the time spent and value it is going to provide. It should be balanced between the time spent on making the code more readable or standard v/s the gain it is going to provide.
Having said above, I simply want to say there needs to be a balance between everything. Aim of the developer should not be to spend more time in making things more developer friendly, it should be balanced and questioned every-time against the value it is going to provide to the customer.
So when should I do this?
Yes, all the time. But as I said before, we have to be very careful and do the home work before suggesting. We have to weigh between cost and gain. If the gain is significant, go ahead, but keep the cost factor in check all the time.
This means if the feature is in UAT / release stage and you find out that we might have done it bit differently and gain with new approach is huge - you should know cost factor now would be toooo huge, too literally. If it is a long term project, put up a suggestion for later improvement. If it is short term project, don't bother suggesting it now. Keep the point in retro about we could do this better next time but not for that particular project.
Tips on how to do this (cost analysis, home work, making suggestions)
- Client: Put yourself in Client's shoes and try to understand their business model, requirements, goals.
- Domain: Try to understand more about the domain, if it is NGO - try and understand how normally NGO's work, what are the features are usually required from an app or website.
- End-users: Be the user and feel what the end users are going to feel. It is also important at times to understand cultural differences if the project is for specific group of people. People from different regions behave differently, if I were to suggest a UX behavior of people in USA without meeting even 100 people from there I would be doing it wrong.
- Cost v/s Impact analysis: Goal of this to give Client enough data to make the decision
- Like bugs, improvements and suggestions also cost more with the project phase. Consider this while calculating cost v/s impact.
- Check how much efforts it is going to reduce in the project in future. For instance, writing a script to deploy on production may delay a release but impact would be huge in future but writing code for next version of PHP can be done later and impact isn't that huge. Again, the same example if we have missed security EOL deadline and now the hosting provider won't support older version, do you think we can say the same? I would say no - this becomes the blocker
- Try to bring in numbers. For instance - with current approach it works but it takes 3 seconds to load, with new approach it would load in 1.5 seconds.
- Try to give rough efforts estimate. For instance - with the new approach it will be better UX but it might take a week of additional time.
- Lastly, use your common sense.
- Making suggestions - how to do this effectively
- Do your homework
- Suggest as soon as you come to know, don't wait for someone to ask you
- Suggest to your senior first, remember they have spent more time in the industry, they might have thought about it already.
- DO NOT SPEND TOO MUCH TIME BEHIND DOING THE HOMEWORK unless you are using your own time. Do it in steps, just suggestion first to senior with quick summary (I feel we can improve performance, I feel we can reduce clicks from 5 to 2) and if they say show me how you can ask for some time to do a POC or to do the full homework.
While doing this, keep your mind open and be good listener, it is possible what you are suggesting has already crossed Client's mind, but their priorities are different. Respect their priorities, remember it is their business idea and they will be responsible for the outcome (good or bad), not you.