Development perspective: Project Extension and recruitment with product departments

As a technical engineer who has not yet transferred to the product, it's okay to talk about the technical development department and product issues, and it's still the problem that the two departments will never be confused about the project extension, it may help your transformation and learning in the future.

 

From the perspective of development, let's talk about the delay caused by the development:

 

1. Development estimates can be made on time without just a few simple sentences or careful preparation. Even experienced project managers cannot completely guarantee that the three years of development have reached the present, almost all development headers agree that "it is almost impossible to extend the project without delay" is just a question about the length of extension !! If it can be completed in advance, it is generally the first eloquence .....
   
2. Demand changes are almost the most terrible, because they have to be changed from beginning to end.
   
3. Technical difficulties and technical difficulties may not be difficult to understand when looking at the needs or conditions. It was set to three days and the results were not completed in a week, it is actually a abnormal function (often caught ).
   
4. Incomplete use cases during testing, resulting in too many problems exposed during small-scale internal testing, and extended the debugging time.
   
5. Other uncertainties. For example, personnel loss or hardware failure.
   

 

The above points should be relatively common and objective factors. In fact, some subjective factors also exist. For example, the negative emotions of old employees, the inner and Inner Communication of technicians, and the carelessness in the coding process. For a product that can be released to real customers, the time may be doubled or longer.

 

From these factors, it seems that the problem is all focused on the technical staff. We coders can only join the class with a red eyeCode. Then, we gradually changed from objective factors to subjective factors such as passive absenteeism, and always vented things such as XX being Sb behind the scenes. Finally, it seems to be a very sad job to either quit or be swept out.

 

In fact, the problem lies not in the communication between products and technologies. As everyone emphasizes, communication is good, so that cooperation can be better. But it is easy to say, but it is difficult to do it! Not to mention the overall environment of the company, we can only look at the cooperation between products and technical teams. It seems that the product will never stop pushing, the technology will not stop, the final effect will not be correct, and the implementation will be unreliable, when I got online, I complained, and finally I had to quit. Isn't 80% of products aborted like this? To reduce the flow rate, should we first consider the cooperation between the two departments?

 

We have made great moves with our products. We just hope that we don't need to change the requirements. We should make it clear before writing the first line of code. There are no other things in these two points. However, after several years of work and product knowledge, it is found that less powerful product managers are often just the words of the boss. I don't believe you can tell me more about it. The boss has more experience than you. Sometimes, even if the argument is not changed, you can only change it according to your boss's ideas, in the process of reform, the product manager is also deeply suffering. When it is handed over to the technical staff, the product manager is confused in his own mind, so that it will not be blamed. The boss will not care about your technical architecture issues. A small feature change may bring about the collapse of the entire architecture, and the extension of the project will become inevitable. (Another phenomenon is that a major function change may only change a little bit of code.) These phenomena are almost seen every day during the development of the entire project, especially in my previous company, every product is like this. Even though we know that we are doing a lot of work, every redo is so reluctant, but the senior management has completely cleaned up the original stuff, so we are always in an infinite loop of the same thing.

 

In addition, the product manager has many ideas, and the demand changes may also appear from time to time. However, it is generally more reliable. If the product manager is very unreliable, that can only be said to be the sorrow of the technical department.

 

Another step is to learn from products and projects. From the product perspective, do our product personnel take advantage of their own advantages and take the initiative to talk to technical personnel. Understanding their problems can play a greater role in predicting the development time. If I want to talk to my boss more, some problems may be directly killed in the cradle. Since the boss wants to hire a product manager, he must know what the product manager is doing. If the boss is blindly forced to intervene, it would be better to make the boss a product manager. So,The product is still hard at this time. Of course, good suggestions can be adopted directly, and opinions on projects that will make major changes in development cannot be tolerated, after careful research, you can directly give or adopt or delay or reject the attitude. Otherwise, the culprit that may lead to project delay or miscarriage is the so-called product manager.. However, we still need to listen to others' opinions on our own ideas and be able to grasp the technical knowledge. All said that the product manager should be knowledgeable, of course, this aspect of technology cannot be left behind, and it will not take much time to learn a little bit. In this way, when talking to technical managers, they also have their own shares, so that they will not impose others on them because of their simple ideas and difficulties, it will not give up the demand that can be fulfilled due to the passive guidance of the Technical Manager.

 

Hold on to the boss, find the real goals, business values, and requirements before starting development, and then develop and expand in the future. Such a product is believed to be hard-looking even if it fails. To be honest, sometimes many problems are not what our developers want to solve. Maybe they just don't know what we want to do.

 

The same is true for technical managers. If we directly face the impact of changes in the project development process when facing the boss and product manager, the final sinner may be you. At the last level of technical implementation, the Technical Manager also has an irreplaceable role and absolute influence. Whether it's the boss's needs or the product's needs, you must give an attitude after the evaluation, rather than simply saying "OK, unless this function is changed, it is really a piece of code. One of the greatest responsibilities of the technical manager is to control the project progress. To say that the product manager is the mother of the product, it is estimated that no one dares to be a father-in-law in addition to technical skills! (It doesn't matter who is a father or a mother. It is the best person for a successful product, for fear of misunderstanding ....)

 

Therefore, products and technologies have never had a relationship between superiors and subordinates, and there will be no question of who leads or who leads. One is the soul, the other is the body, and the two aspects of coordination can become a complete person. If the soul is missing, nothing is more than walking dead; if the body is missing, the soul will not rest in peace. In the above example, I used my Mom and Dad to talk about less complaints from each other (but even a couple may still have a quarrel). Only a lot of mutual understanding is the right way to form a product, as for its future growth and development, we still have our operating siblings. We will talk about it in the future!

 

When the product and technical brothers are okay, confess to each other. No harm, hey!

 

------------------------------------------------

If you use word2007 to publish an image, the image is not displayed, or you are prompted to have an attachment but no attachment, go to the independent blog to view the complete information.Article!

Modify and add content of the article only in the independent blog!

My independent blog: kiddie-Http://www.zyblog.net/

Link to this article:Http://www.zyblog.net/post-87.html

You are welcome to reprint it. Please indicate the source of this article.