编者按
软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。为使软件项目开发获得成功，关键问题是必须对软件项目的工作范围、可能风险、需要资源（人、硬件/软件）、要实现的任务、经历的里程碑、花费工作量（成本）、进度安排等做到心中有数。下面看看作者是经验给我们带来些什么启发！
最近带了一个项目，团队人数20人左右，项目研发4个多月，结合这些年的项目管理实践，有一些思考，总结成文，供大家参考与讨论，共同提高项目管理水平。
项目管理是一项对综合素质要求很高的工作，也是一项技术活，有许多技巧，也很琐碎，需要细心、耐心。项目的时间往往很紧张，也很容易犯错，稍有不慎就会走很多弯路。项目经理要把主要精力放在项目管理上，始终从全局出发，避免顾此失彼。规模比较大的团队，应有专门的项目管理人员。
这里不详细介绍项目管理的流程，仅分享一些实践效果比较好的方法。这里介绍的项目管理采用公司的敏捷开发模式。
1需求
需求是源头，对需求的要求再怎么高都不为过，需求环节如果出了问题，后面所有环节都会受影响。需求不确定，巧妇难为无米之炊。需求尽可能清晰和完整，经的起推敲，尽量不用太专业的词汇，让所有人都能看懂。任何一个没有描述清楚的细节，开发都要先确认，这样不仅浪费时间，开发人员的思路也会被打断。研发也需要一鼓作气，再而衰，三而竭。需求不清晰，士气受挫。
2工作计划
项目经理最重要的任务是合理的安排工作，调动别人去做事情。需要有大局观，能分清事情的轻重主次。知人善任。还能根据情况变化，及时做出调整。
2.1Story拆分
大家一起参与story拆分，PO和SA控制好拆分的思路、粒度、story描述，描述让所有人都能看懂。
2.2设置里程碑
里程碑作为项目过程中的阶段性目标，团队为了到达下一个里程碑而努力。每当到达一个里程碑，项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作效率。
2.3识别最复杂模块
木桶的容量是由最短那块木板决定的，最复杂模块可能是耗时最长的，如果延期，派人支援也来不及了，可能导致项目延期。安排充足的资源去完成。
2.4安排工作的注意事项
1）确定每轮迭代的开发范围。如果开发的模块太多，战线拉得太长，迭代周期太长。如果开发的模块太少，阵地上人太多，又会施展不开。每个迭代交付的story应为系统的一个组件，具有独立性和可测试性。
2)考虑前后台的协同配合。很多功能都涉及前台和后台开发，一般是前台依赖后台，后台进度要尽量往前赶。前台也不要影响后台的测试交付。
3)应考虑人员的技能、效率、稳定性等多种因素，不同的人分配不同类型的story。一般不把重要的模块分给工作积极性不高或将要离职的员工，开发是很讲究责任心，离职人员由于心思没有全部放在工作上，交付质量下降。尽量避免这种风险。
4）每个迭代前，PO应先将每人的工作分配好，然后再征求一下大家的意见，做适当调整，制定出来的计划就比较合理。
5）根据需求变化、进度、人员变动，及时调整工作安排，确保工作量饱和，防止工作分配不均衡。提前安排好下一阶段的工作计划，提前完成的，可以提前进入下一阶段。
2.5测试阶段工作安排
开发结束，进入测试阶段，这个阶段开发人员的工作缺乏计划性。因为开发阶段，有迭代计划，测试阶段没有这样的计划。为了让工作有计划性，便于控制进度，需定期与开发沟通问题单处理计划。
2.6投票表决对工作计划的信心
制定工作计划，需参考团队成员的意见，在计划会议上，大家要表示对工作计划的信心指数，是项目时间计划的一个重要参考，也是对按计划完成项目的一种承诺。
3沟通管理
3.1会议
3.1.1启动会
启动会很重要，讲解项目背景、价值，美好的前景，独特的设计，激发团队成员对项目的兴趣，树立信心。也是了解每个人的经验和技术背景的机会，这对识别风险和工作安排都非常重要。也是树立良好的形象，展示个人魅力的机会。另外，还要宣布重要的规章制度，约法三章，增强按制度和流程办事的意识。至少应包括：
1）编码规范的注意事项
2）QC的办法
3）开发看板维护办法
4）沟通注意事项
3.1.2晨会
敏捷晨会要求15分钟内完成，根据团队规模，最多不应超过20分钟。超过这个时间，投入将大于收益，晨会就没有意义了，不如每天点对点沟通。如果团队规模大，可以分组进行晨会。晨会的目的是了解每个人的进度，记录问题风险，宣布重要事项。不是为了讨论细节问题。晨会是全体开会，而且是每天都要开，节约时间非常重要。晨会的制度:
1）每人发言时间为半分钟。发言内容为对昨天的总结、今天的计划、问题，应该适当的概括，不用描述过多的细节。
2)讨论一个问题，如果几句话讨论不出结果，那就记录下来，会后再讨论。
3）一个人发言结束，一般会停顿三秒，后面人立即接着说，不耽误时间。
4）如果开会老是有人迟到，可实行最后到的做会议纪要，会议纪要的重点是问题和决议。
5）先讲两句开场白，活跃一下气氛。
7）PO问题记录区分哪些是会后要亲自解决的，哪些是明天晨会要跟踪的，确保问题闭环。
3.1.3其他会议
1)提前通知会议的时间、地点、内容，并将相关资料发给参会人员
2)斟酌哪些人要参加会议，无关人员不要通知，或让其晚一点到。
3)主持人控制会议议题，使会议聚焦，不要太发散。
4)会议讨论完一些问题，后续议题只与部分人有关，告诉无关人员可提前离场。
5)做好会议纪要，每次会议都应要有会议决议，便于以后查阅。
6)最好确定会议最迟结束时间，到时间会议必须结束。
3.2与主要干系人的沟通
1）识别干系人，分析主要干系人对项目的影响，与主要干系人沟通，深入了解项目的背景、收益、交付日期、人员情况等信息。
2）定期通报项目进展。让大家对项目的进展、存在的问题、采取的措施达成共识,形成合力。节省汇报工作的时间。
3.3了解项目成员的情况
在项目开始前，与合作方的项目经理沟通，了解他们的对项目的预期、建议以及人员情况。他们对开发测试人员最熟悉，交付经验也很丰富。努力获得他们更多的支持、理解。
3.4尽量与开发团队在一起办公
多参与他们的讨论，由于经验或能力的关系，他们可能经常会遇到问题解决问题的方式也可能不对，及时帮助他们解决。也增进彼此的信任和了解。
3.5沟通方式
根据不同情况，选择最合适的沟通方式，沟通方式包括面对面、espace、电话、邮件、会议等。对话一般是效果最好的沟通方式，特别是跟踪进度。
4进度控制
4.1开发工作跟踪
晨会是进度控制的好办法，每周统计开发进度，并知会主要干系人。进度有问题的，还要单独沟通，一起想办法解决。引导开发测试正确求助，及时反馈问题，有问题第一时间解决。
4.2Ba与Sa工作跟踪
开发测试人员的工作有看板跟踪，BA和SA的工作没有文档可以跟踪。建立一个SA与BA工作看板，明确工作内容、重要性、依赖、完成时间点。有需要的时候当面或电话沟通。
4.3每天检查需要跟踪的问题
需要处理的事情很多，比较琐碎。养成记录的习惯，经常检查还有什么事情没处理，还有哪个人没有沟通到位。正确估计研发人员的能力和执行力，做好事情的监督检查，确保问题闭环。
4.4提前确认需求
开发应提前几天与BA确认需求，不要等要做这个story了才去确认，那样可BA可能积压太多事情，不能及时确认。
4.5倒计时
项目进行到尾声，提示剩余时间，唤起紧迫感。
5质量管理
5.1设计
系统设计要经过充分论证，充分考虑将来可能的变化。如果时间充裕，SA设计到类、方法的层面。开发只需要往方法里填代码，程序质量更可控。
5.2代码QC
QC对负责人的要求很高，既要有扎实的开发功底，又要熟悉业务，还要有敏锐的嗅觉，还需要足够的时间保障。重点QC重要的模块、复杂逻辑、新手写的代码。QC主要北京治疗白癜风的价格是多少钱北京看白癜风正规医院