All the considerations below are based on DevOps <-> Dev scenario, but IMHO vast majority of them applies well to any supplier <-> buyer scenario.
DevOps' reality is somehow simple:
- they work for other developers (their "clients")
- their goal is to make other developers focus solely on the business functionality, without caring much about setting up the development process or deplyment pipeline itself
- automating what could be automated (so other developers have as few tedious and repetitive tasks as possible)
- setting the standards & convententions that would keep the tech debt under control / security procedures intact
Let me state it once more - DevOps work to aid other developers: by bringing them suitable tools, setting up release mgmt, configuration mgmt, basic CI, etc. It looks straightforward, but DevOps tend to forget about few important points ...
Feedback is precious
Once you set something up, you need to gather the feedback - whether it does work as intended or not:
- do the people use what you've created for them in a way you've designed it? or do that have to hack-around?
- is what you've done enough? or do they have to add additional error-prone manual steps?
- do people understand what they are doing? do they see the sense of purpose in that? or maybe they are just forced to do as it's written in a policy?
Getting feedback is crucial and it's YOUR responsibility (as DevOps) to do that. Don't wait for it:
- ask for it specifically, be persisten in drilling it down
- organize hands-on-experience sessions with new tools to go through some real-life scenarios
- do some dog-feeding (try it on your internal projects first)
And once you get this feedback, remember that it was some kind of effort from your "clients" as well, so make them feel it pays off:
- make it fully transparent, so they can see whole lifecycle of every comment / issue they've applied (whether it was rejected / resolved / waits for decision, etc.)
- respond their concerns in a clear way and make sure that the understanding is shared = both sides are "on the same page"
Doing well is not good enough
If you respond to any need that has been risen by your "clients" (in formal / informal way), make sure that they will know it, so:
- they are assured they are being listened to
- they see that you continuously put some effort in active maintenance of the tools they use (so they can expect situation to get gradually better)
Doing well is not enough, if you keep the information about what you've done just for yourself. You have to sell it internally - don't worry, the recipients will be very happy to hear about what you've done for them!
Push vs Pull
When you have some information to share (about the accomplishments made, about the further plans, about the workaround for raised issues), make sure that you choose the proper way to distribute the information:
- aim your recipients well: target only people who are really interested in the information you'd like to pass; there are not many things worse than the overflow of irrelevant information - all the following communication will just be ignored: you can't really afford that
- make sure that you get the basic distinction between
'push-like' and 'pull-like' information distribution: - use pull approach (wiki, blogpost, structured documantation) if you don't know when your client will be interested in the information published and you're sure they will know where to search for it
- use push (mass-mailing, notifications) if the information is urgent / expected right now (maybe there's an issue to be addressed ASAP)
Definition of done (again)
If there are any needs to be addressed / issues to be resolved, make sure that every DevOps has the same understanding what's the final, expected effect of their work:
DevOps are not just expected to develop & test the solution, they are also expected to make sure it's actually being put in use by their 'clients'! They are supposed to:
- announce / advertise the change
- reach out to the target users
- educate them by providing the sufficient training / documentation
- make sure that they have a way to give a proper (and trackable) feedback
- confirm, that the changes are actually being used and they've met the expectations
Seriously, there's no gain in changes if no-ones knows about them / uses them / understands them. We are all salesmen, that's how life is these days.
Solution vs workaround
Sometimes you'll receive the urgent issues you can't solve immediately. Some of them may seriously impair your 'clients'' work. And let me tell you something: they don't care whether you'll have the complete solution in a week or in a month - they want you to do something that will make them work normally (or as normally as possible) NOW, because otherwise:
- there will be an additional cost or ...
- ... maybe even they won't be possible to continue work at all
That's why the first priority is not to solve the root cause of problem, but to make sure that operations are recovered back to normal ASAP, even if it means a (more or less) dirty workaround before the full solution is deployed.
The conclusion
As DevOps, usually you're not facing the business client directly. But it doesn't mean that you have no clients - you still work for someone and your main priority is to make them happy:
- to assure them that you understand their needs
- to make your workstream visible enough, so they know their priorities are reflected in your work pipeline
- to convince them, that no raised issue is ignored / forgotten
If you forget about that, you're becoming more a burden than a real use.
