Sunday 13 February 2022

Talk about problems in project management

Abstract: the progress of the project in the process of implementation is not as fast as expected, what is the reason? take a look at this article for you to analyze minor issues in software project management.
now that this project has been done for half a year, it has been found that the progress is far from what i thought, what is the reason?

I summarized the following two main points:


  • 1. use agile development
  • 2. role assignments


Agile development, which is a very fashionable word now, sounds quite awesome, agile, and makes us feel that it will be faster when we use it. after being tortured by this development model for more than 1 year, i would like to say that in fact, it is the same as everything else, it has its own applicable areas, if you mistakenly think that any project can be agile with agile development, it is self-inflicted.

why? agile development is characterized by iterative iterations based on user needs, one iteration solves an iterative problem, and for a project with a clear architecture, each iteration will have some results. and for some projects, such as antivirus software, disk analyzer, etc., for this kind of product class of projects, many times its needs are at the beginning of the need to be clearly defined, the customer is nominally the majority of pc users, in fact, pm or pgm, pm said that this project we want to do 3 functions, then we need to do 3 functions, more than one no, less than one is not ok, if pgm after you do 3 functions to tell you, to add a function, and this function is difficult to implement on the old architecture, then this pgm is not qualified, why? because he increased the cost of the project.


so, i would say that if the requirements are defined by ourselves, and we know very well what we want to do, the risk of adopting agile development may increase, because it relies too much on iteration, thinking that iteration can solve most problems, but the reality is far from optimistic! when your pm says to you that we are going to add this new feature, and the previously defined function is not working this iteration to change, what can we do as a programmer? go and say to the pm, sorry, our previous underlying architecture does not support this perverted demand, pm will tell you, i am on behalf of the customer, this function has to do this, i have the final say, why not support, we are not the use of agile development, agile development characteristics are not iterative to solve the problem?


honestly, one of the benefits of the waterfall model is that your pm can have fewer reasons to change the demand, and the pm changes the demand once a week, and we programmers will not be happy at all. therefore, i would like to advise some project managers, do not take the change of requirements as a matter of course, you are not a spoiled child, there is no need to change the needs of the needs do not change, if you take the needs of agile development as the reason for your needs to change every three to five, then the next project, when your programmers hear that you want to use agile development, you must want to cry.



you are the designer of the product, the appearance function of this product, should be defined at the beginning, do not say a month ago to do a rice cooker, this month and said to add a microwave oven function in the rice cooker, if your programmers work hard, the function of the microwave oven is really added into the rice cooker, that can only say pm lucky, met the technical cattle, and the technology is indeed feasible, but if the function can not be realized, then the pm may blame the developer, think that they are not good at technology, think i use agile development, why did i give you time shortages that wouldn't solve the problem?"


time does solve problems, but as a developer, you'd rather spend more time on the requirements analysis phase than on modifying old code.

the development model is just a tool, and relying on agile development is not a panacea for solving all problems.

as a project manager, you are not only responsible for the customer, but also for the product, and for your programmers. in fact, if you can't do the last two points, the first point is not easy to do, because the project is likely to be often delayed, and in the end the customer is not satisfied, or the product has already fallen behind other products on the market when it is launched.

the problem of role allocation in the whole software development process is also very important, to say that the simple point is to divide labor to be clear, according to the view of game theory, if each of our goals are reasonable, then we promote the cycle of the project through mutual constraints, but if the role allocation is unreasonable, such as duplication of responsibilities, lack of roles, etc., then the development process will encounter a lot of conflicts of interest, poor solution, it is easy to lead to team disharmony, no cohesion and so on, the most serious situation is that everyone is independent, they can't listen to the opinions of others, everyone is a person who will think about others, but sometimes they think too much, they will always feel unreasonable, unfair, and inevitably affect the mood of work.

in my current project there is a similar problem, first of all, there is no architect, experienced development and less experienced development to do the same thing, the design of the overall architecture is nominally done by everyone together, but in the development process found a problem, for an architectural change, no one has the ability to make decisions, tm will only say, there is a problem with me, and then you found a problem to tell him, but he does not know who to discuss, after a discussion with one developer after another, if you think that this architectural change is indeed necessary and feasible, you have to hold another meeting to discuss how to make this change and who is responsible for this change, so sd is a must.


and in a meeting i heard others say that doing sd must have 10 years of experience, i think it is a bit ridiculous, there are a lot of excellent developers in the very early on to do the architect, i know one of them, in fact, i think logical thinking ability is stronger, there is an overall architectural idea, and the use of technology in the project has a certain research can do sd, but i don't understand why many software companies now care about the working years, think that doing 10 years of it is a panacea, anything can be solved, what a big mistake.


i think that there is a difference between fine and not refined in everything, if the language is not important, what is important is the thought, i think it really doesn't make sense. we all know that the focus of c and java.net is not the same, one bias towards the bottom, one bias towards the application, let a person who has done c for 10 years to do a website may not do well, why? because he does not understand the application of the website at all, what the user needs he does not know, his head is only thinking about how to make the user experience more brilliant, but he does not know whether the web page can achieve this brilliant effect, the web page upload to do a progress bar can not be realized, the difficulty of implementation is not large, he does not know, such an architect can do a good job of the website. also let. net programmers don't necessarily do java well either. there is a succession of hearing the tao, and there is a specialization in the art, and this sentence makes sense.


the problem of role assignment is also reflected in the fact that we can't cross the kitchen, if you are rd, you don't want to fiddle with the demand too much, feel that the demand should not be done, because this problem should not be you want, thinking about this problem is just a waste of time, if you are pm, you do not ask about the architecture and technical details, because you are always better than the development to understand the actual problem, if you are a pm that has been developed for more than ten years, the technology under your own hands is not as good as yourself, you have to do things according to your own ideas, then do not do pm, you can make an sd.


i have encountered such a pm before, let me do a picture processing program, he wants me to make a picture clear, i think a picture from 100k compressed to 10k you also want him to become clear as if it is impossible, with the toes to think about the problem also know what the lost 90k is for, pm wants me to test a few times, after testing is indeed not feasible, but pm does not believe, because he did more than a year of development, so noon did not eat to run to my machine to write code, when i finished eating and took a nap, he finally conceded defeat, but from this matter i felt a little unhappy, and i didn't want to say more.


the above i made a little summary of the problems in my own project, it is also a little complaint, as a small rd only to let themselves record the problem in the future project as far as possible to avoid, may be a little extreme, i hope that you netizens more advice, i will learn with an open mind.

No comments:

Post a Comment