Comment Re:As much as it pains me to say this... (Score 5, Insightful) 262
I recently had the (mis)fortune of managing a small project from start to finish. Here's how it should have gone:
Business Requirements -> UI/UX design -> Development -> Review and Revision -> Implementation
Here's how it actually went:
Business Requirements (BR for brevity) assuming advanced (impossible) AI -> UI/UX/Dev meeting -> New realistic BR -> UI/UX/Dev mockup and approval -> Development Committments made -> Solution approved by UI/UX -> Implementation and Financial Committments made (with new BR "minor adjustments") -> UI/UX/Dev meeting to explain why BR "minor adjustments" are impossible with Implemented Solution -> Blame, paper trails, resumes updated, late night cowboy coding -> New Solution -> UI/UX/Dev meeting results in UI/UX "minor adjustments" -> Emergency Spagetti Coding -> UI/UX/Dev meeting results in UI/UX "minor adjustments" -> Much Balmer Peak coding, Terrifying Debugging -> UI/UX/Dev meetings results in UI/UX "minor adjustments" -> Spagetti code disassembled, rewritten for sanity (more late night Balmer Peak coding) -> UI/UX meetings finally result in a final stable Soution
I adamently wish I knew how to adjust the process so that the "should have gone" cycle would actually happen but there are hurdles I haven't found a way around because all too often:
- Business Requirements writers don't know what is really possible because they don't understand the data or programming possibilities
- Users don't know what they really want because they can only imagine what they already know with added buttons
- Developers commit to plans blind to what future changes will be required
- User Interface designers don't realize the limitations of development, the data, or what the users will actually do