How to organize a team creating ONE app with two distinct users groups

January 25, 2013 7:22 AM

The product will target two completely different groups of users, with different deadlines. Should we be separate teams or one team? What other applications are there that does something similar and how are they managed?

I am a software developer that is about to start working on a project. Our manager wants to create one team of developers and analysts and have them work on the application. And based on the priority and deadline, the developers and analysts will focus on the specific group of user. His main goal is to avoid redundancy and he thinks this will be more efficient. While I don't disagree with this approach, I'm sure other teams have had to deal with this type of issue and want to know how they managed it.

posted by tedunni to computers & internet (7 answers total)

Is the code different in any way between the two user groups? Code customization, configuration file customization, custom installs? Whatever the point of customization, you want to have very good/strong/stable interfaces between the core code and the custom code. The core team should be separate from the custom team. It sounds like you're going to target one group of users, build the app for them, and then deliver it to a second group of users -- that will simplify priorities on the core team.

The main issues you will face, in my experience:
- interface definition/stability between core/custom
- different priorities/deadlines for the core team
posted by elmay at 7:42 AM on January 25

You don't split vertically, you split horizontally. Find the core that's common to both products and have one team work on that. Their customers are the team(s) working on the user-facing products.

Works best when your components have well-defined boundaries, as in, say, SOA.
posted by Leon at 7:48 AM on January 25

elmay
The code will be different between the two different user groups. The plan is to use a strategy pattern and based on the data to load components specific to the group of user.

Leon
What do you mean by "you don't split vertically, you split horizontally"?
posted by tedunni at 7:58 AM on January 25

You can think of your product as comprising lots of layers; the top is layer is what the users see, and then you descent through display, processing, ... all the way to backend stuff like fetching data from a DB. I think of this like a cake.

"Split vertically": each group makes a separate cake, and then you put the cakes next to each other.
"Split horizontally": each group makes a layer, and then you stack the layers on top of each other.

So, for (a bad) example, think about a product that displays some data in different forms, say showing charts of US economic figures to US users and GB economic figures to GB users. The "vertical split" way to do this is to have one team work on the GB users' product, and one team on the US users'. The "horizontal split" way is to write one product that fetches and processes data, and two data-fetchers and data-charters.
posted by katrielalex at 8:42 AM on January 25

"Split horizontally": each group makes a layer, and then you stack the layers on top of each other.

A better explanation than I could have mustered. Linky
posted by Leon at 8:47 AM on January 25

If the app's content is oriented around what could be called user "roles," then it sounds like it's mostly one app with varying kinds of data behind it, in which case it makes sense to tackle them sequentially. If anything, you could have another person(s) working on the other kind of content, but if the app itself is substantially the same in functionality between them, working on one at a time would be smart. The thing to look out for is whether the second-group deadline is malleable as you learn through the first one how long it takes to take care of the content/structure/differences.
posted by rhizome at 9:25 AM on January 25

Your questions are pretty much unanswerable without more information. That said, you've said enough to make me question your manager's choice.

Efficiency shouldn't be one's main goal in organizing a software project. This isn't to say that one shouldn't strive for efficiency, but only when it is subservient to the questions of risk and reward.

First question I'd ask is why, if there are two completely different user bases, this is being treated as a single app? How much overlap is there in scenarios/use cases between the different user groups? How different are the deadlines? How far in the future are the first deadlines?

What I'd probably do is have the analysts work together to define requirements for both audiences so that they have a shared understanding of the commonalities and differences in needs. As they are developing that understanding, they should be communicating their understanding to the developers so the developers can be thinking about how to architect things.

Once there is a good consensus around requirements and architecture, I'd start thinking about how to divvy up resources. If timelines allow for sequential development, I'd lean towards keeping the team focused on one at a time.

If the timelines demand parallel development, I'd put one or more teams on the shared parts of the architecture, and one or more teams on the role-specific functionality.
posted by Good Brain at 7:25 PM on January 25