Desktop and web apps can expand "forever". There are no practical limits to the number of dialogs one can add to a desktop application. There is no limit to the number of web pages on can include in a web application.
Mobile apps, unlike desktop and web apps, have limits on their functionality. These limits are set by the device and our expectations of mobile apps - an app on a smart phone can be only so complicated. Part of the limit comes from the screen size. The other limit comes from our ideas of mobile apps. We expect easy-to-use apps that "just do it".
What this means for development teams is that a mobile app may expand until it reaches that (nebulous) limit of complexity. At some point the app becomes Too Complicated. At that point, no features may be added -- unless you remove or simplify other features.
What this means for the managers of the development team is that the process to select features for a mobile app is very different from the process to select features for a desktop or web app.
The limits on development of these apps are not complexity, but team resources (and indirectly, money). A team can add features to desktop and web apps, and the constraint is the team size and the ability to test and deploy the new features. Development teams can be expanded, with additional funding. Test teams can be expanded. Deployment and support teams can be expanded. Funding can even overcome the limit of the building that houses the development team -- with enough money one can lease (or construct) another building.
The politics behind desktop and web applications are well known within organizations. The typical organization will have a committee (or perhaps a single person) who gathers requests for new features, assigns priorities, and feeds them to the development team. This committee acts as a regulator on requirements, and prevents the need for expansion of the teams (and hence limits the expense of the teams).
Discussions about feature selection and priorities may become heated as individuals disagree. Yet underneath the debate and the arguments is the understanding that all features can be accommodated, given enough time. If your request is not granted for one release, it is possible that it will be included in a later release. This understanding provides a level of civility in the discussions.
The politics for mobile apps is different. With hard limits on a feature set, there is no guarantee that a requested expansion will be included -- even eventually. Once a mobile app reaches a level of complexity that discourages customers, the app is essentially "full". Adding features to the app will drive away customers (and business).
The selection of features for a mobile app becomes a zero-sum game: features can be added only by removing others. This means that some requests will win and other will lose. And lose not in the "maybe for the next release" sense, but in the harder "not now and not ever" sense.
Once people realize this, they will fight much harder for their features. The debates and arguments about features will be more heated and possibly unpleasant, depending on the culture of the organization.
Savvy organizations will prepare for this change in politics. I can see three changes:
- Designate individuals or committees to define the user experience. These individuals will oversee the app design and review all features.
- Change the processes for feature requests to specify business benefits, preferably in terms of revenue or expense reduction. Also, define processes to hold requesters to their earlier estimates.
- Provide training for negotiation and conflict resolution.
The organizations that prepare for this change will be in a better position to move to mobile apps.
No comments:
Post a Comment