项目沉思录 2022-06-09 / 350 次 / 快抢沙发 / 8

记录这么多年来，针对项目的一些个人见解。

备注：本来想将此文的标题命名成项目管理沉思录，而最终取名项目沉思录，是既有作为项目经理这样的项目管理者，又有参与项目的成员的视角来对项目本身的一些思考。

不同项目类型

ToB/ToC/ToG：

ToB: To Business 面向企业用户
ToC: To Customer 面向个体用户
ToG: To Government 面向政府用户

实施型/交付型：

实施型：侧重于“实施”一定价值的项目，自己长期维护推进项目。
交付型：侧重于“交付”一定价值的项目，最后交给客户推进项目。

瀑布型/敏捷型：

瀑布型：“按部就班”遵循计划。“稳”且“好”。
敏捷型：“频繁交付”不断调整。“快”且“好”。

项目经理：

瀑布型项目中的项目经理
说明：传统项目中的项目经理，需要针对整个项目负主要首要责任，属于领导责任制那种，而且项目经理会跟客户（或需求方）有更多的交流互动和对接。
敏捷型项目中的项目经理
说明：敏捷项目中的项目经理，一般会和 PO（产品负责人）及内部其他项目成员一起针对整个项目负责，属于连坐制那种，产品负责人会跟客户（或者需求方）有更多的交流互动和对接。

PMO（Porject Management Office）项目管理办公室：

PMO 是属于一种职能部门，一般小公司不太常见，大公司必定会有。PMO 可以大致理解为指定项目管理规范指导方针的职能机构，“指导方针”可以理解为一个参考方向，一般不太会去指导或者实施具体项目流程和细节。

项目千差万别

不同类型的项目，项目内容千差万别，对项目经理的要求也各不相同，但是，不要怕！登月项目、三峡大坝项目、政府交付类项目、互联网实施项目，太多太多的事情，都可以被称为项目，每种不同行业的不同类型的项目，都有很多不一样的内容，有些比较在意法律法规，行业标准规范，有的比较在意交付的结果，有的有比较在意实施的流程，有的对项目经理有某一垂直领域的知识深度要求，有的又要对项目经理横向领域的知识宽度要求，而且有些项目都没有相关的流程规范，你只能摸着石头过河。

但是这些都不要紧，作为项目经理，你只需要时刻铭记最关键的一点：把事情搞定！所有的一切都是为了能够让项目顺利的完成，而在这个过程中，不要太拘泥于流程，不要太因循守旧，凡事奔着解决问题的思路，一步三问，强力 PUSH，你会发现绝大多数的问题，都是可以快速的被解决，只不过在于你解决问题的能力，更确切的说是解决问题的方法和韧劲。

如果你长期从事互联网或者物联网相关的项目管理的工作，以项目经理作为主要发展的职位的话，还是强烈建议要考取一下 PMI （美国项目管理协会）的 PMP（传统项目管理） 和 ACP（敏捷项目管理） 证书。这样能够对之前的项目管理工作中的实践与现有知识理论相结合，并进一步提高自己项目管理的能力，野路子与正规军齐头并进，所向披靡。

我在本文中就不针对 PMP 和 ACP 的理论知识展开详细的描述，我会在单独的文章中进行相关的描述，后续会在这里引用文章超链接。

一个好的项目管理团队，必然会有一定程度的项目管理流程规范。规范化、文档化、流程化、系统化。

公司有 PMO 制定大的指导性方针，有良好的项目管理团队指定针对不同类型项目的管理流程规范，这种是再好不过了。如果既没有 PMO 也没有良好的项目管理团队，也不用灰心，可以从零开始，针对当前公司项目的实际情况，制定适合的项目管理流程规范。

由于不同的项目，涉及到项目本身的类型，公司的组织架构设计，甚至客户的一些特殊情况，根本无法制定一套通用的项目管理流程规范。但是大体的项目因素都是差不多：团队组建、项目干系人、范围 + 进度 + 成本、实施/交付/验收、工具/流程/方法，回顾/总结等。针对这样的内容，制定出相关的项目管理流程规范，以文档的形式呈现，并且文档要记录版本，然后不断的迭代，根据实际的项目运行效果，不断的调整项目管理流程规范。

禅道
我刚做移动互联网项目管理的时候，自己调研过相关管理工具，那个时候发现“禅道”真的很不错，又是开源，又能一定程度免费，还能定制开发，关键是禅道的入门学习坡度不陡峭。

Teambition
Teambition 是我去了一家较大互联网公司才开始使用的项目管理工具，不可否认，Teambition 的确很强大，但是入门学习的坡度很陡峭，特别是能够定制项目管理流程模板那块，要对项目管理流程有比较深刻的认识，同时对当前项目的实施细节有很清楚的了解。
Teambition 相对于禅道的优势在于能够很好的和第三方常用的技术开发工具相结合，例如：GitLab/Jenkins，甚至是钉钉，这样的话，整个的项目链路结合的就更加紧密。

Microsoft Project
微软 Project 是我在做 IoT 项目时候，接触到的一款项目管理软件，是微软出的客户端软件，当然目前只支持 Windows 端，但是据说微软推出了一个 Project Server 服务端软件的东西，在 Windows 系统的服务器上安装 Project Server 能够使用 Web 版本的 Project，这样可能就可以在 macOS 或者 Linux 系统上通过浏览器来使用了，相当于自己部署一套私服，至于说是否免费和浏览器端的整体功能问题，没有进一步研究，有需要的朋友可以了解下。
微软 Project，毫无疑问，肯定是非常强大的，我用的时间不多，但是刚开始用的时候，发现里面针对项目时间和资源（尤其是人力资源）这块的统筹挺好的，能够一定程度规避时间和资源的错误规划和过度使用。
当然，考虑到项目组成员之间的项目状态共享与更新，向领导汇报等因素，还是建议大家选择一款适合自己的项目管理系统，这样能够高效的应对这些场景。

其他项目管理工具
其他诸如腾讯出的 TAPD，Atlassian 出的 JIRA，也都是大家经常用到的，还有新兴的 ONES 之类的项目管理系统，都是能够去尝试。
并不一定说非要用项目管理系统才能进行项目管理，有些人用简单的 Excel 表格也能够进行项目管理的追踪，早期没有电脑的年代，人们直接画白板，也一样能够管理足够复杂的项目。

项目管理小工具：甘特图、燃尽图/燃起图、缺陷跟踪
以上所提到的甘特图、燃尽图/燃起图、缺陷跟踪，这些只是项目管理中的常见小工具，一般不太需要单独采用某种特殊的工具，因为现代强大的项目管理系统基本上都支持这些功能，只需要理解他的功能和在项目中起到的作用就可以了。

我们这里的项目团队，主要是针对项目实施过程中，项目经理需要管理的相关项目实施人员，不包括外部的其他人员（项目相关方）。项目团队的组建，我们首先需要考虑的就是公司先行的组织架构：职能型为主，还是项目型为主。职能型为主的组织架构，通常项目经理需要向职能型的 Leader 申请相关人员加入到项目组，等待项目完成之后，项目团队解散，项目成员回归到职能型部门，而项目型为主的组织架构，项目所需要的相关人员直接归属这个项目型的组织，长期参与这个项目。

职能型为主与项目型为主的组织架构，没有太多好坏之分，只是根据公司当前业务需要由相关领导来确定推进。但是无论是职能型或者项目型组织架构，一旦项目经理组成了一个临时的项目组，一定要赋予项目经理一定的权利，争取项目奖金以及对团队成员的考核权利。项目奖金有利于提高团队成员的积极性，而考核权利可以一定程度防止团队成员消极怠工。

什么是仆人式领导、保姆式服务？项目经理，尤其是传统项目的项目经理，或者以项目型组织架构中的项目经理，首先是一个领导。但是做项目，你需要像仆人或者保姆一样，为团队在合理的时间内完成有质量保证的项目交付，必须为项目中出现的所有的问题，站好最后一道岗，成为解决问题的最后并最终的选择对象。任何团队成员自己或者自组织无法解决的问题，最终都需要项目经理去尝试解决，尤其是影响项目在合理的时间内完成有质量保证交付的事情，有些事情不是团队成员所能解决的，最后只能靠项目经理。

参考案例：

案例 A：

曾经在一个项目团队中，两个开发工程师因为交流沟通上的言语问题，导致其中一个人开发工程师情绪比较大，直接向我提出来想要立即辞职，而当时项目十分紧张。

遇到这种问题，首先我赶紧安抚这位工程师，站在他的角度感同身受，非常能够理解他的情绪，大家都是年轻人，肯定都是年轻气盛的，我给他的建议是：如果你觉得事情无法挽回，你选择离开项目组，我表示理解，但是如果你此刻直接选择离开，无论是对于团队，对于项目，还有你自己来说，一个未完成的紧急项目，是没有一个好的交代的，这样对于你下一份工作，也没有起到更多砝码的作用。另外如果你真的选择离开，建议把这个项目结束掉，也就最多两个月的时间，然后我还可以发动我的人脉资源，帮你找下一份工作。另外，如果你觉得只是一时冲动有情绪，想要发泄下，我可以直接安排你几天假期散散心，调整下。

同时，我对另外一位开发工程师进行了有理有据的批评，也让他明白作为技术 Leader 该有的责任与胸怀。他自己也意识到言辞过于激烈的交流沟通伤害到了别人，另外我也提出来让他主动跟另外一个开发工程师道歉，并且指出这次事件的背后是他本人性格及交流沟通的问题，如果你接下来还是这样的话，当我选择团队成员去留的时候，我会毫不犹豫的选择让你离开，这是实实在在的基于现状考虑，表明自己的态度，同时也站在他的角度表明虽然另外一位工程师技术能力差点，帮助他解决问题与学习提升，是你作为一个 Leader 的基本责任，你享受着 Leader 级别的收入与权力，义务你同样要承担。

通过与双方的沟通与斡旋，最终让他们两个合好，问题得到解决。

案例 B：

曾经在一个团队里面，遇到一个大家羞于开口的特殊情况：团队里面有一个男生不太注重个人卫生，汗味、脚臭味与烟味混合的味道非常重，而且由于会议室本来透风情况和空调状态就不好了，他一进去，就严重影响会议室的气味，而且整个空调都被“感染”了。非常影响大家的办公环境与心情。

大家碍于情面，都不好意思去说别人，于是乎这个“重担”就交给作为项目经理的我手上了。我私下与这名成员交流沟通，晓之以情，动之以理，让他逐渐意识到自己的卫生问题，后面逐渐改善了这个问题，让团队成员的鼻子好受点。

思考总结：

只有你真正的践行仆人式领导、保姆式服务，去亲身解决团队成员无法解决的一些问题，你才能在项目经理这个岗位上得到全方位的锻炼。

成员利益相关

提高项目成员的积极性与效率，一味的以项目经理的身份去强压，绝对是行不通的，而且很多公司的项目经理并不具备一定的权力。最好的方法，就是要去争取和挖掘你所主导的项目对于项目成员的价值。所谓的价值有：项目奖金与福利、项目锻炼价值等。

项目奖金是项目经理在职责方位内能够争取到的比较能够推动项目成员积极性的因素，这个项目完成之后，大家能够分项目奖，能够拿钱，这是一个实实在在的利益。

项目锻炼价值，这个就要靠项目经理对各个业务的熟悉程度来挖掘不同项目成员的锻炼价值，比如对于产品经理来说，这是咱们第一款 IoT 整机产品的项目，相对于 IoT 软件项目，更具有挑战性和锻炼价值。对于开发人员来说，这是咱们第一款采用 Flutter/Electron/React Native 的跨平台开发技术，对于开发技术人员的技术宽度提升有蛮大帮助，对于 UI 设计师来说，这是我们首款 Web 端/移动端/IoT 设备端都涉及的设计工作，对于 IoT 相关的产品设计，会有进一步的认知，对于测试人员来说，这是我们首次引入自动化测试框架自动测试的项目，对于测试人员的测试能力的提升有很大帮助。等等这些所谓的锻炼价值，也是需要项目经理去做宣导的。

集中办公与小黑屋模式

集中办公能够提升大家的团队凝聚力，让大家有一种团队的存在，同时小黑屋模式是阶段性冲刺，提高效率和战队力的比较好的方法，小黑屋会让大家从身体和精神上都能够快速专注投入，可以尝试一下这种方法。

团建必不可少

请客吃饭，吃喝玩乐，这种传统技能，项目经理必备可少，如果公司能够提供相关经费更好，如果没有，项目经理还是要适当的自掏腰包来组织相关的团建，虽然看起来有些花钱，但是很多工作也是能够事半功倍的去推进。

了解你的每一位团队成员

俗话说，知己知彼，百战百胜。作为项目组成员，你需要了解每一位团队成员的各种重要的信息，这个团队成员资历、能力、性格，最近的状态等等。有针对性的帮助解决困难，利用好相关的资历、能力、性格，给到每一个人想要的不同的点。比如有些人就喜欢在公众场合得到认同，那你就要在项目允许的范围内，创造这样的机会。比如有些人想要都通过这个项目得到晋升，那么你就有意安排那些可以帮他得到晋升的相关工作等等。

对于刺头成员的管理

对于刺头成员的管理，真的是能够考验项目经理的能力，主要是业务能力和情商。大部分刺头成员本身不坏，只是有些自负，或者想要得到尊重和理解。那你就需要有针对性的去解决这样的问题。最常见的就是刺头会认为你项目经理能力不行，什么都不懂。当你面对这样的问题时候，你就需要不断的去学习自己需要掌握的业务知识之外，不断的提升自己解决问题的态度和能力，在一些关键的问题上，你所表现的解决问题的态度和能力，基本上都可以让你在他心目中的形象改观，让他逐渐的接受、认同甚至是佩服，同时你需要给足刺头所在意的“虚荣心”，尊重，理解和表现的机会，只要你不断的让他在项目中感觉到“舒适”，他就会不断的拔掉身上的刺，向你靠拢。

当然你也会遇到那种恶意摆烂，想要被主动优化。或者那种故意刁难的项目成员，当你掌握了关键证据并且尝试做出友善改变之后，仍然无法解决这类项目成员，并且严重影响到你项目进度的时候，果断的剔除此类项目成员。

俗话说，10 个项目 8 个在延期，还有 1 个在延期的路上。很少有不延期的项目，不延期的项目不仅对于项目经理及项目团队成员的能力要求很高，而且外部的各种项目干系人、客观因素（法律法规、市场变化等）不能有太大的干扰。虽然说我们很难 100% 保证项目进度，但是我们可以一定程度上改善项目进度的延期，本来要延期一个月的项目，经过改善，只延期了一周，这样也是一种成长。

对于项目任务过于乐观的估计

这是我所参与过的项目中的第一大导致项目延期的原因。项目中的相关成员对于自己业务相关的内容，经常会有过于乐观的估计，本来这个任务实际上需要三天时间，但是开发工程师直接报一天。每个环节都是这样，到最后就会出现大家预估一个月的时间，轻松延期到三个月。如何改善这个问题呢？可以从以下几个方面入手：

和产品经理或者产品负责人（PO）积极配合，合理的分配当前项目迭代周期中的产品需求，包括新的产品需求以及需要针对先前一期的未完善好的迭代及产品 Bug 的修复。合理的分配指的是尽可能的让功能开发模块单独独立，并且便于业务相关人员进行较为合理的估计，条件允许的情况下，拉上业务负责人一起评估。这样也可以一定程度的避免另外一个问题：有些业务人员可能会消息评估，比如只需要一两个小时工作量的工作，他评估成一个月。而且这个对于项目经理的业务能力和认知水平要求很高。

项目管理中，项目经理需要追加时间 Buffer

项目经理根据自己的过往经验，要给每个业务节点的评估时间加上一个合理的 Buffer，比如 1.2-1.5 倍的时间基数，这样可以一定程度改善项目延期的问题，当然这个时间基数不是为了改善项目延期而故意加上的，长期从事项目管理的同学知道，项目推进过程中，很难有完美的客观因素状态，比如团队成员无法每天保证 8 个小时的 100% 注意力专注高效的时间，无法保证不出现前期技术调研遗漏的技术难点和偶发的 Bug 解决时间，还有突发状况的上下游业务相关人员的请假和人员之间交流沟通等等不可控因素，这块一般各个业务模块的团队成员是不会去过多考虑这些问题了，就需要项目经理加上一定的时间 Buffer。

项目范围蔓延

项目范围蔓延这个问题，在传统瀑布型项目中会经常出现，但是近些年，一些小公司，老板作为“产品总监”的敏捷型项目中，开始逐渐成为最常见现象，老板经常会有所谓的“金点子”，迫不及待的想要让产品经理去安排实现。项目经理会发现，本来这期的项目迭代内容，按照正常情况，不用加班加点都可以搞完，但是随着老板不断蹦出的“金点子”，不断的要求产品经理尽快实施，项目也就逐渐的变得失控。对于这种问题，一定要及早的和领导，尤其是作为“产品总监”的老板，针对项目的变更流程规范达成一致，你有好的点子，想要实现，没关系，走流程，你最终签字，而且不是紧急的产品需求，我们这期不做，如果这期要做，那就要砍掉现有的产品需求规划，你领导是否同意，同意就签字。

这种方法可以极大的改善此类问题导致的项目范围蔓延，从而导致项目延期。如果你或者你的项目管理的领导针对此种方法无法推进，领导或者大老板不同意此类方法，告诉你终极的解决方法，直接离职走人，这样的公司是做不好产品的，我见过太多这种，留在这样的公司，没有任何意义。

项目进度不是合理评估出来的，而是由上至下要求指定的

这个问题，从项目管理的角度来说，是很不可思议的，项目进度的评估，肯定是基于现有的人力投入和外部客观因素来综合评估的，而不是你领导直接定一个项目周期，有些项目有固定的时间要求，这个可以理解。或许是客观的时间节点。但是作为项目经理，面对这种情况的时候，一定要拉上项目团队成员基于现有的人力投入和外部客观因素来进行一轮评估，得出一个合理的结论。然后反馈给领导，不管领导是否接受，这个步骤对于项目经理来说，十分关键。一来对项目组成员有一个交代，有一个共识，二来告知领导这个项目时间进度是不合理的。当然你还需要提出整套解决方案，如果想要在领导规定的时间内完成此项目，那么追加加大投入，追加人力，人力外包，减少需求等，这个是你一个专业的项目经理应该做的，做好自己，最终交给更高组织和领导来评定。

提高项目风险识别能力和应对无法识别的突发风险能力

导致项目延期的另外一个原因就是项目中出现风险点，风险点有两种，一种是被识别出来的风险，这种可以有事先的对策和预防机制，并且及时此类风险无法解决我们也有 Plan B 计划，或者最终兜底方案。而因对无法识别的突发风险能力，才是真正考验项目经理，尤其是一个团队的应变能力。遇到突发风险，不要慌，沉着冷静，凡事秉持解决问题的态度，怀着强度的解决问题的韧劲，使用一定的解决问题的方法步骤，基本上都可以解决相关的问题，如果在你们尝试各种方法都无法解决的话，就反馈给上级领导，反馈给上级领导中，一定要详细描述当前遇到的问题，以及咱们已经尝试努力过哪些方案，最终反馈给上级一定是你们无法解决了此类问题的情况下。

要记住一个核心理念：是问题，一定有解决方法，没有解决方法的，那就不是问题，而是事实，事实只需要去接受，而不需要提供解决方法。

尽量把不可控的因素变成可控

项目之所以延期，进度出现问题，就是因为很多不可控因素的存在，我们如果能够把很多不可控的因素变成可控，那就可以很大程度上减少项目延期。咱们举一个软件上的例子，我们无法保证软件 100% 不出问题，软件会出问题，哪里出问题，什么时候出问题，这件事，是不可控的。但是我们对软件加上异常跟踪机制，错误日志回传。同时保证软件的可迭代升级性，这样两项简单的措施，可以很有效的将不可控的因素变成可控。

项目链路的关键节点的控制

项目进度的失控，很容易出现在项目链路中的关键节点中，这里所提到的关键节点，有两个方面：一个是项目内容本身，尤其是里程碑式的节点。还有一个就是项目干系人相关节点，尤其是外部项目干系人。

项目内容本身的里程碑节点，比如咱们的从 0-1 的产品，要实现 MVP（最小可售卖产品），具备重点核心的 MMF（最小市场化功能），首个版本的上线。项目干系人相关节点，内部团队不同业务类型成员之间的配合，外部重要干系人的管控与配合。对于项目链路的关键节点的控制，尤为重要，而且很多链路上的业务是一环扣一环的，一个地方失控，很容易链式反应，造成整个链路失控，比如最常见的就是与技术方案承包商之间的合作，这个是我在做 IoT 整机项目时候最头痛的点。

对于外部不可控或者很难控制的诸如技术方案承包商的进度，你需要花更多的时间，顶住关键节点，一旦出现预期的问题，反馈给商务同事或者领导，从更高层级去推动，是一个不错的解决方案。

项目进度的失控是可预见的

为什么说项目进度的失控是可预见的呢？因为当你作为一个项目经理，如果提高项目进度复盘的时间颗粒度，比如每周项目核对会，每日项目站会，如果项目开始延期，你对业务颗粒度了解的够细，你就会发现项目进度的失控是可以预见的，按照现在这种情况下去，项目进度一定是延期的，不可避免。

当发现此类问题的时候，本来规划的时间要做相应的事情，并没有开始做，而是在做之前规划的时间，作为项目经理，需要具体识别出其中的具体问题所在，并加以改善，看能否抢救回相关的时间，如果不能，就要从其他的地方一定程度抢救时间。更好的上下游业务的配合，提升人员能力，追加人力等。不要等到项目出现不可逆转的重大延期才去做出改变，改变就要从发现项目延期那一刻开始。

项目总结汇报

项目总结汇报能力，是项目经理的必备重要能力，尤其是在项目进行中的阶段汇报，好的项目总结汇报，不仅能够体现出项目经理的业务能力，团队的付出，问题所在，解决方案的呈现，以及所需要的帮助，更重要的就是关心项目进度的相关人员心里踏实，掌控项目进度。

一般来说，汇报内容上尽量简明扼要，汇报形式上，不要过于追求创新，最低保险是 PPT 形式。

实时共享项目状态

这一点对项目团队成员，外部干洗人员，尤其是关心此项目进度的客户与领导，都能够实时的掌控项目进度，这个就要借助于一个合理的项目管理工具，既能够让项目执行的相关人员有紧张感与压力感，也让关心项目进度的相关人员有掌控感和踏实感。

*EVT/DVT/PVT/PP/MP
*ID/MD/CMF/DFM
*OEM/ODM/OBM
*成品、模具、开模、贴片、丝印、PCBA、SMT、打板、打样、BOM、Layout
*QC/QM/QA
*NRE 费用
*TAT 时间
*ROI
*3C/SRRC/CTA
*T0/T1 试模
*NDA 协议
*整机可靠性测试
*电性能测试
*产品包装材料
*AI 语音/CV 测试
*声学测试
*产测软件
*委托采购、加工
*FOTA
*IoT 项目经理、供应链经理、硬件项目经理、软件项目经理、品质经理、硬件产品经理、软件产品经理、售前售后客服经理

上一篇： « 软件沉思录 下一篇： 管理沉思录 »