(Migrated from the legacy OSLC wiki. Source.)
Original post on the mailing list September 24.
Idea: A set of personas and user stories representing the kinds of people who should care about OSLC, will make it easier to determine what messages we want to send, and what channels we should use to send them.
Personas
N.B.: typically personas are the result of the analysis of empirical data (including interviews), I don’t have that detail at this point, so these are more a “stick figures” supported by my personal world view. To start, I’ve created one for each stakeholder group identified in Outside-in software development, diving deeper in, we will likely find more distinct personas of each type.
- Systems Integrator [ Partner, though sometimes played by an End user ]
May be internal or external to the company who will use the final integrated system.
Faces enormous pressure to make two (or more) disparate software systems work together; or even to make systems that should work together, work together in a specific way that supports the company’s processes.
If able to influence purchases, has a strong preference to selecting systems that integrate “out of the box”, or those with a well-defined and proven integration strategy/method.
- Tool Vendor [ Insider ]
Has one or more offerings in the market.
Faces competition from other vendors, including open source software.
Primary value to customers is in making them more efficient, more accurate, more productive, etc.; i.e. they need to demonstrate that they reduce costs for their customers – they don’t drive revenue for their customers.
In sum, lowering costs is a challenge faced by both the vendor and its clients.
Even if they do everything right within their own product(s), many sales opportunities are stillborn by the prohibitive cost of migrating and integrating the product into a prospective client’s existing system.
- Tool Buyer [ Principal ]
Already has software being used to facilitate its current processes.
Cannot throw current software solution away and start from scratch.
External pressures (from its competitors, for example) may cause them to consider more drastic changes to its system, but incremental improvements are more common.
Often stuck waiting for vendors of its current software to “catch-up” with another product available in the market because the cost of migrating to the other product and integrating it into the existing solution is prohibitive.
- Tool User [ End user ]
Has experience with some existing technologies, some are used by his employer, other used through previously experience.
Measured on results – adverse to change that puts ability to deliver in jeopardy. (May actively resist initiatives to adopt an unknown software, may actively promote initiatives to adopt a previously used software.)
Often has a more short-term perspective and is a resistant recipient of change coming from management’s attempts to address broader business challenges.
- Influencers
E.g. Press, Analysts, Consultants
Provides comments, observation, advice on industry and technology trends. Those who have a platform/opportunity to “spread the word”.
User Stories
- As a Systems Integrator,
I want to know that I can augment an existing system of software tools with a new tool that addresses a new business need, with minimal disruption to the operation of the existing system, before I begin the project,
so that I can accurately estimate the effort and cost of integrating the new tool into the system and avoid unpleasant interactions with any stakeholders of the existing system.
- As a Systems Integrator responsible for providing and supporting an integrated environment comprised of homegrown, open source, and purchased tools,
I want to use standard and common integrations,
so that I can reduce my administration and support efforts.
- As a Tool Buyer,
I want the best tool available for my specific needs to easily integrate with the rest of my existing solution,
so that I can reduce the costs/maximize the production of my IT organization.
- As a Tool Buyer,
I want the option to select the second best tool available for my specific needs because it also easily integrates with the rest of my existing solution,
so that I can negotiate lower acquisition and/or maintenance costs from the vendor of the tool I prefer.
- As a Tool Vendor,
I want to reduces the costs of, or even eliminate the need for, a proof of concept before a prospective client is willing to purchase my product,
so that I allocate more resources to improving my product, general marketing, or profit.
- As a Value-producing Worker,
I expect any new software I have to use to have an “intuitive relationship” with all the software I’m already using,
so that I can continue to “do my job” even while I learn how to use the new software.
- As a Tool Buyer who has to invest in integrating a new purchase into my existing infrastructure,
I want to purchase software that will make future integrations easier,
so that I don’t have to re-invest in doing the same thing, with different tools, five years from now.
