[Others]After numerous request changes, how to weigh business requirements and technical deliveries?
Created#More Posted time:Feb 23, 2017 13:11 PM
Programmers or technical managers may all have such confusion: When the business team plans a magnificent and splendid blueprint, but only allows you and your team the time for fixing a bug. After numerous rounds of negotiations on the requirements, only one feature is implemented within the limited time period. The business demand and technical implementation are always a topic of games and balance.
The business team and the technical team may have different opinions based on different perspectives.
From the business perspective: 1.The business challenges the technical delivery speed; 2.The business challenges the technical resource transparency.
From the technical perspective: 1. Why does the business direction keep changing; 2. Why is the business requirement so ambiguous and always changing; 3. Why are the business requirements always arranged in the reversed order; 4. It is hard to balance multiple business teams; 5. The boss urges technologies which promote the business development, but how?
Let’s talk about:
• The most miserable thing you have met in your dealings with the business team?
• Do you have good practices or technical methods in this regard?
1st Reply#Posted time:Feb 24, 2017 9:27 AM
In fact, it is a problem of cost and efficiency. If the business personnel failed to consider the development and time costs, the requirement they propose won’t be a complete and scientific one in nature. If both the business and technical personnel, or at least persons in charge from both teams, are involved at the same time in formulating the requirements, the requirement output will be the most complete and scientific. It will be the most balanced for both business and development, hence being able to fundamentally enhance the efficiency. We call it optimal development. In a word, it refers to a standard process with necessary communication and sound configuration management.
2nd Reply#Posted time:Feb 27, 2017 9:54 AM
The mind of a programmer is filled with the implementation model of the current product, just as the architect well understands every detail of a house he/she designs. If the house structure is changed, the architect must know the consequences from even a tiny change. This is the same case for a programmer. A product requirement seems simple, but in the micro-level implementation, it may require changing the housing structure. To be blunt, who will be responsible if the house collapses because of the change? In other words, we don’t mean that the house cannot be changed, but under the cover of a simple requirement may be a huge infrastructure change, such as changes to the underlying architecture and data structures.
3rd Reply#Posted time:Feb 28, 2017 9:21 AM
The ever-changing requirements are common and headaches for many. Regarding requirements, we are engaged in constant changes and dealings between the client and technicians. Here are some of my experiences: not all the proposals by the client can be fully satisfied (otherwise you may end up spending 1.5 million yuan on 1 million yuan worth of value, with complaints from the client). The client should provide a uniform interface to propose consistent requirements. We have to be patient and leave enough time for the client to think over their requirements. In addition, the most urgent requirement of the client should be met immediately, and you should deliver a demo version for the client’s confirmation even if the demo contains errors. An old saying goes: attitude is everything. First we should let those proposing requirements feel our sincerity.
4Floor#Posted time:Mar 1, 2017 9:43 AM
Business team: We are also the same! We hope the service to be quick and better, and less costly!
Technical team: The challenges from the service owner and relentless changes will confuse or even drive our technicians crazy!
Reason? The philosophy of “customer is God” does not fully apply to technicians – they are dispatched to varied tasks here and there all the time!
1. Formulate a rule on what changes are accepted and what changes are not, as well as how to implement a change.
2. Set constraints for the business team.
Technicians are not beggars and they shall not be bossed around by service owners, which will disturb their trains of thoughts, exhausting them!
The business team should put themselves in the technicians' shoes. We all want to do well and better. Do provide detailed descriptions before making an instruction.
5Floor#Posted time:Mar 2, 2017 9:22 AM
Allow me to talk about my opinions on the business requirements. Many times if I feel the requirements from operation personnel are very urgent and a small adjustment to the online services will work miracles, I am happy to start the work. After all it is very helpful for our entire team.
However, some other times the development costs on the program fail to be forecast when many requirements (ideas) are proposed, neither are the outcome operation effects estimated. The process is basically a stream of trials and errors. But I often feel that such an innovation-at-all-costs mentality is a blow to the enthusiasm of all the personnel (not limited to programmers) involved in the development process. Significant effort has been invested, yet with no results as evidenced by the data.
Sometimes we need to balance the operation requirements and development costs. A very detailed flaw discovered under a magnifying glass involves very complicated logic to fix, which is a tough and thankless job.
It is suggested that the idea proposer should estimate the resulting data traffic brought by the change, giving himself/herself some stress and providing some information for the entire team as well, instead of proposing ideas blindly.
6Floor#Posted time:Mar 3, 2017 9:22 AM
My ideas on business requirement changes: we adopt agile development, with no requirement documents or outlines, and each development cycle basically lasts half a month. Before the end of each development cycle, the product personnel hold a two-hour session on the requirement briefing for the next cycle and the following work is left to the developers. As a matter of fact, we can only claim that we understand the requirement delivered by the product personnel during the session, and we developers can only estimate the time needed to complete the development. During development, we will also meet a lot of pitfalls. For example, 1. Some of the features that the product team requires are dependent on third parties and the interface may not be available, thus the project is delayed. 2. It looks easy to add one database or a segment in the development, but the actual workload involved is significant – we have to consider whether the newly added item will affect the existing features and whether data correction is required.
7Floor#Posted time:Mar 6, 2017 9:17 AM
About development and product personnel: the requirements proposed by the product team aim to facilitate the services of the business team and stand in the shoes of the business team; the development side considers things from the technical perspective. The back-and-forth changes raised by the product team are all at the requirement of the business team. How should we cope with the product requirements? The answer is: architects should control the code coupling degrees and the expansibility of the architecture. They should try to modularize configuration where changes may occur. This poses a demanding requirement for the architect. The product team should also try to finalize the requirements with the business team in advance and let the business team know that a change to the requirement is not as easy as rolling off a log.