乙方是服务的提供商,乙方的项目管理更偏向同质性和重复性。因此做乙方项目不仅仅是从一个项目的角度去把控范围，时间，成本，质量。更要从项目的长远运营,标准化,规模化方面来进行统筹规划。
系统性原理与相对性原理表明
(1)孤立的事物是没有比较属性的,比如孤立的一个人,身高1米7,既不高也不矮，只有与其他个体组成一个系统，才有比较属性。
(2)比较属性取决于系统而不取决于事物本身,比如1米7在小学生里是高个子,在篮球运动员里是矮个子，又比如兵败诱敌,在一个局部战争中是失败了,在战略中是胜利了。
因此,为了做好项目管理，第一步是做目标管理,项目的目标一定要根据公司的战略目标制定。在公司创业初期,一切以获取客户,满足客户需求,定制化为导向,此时的工作内容应偏向沟通与风险把控。当做了一些项目,踩了一些坑,为了以后不再重复犯同样的错误,此时应注重知识沉淀,当业务量继续发展, 为了应对3倍,10倍的业务增长,就要考虑流程建设，划分研发岗位和实施岗位，将较为机械的固定规则的部分交给项目实施，复杂问题给研发岗位做问题分解。
目标管理
制定依据: SMART原则--具体的,明确的时间,可以衡量的,与总目标相关的,可达到的
例如: 截止2019年6月30日,将单月客户投诉率从1%降低到0.8%
项目的4个目标层次
（1）被动解决问题：客户有了问题来找你，这属于事后补救
（2）被动式预防：比如说明手册，提醒手册，警告标志。这能起到一定的作用,但是仍然避免不了很多问题的发生
（3）主动式预防：比如软件容错处理，乘航班时强制扣安全带。
（4）商业成功： 项目的成功，并不代表商业的成功，还需要主动出击，联合产业链上下游
过程管理
古代人制作炸药, 成功率很低,因为他们不清楚中间的化学过程,类比到项目管理中就叫靠运气做项目。过程管理就是把一个复杂的事情拆解成一个个更细微的过程,明确过程的边界，找到输入与输出的关系,通过控制过程来控制结果,这样项目就从偶然王国走向了必然王国。项目的成功率也就提高了。
过程改进的核心是灰度验证,迅速迭代,即使项目再多,也建议抽出20%的人力来做过程改进。比如硬件测试,做功能性测试,测一万年也只能知道有没有问题,不知道怎么解决问题。但是做定量测试,就能掌握各个部件,材料对硬件的影响,从而指导未来的硬件设计,从被动式解决转向主动式预防。
结果导向
绩效考核以结果为考评依据,论功劳不论苦劳
知识沉淀与工具方法论
为了大规模对外赋能,首先要做内部赋能,通过知识沉淀, 将所有人的知识储备提升到同一个基准,然后可以在这个基准上不断解决新的问题,才能不断提升项目落地能力。要从依赖个人能力的项目运转方式转变成以依赖流程为核心的项目运转方式
另外,我们提倡工具方法论, 将重复的规则化的过程用工具来完成,有以下好处
(1)让普通人具有专家的某项能力,学习成本低
(2)所有人都是在原有的基础上,不断优化工具,这种优化会不断累积
(3)过程标准化,结果标准化,结果可预期 ,节省时间
(4)人员的离职,对企业影响很小
全流程建模
流程建设要从简入繁，然后化繁为简。
(1).流程建立--目标导向，流程的建立首先要能够解决具体的业务问题，要说明流程的意义，对客户的价值。并以业务流程为主线，其他支撑流程围绕主线建立。
(2)流程完善--问题导向，初次建立的流程运行中会碰到很多问题，通过问题来完善流程，此时的流程处于由简入繁的状态，经过不断的积累，从而形成特定行业具体问题的最佳实践。 比如一开始没有检测芯片的良率,直接生产导致产品成品率低,那么就增加一个产前芯片良率测试过程
(3)瓶颈突破--效率导向，当流程运行一段时间后，此时考虑提高效率，降低成本。
全流程建模的意义在于分阶段把控质量和风险,精准定位问题,提供全局性视野,避免做局部优化。在木桶这个系统中,短板决定了木桶中的储水量,别的部分再高也没用,因此基于项目目标,找到并补齐短板是产生最大价值的方式
全流程建模把从人驱动的项目,转化为流程自驱动的项目,责任到人。
成本效益分析
任何操作都有成本,包括工具开发,过程监督,培训等等。因此有没有必要做,什么时候做,做到什么程度都要算一笔帐。针对客户的新需求,考虑复用性,扩展性。针对内部过程改进,通过全流程建模找到能够产生最大价值的部分,再通过工具进行改进。工具能够减少学习成本,操作成本,检查成本,纠错成本。一次性就做对是最好的方式
保健型投入与改进型投入, 一项投入,如果能够提升单位投入效益,追踪最新的技术营销趋势,这属于改进型投入,否则就是保健型投入。例如工厂通过招人来扩大产能属于保健型投入,通过技术改良提升产能就属于改进型投入。对个体来说，不学习就落伍。对公司来说没有保健型投入就没有当下，没有改进型投入就没有未来。
信息优化
信息有价值,但是过多的信息反而会造成混乱与信息负担。有以下优化的方式
(1)项目动态与静态信息分离,减少信息干扰。
(2)统一知识沉淀平台,但隔离项目信息,每个项目的新需求,风险点,项目总结,改进要沉淀到统一的平台上,内部共享,这部分只占一个项目信息的10%,还有90%的项目过程信息,其他成员不需要了解。这就是时下最热的大中台，小前台架构
(3)不同过程的信息隔离 , 过程与过程之间的接口应该相互独立,完全穷尽, 项目经理需要对整个项目负责,了解项目的整体信息, 但是其他人员只对自己的过程负责即可。理想情况是所有信息传达给每个人，实际条件下做不到，这么做反而造成重要信息被淹没
产品发布
基线版本是经过验证的,稳定的,可靠的软件版本。软件的快速迭代,即使经过严谨的测试过程,也可能隐藏了一些bug 。对客户而言,有bug的新功能版本不是9分,而是0分。即使基线版本无法满足一些新需求,也比0分好,基线版本提供了一个可靠的回退点。bug fix版本最好与新功能分隔为两次发布，否则很容易造成没有一个客户可信赖的版本。
灰度发布:就是先试点,再广泛铺开。灰度发布可以尽最大限度来控制bug的影响范围,并收集用户反馈
快速迭代:保持每天1%的进步
高内聚,低耦合:每个功能要保持简单,通过基础功能的组合来实现对客户多样化需求的满足。
默认配置,接口开放:通过默认配置的方式,降低新手的使用门槛,比如windows系统有成千上万的默认设置(桌面背景颜色,自动待机时间),用户会迅速度过新手期,然后会有各种各样的想法和需求,此时通过开放的接口,让用户可以自己组合功能与属性。
