Project manager initially as project manager

the day finally came: You were promoted from a frontline developer to a project manager. Perhaps you have been looking forward to, perhaps your heart still uneasy, perhaps this is your career development choice, perhaps you just reluctantly promised the boss "to try". In either case, you may not have an educational background or training experience with project and personnel management and leadership. Priority set-up       Your second priority is to make your organization's customers happy. As a project manager, if you are no longer involved in the first-line development of the product, you may rarely have a direct opportunity to satisfy the customer. But you have to create an environment for your project members so that they can work in this environment and most effectively meet the needs of their customers. This is an important function of the project manager.       Your third priority is your own business. It may be a technical problem with the project (which you are interested in, of course), or something your boss wants you to do. But when these things conflict with the above two higher priorities, you need to be prepared to postpone processing.       Your lowest priority is those things that are purely pleasing to your boss. In a normal organization (a non-dilbet organization), your boss is already pleasantly surprised if you do the three more important things that you said earlier. Although not everyone is so lucky to work in a "normal" organization, try to do the three most important things. Focus on helping subordinates as efficiently as possible--  and happy--rather than pleasing to those who are "above". Analyze your skill gap       It's a great value for me to start my career as a Listening with a skill-listening program. In the first line of development, we often have people's energy to express their technical views. However, as managers, more need a kind of tolerance and listening to work style and communication way. Then, from the "listen" position to the "say" position, you need to improve your speech (Presentation) skills. If you are uncomfortable with speaking in public, you need to receive some special lecture training. This will be good for your future work.       as a project manager, it is your responsibility to coordinate the work of others, plan and track projects, retrace projects when necessary, and take corrective action. If possible, receive training on project management, learn how to set priorities, how to host efficient meetings, how to communicate clearly, and more, and read more about project management and risk management books and magazines, such as Project Management Institute's Monthly magazine PM Network "(Translator Note: You can also get a lot of valuable software project knowledge from the PMT review). You can also find a lot of useful advice on software project management from the SWCMM (software Competency Maturity model). Define "quality" While the vast majority of people are serious about quality and want to produce quality products, the definition of software quality remains controversial, such as whether high quality is "good enough" or a more classical view of quality-"no defects". In order to lead your team to success, you need to spend some time with your subordinates and customers to clarify what quality means to them. Your subordinates and clients are two different people, they are likely to have no consistent view of the quality, it is easy to have different purposes. If the customer insists on the delivery period, he may not be patient enough to listen to the programmer explaining why it takes extra time to check each line of code. If the customer values the reliability of the software, he will probably choose the latter between adding functionality and reducing bugs. If the customer is accustomed to the old version of the keyboard operation, he will rarely be interested in the new graphical operator interface. In a project I was responsible for, in order to better understand the quality requirements of the customer, I held an open forum, in addition to project members and customers to participate, I also have the client's superiors to participate in the discussion. The discussion was valuable because we found that many of the original ideas ran counter to the real quality needs of our customers. Understanding the differences in these ideas allows us to focus on the things that make our customers happy, rather than on things that make "development satisfactory." Software quality is often understood as conforming to specifications, satisfying customer needs, and minimizing defects in documentation and code (DEFECT), and so on, which are "classic" definitions. "Six Sigma Quality" (Six-sigma quality, translator Note: A quality standard and the corresponding quality management method) sets a high standard for defect density (Defect Density) and/or failure rate (Frequency of Failure), but It does not involve other aspects of quality, such as delivery time, availability, feature set and performance-price ratio, and so on. Whether we are a producer or a consumer, we want the quality of our products to be as high as possible in all these areas, but in fact, we always have to make tradeoffs and choices. We consider in the demand phase what quality characteristics are important to the customer and enumerate them (e.g., interactivity, correctness, ease of learning, etc.). We then came up with some key customer representatives who asked them to rate these quality traits. In this way, we can grasp which quality characteristics are the most important, which are secondary, so that can be targeted, for these quality characteristics and optimize the design. What I hear is more interesting. A software quality definition is "the customer returns, but the product does not" (the customer comes back, but the product does not). Work with your subordinates and customers to define the right quality goals, and once defined, spare no effort to achieve these goals. Also to lead by example, to high standards of self-demand. Remember this sentence: "Not perfect not fight, non-excellence not Satisfied" (strive for perfection; Settle for Excellence). Recognition of progress It is an important incentive to praise and reward project members for their accomplishments. You'll want to make the recognition program a top priority, unless you've got the right incentive plan. Rewards can be either symbolic certificates, certifications, or real prizes and cash. Awards remember to say, "Thank you for your help", or "congratulations on your complete ...". Also remember that the scope of the award should not be confined to your project team, but also to account representatives and some outside team members who provide special assistance to you. The rewards program not only requires a small amount of money, it also requires you to move your mind and think about how you want to reward it. Communicate with your subordinates to find out what kind of rewards they care about. To turn the rewards into a part of the team culture. In addition, try "invisible" rewards to let your subordinates know that you are really aware of their contribution and are grateful for it. Lesson , Future       In addition to this, you need to understand the best practices that are generally recognized by the software industry (practice). In Stevemcconnell's "Rapid Development" (Microsoft press,1996), 27 best practices and 36 software development "classic" issues were introduced. This book has been Jolt Award, is a good starting point for learning. When you want to introduce some good methods, tools, and processes into your project, others may reject, oppose, or even resist, and that's exactly what your job is, and you want the project members to understand why and make sure they do it. There are also some best practices within your team, so you need to take steps to facilitate communication and adoption of these practices among project members. Set goals for improvement When you review past projects and define the meaning of "quality", you need to set up some short-term and long-range improvement goals. As far as possible, these goals should be quantifiable, so that you can measure whether you are moving towards these goals with a few simple indicators. For example, you find that past projects are often postponed due to changing requirements, so you can set a six-month goal to increase the stability of demand by 50%. Such a goal requires you to do practical work every month: the number of changes in statistical requirements, the identification of sources of demand and the reasons for change, and measures to control change. This is likely to change the way you interact with those who need to change. Your goals and metrics form part of the software Process improvement. While process improvement is often blamed for "bureaucracy", in fact, every team can find something that can be improved. If you stay in the usual way of doing things, you'd better not expect to get better results than before. There are usually two reasons to improve the process: correcting errors and preventing errors. Focus on the threats or factors that may threaten the success of your project; lead your team to analyze the strengths and weaknesses of your current practices and the threats you face. My own team has organized a two-stage brainstorming exercise to identify barriers to improving our production and quality. In the first phase, participants wrote the obstacles they thought of themselves on the sticky note, and each instant posted an idea; then the coordinators collected and categorized the sticky stickers, so we got a few big categories, and we wrote them on a large piece of paper. In the second stage, the same participants, in response to the obstacles written earlier, put the thought of the overcoming method on the instant sticker, and paste it into the corresponding classification. After further discussion and analysis, we have been able to refine these barriers and obtain a range of actionable solutions. Setting measurable, measurable goals will focus on your efforts to improve the process. You need to review the results of the improvements regularly with your team members. Remember that process improvements are aimed at the success of the project and the company, not in order to meet the rules of the book. Process Improvement as a project to operate, with its own progress, input and output. Otherwise, the process improvement is always not due to the attention, and ultimately by trivial daily work to drown. Don't be impatient . Some of the practices suggested in this article will help you to achieve greater success for this project management novice and your team, and you may become another "linger" person as you work under pressure every day, but you should always be aware of a task that you are tasked with (which may also be your chance for success), It is a long-term task to form your team culture and a set of ways to do things. You can't do all the things you want to do all at once, you can choose according to your situation and take the road calmly.

Project manager initially as project manager