本文近3.8千字，来自跨界学习
“君子生非异也，善假于物也。”——荀子
曾经，遇到团队中的两个问题：
一个是：发生bug之后，每个领导都在群里问来问去表达关心，结果扰乱解决问题的主线进度（或者是不懂，或者是刷存在感）。
另一个是：一些具备项目属性的大“需求”，上游直接丢给下游（一群人），缺少项目仪式感和明确的责任归属指派。
这两个都会导致事倍功半！且团队越大，效果越差！
“人效工效”提升的基本保障，是要有规范的制度。
你看宇宙星辰灿烂，但只要恒星给行星轨道，就能吸引对方并有序运转！
否则任何一个芝麻点大小的问题，都经不起“成本放大效应”，甚至引发“集群效应”！
那么容错率要求更低行业，比如建筑行业，是怎么“正向”和“逆向”面对类似问题的呢？
今年二月，意外参加了“二级建造师”考试。学习中，感觉跨行业的一些方法，完全可以复用到互联网中。
荀子说“君子生非异也，善假于物也。”诗经说"他山之石，可以攻玉。”
本文从项目思维切入，分享这段学习备考后的感受！
原文出处：公众号 jjyypm
01
“项目思维”是古老的智慧
前214年（秦始皇三十三年），一项即将历时5年的，极为雄伟的防御建筑工程——“万里长城”的修建拉开序幕。
利用地形，沿黄河、阴山，材料就是生土、黄土、夯土。
用今天“建筑工程”的话说，建设方是始皇帝，工程总包是蒙恬，监理、分包单位，以及大量的劳务“分包”给了士兵、农民等等三十万人。
这是一项充满不确定性、风险、极大成本，却又利在子孙的事业。
可以想象进展中一定在有意无意地摸索着最高效的项目管理方式，以克服内部外部的矛盾、恶劣的自然条件和外敌侵扰，以期尽快交付。
这或许是最古老的建筑工程项目之一。
历史如此相似，埃及的金字塔、古罗马的供水渠、汴梁古城的复建，近代美国的曼哈顿实验、登月计划、阿富汗计划、中国的08奥运会等人类恢弘建树，都是举不胜举的项目案例。
项目，就是用组织思维，在有限的时间和资源下，冒一定的风险，干一票独特的大事。
项目管理，就是应对重大事件、复杂体系、难测风险等的有效管理手段。
项目化管理，是有意无意都在执行的管理标准。是一种循序渐进地持续优化资源配置的行为。
02
各行业如何对待项目？
万事皆可项目，三百六十行皆可项目思维。
互联网行业刚起步的时候，管理管理主要还是用在传统行业。
比如制药行业。（我就是从药物研发行业转行的）。
在国外新药专利到期的前几年，就要做专利和市场调研，定下仿制品种项目，然后调研研发工艺、专利申报准备……药品研发周期基本15年以上。
又比如现代的建筑工程行业。
围绕着五方主体（建设方、施工方、设计方、勘测方、监理方）的牵制和纠缠。
面临较多的人身财产事故风险、隐蔽工程质量风险、烂尾风险、合同风险、物权债权风险、投资成本工程款风险等。
了解了其他行业，其实互联网项目并不是最棘手的，但它有自己的难。
简单分析互联网项目的三个难点：
1、节奏快、周期短、人员变动高频、影响范围广，人员压力大。
2、信息的密度大，细节过多，存在转瞬即逝的不确定性，沟通成本之高是前所未有的。这也是很传统领域最大的区别。
3、虽然没有“五方主体”，但是也林立各种角色之间的矛盾，或者权利不匹配，就连项目经理本身，可能都是产品经理兼任的。
产品经理是围绕着需求展开工作，不断调整决策，确保“做正确的事”。切换到项目经理角色，则是对整个项目负责，确保“正确地做事”。
而很多时候，很多公司就是这么项目⇆产品混着用。
03
从“建筑工程”项目中借鉴
建筑领域的工程项目管理，与互联网的项目管理对比，除了理论上的相通，比如“挣得公式”、“进度网络图”、“组织论”之外，还有很多工程管理的特色点，可以借鉴到互联网项目管理中。
学习“建工”项目之后，感觉很受启发，不少方法可以借鉴到工作中。开头的两个问题，也能找到答案！
1、“香蕉图“
在工程网络计划中，如果按照工程网络计划中每项工作的最早开始时间绘制整个工程项目的计划累计完成工程量或造价，即可得到一条S曲线（ES曲线）。
而如果按照工程网络计划中每项工作的最迟开始时间绘制整个工程项目的计划累计完成工程量或造价，又可得到一条S曲线（LS曲线）。
两条S曲线组合在一起，即成为香蕉曲线。
如果接近ES曲线，那么延期风险小，但是过早将资金投入进去，不利于资金最大利用。
反过来，接近LS曲线的，有延期风险，但是资金可以用于前期投资其他项目，可以实现最多资金效益。
在项目的实施中进度控制的理想状况是任一时刻按实际进度描绘的点，应落在该"香蕉"型曲线的区域内。
所以并不是越早完成就一定是越好的。
在多个项目并行的矩阵式管理团队中，资源平滑、平移，表面是为了平衡各个项目，但本质也是“香蕉图”的体现。
Tips：
在一次项目中，项目主管不断催促一个定制项目，理由是能提前的为什么不提前做。
产品经理心知肚明，这个项目出力不讨好，没必要做那么早。于是产品经理拿出了“香蕉图”，很快就说服了项目主管：资源过早投入，不仅影响其他事项，而且会导致客户不断加需求致使“寻求膨胀”！
2、“监理”制度
曾经合作过一个互联网团队，百十号人的程序员，但基本从来没人管理过代码质量。
有次遇到一个表格功能，居然累积了三千行代码，接盘的开发人员直接大叫“看不懂”。更别说接口“传参”不过滤，返回冗余等问题。
为什么就没人关心下代码质量呢？
反观在建筑行业，监理由第三方监理单位担任，为建设方把关，类似古代的监军。
监理不参与施工，但是会监督施工。比如：
见证工人抽样检查、实验取材的真实性、合理性。
旁站，监督“隐蔽工程”的工序是否合适。比如钢筋笼是否扎呈“八”字型的，是否漏绑扎了。不然一旦浇筑混凝土后，就难以检查隐蔽处的质量了。
所以在正规的互联网公司，代码的质量监督也是一项大事。需要定期抽查代码的质量，发现底层结构的风险，将监督到的问题汇报整理。
3、“四不放过”原则
在互联网领域，“拼的是脑子，不流血”，但在建筑中，人身、财产损失危险还是比较常见的。
为此，规定了质量事故的“四不放过”：
事故原因未查清不放过。
事故没有得到切实可行的整改结果不放过。
事故责任人未受到处理不放过。
事故责任人和广大群众没有受到教育不放过。
用在对互联网产品bug或质量事故的管理原则上，是不是很合适啊。
4、工程量清单
工程报价的方式主要有三类，有固定金额，有的是“固定成本+酬金”，还有一种是按“工程量清单”。
“固定成本+酬金”类似于互联网中的基本工资+项目奖金。干完得越快、质量越好、成本越低，则奖励越高。
“工程量清单”的话，那就是将工程，量化为统一单位的数值。以此代表工作的多少。再定出单价。将来之后实报实销。
在这个过程中，就有点类似于产品开发的工时制度。
工时制度的评判，有多种方式，比如制定最小颗粒度的工时规则，分解项目后执行；也有类似“德尔菲法”的扑克牌法，也就是背靠背评估出对该需求的工时，取平均数。
工时的好处是，量化工作难度，但要注意标准和经验的客观性。
只听团队成员一句“做不完”，往往是不可控的前兆，会让项目变得无法把控。
5、施工流水节拍
建筑的工序，比互联网中更重要。每一个紧后事，都要求前置条件确认无误。比如：
“基线找平—>基坑开挖—>坑槽验收—>地基基础—>绑扎钢筋—>支架模板—>浇筑混凝土”等等。
而大楼每一层、每一栋之间往往相似或相同，这就意味着：
各组人马可以按计划依次进场；
可以实现多班，轮流施工；
于是理论上就可以得到尽可能不“窝工”的横道图，如下图：
这种流水节拍施工计划表，一目了然。不管用在互联网多团队项目还是其他工作中，都大有裨益。
6、“专家论证”
一些在其他互联网团队中可能比较成熟的功能，换个团队做得很慢。
原因是程序员单兵作战的情况下，遇到技术问题没有及时组织技术评审或技术攻坚。
导致实现方案绕弯路，技术落后，或者自以为触摸到了技术瓶颈。
而在建筑领域，也是有很多工艺和技术的，比如混凝土模板中就有“爬模、滑模、飞模”等设备，施工中有“泥浆护壁钻孔”技术、“二次抹面工艺”等。
建筑团队会制定标准，满足标准的必须组织专家论证，比如“四新”（新工艺、新材料、新设备、新技术），比如水下工程、5米以上深挖基坑、50米以上的幕墙工程等。
同样，在开发技术团队，也应该有这种判断标准。避免半小时的工作，去做写两天的代码。
7、第一责任人
在工地上，第一责任人通常是工头，也就是“项目经理”。所以明确的授权是一件很重要的事情。参考RACI模型。
太多的思维说明这个的重要性，比如：“羊群效应”、“志愿者困境”、“旁观者效应”等
8、预验收
在工程验收阶段，监理带着施工方先验收通过后，再找建设单位进行验收。类比开发先自测。
9、不越级汇报
工程的总承包，将任务分包给分包单位的情况下，分包很多时候不能直接和建设方（出资人）汇报。类似的情况很多，这种规范让事情有序，避免不必要的麻烦。
10、主体工程不能分包（钢结构例外）
主体是建筑中最核心安全系数最高的部分，这部分必须由总承包方完成，来倒逼确保项目的质量有保证，缩短干系主体链路。
小结：
借鉴其他领域的知识理论，有时候是“杂交优势”。
除了建筑上上述之外，我还常常用医药上的“质量过剩”表达产品的冗余功能，类似医疗的“过度治疗”。用“循证医学”对比用户大数据碎片观察统计等。
同时，互联网信息技术也一直在辅助传统行业。典型的如将“数字孪生”技术用于基建工程在修建高速公路、桥梁等基础设施。完成数字化建模，评估工程。
跨领域理论的掌握，除了辅助自己把事情安排妥当之外，还有就是说服别人做理性决策。
正如俞军说的，理性决策的前提是要把对方拉到和你一样的知识水平，否则他怎么也不懂你。
加号主，进产品微信群
和一万产品经理共拓职场可能
