做项目两年感悟（互联网&电子商务）

       ​参加工作已经两年多了，加上实习的时间差不多快三年了，中间做过很多项目，但是成功的不多，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、踩过的坑，记得分享出来；

    ​    ​至此，一个完整的项目已经上线了，这些是经历过多次项目之后的一个总结，可能有些不正确或者不全面。工作还是要继续，后面随着工作的深入，可能对于项目的理解会不同，但是上面这些点，是目前阶段的理解。