What to pay attention to when simplifying software project teams

　　Now many software development projects, many things are carried out by some studios or small start-up companies. Both in studios and small software development companies, the division of labor in project teams is often simplistic, and one person may be responsible for many tasks. Large companies are often accustomed to subdividing the company and making the job content more clear and precise. So, what should be paid attention to when simplifying software project teams in studios or small startups? The following will describe four aspects: roles, processes, branching processes, and documentation.

　　Role simplification:

　　According to the current situation of things and the team, to make a reasonable simplification, this is a test of experience, you must see a team with a very fine division of labor, and then understand how each role is differentiated step by step, and the purpose of the setting can be done. Okay. For example, for the current situation of "Tuoyuan excellent course scientific research project management software development (project name)", our approach is: do not distinguish between interaction and vision, no full-time testing but national testing, no operation and maintenance DBA and other subdivisions to undertake all development, front-end or Listed separately, so there are four roles in total: product, design, front-end, and development. Of course, for the simplest team, one can be removed. The three roles of product, design, and development are indispensable. Note that there are three roles, not necessarily three natural persons.

　　Simplification of the process:

　　Similarly, you need to see more complex processes and know what each step is to prevent in order to simplify them reasonably. The minimum requirements are four key nodes. In addition to the product technical team and key people in market operations, these nodes must also participate. I don’t think it can be cut anymore.

　　Project initiation meeting: determine the purpose, why, and what to do;

　　requirement review: determine how to do it (for small projects less than 2 weeks, it can be combined with the project initiation meeting, and the overall time is controlled within 2 hours);

　　functional review: simply put, it is in the Demonstrate the product in the test environment, and determine whether the product is what the team wants (it will be done in about 1 hour);

　　release and go online: determine whether it is what the user wants, and what does the user want... Get feedback and form a closed loop.

　　Two branch processes:

　　Change: At the beginning, it can be simplified to someone who decides whether to accept the change or not.

　　Daily: that is, scattered small requirements, only a little bit, all requirements must go through the product, and can not directly find development for operation, to ensure that the product manager knows all the demand information.

　　Simplification of documents:

　　There are almost only three sets of PRD, design draft, and code. Others are resolved with Kanban and stand-up meetings. Then, to emphasize one, the communication plan, the vast majority of problems are communication problems. Everyone has to make an agreement, whether to hold a meeting every day? Choose a collaboration tool online? Write a weekly report?... If this problem is not solved, you will definitely make up for it later if you don’t want it.

　　The above is the project management experience of some start-up project teams, not all of them are suitable for your team. However, you can combine the actual situation of your own team and see if there is anything you can learn from. Have you noticed these when you are building and managing your own project team? Think about the effect of simplifying and managing the project team through the methods mentioned above. Perhaps, there is one thing in it that can really solve your current problems.

　　This article is reproduced from Tuoyuan Youke: www.toyoke.com