When you think about the software requirements process, the simple process that comes to mind is about the Business Analysts or the Product Manager studying the business needs, and then coming out with the requirements. In a number of cases, there is the expectation that the Product Manager or the Business Analyst will spend time on these business cases and then there will be a Requirements Documents that will be released to the team for the next part of the cycle, the design and architecture phase. In the case where the work is being done for a client, the Requirements Documents generated by the Business Analyst can be sent to the business people from the client end so that they can verify that whatever is being done is right. However, there is a black hole about the requirements process, with the team getting a completed document.
When you consider the case where the team has worked on the product before (which is true in most cases of product development, or even in cases of client work where the team has worked with the client on their software previously), the team has a great deal of knowledge of how the software works. This also means that the team is a valuable knowledge base that the Product Manager or the Business Analyst should be exploiting. However, it is equally true that there are Product Managers who consider themselves to be above taking support of the team (at least in the process of generating the Requirements Document).
If the Product Manager was to take the help of the team for generating the Requirements Document, how would this happen. Well, for a complete process of taking help,
- The Product Manager would need to start out with forming a small team that would assist him or her in this process, taking the more senior folks from the development and testing team.
- The Product Manger would need to lay out the high level points of the requirement, and put them in a list or form that the team can review and get back in terms of comments that they may have. At this stage, it is unlikely that the team would have substantial comments since these are high level requirements.
- Once the Product Manager starts detailing out these requirements, converting them into more detailed requirements, or into User stories, this is where the team can really contribute. These can be put onto a document or internal web page that the team can review and comments posted, followed by a meeting. In some cases, I have known that team members taking care of the development or testing of a specific area have more knowledge of the details of the workflow and have made corrections, or even suggested some improvements that have added value. However, it remains at the discretion of the Product Manager to decide which of these points should be taken or not (it makes for a more cordial relationship though if the Product Manager does explain the reason why something is not taken).
- This can be an iterative process, but once it is done, then Product Manager has a set of requirements that form the basis of the work that happens next, and the advantage is that during this process, the team already has a great idea of the requirements flow; and equally important, understand the amount of work required, which also helps in determining the resource requirements and time needed for all these requirements (or atleast, gives a much better feeling in terms of increased accuracy of the resource estimation).
When you consider the case where the team has worked on the product before (which is true in most cases of product development, or even in cases of client work where the team has worked with the client on their software previously), the team has a great deal of knowledge of how the software works. This also means that the team is a valuable knowledge base that the Product Manager or the Business Analyst should be exploiting. However, it is equally true that there are Product Managers who consider themselves to be above taking support of the team (at least in the process of generating the Requirements Document).
If the Product Manager was to take the help of the team for generating the Requirements Document, how would this happen. Well, for a complete process of taking help,
- The Product Manager would need to start out with forming a small team that would assist him or her in this process, taking the more senior folks from the development and testing team.
- The Product Manger would need to lay out the high level points of the requirement, and put them in a list or form that the team can review and get back in terms of comments that they may have. At this stage, it is unlikely that the team would have substantial comments since these are high level requirements.
- Once the Product Manager starts detailing out these requirements, converting them into more detailed requirements, or into User stories, this is where the team can really contribute. These can be put onto a document or internal web page that the team can review and comments posted, followed by a meeting. In some cases, I have known that team members taking care of the development or testing of a specific area have more knowledge of the details of the workflow and have made corrections, or even suggested some improvements that have added value. However, it remains at the discretion of the Product Manager to decide which of these points should be taken or not (it makes for a more cordial relationship though if the Product Manager does explain the reason why something is not taken).
- This can be an iterative process, but once it is done, then Product Manager has a set of requirements that form the basis of the work that happens next, and the advantage is that during this process, the team already has a great idea of the requirements flow; and equally important, understand the amount of work required, which also helps in determining the resource requirements and time needed for all these requirements (or atleast, gives a much better feeling in terms of increased accuracy of the resource estimation).
No comments:
Post a Comment