It's now 11:30 pm and I am still just on my way home. I am working on a project wherein I am the only developer. And now that it's just a few days from QA testing, I find it hard to test all my implementations and verify it against the FSD (Functional Specification Document).
The project started without the FSD. And since the project plan indicated that I should start without the FSD, so I did. It was tough. I had to rely on verbal requirements from the SA (Systems Analyst) and the verbal technical decisions from my team lead whom is located on the other half of the world. On top of that, I had to deal with the changes in the requirements that wasn't being tracked properly since it was verbal as well.
When the FSD finally came out, I had to recheck everything which is what I am doing right now and make the necessary adjustments. Oh by the way, I just came from a TSD (Technical Specification Document) review. These gives huge risks in the final product's quality and sacrifices traceability and coherence. Not to mention, it creates confusion and a lot of frustrations.
This post is not meant to be a rant. Just think of this as my way of sharing my experience so that other managers, leads, and analyst may learn from these. Ok ok I am in a way ranting... Hahaha!
So what are the lessons learned from these?
1. If you are a project manager and you want to do the requirements definition, technical analysis and design, and development at almost parallel, then use the appropriate approach like the agile methodology. Also, do a lot of risk planning.
2. If you are a developer and the above holds true, then record everything you can weather you ask questions through email or you record your discussions and give out minutes of every meeting with your lead and analyst. These will later on come handy when they are trying to find someone to blame for the not-so-good outcome of the project. It's so easy to point at unsuspecting developers believe me.
3. If you are a lead and the above still holds true, try to pressure your manager and analysts to stick to the requirments or finalize them as soon as possible. Also make sure that your whole team is on the loop and that all changes in any requirements and design are reflected back to the estimates and ultimately the project plan.
4. Lastly, for the analyst, make sure that the product owner or the ones giving out the requirements is comitted 100% to the project so that he can give out timely decisions and prioritization of requirments as well as to give clarity to what he wants as the project progresses.
So there, I hope this experience of mine might benefit one of you someday.
-------------
sent through email via my mobile phone
