ASK MO第65期 | 什么业务类型的项目经理，能力最强？

游戏，金融，电商，这些行业其实对项目经理的要求还是差不多的，项目经理的要求，一般是3个因素：

1、管理的人数

一般来说，管理的人数越多，对项目经理的要求也更高，因为沟通渠道是n（n-1）/2的，所以随着项目的人员越来越多，对于项目经理来说，管理成本越高。30个人对于项目经理是一个坎。如何管理好30个人以上的团队，这是简单地区分一般项目经理和高级项目经理的分水岭。

2、组织构型

即组织形式是项目制，还是强矩阵式，还是弱矩阵式。一般来说：

弱矩阵式项目经理一般是属于项目协调员的角色，要求相对较低，主要是协调项目资源，跟进项目进度。

强矩阵式项目经理会有绩效建议权，要求比上述要求更高，需要对项目整体进行把控。

项目制的的组织形式，项目经理是有绩效考核权力的，他的要求是三者最高的。项目经理就是整个项目成败的关键负责人，他需要具有很强的风险控制能力，协调沟通能力，与上级汇报能力等等。

3、To b还是 To c

To c 的项目经理属于协调型的项目经理，主要要求是对项目组内部人员进行沟通和协调，To b的项目经理是属于项目交付型的经理，不仅要求和团队内部沟通和协调，而且需要与客户进行沟通，提升客户对项目交付的满意度。所以，一般来说，To b的项目经理要求比To c的要求更高，还需要有搞定客户的能力。

如果需要预估一个相对靠谱的测试排期，那么方法和开发预估工作量一样，就是把测试的工作流程划分地更加细致，考虑到每个节点花费的时间。

因为每个公司情况不一样，项目周期也不尽相同，所以，我这边现在无法给出一个完成每个工作流程的预估时间，我只能把工作流程简单地列出来。

需要分工作流程来估算的时间点有：

1、对新需求的理解和分析

开始时间和结束时间需要和需求确认过程同步，但往往在需求完全定好后还会有少量的消化时间来服务之后的测试用例编写。

2、测试用例的设计及整理

编写测试用例的过程就是需求的再确认及拆解过程，最后会落在纸面上供研发和测试使用。

测试用例是要测试、研发，项目经理，产品经理一起评审的，评审过程中有时会发现需求歧义导致需求的变更优化，这个时间也需要考虑到。

3、测试环境的搭建

测试环境的搭建也是需要花时间的，有和没有自动化搭建环境的工具，则用时不一样，需要考虑进来。

4、新功能测试执行到结束

考虑范围应包括但不限于：线上环境和测试环境，功能，性能，接口，埋点，ios和android，web，新旧版本兼容，数据迁移...

这是占比最大的时间，排期的预估应以测试用例为依托，由于每一个迭代的业务需求不同，时间会有所浮动。

PS：测试人力资源多少可直接影响排期的预估。

5、老功能回归

由于集成新功能有可能会影响老服务，需要按优先级回归下老功能。

PS：如果配以卓有成效的自动化测试辅助，时间会缩短甚至大幅缩短。

6、新增缺陷修改后的回归

缺陷的回归往往会成为吃时间的怪兽（比如修改缺陷再次引入新的缺陷），尤其在项目工期紧或者倒排工期的时候。所以这个时间不容小视。

7、测试总结

测试报告产生时间排期，相对固定。

8、产品例会，产品变更引起的工作量增或减

浮动项目，时多时少，可根据实际情况修改排期或根据经验提前预估排期。

9、技术学习和交流等额外时间

浮动项目，根据业务时多时少，可根据实际情况修改排期或根据经验提前预估排期。

10、线上问题反馈跟进

浮动项目，时多时少，可根据实际情况修改排期或根据经验提前预估排期。

答案其实你自己已经说出来了，不过硬件这块通常走的不是瀑布模型，而是集成产品开发（Integrated Product Development, 简称IPD）流程。

IPD作为先进的产品开发理念，其核心思想概括如下：

1、新产品开发是一项投资决策

IPD强调要对产品开发进行有效的投资组合分析，并在开发过程设置检查点，通过阶段性评审来决定项目是继续、暂停、终止还是改变方向。

2、基于市场的开发

IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此，IPD把正确定义产品概念、市场需求作为流程的第一步，开始就把事情做正确。

3、跨部门、跨系统的协同

采用跨部门的产品开发团队（PDT：Product Development Team），通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。

4、异步开发模式

也称并行工程。就是通过严密的计划、准确的接口设计，把原来的许多后续活动提前进行，这样可以缩短产品上市时间。

5、重用性

采用公用构建模块（CBB：Common Building Block）提高产品开发的效率。

6、 结构化的流程

产品开发项目的相对不确定性，要求开发流程在非结构化与过于结构化之间找到平衡。

网上有很多有关IPD的资料，这个可以慢慢聊，但是软件部分，在硬件接口确定好之后，可以用敏捷方法来进行升级和发布。例如汽车行业的特斯拉，手机行业的苹果，华为，小米，都是在既定的硬件基础之上，通过升级软件，有时候也叫固件，操作系统，车机系统等，解决一些系统级的BUG，优化用户体验。如解决系统流畅性，节约电耗等等。

看来部门负责人和大领导不是一个人。

如果把这个看成是一盘棋局的话，这个局怎么下都是死棋。为什么呢？我们来分析一下：

如果大领导叫你来干预本来是部门负责人要做的事情，本来就是越权了，但大领导又不给你权力，这叫出师无名，在这个情况之下，会有三种情况出现：

1、 这个事情你会大概率失败。如果你干好了，就会显得部门负责人很无能，所以有权力的部门负责人不会配合你去做这个事情，不配合也算了，如果他暗地让项目经理和你较劲，阻止你做好这个事情。

2、如果你真失败了，所有的锅都是你来背，部门负责人再往上一捅，说你无能，那么大领导对你的信任也就没有了。

3、如果真的很强，力挽狂澜给你干成功了，那也主要是部门负责人带着好，因为他是主要负责人啊，在他下面的员工都提升上来了，你和功劳也只是培训老师而已，培训的东西，终究还是要大家用起来才能提升啊，要不是部门负责人给大家提供这样的环境让大家用起来，光靠培训也没有太大作用。

所以，怎么看这个活都不应该接，如果真要接，要说清楚，只是把培训当成一个任务而已，不保证培训完之后的效果。如果可能的话，最好把这个培训外包出去，你只是做一个推荐，这样，上得好不好也不自己的问题，也是外部老师的问题，外来的和尚好念经嘛。

打造自组织团队，最重要的就是要做好引导，引导什么？引导团队啊。

1、清晰并可达到的目标

给团队一个清晰并可达到的目标。

团队共同解读这个目标，并承诺完成此目标。

2、转变思路

从以前的发号施令者变成引导者，不需要团队按照领导的方式去达成目标，而是可以有自己的方式，总之，关键不是用哪种方式达成目标，而是达成目标这个结果。让团队以自己最高效的方式完成目标。这也是非常多领导没有转变过来的思路。我以前也经常这样，总是忍不住自己插手。

3、充分授权

要相信团队成员，并划分清楚团队成员的职责。

4、拆分

把大的团队分成特性团队，每个团队能独立完成一个子模块，大大降低沟通成本。

5、复盘

这是打造螺旋上升的自组织团队最重要的工具，不管是出现外网问题，还是项目完成后的总结，以复盘的方式进行，让团队自己暴露问题，并自己解决问题，最后形成团队自己解决问题的最佳实践。