Personas
This document describes the main personas we are targeting with devo.ps, in order of importance.
Our audience is found in technical teams, with the following preference;
| Aspect | Description |
|---|---|
| Picture |  |
| Background | Roy is a Web developer on a team of 4 engineers and 2 front-end guys (1 designer and 1 UI developer). He's mostly in charge of the back-end stuff and works primarily on his local. His main interaction with infrastructure is through the "ops guy" (one of the engineers). |
| Key goals | As a developer, Roy doesn't want to get his hands dirty and be in charge of what happens on servers. He mostly deals with it when he wants to deploy his work to actual servers (asking for a service to be added, a configuration to be changed or some code to be deployed) or when something goes wrong (the applications slows down or break). From his point of view, Moss (the ops guy) is the one responsible for applying changes and investigating any issue that code may encounter when deployed in production. |
| Key issues | For Roy ops are a complete black box AND a bottle neck. It takes ages for anything to get done ("You need a new dev server? No problem, I'll get to it next week."), changes are often met with resistance ("We can't install Redis on production. Use what we already have; MySQL for example.") and he has little to no visibility ("Server logs are restricted to ops, but I can send you a copy."). |
| Scenario | Roy just finished building a new applications that Jen, his manager, asked to put online ASAP. Problem is, he doesn't have access to the AWS console to spin off a new server. Even if he did, he wouldn't know where to begin with and would be afraid to mess things up. Using devo.ps, Roy can simply clone a box set up by Moss, without having to add to his colleague's workload while sticking with his set of best practices. Making a few changes to meet his requirements and deploying code is fairly easily performed by changing a couple settings, which can be safely reviewed and integrated back into production later on by Moss. |
| Selling points | Visibility/accessibility, low barriers of entry |
| Aspect | Description |
|---|---|
| Picture |  |
| Background | Moss is the ops engineer (sysops, sysadmin, DevOps dude...). He's the only one of his kind on his team and is in charge of building and maintaining the infrastructure, as well as deploying and ensuring applications are running fine. When something goes wrong in production, his ass is on the line. When one of the engineers on his team need to run code on a server, he's the one picking up the slack. |
| Key goals | Moss tries hard to ensure that the infrastructure, and the code that runs on it, is secure, stable and scalable. He defines best practices (security, cloud of choice, OS flavor, recommended technologies...) and keep the keys to the infrastructure to make sure his team sticks to it. He monitors as much as he can and usually try to control the chaos that new code introduces on performance and dependencies. |
| Key issues | Moss feels like he is constantly running, putting out fires and catching up with the work load his colleagues are collectively dropping on his plate. He often has to push back on requests to make sure "his" infrastructure is not changing too fast (which would increase the risks of security or performance backslash). His workload keeps him in FIFO and away from investing more in what the cool (DevOps) kids recommend: automation, monitoring (all the things), configuration management, deployment strategies... He knows that if sht hits the fan at 3:00 AM, he'll be the one up fixing it and will still be blamed for it, even if the issue was introduced by shtty code. |
| Usage scenario | The development team is about to work on a new major redesign of their backend API for their upcoming mobile application. They are ggoing to need development machines to test their code and more importantly, some of the architecture changes they will introduce will need to be merged with the production infrastructure. Using devo.ps Moss is able to let his team clone existing machines while knowing his best practices (backup strategy, service configuration, automation...) will be clone along with it. Once his team has made enough headway, he can easily review the changes on both infrastructure and automation for integrating things back into production. |
| Selling points | Embedded best practices and boilerplate, ease of sharing (with the technical team), true infrastructure as code, easy automation |
| Aspect | Description |
|---|---|
| Picture |  |
| Background | Jen is the project manager. She's in charge of managing the chaos of her engineering team and interfaces with the client, in her case the upper management of her company ("Evil Bastards Inc."). She has some level of technical expertise and contributes to architecture decisions. She understands the nuances of the various technologies her team uses. She's the one keeping people on track and on budget, moderating discussions between front-end, back-end and ops guys and taking the tough decisions. |
| Key goals | Jen is trying to make sure both developers and ops get along and communicate. Ultimately, her goal is to make sure things move as fast as possible without crashing. She has little to no preference for specific technologies as long as it gets the job done, but is painfully aware of the entrenched arguments between both factions on her team. She wants to get the job done but doesn't necessarily always know how to bring both sides to see eye to eye, in which cases she usually needs to take the final decision. |
| Key issues | Doesn't care > Wants to see shit done, has poor visibility over infrastructure (like dev), is struggling to see investment in ops being properly captured, can't seem to see ROI since poor automation/cm/... |
| Usage scenario | Coordinating launch of a new API, she needs to see things online quickly. |
| Selling points | Visibility, investment is actually captured in code, able to onboard others |
For enterprise clients, persona of a typical manager who takes the decisions with regards to SaaS solutions.