Ambiguity in DevOps Technical Training
What’s the most valuable skill when developing technical training in a DevOps environment? The ability to embrace ambiguity is up there.
First of all, DevOps is a method used to deliver digital applications and services at a very high speed. The Development and Operations work on the product together instead of in two silos, which moves thing along in a more efficient and consistent manner.
When things move that quickly, there’s a lot of building the plane as we’re flying it. Creating software training in that space means the only thing you can anticipate is that your plan will change.
My brain tends to be very cut and dry, so embracing ambiguity didn't come naturally at first. Over time, I accepted some fundamental truths that exist in every work project in which I’m involved.
Accessing an environment with appropriate test data will be challenging. Demo, test, or reference environments may be unstable, or full of glitches. If the development team is running behind, your environment access will be delayed. Sometimes you have to get creative about building technical training without an environment, like covering the concepts with some high-level screenshots without getting into specific workflows at that point in time.
The functionality and use cases will not be set in stone. I’ve had learning objectives change days before publishing a course because the product team pushed back some of the workflows to the next release. Buttons in the GUI (graphical user interface, basically what users see on the screen) will appear and disappear multiple times throughout the project. You have to keep very clear records of what features you are expected to cover.
Release dates should be included in the plan. If an update to the product is coming down the pipeline every six months, decide who is responsible for updating the training materials. For example, maybe the trainers make a list of what updates impact training, and the instructional designers modify the slide decks.
Customizable solutions means each customer’s screen might look different. Will you sell core or customized training? Customers may purchase core training to save money because customized training takes more time to build, but will they be disappointed when the trainers’ screens and workflows don’t exactly match their own?
When developing technical training in a DevOps environment, my greatest advice is to stay curious and ask lots of questions. Hunting down the clarity and resources you need to develop an excellent learning solution for your product is just part of the process.
