Requirement gathering co-development is quite different from a services project. It is more important to understand the phase of the product while working on the requirement gathering.
The phases could be broadly the initiation phase, the implementation phase, and improvement phase.
The requirements at the initiation phase would be more cumbersome as the ideas are yet evolving. The requirements will be more concentrated on the business intent.
It would be more important to understand the intended audience in this case. This should in turn, present the business case of the intended application.
The road map needs to be worked out meticulously; keeping the targeted audience in mind. It is better to aim the to-market to be within six months. New features would be added later.
This phase should also articulate the engagement model ensuring that the roles of the stakeholders are well defined.
The requirements at the implementation phase would pose challenges with respect to time, schedule and effort.
Most probably, small components will be outsourced and one would have to ensure that the small components are quality checked. The owner for the development of the skills required by the resources need to addressed.
All milestones should be well elaborated in terms of deliverables and ownership. There should be clarity in terms of the quality of code expected the required collateral and documentation, and criteria for exit.
The requirements at the improvement phase would be either for the migration of the application from an older technology to a new one, retrofit the existing application to support new features or upgrade the product suite to meet new business requirements. This would be coupled with the overall maintenance of the application.
The intention for the outsourcing needs to be well identified in this case.
The business intent of each component of the application suite needs to be understood well.
The other goals would be to understand how the product has to be positioned in the market going ahead – short, mid and long term. It also required understanding the present audience and the targeted audience. Most importantly, the road map for achieving the above mentioned.
On the technical front, understand the architecture and the modules in the architecture.
The technologies used in the application need to be elaborated in terms of its usage and requirement. Understand which components are reusable and which components would better be redundant. Each application has a development culture, and once this is understood and adapted well, there would be no problems at all.
On the engagement front, it would be essential to identify the owner for the application; and the authority one has to take decisions. Sometimes; the client would like to have all authority and delegate the work to the outsourcing partner. In the other extreme, the outsourcing partner will require to play the role of the product manager (which could involve sales as well).
It is more important to realize that product co development would be a long term account. When a client plans to outsource a part of the application; he means to partner for a long time and expects quality in return as he would have the clients. One needs to ensure that requirements are captured well so that there is no ambiguity in the future.
No comments:
Post a Comment