参加工作已经两年多了，加上实习的时间差不多快三年了，中间做过很多项目，但是成功的不多，PM，也就是所谓的项目经理做过很多次，有业务项目，有技术驱动项目，有大型跨团队项目，有了一些感悟，大概几个月前在团队内部做过一个分享，最近刚刚忙完双十一，就把之前的PPT简单翻译一下放出来吧。
什么是项目？
特定资源高质量的完成特定的任务。从这个简单的描述中，就能看出，项目的四个点，一个是进度、一个是资源、一个是范围、一个是质量。项目可能分为业务型项目、技术驱动型项目、预研类项目，这三种类型有幸在公司的这几年都参与过。
PM（项目经理，在我厂大多数是开发的同学负责，当然有的项目PM是测试或者其他）最重要的素质是啥？
这个时候，你的脑海中可能会有“懂产品”、“懂技术”、“比较强势”、“沟通能力比较强”这些词语，其实，我觉得，项目经理作为项目的负责人，我认为最重要的是“积极主动”这个素质。有了这个习惯或者素质，其他的也就没有问题了。本篇不是心灵鸡汤，点到为止。如果技术差，需要在之前就需要补一下技术的东西，产品理解比较弱，那就多看看产品相关的东西，如果沟通能力比较弱，那就需要在平时多多注意这些方面的锻炼。但是如果这时候项目来了，咋办呢？那就积极一点，主动一点，这时候问题可能就不是问题了。
关于项目流程
各个公司，尤其是大公司，会有很多流程，有的整合到工作流系统中，有的通过邮件或者公告的形式大家约定的一些流程，这篇文章不包含这些流程的东西，主要是自己的一些摸索和感悟。流程可能比较简单，例如“需求评审”-“技术方案和设计”-“编码测试”-“发布上线”这几个步骤，也可能比较复杂，流程的分支让你看半天也理解不了。那流程是什么呢？我认为流程是游戏规则，如果不懂规则，怎么能够玩好游戏呢？流程本身不是生产力，但是好的流程和约定，能够提升效率。
项目中沟通的原则是啥
就两个字“坦诚”，项目绝大多数都是技术人员，总体比较简单，沟通不会有一些乱七八糟的问题，遇到问题可以坦诚的说出自己的想法。没必要搞的很复杂。在刚刚工作的时候，遇到一个同事比较难沟通，于是找老板告状，然后再比较强势的沟通，后面发现效果不是很好，然后紧接着一天就坦诚了说出了自己的想法以及为啥沟通不爽啥的。所以，坦诚沟通即可，简简单单更好。
团队内部怎么沟通比较好
这里马总在内网的一次讨论总结的很好，这里就借用一下。好的团队，在会议室会争吵的犹如仇人，凭借嗓门各抒己见，一离开会议室战斗中犹如兄弟，互相配合支持和掩护。离开会议室的决定就是团队的决定。坏的团队，在会议室讨论犹如兄弟，都是同意，赞美或者沉默，不发表意见或者不痛不痒，离开会议室就各自拔刀诋毁，拉帮结派，争权夺利。好团队碰到问题会去解决问题，怀团队首先是指责或者推卸责任或者批评别人的不对。
如何讨论需求
1、需求阶段的讨论，是性价比最高的（和后面的开发阶段以及测试阶段相比的话）；
2、事无巨细，挑战PRD（需求文档）中的任何细节；
3、关注合理性、可行性以及价值等抽象层面；
如何避免吵架
在项目中吵架在所难免，但是有个前提，就是吵架不能解决问题，吵架伤身，也伤感情，最好减少。这里总结了三个点：
1、换位思考（换个角度思考，看看对方的观点为啥会是那样的）；
2、听完对方的讲话之后再表达自己的观点（很多时候，吵架的双方都彼此不听对方的讲话，各自说各自的）；
3、愤怒时，自己默数几个数之后再表达自己的观点；
如何进行跨团队协作
了解需要协作的团队的业务和技术，在了解之后，沟通的障碍会少很多。
1、了解对方大体的业务场景；
2、双方重度合作的，可能需要看一下彼此的代码；
3、这也可能四知己知彼，百战不殆的另外一个层面；
啥是好的技术方案
1、能够梳理清楚业务需求（这一点，需要让项目中各个角色的人都能理解需求是啥）；
2、技术方案要能够支持团队的开发同学设计详细的方案；
3、一个问题点有多个方案的时候，列举多个，并比较各自的优势和劣势；
在做好技术方案的时候，建议提前和比较资深的同事沟通，请同事帮忙review一下。平时和多看一下同事或者团队外部的技术方案，学习一下。
UC（use case 用例）的作用是啥
需求用例，这里的作用，我觉得就是需求达成一致，在UC评审的时候，需要项目中的产品经理、开发同学和测试同学能够达成一致，因为一些点，大家可能彼此以为理解了，但是时间上理解的是不一致的。UC或者设计的时间，建议PM给开发同学多留一些时间，好的UC或者设计能够很好的减少后面的返工，也能够及时的发现一些细节问题点。
什么样的UC才是合格的呢？
1、写完之后，把自己掏空，换角度思考，从测试或者产品的角度来看一下UC；
2、如果自己以一种小白的角色，还能看懂，我觉得就OK了；
3、页面类和接口类，在UC上面要求是不同的，页面可能需要交互的细节比较清楚，接口类的可能需要入参和出参啥的很清楚才可以；
4、在我看来是没有固定的模板或者格式的，能够讲清楚，别人能够看明白就行；
如何评估工作量
实际在项目中，时间都很近，这里建议在评估工作量的时候，多考虑以下几个因素：
1、一些需求可能在写代码的时候还在讨论；
2、在写代码调试的时候，可能环境问题搞死人；
3、扩团队的协作是很消耗时间的，这里要多预留一些时间；
4、在你做项目的时候，可能还有一些紧急问题，例如线上问题等着你处理；
作为技术要不要懂产品
我觉得必须懂，如果不懂，仅仅是去实现产品，那就成了工具，最起码我是这样认为的。我觉得终极目标就是比业务同学更了解业务。在项目中，主动挑战产品，以此来判断产品思考的是否完善。对于产品中的问题，给出自己的建议。项目经理和产品经理是上下游协作的战友，比较多一些了解方便沟通。
如何分配项目任务
1、提前沟通项目成员的长项和兴趣点；
2、了解项目组成员期望在项目中学习的东西是啥；
3、紧急情况下（例如上线时间特别紧急），这时候擅长的人做擅长的事情；
4、划分模板，模块内部高内聚，模块之前低耦合；
5、项目经理做好项目组成员工作的衔接，链接各个零散的模块；
6、哪里确认，PM都要顶上，这个对于PM的技术要求比较全面；
单元测试需要做多细
在项目过程中，开发同学要把东西做一个单元测试，之后再提交测试同学做测试，这里有个问题，就是单元测试要做多细呢？
1、DAO层的就不要做了，可以通过工具来生成一些配置或者代码；
2、重点关注一些容易出错和边界点；
3、主流程的测试切记要能够覆盖到；
4、单元测试多花点时间，其实能够很好的减少后面测试环节的扯皮和返工；
为什么要做冒烟测试
所谓冒烟测试，就是找一个时间点，开发和测试同学约定项目的主流程，然后走一遍，成功则冒烟测试成功。
冒烟测试是项目提交测试的里程碑；
在测试用例评审的时候，约定冒烟测试的范围；
这个标志着项目进入稳定期，也是项目最紧张的开始；
如何开每日例会
1、挑选一个大家都在的时间点，也可以项目组中约定一个大家觉得不错的时间；
2、确定例会的范围（昨天做了啥，今天的工作计划，遇到的问题）；
3、切记，不要在例会上讨论细节问题，抛出问题即可，细节的会后讨论；
要学会说“NO”
什么情况下可以说不呢？我列举几个情况
1、业务方对于上线时间要求完全不靠谱；
2、产品经理在没有沟通的情况下就进行重大的需求变更；
3、牺牲项目的质量来强行上线；
如果开发同学事事都说yes，那会很苦逼，并且没人说你好。
关于发布计划
为啥要有发布计划呢？
1、这个是发布顺序的描述以及线上变更的计划；
2、必须有，且必须重视；
什么样的发布计划是合格的呢？
1、合理的发布顺序；
2、每个环节有人关注，有人check；
3、有回滚计划；
4、善于利用工具，多多check；
项目过程中的风险管理
1、有风险一定要提前抛出来；
2、动员项目组的成员多多思考各自模块的问题点；
3、拉上资深的同事帮忙review一下风险点；
4、PM要花一半的精力在以后的事情上，多多思考后面几天要干啥，提前做一个准备；
项目中的沉淀
1、文档沉淀（供后续的新人或者非项目组成员看）；
2、技术沉淀（用的新框架或者组件啥的）；
3、踩过的坑，记得分享出来；
至此，一个完整的项目已经上线了，这些是经历过多次项目之后的一个总结，可能有些不正确或者不全面。工作还是要继续，后面随着工作的深入，可能对于项目的理解会不同，但是上面这些点，是目前阶段的理解。