Introduction to Customer Empathy Workshops

Product feedback from users goes a long way. It’s why Red Hat’s OpenShift Web Console UI is as awesome as it is today. Features like Dashboards and Topology were added because of user feedback—and that’s how we plan on enhancing the console even further. One thing’s for sure: The path to a better console experience relies on continued customer engagement.
Thus, Red Hat has launched a series of workshops specifically geared towards engaging and empathizing with OpenShift customers in order to better understand their needs. We’ve dubbed them customer empathy workshops.
What they are
Our customer empathy workshops enable customers to collaborate with OpenShift user experience, development, and product management to directly influence the future of the OpenShift console. Each workshop has a special topic to focus on so that the group can really hone in on the challenges they face in specific areas. Customers are introduced to our design thinking process as we dive into real product development challenges, starting with problem discovery and following with solution ideation.
The design thinking process

Hands-on activities give our customers the unique opportunity to connect with the OpenShift team, share their pain points, and collaborate with other community members throughout the session. This kind of collaboration makes the product what it is today, so we want to continue engaging with users as much as possible.
Value for our customers 
These workshops certainly help the product evolve, but they also give customers an opportunity to discover, impact, and connect.
Discover: Our customers will get the opportunity to learn how product decisions are made from the small fixes to the larger feature additions. They can also share their pain points, what they struggle with, and where they need help—as well as learn how other companies have overcome similar obstacles.
 
Impact: Customers can lead the conversation around the OpenShift user experience, engage with other OpenShift users, and collaborate through knowledge sharing and group solution ideation.
 
Connect: Discussing the OpenShift console with users brings together folks from different countries, industries, and technical backgrounds. We hope that our participants walk away with new connections and feel even more connected to the OpenShift community.
Our opportunities
While customers are discovering, impacting, and connecting, we’re gaining valuable insight from all the feedback. Specifically, we have the opportunity to listen, prioritize, and design.
Listen: We want to learn more about how our customers use OpenShift: What their environment looks like, how many people are on their team, what their biggest pain points are, and more.
 
Prioritize: Through hands-on activities, we hope to better understand the problem statements that arise throughout our workshop. The more we learn about customer pain points and what ideal solutions might look like, the better we can design a powerful experience.
 
Design: At the end of the day, we want to take all customer  feedback and implement features to make the OpenShift experience better. So after each workshop, we’ll analyze the data, explore the proposed solutions, and design a fix or new feature to address it.
Stay tuned
This series has been an exciting addition to our engagement efforts, and we’ve heard some great feedback from those who have already participated. Following each workshop, we’ll share a summary of the workshop and preliminary results. So keep an eye out for upcoming customer empathy workshops and content. We look forward to sharing the results with you in an upcoming blog article!
The post Introduction to Customer Empathy Workshops appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

How Omnitracs Transformed to a DevOps Culture with OpenShift

Omnitracs has taken an interesting road to get to its current position as a leader in fleet management software for logistics and transportation companies. Their SaaS-based offering allows companies to track, monitor, and bring into compliance all of their trucks and shipping vehicles around the globe from one system. But just because Omnitracs users were taking advantage of cloud-based software as a service models of consumption doesn’t mean Omnitracs developers were fully utilizing the cloud and the agile methodology it enables.
That’s only been the case for the past year, in fact, since Omnitracs began adopting Red Hat OpenShift. Andrew Harrison, lead IT DevOps Engineer and lead of the Agents of Change team at Omnitracs, was tasked with building the company a road to the future of software development, and the pavement on this road was built with OpenShift.
Since 2014, Omnitracs has been growing rapidly, launching over 30 new products, and merging in the assets from a number of acquired companies. To keep up with all of this growth, the developers in the company had to transform their way of doing things, top to bottom.
Thus, a year ago, Harrison was placed in charge of affecting change throughout Omnitracs’ IT organization. That means introducing devops, automation, agile methodologies, and continuous integration and deployments. That’s a tall order for a single team to spread such changes through an entire enterprise.
And yet, a year later, Harrison said he’s successfully transitioned the company away from a “waterfall” style of development and deployment towards a devops and agile based approach, thanks to the help of the Red Hat OpenShift platform. Instead of code pouring in as it was completed, like a waterfall, developers were able to iterate over time in smaller chunks. While the move began with OpenShift 3.11, the company was also one of the first to roll OpenShift 4.1 out to production systems.
Harrison said the benefits of moving to OpenShift 3.11 were immediately noticeable. “With OpenShift 3.11, we were able to get immediate cost reduction because we moved everything out to the public cloud [eliminating on prem costs]. We got rid of on-premise costs immediately. We wrote custom Ansible playbooks to make sure everything was infrastructure as code and was always repeatable. We reduced our environment deployment times from over a week to less than 2 hours,” said Harrison.
Those technical wins were paralleled by cultural wins as well, he added. “We had a total transformation in the IT department, especially in our organization. Our team, The Agents of Change, evolved from the traditional waterfall style to a real agile methodology which greatly reduced all of our release times.”
Soon after moving onto OpenShift, the team at Omnitracs embraced OpenShift 4.1 and the Operators model for services availability.Harrison noted that the Operators model enabled faster integration of services essential to building out a production-grade cluster. The team now uses Splunk for logging, and Ansible for automation.
Software is not the only thing changing inside the Omnitracs OpenShift clusters, however. The company is also using this Kubernetes-based cloud software to improve its internal IT teams. Said Harrison: “We took the SRE [Site Reliability Engineering] model and turned it on its ear a little. We’re spinning up 35 new scrum teams in the coming years, and we’re not going to find SREs for each of those teams; it’s not going to work. So we took a different approach: we’re using a virtual ops approach, where we’re embedding with these teams now and teaching them the ops part of devops. They are going to be their own SREs. They will have the ability and proper permissions in OpenShift to spin up their own namespaces, start projects, give people access to them, and all of that. We’re really giving them the ability to provide care and feeding for their own areas, but at the same time, giving them the ownership of it. So now when they are building their applications, they are actively thinking about the operationalization of it,” said Harrison. 
That transition also means internal developers are expanding their skill sets to include more capabilities, enhancing their resumes and growing their careers while also contributing to the growth of the company itself. It’s a win-win situation. “They know that the logs are collected in Splunk and through VictorOps, they get that notification back when something’s gone wrong. It’s just part of how they do their daily job now,” said Harrison. 
How did they manage to put all this power into the hands of the developers themselves? “Early adoption of OpenShift 4 was critical to our success. We were very much looking at this as if we were going to be on this for the next five years and didn’t want to get stuck on an older version, so we took that risk. We were very tightly working  with Red Hat while doing this. They’ve been embedded with our teams for the last year. They are a part of our team. We drove innovation within our team and within Red Hat. The stuff we were working on was being brought back into Red Hat to bring the platform to where it is today,” said Harrison.
“That transformation we talked about earlier from traditional systems administrators in an operational role to devops engineers, we did that in less than a year. We weren’t doing this a year ago. We were traditional systems administrators in our silos. We had Linux guys, we had VMware guys, we had network guys. Now we’re all on a team together, we’re all doing this stuff every day. It’s been an amazing transformation for the technology we’re working in and for our careers. It’s been great, and that tight partnership facilitated that shift very easily. Having Operators available to us allowed us to deliver services to the dev teams almost immediately on day one,” said Harrison.
 
The post How Omnitracs Transformed to a DevOps Culture with OpenShift appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift