If you want to do it, you can always find a reason; if you don't want to do it, there are thousands of excuses...
In most cases, the software product manager is the best person to grow your team. i feel that the goal of the product manager is to build a sustainable team and bring added value to the project through this way. a software product manager is like the kernel of an operating system. the kernel itself does not accomplish the needs and tasks of the end user, but it ensures that the user's needs and tasks are accurately completed by the application at the top.
be far-sighted and unload tactically to carry the strategy
if the product manager focuses on team building and individual ability improvement, the entire team will naturally be able to complete the delivery task without timeout or overrun. if a product manager needs to direct multiple projects at the same time, doing so also ensures that the teams are self-driven and self-managing, without the need for nanny-like care. often, product managers are caught up in day-to-day requirements analysis, system planning and design, project planning and tracking. as a result, they can't really have the time to build a team from a strategic level. with long-term planning for team development, product managers can step out of micromanagement, not only from the current project matters, but also with a vision for all future work.
we need to fundamentally change the focus of software project management to give product managers a more strategic role. leaving something tactical to the programming team will ensure that the team is in charge of the project, while the product manager becomes the real facilitator or catalyst, ensuring that the project as a whole is moving in the right direction. similarly, if a product manager can be a true facilitator and coach, ensuring that team members work best together, he can build a self-managing team that not only runs marathons, but also delivers high-quality software.
teams learn from each other and help each other to stay motivated
we all have to keep learning, and in the same way we have to adjust ourselves to a state of ignorance, spending a certain amount of time and effort in each project to delve into the knowledge we need. so why do we have to repeatedly boast that we must know this project even perfectly well in the r&d phase? because science and software technology and the ideas behind them have become so fast in this age that no one practitioner can grasp in time all the knowledge he needs to master in any way.
team members need to learn how to help each other, help others recognize their true potential, and build an environment that allows everyone to push their limits. in the implementation of a software project, find smart, energetic, innovative employees. this is all encounter able and unattainable. on the other hand, it is not easy to keep employees passionate forever, especially when they have been working hard for a while and have not seen any satisfactory results. many project managers have this question, how to make their team full of passion and high productivity? the passion and efficiency of the team is the key to the continuous success of the enterprise, especially for some entrepreneurial enterprises, in the absence of abundant human resources. in general, building a small, agile, passionate and fiery project team is particularly important for the company to maintain continuous growth and profitability.
product managers should actively build a comprehensive body of knowledge
from business logic to business rules, from front-end js code to back-end api interfaces, from data modeling, exchange formats to database sql programs, from controllers to timed script programs, as well as product design aesthetics, data analysis skills and routines, etc... you all need to relate and accumulate. otherwise, you can't easily and happily communicate with all kinds of front-ends, back-ends, databases, uis, data analysts, etc. about a particular need or function. not to mention the eventual agreement and consensus on functionality.
product managers, don't expect to be omniscient during the r&d phase. some methodologies about software development require premises and assumptions, such as spiral or agile methodologies. iterative development is seen as the key to getting the delivered project to meet the "final" requirements. unfortunately, for proponents of methodology, the delivery of a software project is merely a comma in the development process, not a period.
Even if those requirements are "agreed upon" during the previous detailed design phase, they will change during the development process. it is impossible to know everything in advance. diverse needs often conflict with each other, even when they come from the same source. the same need for different people may even mean different things. different interpretations may be attributed to differences in perception and goals. in order to create a successful software project, we must embrace and even absorb these different ideas. we cannot be omniscient, and we can never be "omniscient."
focus on summarizing methodologies and strategies and reaching consensus with the team
What will our project management approach look like? if each small project team cannot agree on the methodology, procedures, processes, and overall change control steps that the entire large team will adopt, it will be difficult to achieve the common development of these small projects, and thus not be able to better serve the big plan. therefore, when choosing which methodologies, program processes, and defect management strategies, the software product manager needs to solicit and ask team members which templates and methods are reasonable, practical, and can help them effectively execute and manage project development and testing.
Once you have a common process and documentation (template) tool, you can combine technical projects into a larger plan. these big plans will bring more value to your customers and organizations than any single project. there is a set of successful methods, and we need generic and flexible documentation or templates that can be applied to all projects. so before we get started, we have to agree on the documentation we're going to use.
differentiated team management with a focus on methods and techniques
according to the behavioral characteristics and preferences of the project team, the project team talents are divided into four categories: prescriptive, kind, analytical, and driven, and the following describes the behavioral characteristics and preferences of these four types of members, and gives methods and techniques to adapt to each type of members. for example, expressive talents:
Merit:
Strong desire to perform, the pursuit of others to identify with their own abilities and views;
the work will show a strong initiative, have ideas, and have a sense of innovation;
very much attention to the sense of self-existence. discussion meetings such as weekly project meetings, progress reports, risk identification, etc. are expected to be actively engaged and to express opinions and opinions for as long as possible.
shortcoming:
Individual opinions and opinions are limited to the narrow scope of the self, often ignoring the scope of the project and the overall project.
unable to grasp the focus of the conversation, it often lengthens the project meeting time and reduces the efficiency of the project meeting
Cultivate:
Motivate him to take the initiative, encourage him to remain self-driven and goal-oriented for a long time, and guide him to pay attention to the overall situation of the project and grasp the key points in the discussion. don't rush to refute and argue, and when they are quiet, make clear and convincing comments and methods. we should give public praise to their achievements in a timely manner, and at the same time remind them to think calmly and proceed from the overall situation. make a specific plan for them in every detail of their work (it must be in writing), otherwise, they can easily deviate from the goal of the work.
Then kind, kind, analytical, driven talents, as long as you are willing to pay attention and carefully observe, research and summarize, will always be able to explore the methods and strategies for managing these project members. so in the end, if you want to do it, you can always find a reason; if you don't want to do it, there are thousands of excuses...
No comments:
Post a Comment