As someone who recruited a team for an application that spans PC, mobile and web I have some scars in this subject area!
Myth 1: You need to hire mobile experts.
Reality: Hire great athletes; mobile “experts” will be useless in 6 months
So true. Yes, you do need some specialist mobile knowledge, as the idiosyncrasies are many, but just because they have expertise in mobile doesn't mean that they should lead the team, but rather they should be used as a mobile SME for the rest of the team.
Myth 2: Your mobile codebase is different from regular code.
Reality: It's just code. You should treat it as such.
True, but I don't think this is a myth, so a red herring really.
Myth 3: You need carrier or handset deals to distribute a mobile product.
Reality: Focus on standard consumer distribution first, not carriers or handset manufacturers.
Hmm, moot point, as this definitely not true any more, but once upon a time, getting your apps on mobile operators' deck (ie their home page which listed 'recommended' apps) was key.
Myth 4. You must build for all platforms from Day One.
Reality: Start with iPhone or Android only first.
Myth 5. (Once the app launches) We are mobile geniuses!
Reality: Stay hungry and keep questioning your mobile direction
Both are true, but so obvious, this isn't a myth.
Some of my own observations:
1. Version Control and Release Management is more important
With multiple platforms with interdependencies between web code set and mobile code set and PC code set, then release management and planning must be taken to a whole new level.
Agile programming and development approach (which work really well on for internet deployment) slowly crumble in the face of multiple environments. Development can be done in short 'agile' styled bursts, but only really work for interim releases (ie NOT vX.0 releases).
Significant functionality enhancements (ie X.0 releases) require mega planning so that the new functionality works at every tier. As a result, some platforms 'get ahead' of others. eg the mobile platform is dragging its heels, so the web dev team start working on the next release (or even the release after that). As you can imagine, Code Management has to be very robust! (And DO avoid the temptation to crash a release out on one platform, even if it isn't ready on other platforms - the user experience / PR fall out is significant!)
Do check out my Feature Prioritization & Product Road Mapping Whitepaper which covers these issues in detail.
2. Architecture is very important to get right first time
For the reasons in (1), getting the architecture is very, VERY important, as modifying this is SOOO painful. Again, an Agile approach of 'hmm, let's build something simple to start with and see what happens' is full of fallabilities - I'm not saying it is wrong, but will generate problems in the future. (I have LOTS of scars here from this decision - porting data from database structure to another seemlessly so users aren't impacted took months and months. (I am very, very pleased to start that the project was a fantastic success, but it required a lot of time and some very high calibre people to see it through.)
No comments:
Post a Comment