It's so frustrating trying to troubleshoot problems and to provide solutions when we do not control changes, especially changes on top of changes. What typically happens when you allow changes on top of changes is that you do not give ample opportunity for discoveries that may need to be addressed. If more changes happen, then it adds a level of complexity to the troubleshooting process. Did the new change create the problem or did it simply provide a means of allowing the previous "flaws" to surface?
I think we all deal with change just fine, but I really hate being in reactive mode anymore. I prefer requirements, design review, code, test, beta rollout, feedback, fix package, test, document, train and implement. Is this realistic or impractical?
I think it's somewhere in the Middle??
ReplyDelete