I work for a software development company where the development work have been o
ID: 650937 • Letter: I
Question
I work for a software development company where the development work have been off shored to us. The on shore team handle the support and talk directly to the clients. We never talk to the clients directly we just talk people from the on shore team who talk directly to the clients.
When requirements come, on shore team talk to the clients and make requirement documents and informs us. We make design documents after studying the requirements (we follow traditional waterfall model ).
But there is one problem in the whole process: nobody in the either off-shore or on-shore understand the functionality of the application completely. We just know its a big complex web app handling complex order processing, catalog management, campaign management and other activities. We struggle with the design document as the requirements would not be clear. It then goes into a series of questions/answers back and forth between the on shore team,off shore team and clients. We would often be told to understand functionality from the code. But that's usually not feasible as the code base is huge and even understanding a simple menu item take days if not weeks. We tried telling the clients to give usknowledge transfer about the application but to no avail. Our manager would often tell us to start coding even if the design document is not complete or requirements not clear. We would start by coding part of the requirement that seems clear and wait for the rest.
This usually would delay the deployment by a month. In extreme cases we would have very low errors in the development and production but the clients would say that's not what they asked. That would start a blame game and a series of change requests and we would end up developing something very different.
My question is how would you do development work if you don't know the functionality of the app fully?
Explanation / Answer
Short version:
Knowing what to do ? knowing your customer.
Imagine this: you're a company related to real estate development. You ask your partner to build a large complex. The partner says that despite all the documents you gave him, he also need to talk directly to the people who would purchase the flats in this complex. Seriously?
Long version:
It's always nice to know how a specific application will be used, because it's fun to learn things, but it is not always possible on large projects.
Some domains are just too complex. If you're just a developer and you are working on multiple applications from multiple domains, you just can't always understand what the end user is doing, because it would require you to spend five years learning accounting, ten years in medical school, six years in law school, etc.
On the other hand, a software product made with no understanding of the specific domain will be at best, well, a bit unusable.
That's why functional and non functional requirements must be written by people who fully understand the domain. In general, requirements gathering involve at the same time:
Technicians (for example developers who would tell that a specific feature is impossible, that this other one can be much better if done this way, and this one will cost thousands of dollars while there is a much cheaper alternative),
People specialized in project management,
People specialized in the domain of the customer, who have the full understanding of this domain and the precise needs of the customer. Of course, this may be the customer itself.
One functional and non functional requirements are written and are precise enough, you don't need anything else as a person whose work is to translate those requirements into code.
As for your specific case, you describe the cause of the problem yourself:
We struggle with the design document as the requirements would not be clear.
It's not the lack of knowledge about the customer which causes all the trouble, it's the low quality of the requirements. In a correctly managed project, the functional and non functional requirements must be perfectly clear and unambiguous. If the requirements document is not clear or if it tells you that "the visual design of the product must be attractive" or other stupidities like that, it's because it was written by people who don't know how to write it.
Knowing that, you have to act differently:
If you know that the team which gathers the requirements is desperate, and your own team have skilled people for requirements gathering, explain the situation to your superior and tell that the other team must be replaced by somebody competent, for example the people from yours.
Otherwise (i.e. if they are not desperate), try to determine their internal cause of those low requirements and persuade them that doing their job correctly will only reduce the overall cost of the project. Showing the statistics about how badly written requirements influenced the project by increasing the cost (how much?) and the risk of not being ready for the deadline is a good idea here.
Probably the requirements document is just incomplete. I see this all the time: inexperienced project managers are just convinced that one-page document is enough, and don't understand why they would ever write three to four hundred pages instead of one. If it's the case in your company, show that spending more time on requirements would decrease the costs.