Change is constant
We moved our office and our data center earlier this week. It was not without its hiccups but we got through it thanks to heroic efforts by the Techrigy team. We’re also launching yet another update to SM2, about the fourth since I started 2 months ago (details soon). If you’ve ever worked in a software company you know this is pretty cool. If you haven’t here’s a little info about how it used to work and how it now works (if your developers are good!)
Old way:
- Write a BRD. Business Requirements Document, which details every possible thing needed to be built in. Six weeks if you’re lucky.
- Argue about the BRD with engineering and revise timeframes outward several weeks (or months).
- Write code, do a build, break the system and blame each other.
- QA to debug.
- repeat several times.
- Launch ‘beta’ which means if it’s f**ed up you have an excuse.
- Timeframe between builds: 6 months
New way:
- Talk to customers and users everyday and keep track of requests that make sense
- Notice places where users consistently don’t get it and think about how to make it easier
- Imagine you’re sitting at a desk trying to make the app work the way they do
- Decide on a set of doable changes, prioritize which can be done sooner and which require more work
- Build both but launch the simple ones first.
- Timeframe between builds: two weeks.
The reason for the title of this post is that there simply isn’t time to do it the old way. Someone else will come along, do it faster and eat your lunch.