When FeedHenry was acquired by Red Hat a few years ago it was a very exciting time for our team. Something that was little more than an idea in 2010 had turned into a very impressive tech stack that managed to combine mobile and Node.js – two very hot technologies. Nearly two years later we are firmly integrated within Red Hat, the product has been rebranded as Red Hat Mobile Application Platform, and we are now recognized as a visionary in the Gartner Magic Quadrant for Mobile Application Development Platforms (MADP).
Even better, it’s clear that much of the internal education about why a perceived Open Source Linux company needs mobile is finally starting to pay off. The clear indicator of this? Numerous requests for our team that start with “I was talking with _________ over drinks at an event and they had a great app idea!” Our team has come to know these as “Beer Apps”.
“Beer Apps” typically have several common factors:
- Conceptually Simple – Solve 1-2 business problems that are perfect for an app
- Achievable – Often focus on data or collateral access with a nice UI
- Nice to Have – Not mission critical but would provide notable benefit upon roll out
- Woefully Undefined – The raw concept of the app is there, but limited thought has been put into app flow, driving user adoption, distribution, support, etc.
As you might imagine, it’s this last point I’ll be focusing on in this post. As with any IT project, improving the definition of the requirements greatly increases success rates and reduces development time, and in the mobile space this remains true. The lack of definition also forced our team into real “eat your own dogfood” moments – we work with customers to stand up mobile centers of excellence (MCoEs) and scale out app development, but until recently hadn’t received similar volumes of internal requests. It quickly became clear that we needed a way to collect, vet and prioritize these app requests without investing significant upfront time in each one.
Luckily, we had a wealth of consulting and mobile knowledge to pull from. The result is a rather simple system to funnel “Beer App” ideas into moderately thought out requests, and then into app activity at the right time. The framework is pretty simple and is hopefully easily reused:
- Document – Provide one landing spot that explains the process, lists contacts, documents previously created apps, etc. We use an internal wiki, but have seen Google Docs and similar systems work well with customers.
- Enable Self Definition – It’s unreasonable to think that every app requestor should provide detailed requests. It is reasonable to assume that when prompted with simple questions they can easily improve the level of definition in the requirements. We drove this with a simple questionnaire (see below).
- Prioritize – The business needs of apps range from “Game Changing” to “Cute Idea”. Working with requestors to find the true need for the app (and sometimes helping them reset their expectations) will ensure developer time is being used wisely.
- Share – Even the most well implemented apps will fail if they aren’t distributed. Find a way to share and promote these apps internally – both for the defined use case and as an example of a team’s capabilities. We do so through the above mentioned Wiki, an internal Red Hat Mobile Application Platform App Store and will soon be releasing generic versions of these to our Sample Apps GitHub repo.
- Reward – Many of these internal apps are handled by team members on off hours and aren’t a part of their main duties. A nice reminder and recommendation on preferred rewards keeps developers motivated to go the extra mile! In some cases we even see beer apps resulting in beer rewards that drive more beer app ideas – a full Beer Development Lifecycle (BDLC) if you will!
While a lot of the above is borderline common sense, it’s also a structure that seems to work well. Of all these points, the biggest time saver has been enabling requestors to better define their requests. With this in mind, I share the questions we propose early in the request process:
- Please provide an overview of the app including functionality, users, timelines and any other relevant information.
- Who is the sponsor/requestor of the app (name, role, etc)?
- What are we trying to accomplish/improve with this app?
- What is the desired timeline for delivering this app?
- What happens in a best case scenario (Great app, quick turnround, etc)?
- What happens if the app is delayed or unable to be delivered in a timely manner?
- Is there budget for this app?
- What is the goal of the app?
- Are there systems/processes that are already used to accomplish these goals?
- Will these systems/processes be replaced, integrated with or supplemented by the app?
- Please provide a detailed flow of how the app will be used.
- Please provide specific functionality that should be included in the app.
- Who are the core users of the app? How many users are there?
- Are users going to be Red Hat employees? Customers? General public?
- How will this app improve the user’s ability to perform their role?
- What types of devices should this app run on? (iOS, Android, Windows Phone, BlackBerry, browsers, other)
- What systems contain the business logic used to drive this app?
- Who owns these systems and can provide integration details?
- Is Single Sign On required to access materials/resources in the app?
- Will the app require offline data synchronization?
- Will the app require access to device features (camera, gps, etc)?
- Will the app require any external administrative consoles?
Long Term Considerations
- Who is going to own updates, maintenance and improvements to this app long term?
- Please provide an overview of the functionality you’d like to see in V1, V2 and V3 of this app.
- Please provide any additional details that would be helpful
The Red Hat Mobile team hopes you find the above information useful and would love to hear how your team approaches the collection and vetting of internal app requests. More importantly, we’d really like to know what your equivalent name for “Beer Apps” are internally!