前面已经对 “做好，而不是做完” 的问题进行了分析并提供了解决方案。

现在，我们来分析和总结 “项目月末统计及时完成率，出现人人达标的情况” 这一问题，希望能梳理出有价值的见解。

那就从源头开始，最开始，我们计划通过 “任务及时达成率” 来反映项目成员的工作情况，期望从中能发现一些问题并起到督促的作用。

打算通过一定的约束力、紧迫感，促使大家及时完成手头上的工作，为此制定的规则是：

1. 每个月未及时达标的任务不可超过 2 条，超过则需赞助部门经费 50 元。
2. 项目总负责人也不例外，同样需要赞助 50 元。

之所以这样设计，是因为能让项目总负责人与项目成员站在同一战线上，有助于避免形成对立，降低工作开展的阻力。

然而，历经一年有余，除了最开始有一两个项目成员未达标并缴纳了赞助费用外，此后很长时间都是人人达标的状态。

这从正态分布上来说，就显得不切实际。因为，很少有人能保证所有任务都及时完成。而且，月月如此。

为什么会出现这种情况呢？后来我分析了一下，原因是，我们对任务变更没有进行有效管控，插入需求的频率过高。为什么插入需求的频率会过高呢？因为项目业务需要根据客户反馈及时调整，第一时间响应客户需求。例如：

1. 突然有客户反馈紧急需求，希望快速响应；
2. 当前线上存在之前疏忽的功能细节，需要及时完善和补充；
3. 有客户询盘并表达合作意向，但对某个功能不太满意，需要及时给出优化方案以推进合作。

这些情况都会破坏之前制定好的项目计划和正在执行的任务。此时，无论是项目总负责人还是项目负责人，往往没有深究是否应该变更，而是默认允许变更。

只要产品、后端、前端、运维等任何一方出现需求问题或任务执行未及时达成，影响后续关联任务，就会出现任务变更的情况。

此时，很多人要么不具备分辨能力，要么贪图省事，不愿花心思去辨别是否真的应该允许变更，而是一概通过变更申请。

要解决这个问题，首先应从减少插入需求入手。但对于研发工作而言，如果完全不允许插入需求和任务变更，就显得过于僵硬和死板。市场在实时变化，响应时间的早晚可能导致截然不同的结果。因此，对于紧急、关键的需求，肯定要及时响应。

然而，如果总是允许插入需求，项目计划就容易失控。久而久之，项目成员会产生一种心态，反正最后都要变更计划，今天做完还是明天做完有什么区别呢？ 这种思想一旦萌生就很难消除，必须从根源上、从制度上解决。

项目负责人要引导项目成员主动思考是否可以通过其他方式解决延期风险，而不是通过变更影响后续任务。例如，可以提高事情优先级、提升工作效率、适当加班等。这样才能以目标为导向，锻炼应对不利情况的能力。

当然，如果插入的需求需要较长的开发周期，自然需要变更任务计划，并同步更新。这一观点我在之前的文章《项目需求变更时如何处理》中也提到过。坦白讲，就是要在 “插入需求” 和 “任务变更” 之间取得一个平衡点。

这实际上，还是回到了项目计划和里程碑的目的。**正如我在之前多篇文章中提到的，项目计划的目的是提供一个方向和时间节点，就像大海中的灯塔，引导大家朝着同一个方向前进。**如果张三往东走，李四往西走，王五往南走，工作就无法有效开展。

其次，项目负责人和项目成员在面对任务变更和各种突发事件时，应该充分发挥自己的智慧，制定有效的策略，就像行军打仗、摆兵布阵一样，明确先做什么、后做什么，如何争取资源，如何与其他成员和上级领导协调沟通，以确保在规定时间内达成目标。

如果某个项目成员反馈任务需要变更（例如前端因为后端接口问题导致任务受阻，申请延长任务时间），项目负责人需要了解事情的前因后果，而不是仅凭这个项目成员的一面之词。这就需要把相关项目成员（如后端）叫来一起沟通，了解问题所在及解决方案，可能出现的情况包括：

1. 后端接口没有问题，只是两人对需求的理解有误，这种情况不需要变更；
2. 后端接口有问题，但前端可以先开发界面，最后一两天再联调，这种情况不一定需要变更；
3. 后端接口真的有问题，但前端对延长时间的理解有误，可能存在故意拉长时间的情况；
4. 后端接口真的有问题，追溯起来是因为对需求的理解不一致，这种情况可以总结经验，下次在需求层面多做分解和沟通；
5. 后端接口真的有问题，前端提出的延长时间合理，符合常规理解，可以同意变更。

可以看到，有些任务只是看起来需要变更，有些任务只是看起来需要延长时间，实际上不一定如此。

归根结底，就是项目负责人在执行上出现了问题，为什么没有做到位呢？换位思考，我在带一个项目，里面有关系好的，关系不好的，关系好的呢，肯定是适当通融，关系不好的呢，不想得罪对方，这是人之常情。

每个人的角色不一样，所掌握的话语权和资源也不尽相同，面对同样的一个人或者一件事，在你看来，很容易处理，但其他人就会觉得很难，不同的立场，面对的阻力就会发生变化。

所以，要为项目负责人的执行背书，从源头梳理，制定《项目管理规章制度》，特别是任务变更的规定，然后，组织项目负责人讨论会议，对这份《项目管理规章制度》里的每一条规定，都反复讨论和敲定，有什么问题，当场提出来，现场就解决对方的顾虑和疑惑，能够达成共识。

只有达成共识，项目负责人执行起来就会从被动变为主动。 然后，再把这个《项目管理规章制度》在部门里发布和告知。

之后，项目负责人在执行的时候，就照着规定行事，不用顾及对方的感受，直接按规矩办事，实事求是，如果对方反应很激烈，那也不用项目负责人去解决，只需要把这种对立情绪向上反馈，由项目总负责人、部门去解决，不用有心理负担。

说到底，就是要给项目负责人做这个事情的正当性，而不是把压力完全由项目负责人承担，从源头贯彻理念，而不是处于模棱两可的状态，规定个12345，有问题解决问题，直到大家都没有异议，那么执行起来，就不会有那么多阻力。

谁没做到位，直接提出来，到底是什么原因，是制度的不完善，还是人的问题，制度不完善，继续完善制度，人的问题，就解决人的问题。

最后，要提的一点是，任务变更固然是一个问题，但这都是基于 “目标如期达成存在很大风险” 这个主要矛盾延伸的，先明白了这一点，再去抓任务变更这个事情，才不会舍本逐末。

前言

近期，在项目管理过程中，发现了两个值得深思的问题：

1. 有的同事任务做完了，但是暴露出很多显而易见的问题；
2. 项目月末统计及时完成率，出现人人达标的情况。

这两个问题，都在一定程度上反映出任务执行过程中、项目管理方面存在一些方法不对，或者制度漏洞，导致没有达成预期的效果。

现在，就基于这两个问题，好好分析以及给出对应的解决方案。

任务要做好，而不是做完

在会议室验收功能的时候，有个同事开发的功能模块，比如设备列表，暴露出很多问题。而且，还是一些很明显的问题：

1. 列表只是展示 10 条数据，没有滚动条，没有分页，导致后面的数据都看不到；
2. 点击删除按钮的时候，没有二次弹窗让用户确认，而是直接删除了，删除之后列表也没有更新。

这些虽然是小问题，但是表面风平浪静，实则暗流涌动，从中可以窥见在水面下的深层问题：

第一个就是没有用心在开发这个功能，这些都是很明显的问题，一些细节都是约定俗成，并不需要别人反复和你强调。

第二个就是换位思考，假设你是用户，在使用自己开发的功能，难道就没觉得有问题吗？

任务要做好，而不是做完，做完只是机械地执行，做好就需要动脑思考。

任务执行过程中，到底有没有对这个任务的方方面面了解清楚呢？

任务的背景是什么？为什么要做这个功能？什么人在用？到底会关注哪些细节？这个功能定好的实现方案，是否有更好的？现在遇到的这些问题，不解决的话，会留下什么隐患？

经过这样反复思考，如果觉得有问题，就应该及时反馈、暴露出来、及时沟通和处理。

而不要觉得，多一事不如少一事，差不多就行了，要是反馈的话，搞不好还增加工作量，我才不傻呢。

大部分人都会这样想，并没有什么问题，还是那句话，人之常情。

只是，要算一笔账的话，就会知道，很划不来。

因为，如果后面功能验收出了问题，除了影响你在工作上的口碑，还有可能会返工，那还是要增加工作量的啊。

那还不如，从一开始就做到位了。

当然，有人会说，要是每做一个事情，就经常反馈、提建议，让人觉得自己很难沟通，怎么办？

确实，有时候，要的就是执行命令，而不是习惯性抬杠。

但，我想说的是，要看从集体利益，还是个人利益的角度出发了，如果是集体利益，而不是私心，只要说的有道理，都是应该听取的。

凡事都可以商量着来。

完成比完美更重要

在 2024 年 8 月，3A 大作《黑神话：悟空》上线以来，全网一片好评，很多人评价，包括我，都说是划时代的作品，会在游戏的历史长河中，被铭记于丰碑之上。

但是，美中不足的是，后面两章，明显没有前面几章那么精细，赶工痕迹特别明显，特别是第六章，整一个大石敢当，实属无语，感觉有点敷衍了。

如果好好打磨，会更上一层楼。只是没有办法了，没那么多时间了，所以，就像主创冯骥说的：

“完成比完美更重要。”

在现实生活中，同样也是如此，很多坚持打卡的事情，早睡早起啊、坚持跑步啊、坚持控制饮食啊、坚持看书学习啊等等。

有一些人，比如我，会陷入完美主义的陷阱，比如要在草稿纸上写一段话，如果第一个字感觉没写好，就会撕掉重写，这个现在看来，是有问题的。

就好像人生，就好像打牌，不可能每一次开局都那么完美，只能是基于现有的牌，来不断调整策略、方法，然后能打赢。

之所以写一个字，没写好，就可以撕掉重写，无非就是撕掉一张纸的成本过低罢了，没有伤筋动骨，当然不会觉得有什么。

但是，无形之中，会养成这种较真的、不切实际的完美主义的思想，对于做好一些事情，是有害处的。

而这种思维，和上面提的 “做好，而不是做完” 的区别在于，是有先后顺序的，不同的阶段，不同的思维，不应一概而论。

最后

总之，不管是工作还是生活，我的结论是：

首先要有 “做好，而不是做完” 这个意识，等这个意识在你脑海中生根发芽，这是第一步。

很多事情，你确定自己是真的倾尽全力了，只能做到这一步了，再怎么责备你也没办法了，就算拿把刀架你脖子上，也不会更进一步了。

然后，这个时候，才可以说，完成比完美更重要，这是第二步。

这是一个递进的思维意识，而不是像二极管一样，非黑即白，本身就是要辩证地看待。

只是大部分人，没有第一步的意识，就妄想直接跳到第二步，来为自己的懈怠开脱。

所以最终还是要回到项目的完整的生命周期，对每一个环节，都要深入分析和研究，确保自己是真的做到位了。

下一篇，就说明一下完整的项目生命周期有哪些。

前言

在软件开发过程中，我们经常会遇到一些探索型的功能开发任务，就是那些没有做过、没有参考案例、甚至整个部门都没人有经验的功能开发。

这种任务往往充满了不确定性，也最容易出现问题。

书接上回

还记得之前张三和李四因为临时方案爆发的争论吗？

李四最近的开发工作一直都差强人意。

每次功能做完在会议上演示，总是会被挑出很多问题：功能实现丢三落四、界面样式不够美观、逻辑处理不够完善等等。

问题表现

这个问题到底出在哪里呢？是李四做事情不够用心吗？

经过一段时间的观察，我发现问题主要出在两个方面：

问题一：需求沟通不到位

首先是需求沟通的问题，很多时候，需求给出来的时候就存在可协商的空间，什么意思呢？就是需求描述不够明确，没有达到可量化的程度。

比如只说 “界面主题色是蓝色”，但没有给出具体的十六进制值。对于开发人员来说，蓝色可以是天蓝色、浅蓝色、粉蓝色，甚至深蓝色。

结果等开发完成了，你又不满意了，说想要的是深蓝色。这个时候功能都实现完了，找谁说理去？

问题二：探索型任务的特殊性

第二个原因是，李四的开发任务是探索型的任务，这类功能没有做过，甚至整个部门就他一个人开始做。

对于这种类型的任务，最容易出现的问题就是口头沟通的局限性，两个人在座位上你一句我一句地讨论功能实现、技术预研、技术框架、设计方案、函数封装等，都是口头沟通。

因为没有参考案例，沟通双方很容易出现 “我觉得我说清楚了，你觉得你听明白了” 的情况。

结果呢？

等功能开发出来，李四觉得自己已经做到位了，张三一看，觉得和之前沟通的完全不是一回事儿。

解决方案

面对这些问题，我们应该怎么办呢？

对策一：需求量化是基础

首先，需求必须可量化、可验证，这是解决问题的第一步。

颜色要给出具体的十六进制值，尺寸要给出具体的像素或百分比，功能要明确输入输出，性能要给出具体的指标要求。

所以说，模糊的需求必然导致模糊的结果。

对策二：方案文档不可少

其次，对于探索型任务，方案文档是关键。

李四应该在开始敲代码前，先在脑子里过一遍整个开发流程，找出可能存在的技术难点和争议点，针对每个难点提供 1-2 个解决方案，然后形成方案文档，文档应包括：做什么、为什么、怎么做、有什么问题、怎么解决、结论。

一来可以把思路梳理清楚，二来可以提前预知可能出现的问题，把风险在开发前就排除掉。

对策三：多人讨论是保障

最后，一个人拍脑袋决定的方案往往存在隐患，正确的做法是召集项目负责人、相关同事等一起过一遍方案文档，大家从不同角度提出意见和建议，明确解决方案和实现方式。

为什么要这么做？

因为每个人掌握的信息不同，多人讨论可以避免信息盲区，可以发现个人思考中忽略的问题，最重要的是，集体决策可以分摊责任，如果最后方案还是不太理想，也怪不到某一个人头上。

总结

说实话，探索性功能开发确实充满挑战，很多人会觉得这类型的任务，最大的难点是在技术层面的攻关，但实际上，只要做事情的方式不对，同样得不到自己满意的结果。

所以说，探索不代表可以随意，创新也需要规范。按照正确的流程和方法去做，你会发现，很多看似复杂的问题其实都有章可循。

前言

说实话，这个事情真的太常见了。在项目开发过程中，时间紧、任务重，大家都想赶紧把功能做出来，这种时候往往就容易出现一些临时方案。

但是呢，临时方案这个东西，用好了是救急，用不好就是埋雷。

今天就给大家分享一个真实发生的案例，看看在项目紧急情况下，我们到底应该怎么处理。

事情是这样的

李四最近在赶一个项目的进度。说实话，时间真的太紧了，按照正常的开发流程，根本来不及完成所有功能。于是呢，李四就动了个心思，用了一些临时的解决方案。

比如说，有些条件判断、有些循环逻辑，本来应该是根据接口返回的数值来动态设置的，但是为了赶时间，李四直接把这些值硬编码写死了。这样做的好处是，功能马上就能跑起来，测试也能顺利通过。

但是呢，这种做法在功能、代码规范上面肯定是有问题的。就像你盖房子，本来应该用钢筋混凝土浇筑的柱子，你用了几根木头临时支撑一下，虽然看起来也能立起来，但是，随着楼面东西越来越多，顶不住是时间问题。

矛盾爆发

项目负责人张三在重构代码的时候，就发现了这个问题。说实话，张三当时就火了，在项目进度例会上直接就和李四争论起来了。

从张三的角度来说，这种低级错误真的无法理解。代码规范这种约定俗成的东西，难道还需要一遍一遍地强调吗？如果每个人都这样随意修改代码，那项目质量怎么保证？

从李四的角度来说，他觉得很委屈。当时项目时间那么紧张，我想出了临时方案，至少保证了功能按时上线，自己不但没被表扬，反而被批评，心里真的很不好受。

双方都觉得自己有道理，看起来这个问题真的很无解。

张三的问题

说实话，张三作为项目负责人，也有他的责任。

首先，代码审核没有做到位。这种明显的硬编码问题，应该在第一时间就发现，而不是等到项目上线后才提出来。

其次，在李四解释了原因之后，张三不应该过多指责，而是应该给出建设性的建议，帮助李四改进工作方式，避免下次再出现类似的问题。

李四的问题

李四的临时方案本身并没有太大问题，毕竟在紧急情况下，有时候确实需要一些特殊手段。

但是呢，他的处理方式有问题。在使用临时方案之后，他应该有更好的选择：

方案一：主动告知

在群里或者邮件中告知团队成员，说明自己使用了临时方案，并且承诺在时间节点过后会进行完善。这样既能保证项目进度，又能让团队成员了解情况。

方案二：默默完善

如果不想让太多人知道，至少在时间节点过后，自己要记得把这些临时方案替换成正式的解决方案。

但是很遗憾，李四两个选择都没有做。所以才导致了后来的争执。

总结

说实话，这个案例虽然看起来很简单，但背后反映的是项目管理中的一个普遍问题。

在项目开发中，我们经常会遇到各种紧急情况，这时候就需要我们有灵活的应变能力。

但是，灵活不等于随意，我们需要在保证项目进度的同时，也要保证项目质量。

最重要的是，遇到问题不要互相指责，而是要互相理解，共同寻找解决方案。

只有这样，才能让团队变得更强大，项目变得更成功。

记住，临时方案可以用，但一定要使用正确的方法，想出一个好点子，并不等于就解决了问题，要在执行层面也做到位，那才是真正的解决了问题，而不是出现新的问题。

在多项目管理过程中，会遇到这样一个问题：有的项目人比较多，有的项目人比较少。

比如 A 项目有张三、李四、王五等 4 个人，B 项目则只有赵六、王七 2 个人。

这种情况下，通常会考虑从 A 项目调一个人去支持 B 项目。

不过在做这个事情之前，得先想明白几个问题：我们为什么要调一个人去支持 B 项目？调谁合适？为什么是他？做这个事情的根本目的又是什么？

如果不加深究，很容易得出答案：因为 A 项目人多，B 项目人少，适当匀一下，显得更为合理。

但实际上，人员调配的真正目的是优化资源结构，把钱花在刀刃上，实现利益最大化。

从这个角度出发，你会发现事实可能和之前预想的不一样：

A 项目有 4 个人，B 项目有 2 个人，虽然 B 项目的事情好像更多更杂，表面看更应该加人。

但结合项目对部门业绩发展的重要性来评估资源投入就会清楚，A 项目是行业项目，B 项目只是对内的、满足公司自身需求的项目。

显然，这两个项目对部门发展的重要性是不一样的，A 项目很明显更重要。

所以，即便 A 项目人多，B 项目人少又事情多，也不应该从 A 项目调离人员。

正确的做法是加快 A 项目的功能迭代，同时对 B 项目的功能进行筛选，先做高优先级的，低优先级的就推迟开发。

除此之外，是否调离人员，还需要评估人员的重要性。

结合实际情况，核心成员就该投入到重要性高的项目，再结合对他的发展期望，调整到利于他发展的项目中。这样一来，他的能力能得到提升，也容易做出更好的业绩，从而激励到自身。

还有一点，要尽量不过多变动当前人员负责的业务，不让他们掺杂过多业务，一来精力太分散，容易变得低效；二来人员掺杂过多业务，会加大管理难度，影响多项目推进。

所以在我看来，多项目管理中的人员调配，可以通过这几个来判断：

1. 根据项目对部门业务发展的重要性，评估投入资源。重要性高的项目人多，重要性低的项目人少。重要性低的项目事情多，就适当慢下来，按优先级处理。
2. 依据成员的重要性进行调配，核心成员投入到重要性高的项目，利于其发展、做出业绩，实现自我激励。
3. 避免人员参与过多业务，以最小力度调整人员，保持业务的稳定性。

在之前的文章《37-AI 时代，代码评审方式究竟怎样优化？关键要点有哪些？》中已经提到，AI 代码评审基于 Code-Review-GPT-Gitlab 进行使用，因为这个开源库包含评分机制、问题反馈、修改建议和修正后的代码等部分，比较符合我的预期。

在使用了一段时间之后，考虑到要基于流程规范来操作，项目成员提交代码后，最好能看到 AI 代码评审报告，然后根据反馈的问题修改后再提交代码。

但怎样才算修改好了呢？这就需要制定一个标准，比如将 90 分作为评分标准，每个分支提交到仓库时，都需要达到 90 分以上，代码才能入库。

然而，以 90 分作为标准执行一段时间后，有同事反馈这个标准可能不太合理。因为通过 AI 代码评审，出现了一些幻觉问题，这会导致评分不准确，使得 90 分的要求难以达成。

幻觉问题一直是当下 AI 面临的较大难题，在我看来，这并非完全是由于私有化部署时使用的模型小、性能不够强大所致，很多市面上很强大的 AI 工具，同样存在这个问题。

加上，其实提交的代码只是变更部分，AI 代码评审时，只会对 diff 部分进行检查，这就会存在对业务认知不完整的问题，因为项目中一个完整的业务功能，并不一定就在一个文件里完整呈现的。

因此，流程调整为采用 “AI 预评审 + 人工复核” 的方式，依旧按照 90 分的评分要求，具体问题具体分析。如果出现幻觉问题，则灵活处理，而非因噎废食。

关于幻觉问题，一方面可以考虑升级配置，比如购买性能更好的显卡；另一方面只能等待行业发展，以有效解决 AI 幻觉问题。

在《当 99% 可靠性是及格线，我们如何为大模型装上工程 “安全带”？》这篇文章中，提到了对幻觉问题的探索和解决，后续发展情况仍需持续关注：

在 2025 世界人工智能大会（WAIC）上，蚂蚁集团旗下蚂蚁密算宣布对外开源高阶程序（High-Order Program）大模型可信应用技术框架，通过外部化控制与核验，为构建可信、可控、可维护的大模型应用提供了务实的参考标准。

除此之外，项目成员在提交代码之前，需要在 VSCode 中使用豆包 AI 插件，对所有改动的文件进行检查。

这样至少能在提交代码、进行分支合并之前，在本地提前暴露问题，无需等到提交代码后再用 AI 进行代码评审，从而简化大量工作。

不过，在本地使用豆包 AI 插件检查改动的代码时，无需过度检查。因为我发现，每次提问都会得到问题反馈，即便复制它建议的代码去询问，仍然会收到很多建议，这会让人感觉没完没了。

毕竟代码的写法、规范并非只有一套，功能的实现细节也千差万别，并非绝对统一。所以，只需检查一次，把特别明显的问题改掉即可，若是吹毛求疵，只会陷入无尽的循环。

至此，我之前认为代码评审完全可以由 AI 来完成并让整个流程顺畅运转的想法，显然有些激进了。

以当前情况来看，无论 AI 代码评审能达到何种程度，即便幻觉问题能得到有效解决，也不应该完全由 AI 来承担这项工作。

采用 “本地 AI 插件检查 + AI 预评审 + 人工复核” 这三个步骤，或许更为合理。

一般而言，项目的任务计划都是由项目负责人制定的，其中需要明确每一条任务的优先级、开发周期和开发负责人。

但是，有些项目负责人的技术背景是前端，有的是后端，还有的是终端。

这就会遇到一个问题：他们怎么去制定其他技术栈成员的任务并进行验收？

在此之前，我们默认都是由项目负责人完成这些工作的。比如，项目负责人张三是前端出身，现在他要给后端的李四制定开发任务。

通常的做法是，张三会和李四沟通要开发的功能，然后由李四给出功能开发所需的时间，接着张三填写任务时间，任务安排便完成了。

这里就存在可操作的空间，因为李四给出的时间没有第二人进行审核。而张三是前端出身，并不具备审核后端任务时间的能力。如此一来，任务安排就完全取决于李四是否厚道了。

我们一直反复强调人性，可依赖人性做事情，迟早会出问题。

今天李四心情好，可能就凭良心给出合理时间；哪天他心情不好，或许就会把任务时间拉长，好趁机摸鱼。

写到这里，我想起 2020 年的几场培训，培训老师说过的一句话让我印象深刻：

“如果你不想吃亏的话，要以最坏的情况去判断你的员工。”

即便李四为人厚道、兢兢业业，不会偷奸耍滑，那你能保证王五、赵六也不会这样吗？

你真的有时间和精力去仔细分析每个人，或者持续观察他们的一言一行吗？

那样的话，你自己就不用干活了。

所以，还是要回归到流程规范上来，不回避任何问题，把它暴露在阳光下，通过望闻问切，仔细分析原因和我们的诉求。

接着就是大家沟通达成共识，用规定来约束，用流程从源头解决问题。

那接下来，如何从流程规范入手解决这个问题呢？

这要从我们的目的出发，我们的目的是对任务进行有效制定、跟进和验收，而不是流于形式。

既然要 “有效”，就要实事求是，杜绝虚假。而规避虚假的办法，就是专业的事情交给专业的人。

现实情况是，项目负责人并非全能全知，所以可以把这部分工作交给对应的同事来执行，引入技术端负责人的角色。

各项目可根据实际情况，设立前端负责人、后端负责人和终端负责人。他们的职责是协助项目负责人明确对应技术端任务的开发所需时间，跟进任务进展，并负责验收。

整个项目的人员架构就变成：项目成员 - 技术端负责人 - 项目负责人。

那么，项目成员的任务申请时间变更，由谁来审核呢？

本来我觉得，项目的全部任务本应由项目负责人审核，而技术端负责人已经对开发周期（即天数）进行了把关，项目负责人依据这一点判断即可。

但技术端负责人需要覆盖三个关键环节：制定、跟进和验收。变更属于跟进部分，如果这一环节改由项目负责人执行，整个任务的生命周期就无法形成闭环了。

在项目管理系统中，曾经的设计思路是：项目成员的任务时间变更，审核人都是项目负责人。

如果现在引入端负责人的角色，那么技术端成员的任务时间变更就应由对应的技术端负责人审核，而技术端负责人的任务变更则由项目负责人审核。

至此，我认为可以解决项目负责人如何制定、跟进和验收不同技术栈成员任务的问题。

在这篇文章《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中，已经讲明了当前项目过进度的方式：要求各项目成员到前面的座位来，把上两周以及下两周要做的工作情况汇报一下。

但是，在执行大半年的时间里，发现有的项目成员在会议上汇报自己任务情况时，只是简单说明内容，两三句话就说完了。

怎么引导项目成员更多地反馈工作中的情况，而不是让会议变成形式化、流水账式的无意义会议呢？

我反复思考了一下，项目成员为什么不想说那么多呢？这个点其实在《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中也有过分析，这里就不再过多赘述了，无外乎就是多一事不如少一事 —— 只要我说得越少，问题也就越少。

不过，我也能想到其他的可能，比如 “就是线上修复了几个 Bug，没有什么可说的”“就是正常的功能开发，没什么可说的”“我做的是其他项目的，跟其他人关系不大，没什么可说的”。

关键点就在于 “没有什么可说的”。

为什么没有什么可说的呢？

难道每个人在开发的过程中，真的一点问题都没有吗？

每一条任务的制定，都包含需求、方案、研发、技术笔记和验收等多个环节。

这几个环节中，总该有可以说的点吧？

但是，为什么没有什么可说的呢？原因就是没有做好相关的工作。

很多需求只是一句话，或者口头说一下；很多方案也只是当面沟通一下，沟通好就完事了，没有整理成方案文档记录下来。

至于研发过程中遇到的问题，有些 Bug 在没解决之前是 Bug，解决之后恍然大悟，就会觉得问题不值一提 “原来如此，我居然会犯这个低级错误？” 所以，也就觉得没有什么值得总结和记录的了。

还有技术笔记，写这个是要花时间的，完全看每个人是否自觉去做，那真的太难了，大多数人的想法是，还不如省下这些时间去做下一条任务。

甚至，有些人会觉得，这种知识点还要写技术笔记，会不会让人觉得自己技术很菜、水平很低，还不如不写。

任何问题都要透过表象抓住本质，一般这种问题，只是从人身上入手，效果不会很理想的，你可以口头要求对方一次两次，过段时间，只要你稍微疏忽了，对方也就松懈了，所以，还是要从源头去解决，也就是要从流程入手、从规章制度入手，经过沟通讨论，定下一些规定，让大家一起遵守就好。

比如，项目负责人在制定任务的时候，需要把任务要求写清楚，任务要先整理详细的需求文档、解决方案和技术笔记。

之前可能只是 1 条 “支持 10 万台设备接入”的开发任务，里面涵盖着想让成员写各种文档的期望，现在这个事情直接挑明了，拆分成 3 条任务：

1. 支持 10 万台设备接入需求文档
2. 支持 10 万台设备接入解决方案
3. XXX 框架基本使用、疑难问题解决等技术笔记

这样，就把之前依赖项目成员自觉的工作，变成硬性要求，以任务形式下达，让工作从无序变成有序，从无条理变为有章法。

在这个基础上，项目进度会议中项目成员汇报进度时，就可以把这些资料都过一遍，然后再进行验收，应该能有效解决会议流水账的问题。

背景

在项目开发过程中，代码评审还是很重要的，主要是为了解决代码规范、功能开发方式、相互学习等问题，代码是否符合规范，关系到项目成员协作的问题。

如果写出来的代码风格五花八门，那么，在沟通交流上面，就额外增加了难度，而这是完全没有必要的。

除此之外，上面说到的功能开发方式问题，意思就是，每个人都有可能是孤岛，一个人的想法可能会有缺陷，如果多个人沟通以及探讨，相互学习，有可能会从不同视角发现潜在的问题。

人工代码评审

一直以来，我们要做项目代码评审，通常都是有这几种方式，比如项目组成员交叉验收各自的功能代码，然后把问题整理到文档，再一起组织代码评审会议，把问题都过一遍，然后安排任务去调整。一方面解决了代码存在的问题，另一方面通过深入交流，大家相互学习。

还有，就是在 GitLab 代码合并阶段，项目成员发起功能分支合并至主分支，由项目负责人去审查项目成员提交的代码分支。

如果没有问题，则合并到主分支；如果有问题，则反馈给项目成员。待项目成员修复完成再次发起分支代码合并，然后，项目负责人确认之后，合并到主分支。这个应该就是常规的代码评审流程。

但是，随着团队的发展以及对降本增效的要求，开始着手去研究，团队中哪些工作是有可优化的空间？

项目负责人承担的工作事务越来越多，怎么去有效简化无意义的工作，成为了当前亟需解决的问题。

SonarQube

基于上面降本增效的目的，我之前调研了 SonarQube 代码检测工具。

它基本支持了市面上的 Java、Go、JavaScript、TypeScript 等十多种语言，并提供几千条代码规则，用于代码规范检查、代码优化提示等代码质量问题。

支持结合 GitLab 的 CI/CD 做流水线事件中断，方便代码提交人员，自行去查看反馈的问题。

并且，提供 SonarLint 这个 IDE 插件，在代码编写时，就反馈存在的问题，并给出修改建议。

后来为了减少项目负责人的代码评审工作，整个部门的项目，就都接入了 SonarQube 来实现代码问题检查工作。

在使用 SonarQube 的过程中，给我印象深刻的主要有以下几点：

如果一个历史项目要接入使用 SonarQube 工具去检查代码，这个时候，势必会有很多问题反馈，比如可能 2000 个问题，这个时候，是否要立马安排时间去解决呢？

立马安排的话，就需要比较多的时间了，如果不立马安排解决的话，这些问题应该什么时候去解决呢？

SonarQube 提出了一个 “新代码” 的概念了，意思就是，可以不立即就把这 2000 个问题修复掉，而是在项目功能迭代的过程中，逐步把有问题的代码修复掉。

因为项目功能有迭代，意味着，这部分代码就需要去改动，趁此机会，刚好同步解决掉遗留的代码问题，慢慢地，遗留的 2000 个问题就会以这种方式解决掉。

至于哪些没有迭代的，说明功能已经很稳定了，或者功能不重要，那优先级也相对更低了。

SonarQube 官网文档的这篇说明 《Clean as You Code》 提出的这个方法论，我觉得理念还是很不错的：

SonarQube 旨在通过帮助您（开发人员）确保您提交到项目中的每个代码更改都没有问题，从而确保高代码质量和安全性。通过始终提交干净的代码，您可以逐步提高项目的整体质量。我们称这种方法为“Clean as You Code”。

Clean as You Code 的核心思想是将注意力和精力集中在新代码上。在您进行功能和改进时，SonarQube 会在每次新提交时分析您的代码，并在任何代码质量问题和安全问题上提醒您。然后，您可以立即解决这些问题，并确保添加到项目中的所有新代码始终是干净的。

传统的代码质量方法通常强调在每个开发周期结束时有一个单独的审查阶段，在这个阶段发现并解决质量问题。在这个过程中有一个单独的阶段，通常由不同的团队进行，可能会导致问题，因为积累的技术债务量可能变得难以管理，而责任的划分意味着质量问题可能会从裂缝中消失。

Clean as You Code 避免了这些陷阱。它阐明了代码质量和代码安全性是您作为开发人员的责任。它还通过使其成为日常工作节奏的一部分，使代码质量的维护保持可控。

另一个让我印象深刻的是 SonarQube 代码检测结合 CI/CD 阻断流水线事件的功能，真正去应用了，才真正感受到这个功能的好处在哪里，比如前端项目，要合并分支并自动化发布到线上，这个时候，如果 SonarQube 检测到代码问题，就会中断发布流程，需要解决掉反馈的代码问题，才可以正常发布到线上，从而简化了项目负责人的代码评审工作。

但是，SonarQube 只是静态的代码检查，固定好规则，然后它就去检查，只是一个相对 “死板” 的检查方式，无法结合代码上下文，去提出更为深层次的问题，比如功能的实现方式，代码性能优化的写法建议等等，还是要人工去做这部分的工作。

AI 代码评审

随着 AI 大模型的爆发，我之前设想的通过 AI 去做代码评审的事情，开始可以去落实。

早在选定 SonarQube 作为代码评审检查工具，从而减少项目负责人的工作之时，我就设想能否通过 ChatGPT 来完成这个事情，这个是之前写的结论。

借助 ChatGPT，利用 GitLab 获取到合并请求内容并发送到 ChatGPT 完成代码审查, 并将审查结果提交评论至修改行。当前环境下，该做法可能有点激进，存在法律和安全方面的风险。时机未成熟。

当时是没想明白，怎么解决掉代码安全的问题，因为我们项目的代码，总不能接入公网吧，而且，GhatGPT 还是外网，还要翻墙，还要购买服务等等问题，就此作罢了。

可现在完全不同了，AI 大模型发展迅速，日新月变，全面开花。在这样的背景下，我知道时机应该成熟了。

我的想法是，能够通过 AI 把项目成员自己提交的代码分支，做一次代码评审，然后将代码中存在的问题反馈给项目成员，项目成员自行根据建议修复之后，再次推送分支，这一个过程完全不需要项目负责人参与。

项目负责人只需要在最后一步，合并分支代码的时候，看下 AI 代码评审报告，确定各方面评价满足预期，则合并分支代码，从而简化项目负责人的工作。

后来通过多次调研，发现 Code-Review-GPT-Gitlab 这个项目比较符合预期，有评分、代码亮点、代码问题、修改建议、修改后的版本等等，就开始着手验证和执行。

不过，当前还有一个点要解决，因为这个评论是需要合并分支代码之后，才可以检查 diff 部分的代码，然后结合上下文，给出代码检查报告的，那么就没有做到阻断事件的效果了。

之前，总认为把这个约束放到人身上，大家自行去看合并后的分支报告就行了，不做强制要求。

但是，这种事情，是没办法去考验人性的，要大家自觉去做，可能一开始还行，时间久了，有什么突发事情、工作进度受阻、准备下班了等等原因，就开始趋利避害了。这个是正常的，所以，只能从源头去解决，那就是完善这个阻断事件的功能。

总结

上面就是代码评审的方式以及演变过程，不过，在实际应用中，AI 代码评审也不是万能的，除非你能把它喂到覆盖你需求的程度，但是，现阶段还是比较难的。

所以，最好还是结合代码评审会议去完善代码评审这个事情，比如一个季度开一次，都看看项目的代码，兴许可以发现一些 AI 代码评审覆盖不到的、团队特有的代码规范、功能实现方式可优化等问题。

在当下降本增效的浪潮之下，强调团队的产出，基于这个目的，各个工作环节，都要深入去分析，是否存在可以优化的要点，通过结合实际情况的分析与论证，比如，先以一个项目作为试点，看看大家的反馈如何，没有什么问题，再全面推进，再加以实施，更能做成一件事情，避免弄得载声怨道，事与愿违。

1. 精力就是做事情的能力。包括体能、情感、思维、意志四个方面。
2. 今天我们要分析一条革命性的理论——管理精力，而非时间，才是是高效表现的基础。
3. 我们与运动员合作成功的秘诀并非在于技巧或战略。人们通常认为，才华横溢的人面对挑战时只要配备足够技能，就能够发挥出最好的水平。从我们的经验来看却并非如此。精力才是完全点燃才华和技能的正解。
4. 人们极少考虑我们消耗了多少精力储备，总是想当然地认为它能够随用随取。事实上，不断增长的需求逐步耗尽了我们的精力储备——尤其由于我们不对随着年龄出现的能力减退做任何补救。通过全方位的训练，我们可以极大地减缓身体和思维的衰退，并切实地深化情感和精神的能力，直至生命的尽头。
5. 如果某件事你每次做之前都需要思考，你很可能不会长久坚持这件事。
6. 通过运动和休息交替进行可以最大限度提高表现，这条理论最初由斐洛斯特拉图斯提出，他是古希腊运动员训练手册的编撰者。随着训练强度增大、对运动员要求提高，能力的恢复和补偿程度也必然相应增加，否则，运动员的表现将会逐渐下降。
7. 持续健身能带来身心改善，但若停止一周，曾经的改善就会大幅退步，只要停止4周，这种改善就会完全消失。
8. 自然本身存在规律的脉动，在活跃和休息之间有节奏、波浪形地交替。涨潮退潮，四季更替，日升日落，不胜枚举。同理，所有有机体都遵从恒久的节奏——鸟类迁徙，熊类冬眠，松鼠收集坚果，鱼儿产卵，生物的活动都有一定的间歇。
9. 张弛有度是全情投入、维持机能和保持健康的关键。相反，单线化运动最终会导致机能障碍和死亡。想象一幅健康的脑电图或心电图是如何起伏波动的，再想象它的反面，是不是一条直线？
10. 我拥有在任何情况下高度集中的能力，摒弃那些让我分心的事物。然而，我无法在打完18洞的过程里始终集中精力，即便可以，我怀疑我的思维也会过度损耗，思维变得混沌，最终还是无法推杆入洞。因而我制订了一套步骤，帮助我完成从高度集中到惬意放松的过渡，反之亦然。
11. 从最实用的角度看，全情投入的能力取决于周期性休息的能力。
12. 科技的进步永不止息。它本该帮我们更好地感知周围的事物，然而却成为现实中导致我们无法全情投入的祸因。
13. 《心流》的作者、心理学家米哈里·契克森米哈写道，“最佳时刻，往往发生在一个人的身心为了达成艰难目标或完成有意义的事情，而自愿达到极限的时候。”
14. 我们还发现，喝水或许是最常被人忽略的体能再生方式。口渴不会像饥饿一样散发出明显的信号，等我们感到口渴的时候，身体或许已经缺水很久了。一家研究机构称，每天至少饮用1.8公斤水对维持体能有诸多好处。
15. 睡眠需求随年龄、性别、基因体能而异，但普遍的科学共识是：人体每晚需要7至8小时的睡眠才可以运转良好。还有数项研究发现，即使将人们隔绝自然光或钟表，他们还是会每24小时睡眠7至8个小时。
16. 小憩就是一种精力恢复手段。斯坦皮发现，小睡片刻的工人即便不能长时间睡眠，仍可以保持超过24小时的惊人高效和敏锐。唯一需要注意的地方就是小憩需要定时，以免受试者陷入更深的睡眠中。如果小憩超出30或40分钟，许多受试者会感到眩晕无力，甚至比不睡更加疲倦。
17. 即便适度锻炼有诸多益处，大多数美国人还是几乎不锻炼。原因很简单，提升力量与耐力需要我们踏出舒适区，体验不适的感觉，并且需要持续一定时间才能见效。但大多数人在看到明显的效果之前就放弃了。
18. 对需要坐在办公桌前工作的大批白领来说，日常锻炼的缺乏阻碍了机体的自然增强，导致年龄增长后，大多数人应对挑战和压力的能力都逐渐下降。
19. 定期锻炼可以缓解他的紧张感，帮助他更好地控制情感。
20. 身体锻炼是思维和情感精力的极佳源泉。
21. 盖洛普公司发现，保持优秀表现的诀窍之一是在工作环境中至少交一位好朋友。一段稳固的关系包括付出与回报、倾诉与倾听、珍视他人和被人同等珍视。如果一段关系中总是付出而得不到相应的回馈，不免会感到空虚和失落。以自我为中心的关系，也称不上真正的情感关系。
22. 当愤怒逐渐累积时，保罗会选择用腹部做深呼吸，放松肩膀和面部肌肉，掐断自己一触即发的情绪。当情绪逐渐平复下来，他会想办法将沮丧的感觉用一种大家更容易接受的方式表现出来——通常是自嘲的方式。如果保罗认为有必要提出批评的意见，他会采用 “三明治”技巧。首先真诚地对该员工的良好表现给出正面评价，然后以讨论而非宣讲的形式提出批评意见——因为自己的看法或许并非完全准确，最后以鼓励结尾。用“三明治”的方式提出意见不仅让他看起来充满善意和关怀，而且更容易让员工听取他的建议，不会产生逆反心理。
23. 只有接受那些看似相反的品质，不逼自己在其间二选一，才有可能获得最深刻最丰富的情感能力。情感层面的全情投入需要遵循斯多葛派哲学家的“破格文体”——美德的共同存在性。从这一角度看来，没有一种美德是不依赖其他品质而成为美德的。所有的美德都有条件。例如，毫不留情的诚实只是残酷而已。
24. 越来越多证据表明，大脑的运作方式也类似肌肉——积极使用能够提升能力，使用不足就会萎缩。
25. 尼采有句名言 ：“知晓生命的意义，方能忍耐一切。”任何能够点燃人类精神的事物都有助于全情投入、促进最佳表现。意志精力的关键动力在于性格品质——一个人如果有自己的人生目标，他的勇气和信念，即使面对艰难困苦和个人牺牲也会在所不惜。意志精力由激情、奉献、正直与诚实支持着。
26. 弗兰克尔是纳粹集中营中幸存的心理学家，他创作了《活出生命的意义》这本经典巨著。书中他引用了尼采的名言：“知晓生命的意义，方能忍耐一切。”弗兰克尔也描述了在不断有人死去的环境中，这个认知如何挽救了他的生命：生而没有意义的人是痛苦的，没有目标、没有目的、无需继续忍受。他很快就会迷失。我们的人生态度需要从根本上转变。我们既要自己学着转变，也要向绝望之人伸出援手，告诉他我们对生活的期待其实并不重要，重要的是生活于我们有何期望。我们要停止追问生命的意义所在，每时每刻提醒自己接受生命的检视。我们的回应不仅体现在言语和冥想中，还要贯穿我们的行为举止。生命的终极意义是担起责任，找寻难题的答案，并且完成生命为每个人设定的任务。
27. 每个人都拥有许多未知的潜力，只能在困境中才会激发它们。
28. 当目标感从消极流向积极、从外部流向内部、从自己流向他人，它就成为生活中最强大也最持久的精力源。
29. 设想一下，如果你坐在一艘行驶在海上的小船里，船底突然开始漏水，你的目的肯定是阻止小船沉下去。但如果你一直忙着舀水，肯定无暇顾及小船的航向。生活也是如此。当我们忙着填补漏洞，不让自己沉底，就没有多余精力探寻更深层的意义了。
30. 出于对内心深处软弱无力的恐惧，恃强的人会蛮横粗暴地对待他人。因为不愿承认内心的不足，成功的领导者永远都在吹嘘自己的成就，炫耀自己认识多少大人物。
31. “邪恶的本质缺陷并非是罪恶本身，而是自我否认。”《少有人走的路》的作者斯科特·派克写道，“邪恶攻击他人，而不承认自己的失败……因为必须否认自己是坏人，所以只能把别人当作坏人。”
32. 若困在狭隘的自我视角中，我们也不会注意到或有意培养自己的能力。我们或许可以尽力压制自己令人反感的一面，但同时也很难认可自己的优秀品质。
33. 使用许多手段否认生活中的不如意或逃避为此承担责任。责怪他人并将自己看作受害者是一种常见的方式。
34. 所有表现卓越的人都依靠积极的仪式习惯管理精力和规范行为。如果你一直久坐不动，打算开始锻炼身体，你可以最开始每周3次、每次步行15分钟，然后逐周增加步行时间或加快步伐。
35. 不管面对什么样的事情，他要么全情投入，要么有策略地离开。
36. 人类行为只有5%是受自我意识支配的。我们是习惯的造物，因而我们的行为有95%都是自动反应或对于某种需求或紧急情况的应激反应。
37. 在任何表现至上的领域，压力与恢复的平衡都至关重要。我们越能高效恢复精力，越能尽快储备资源以备调用。

1. 言语上的指责、嘲讽、否定、说教以及任意打断、拒不回应、随意出口的评价和结论给我们带来的情感和精神上的创伤，甚至比肉体的伤害更加令人痛苦。这些无心或有意的语言暴力让人与人变得冷漠、隔膜、敌视。
2. 我很希望这本书能帮助更多的人安静下来。使用暴力的人其实是因为他们内心的宁静遭到了破坏，所以他们才会用暴力的方式维护或寻求心灵的和平。
3. 非暴力沟通提醒我们人性是相通的——虽然每个人的价值观和生活方式或许不同，但作为人却有着共同的感受和需要。这样，在发生矛盾和冲突的时候，运用非暴力沟通，我们将能专注于彼此的感受和需要，从而促进倾听、理解以及由衷的互助。
4. 人们常说：“爱能使心灵的创伤痊愈。”
5. 作为有色人种，生活在执行种族隔离政策的南非并不是很有意思的事情。在那里，肤色随时都可能给你招来无情的刺激。十岁那年，白人打了我，他们认为我太黑了；接着，黑人又打了我，他们认为我太白了。这样的耻辱也许会让任何人想报复社会。
6. 非暴力生活的一个关键就是：感激生活的赐予，而不贪心。
7. 我意识到什么是真正的非暴力以及认识自身暴力的重要性。由于缺乏了解，我们常常认识不到自身的暴力。我们认为，只有打人、鞭挞、杀人以及战争等才算是暴力，而这类事与我们无关。
8. 因为恐惧无法带来和平。
9. 让尊重、理解、欣赏、感激、慈悲和友情，而非自私自利、贪婪、憎恨、偏见、怀疑和敌意，来主导生活。人们常说：这是一个弱肉强食的世界，为了生存，我们必须不择手段。这个观点，请恕我无法同意。
10. 我相信，人天生热爱生命，乐于互助。可是，究竟是什么，使我们难以体会到心中的爱，以致互相伤害？又是什么，让有些人即使在充满敌意的环境中，也能心存爱意？
11. 也许我们并不认为自己的谈话方式是“暴力”的，但我们的语言确实常常引发自己和他人的痛苦。
12. 当我们真诚助人时，我们丰富他人生命的愿望得到了满足。我们的行为，是出于由衷的喜悦。
13. 非暴力沟通的四个要素：1．观察 2．感受 3．需要 4．请求
14. 首先，留意发生的事情。我们此刻观察到什么？不管是否喜欢，只是说出人们所做的事情。要点是，清楚地表达观察结果，而不判断或评估。接着，表达感受，例如受伤、害怕、喜悦、开心、气愤等等。然后，说出哪些需要导致那样的感受。
15. 非暴力沟通提醒我们专注于彼此的观察、感受、需要和请求。它鼓励倾听，培育尊重与爱，使我们情意相通，乐于互助。有些人用非暴力沟通理解自己，有些人用它改善人际关系，还有人借助它改进工作。在世界各地，非暴力沟通被用来协调各个层面的争论和冲突。
16. 对他人的评价实际上反映了我们的需要和价值观。
17. 分类和评判提倡的是暴力。
18. 暴力的根源在于人们忽视彼此的感受与需要，而将冲突归咎于对方——至少大部分暴力的根源都是如此。
19. 美国领导人把前苏联看作是致力于摧毁美国生活方式的“邪恶帝国”；前苏联领导人将美国人看作是试图征服他们的“帝国主义压迫者”。双方都没有承认内心的恐惧。
20. 如果真的想过上悲惨生活，就去与他人做比较。
21. 比较也是一种评判。
22. 我们对自己的思想、情感和行动负有责任。可是，人们广泛使用“不得不”这一短语。例如：“不管你是否喜欢，有些事你不得不做。”显然，这种表达方式淡化了个人责任。“你让我”是人们常用的另一短语，例如：“你让我伤透了心。”此时，我们的表达方式忽视了我们情感的内在根源。
23. 我们可以用负责任的语言代替回避责任的语言。
24. 一旦意识不到我们是自己的主人，我们就成了危险人物。
25. 我们无法强迫他人按我们的期待生活。
26. 认为“某人应当受到惩罚”使我们难以体会到心中的爱。
27. 我们大多数的人使用的语言倾向于评判、比较、命令和指责，而不是鼓励我们倾听彼此的感受和需要。
28. 对于国王、沙皇、贵族来说，将臣民训练得具有奴隶般的精神状态符合他们的利益。“不应该”、“应该”和“不得不”这些表达方式特别适合这个目的：人们越是习惯于评定是非，他们也就越倾向于追随权威，来获得正确和错误的标准。一旦专注于自身的感受和需要，我们就不再是好奴隶和好属下。
29. 人天生热爱生命，乐于互助。可是，异化的沟通方式使我们难以体会到心中的爱。道德评判就是其中的一种，它将不符合我们价值观的人看作是不道德的或邪恶的。进行比较也是一种评判，它会蒙蔽对人对己的爱意。异化的沟通方式还淡化了我们对自己的思想、情感和行为的责任意识。此外，强人所难也会造成心灵的隔阂。
30. 不区分观察和评论，人们将倾向于听到批评。
31. 非暴力沟通的第一个要素是观察。我们仔细观察正在发生的事情，并清楚地说出观察结果。非暴力沟通并不要求我们保持完全的客观而不作任何评论。它只是强调区分观察和评论的重要性。将观察和评论混为一谈，人们将倾向于听到批评，甚至会产生逆反心理。
32. 不带评论的观察是人类智力的最高形式。
33. 对于大多数的人来说，观察他人及其行为，而不评判、指责或以其他方式进行分析，是难以做到的。
34. 非暴力沟通的第一个要素是观察。将观察和评论混为一谈，别人就会倾向于听到批评，并反驳我们。非暴力沟通是动态的语言，不主张绝对化的结论。它提倡在特定的时间和情境中进行观察，并清楚地描述观察结果。例如，它会说“欧文在过去的5场比赛中没有进一个球”，而不是说“欧文是个差劲的前锋”。
35. 只是描述观察结果而不含任何评论。
36. 非暴力沟通的第二个要素是感受。心理学家罗洛·梅（Rollo May）认为：“成熟的人十分敏锐，就像听交响乐的不同乐章，不论是热情奔放，还是柔和舒缓，他都能体察到细微的起伏。”
37. 当我们说“我觉得”，我们常常并不是在表达感受，而是在表达想法。
38. 非暴力沟通的第二个要素是感受。通过建立表达感受的词汇表，我们可以更清楚地表达感受，从而使沟通更为顺畅。在表达感受时，示弱有助于解决冲突。此外，非暴力沟通还对表达具体感受的词语与陈述想法、评论以及观点的词语作了区分。
39. 非暴力沟通强调，感受的根源在于我们自身。我们的需要和期待，以及对他人言行的看法，导致了我们的感受。
40. 听到不中听的话的四种选择： 1．责备自己 2．指责他人 3．体会自己的感受和需要 4．体会他人的感受和需要
41. 批评往往暗含着期待。对他人的批评实际上间接表达了我们尚未满足的需要。如果一个人说“你从不理解我”，他实际上是渴望得到理解。如果太太说“这个星期你每天都工作到很晚，你喜欢工作，不喜欢我”，那反映了她看重亲密关系。
42. 如果我们通过批评来提出主张，人们的反应常常是申辩或反击。反之，如果我们直接说出需要，其他人就较有可能作出积极的回应。
43. 双方都习惯于指责对方。
44. 如果我们不看重自己的需要，别人可能也不会。实际上，如果直接说出需要，获得积极回应的可能性就会增加。
45. 对于大多数人来说，个人成长一般会经历三个阶段：（1）“情感的奴隶”——我们认为自己有义务使他人快乐；（2）“面目可憎”时期——此时，我们拒绝考虑他人的感受和需要；（3）“生活的主人”——我们意识到，虽然我们对自己的意愿、感受和行动负有完全的责任，但无法为他人负责。与此同时，我们还认识到，我们无法牺牲他人来满足自己的需要。
46. 首先，清楚地告诉对方，我们希望他们做什么。如果我们请求他人不做什么，对方也许会感到困惑，不知道我们到底想要什么。而且，这样的请求还容易引起别人的反感。
47. 我们提出的请求越具体越好。如果我们的意思含糊不清，别人就难以了解我们到底想要什么。
48. 抽象的语言无助于深化自我认识。
49. 许多来向我求助的人后来发现，他们感到沮丧或灰心，很大程度上是因为他们不清楚自己对他人究竟有什么样的期待。
50. 如果我们只是表达自己的感受，别人可能就不清楚我们想要什么。
51. 像“你没有听明白”“这不是我的意思”“你听错了”这样的表达，很可能会让托尼觉得老师在批评他。
52. 参加集体讨论时，说清楚我们希望得到怎样的反馈，是至关重要的。如果不清楚发言的目的，我们的讨论也许只是在浪费时间，而无法满足任何人的需要。
53. 如何区分命令和请求：请求没有得到满足时，提出请求的人如果批评和指责，那就是命令；如果想利用对方的内疚来达到目的，也是命令。
54. 我们越是将他人的不顺从看作是对我们的排斥，我们所表达的愿望就越有可能被看作是命令。
55. 在生活中，如果我们不想勉强人，那么，清楚地表明这一点是重要的——这有助于人们相信我们提出的是请求而非命令。
56. 在人们无法满足我们的愿望时，我们是否尊重他们的感受和需要最能体现我们提出的是请求还是命令。如果我们愿意去体会是什么使他们无法说“是”，那么，根据我的定义，我们提出的就是请求而非命令。选择通过请求而非命令来表达愿望，并不意味着，一旦人们说“不”，我们就不再去满足自己的需要。但它意味着，除非已经充分体会是什么妨碍了他人说“是”，我们就不会试图说服他们。
57. 如果我们只是想改变别人，以使他们的行动符合我们的利益，那么非暴力沟通并不是适当的工具。非暴力沟通是用来帮助我们在诚实和倾听的基础上与人联系。使用非暴力沟通时，我们希望人们的改变和行动是出于对生命的爱。一旦人们相信我们看重彼此的感情，并能兼顾双方的需要，那么，他们也就会相信我们所表达的愿望是请求而非命令。
58. 我要会见的学生有四十位。在学校中，他们被看作是“品行不端”的学生。我认为，像“品行不端”这样的标签会带来很消极的影响。如果一个学生被贴上这样的标签，那岂不是说他不遵守学校规矩是正常的吗？这样的标签将鼓励学生做我们不希望他们做的事，然后，他们的行为似乎又进一步证实了我们的判断。
59. “在印象中，如果我没照你说的去做，你就不会尊重我。如果我知道你并不想使唤我，在你叫我时，我会乐于回应你。如果你高高在上，像个盛气凌人的老板，你将会发现，你一头撞在了墙上。当你反复提醒我，你为我做的各种事情，你最好准备再次碰壁！你可以大声抱怨、责骂，但我仍不会去倒垃圾。即使你现在改变方式，我也需要时间忘记不快。”
60. 一旦人们认为不答应我们就会受到责罚，他们就会把我们的请求看作是命令。如果我们清楚地表达我们无意强人所难，人们一般会相信，我们提出的是请求而非命令。非暴力沟通的目的不是为了改变他人来迎合我们。相反，非暴力沟通重视每个人的需要，它的目的是帮助我们在诚实和倾听的基础上与人联系。
61. 在前四章中，我们介绍了如何通过非暴力沟通的四个要素来表达自己。本章我们将探讨如何倾听他人，了解他们的观察、感受、需要和请求，并给予反馈。
62. 尽管有种种相似之处，生活的每时每刻就像一个刚出生的婴儿，一张新的面孔，我们从未见过，也不可能再次见到。我们无法停留在过去，也无法预见我们的反应。我们需要不带成见地感受变化。我们需要用全身心去倾听。
63. 在安慰他人或提建议前，先看看那是否是他们想要的。
64. ·建议：“我想你应该……” ·比较：“这算不了什么。你听听我的经历……” ·说教：“如果你这样做……你将会得到很大的好处。” ·安慰：“这不是你的错；你已经尽最大努力了。” ·回忆：“这让我想起……” ·否定：“高兴一点。不要这么难过。” ·同情：“哦，你这可怜的人……” ·询问：“这种情况是什么时候开始的？” ·辩解：“我原想早点打电话给你，但昨晚……” ·纠正：“事情的经过不是那样的。”
65. 说了什么，并考虑他的情况符合哪种理论，我们是在诊断人——我们并没有倾听他们。在非暴力沟通中，倾听他人意味着，放下已有的想法和判断，一心一意地体会他人。倾听的这种品质体现了它与理解以及同情之间的区别。
66. 分析妨碍了倾听。
67. 不论别人说什么，我们只听到他们此时此刻的（a）观察，（b）感受，（c）需要 和（d）请求。
68. 在倾听他人的观察、感受、需要和请求之后，我们可以主动表达我们的理解。如果我们已经准确领会了他们的意思，我们的反馈将帮助他们意识到这一点。反之，如果我们的理解还不到位，他们也就有机会来纠正我们。此外，这样做还有助于人们体会自己的状况，从而深入了解自己。
69. 一般来说，如果一个人在说话时有明显的情绪，他一般会期待得到他人的反馈。如果我们自己是说话的那个人，我们不妨清楚地表明我们是否期待反馈。
70. 一个人在听别人谈自己的感受和需要时，将会留意其中是否暗含着批评或嘲讽。如果我们的语气很肯定，仿佛是在宣布他们的内心世界，那么，通常不会有好的反应。然而，一旦别人通过我们的语气意识到我们是在体会，而非下结论，他们一般就不会产生反感。
71. 有时，我们认为自己受到了指责，实际上，那些话是他人表达需要和请求的方式。如果意识到这一点，我们就不会认为自己的人格受到了伤害。反之，如果一心分析自己或对方的过错，我们就会认为自己被贬低了。
72. 作家约瑟夫·坎伯（Joseph Campbell）说道：“为了幸福，必须把‘别人怎么看我’这个问题放在一边。”
73. 如果人们常常怀疑我们的诚意，那么，我们就需要好好审视自己的动机。也许，我们只是在机械地运用非暴力沟通，而忘记其目的。这时，我们就可以问自己，我们关心的是加深与人的联系，还是以“标准的”非暴力沟通方式来说话。或者，虽然我们是以非暴力沟通的方式来表达自己，我们在乎的也许只是改变他人来迎合我们的需要。
74. 一旦一个人意识到自己得到了理解和接纳，一般来说，他会觉得很惬意。
75. 怎样判断对方的感受是否已经充分表达呢？首先，如果一个人觉得别人已经完全明白他的意思，他就会变得轻松。这时，我们也会感到放松。另一个更为明显的标志是，他停止了谈话。如果无法确定对方是否还有话要说，就不妨问一句：“你还有什么话要告诉我吗？”
76. 我们无法给别人我们自己都没有的东西。有时，我们会发现自己没有心情去关心别人。一般来说，这反映了我们也需要得到关心。如果告诉他人我们正处于痛苦中，我们无法顾及他们的感受和需要，别人很可能就会伸出援手。
77. 联合国前秘书长汉马斯克德（Dag Hammarskjold）曾经说道：“你越是留意自己内心的声音，就越能够听到别人的声音。”一旦我们能够敏锐地察觉并照顾自己的感受和需要，我们就有能力迅速调整好状态，来倾听他人。
78. 我大声地提出请求，是为了提醒他们注意我此时此刻的痛苦和需要。
79. 当他人遭遇不幸时，我们常常急于提建议，安慰，或表达我们的态度和感受。为了倾听他人，我们需要先放下已有的想法和判断，全心全意地体会对方。倾听他人有助于对他人的理解和接纳。
80. 如果有人倾听你，不对你评头论足，不替你担惊受怕，也不想改变你，这多美好啊……每当我得到人们的倾听和理解，我就可以用新的眼光看世界，并继续前进……这真神奇啊！一旦有人倾听，看起来无法解决的问题就有了解决办法，千头万绪的思路也会变得清晰起来。
81. 非暴力沟通鼓励我们表达自己最深的感受和需要，因此，我们有时也许会发现运用非暴力沟通是富有挑战性的。然而，通过倾听，我们将意识到他人的人性以及彼此的共通之处，这会使自我表达变得容易些。我们越是倾听他人语言背后的感受和需要，就越不怕与他们坦诚地沟通。我们最不愿意示弱的时候往往是因为担心失去控制想显得强硬的时候。
82. “你和我们说，在一个生气的人面前，永远不要用‘不过’‘可是’‘但是’之类的词语。一开始，我很想为自己辩护，我想和他说，‘可是，我们真的没房间’。幸好，在那时，我想起了那句话。我一直记得这句话，是因为在一周前，妈妈在和我争吵时说，‘如果我说什么，你都说‘但是’，小心我杀了你’。想一想，我妈妈生气时听到‘但是’都想杀了我，何况那个男人呢？如果我在他愤怒时说，‘可是，我们真的没房间’，我想我早就没命了。”
83. 当别人说“不”的时候，我们常常会认为他们是在拒绝我们。有时，我们甚至还会觉得自己受到了伤害。然而，如果我们能够体会他人的感受和需要，我们也许就会发现是什么使他们无法答应我们的请求。
84. 有的时候，谈话的气氛很沉闷。我们体会不到说话的人有怎样的感受和需要，也不知道他对我们有什么期待。这样的谈话是很累人的。它只是在浪费我们的时间，而无法帮助我们与他人加深联系。这种局面的出现往往是因为说话的人并不清楚自己的感受、需要和请求。
85. 人们常常没有意识到，他们需要的是别人的理解和接纳。他们也没有意识到，直接表达自己的感受和需要，与讲故事相比，更容易得到他们所期待的联系。
86. 说的人更希望对方打断，而不是假装在听。
87. 所有的人都希望自己的话对人有益，而不想被人当作负担。
88. 有的时候，我们说了心里话，很想知道对方的反应，却发现对方一句话也不说。这时，我们也许会很不安，容易把事情往坏处想。在别人保持沉默时，我们一般会觉得有些别扭，而很难静下心来体会对方的感受和需要。
89. 倾听使我们勇于面对自己的弱点。它还可以帮助我们预防潜在的暴力，使谈话生动有趣，并了解“不！”和沉默所反映的感受和需要。一次又一次，我见证了，倾听帮助人们治愈心灵的创伤。
90. 非暴力沟通最重要的应用也许是培养对自己的爱。
91. 如何培养对自己的爱呢？转变自我评价的方式是一个重要方面。既然希望自己所做的任何事情都是有益的，那么，自我评价的方式就要有助于学习，使我们的选择符合生命的需要。然而，不幸的是，我们的自我评价方式往往导致自我憎恨，而无助于学习。
92. 失误揭示我们的局限性，并引导我们的成长。
93. 我希望，我们的改变是出于对生命的爱，而不是出于羞愧或内疚这些具有负面影响的心理。
94. 羞愧是自我憎恨的一种形式，出于羞愧的行为不是自由而快乐的行为。即使我们试图更加友善和体贴，一旦人们意识到我们行为背后的羞愧或内疚，他们对这些行为的欣赏也就比不上那些只是出于爱的行为。在我们的语言中，有一个词极易引起羞愧和内疚。我们经常使用它来打击自己。它在我们的意识中是如此根深蒂固，以致许多人无法想象，没有它生活将如何继续。这个词就是“应该”，也就是“我应该早点知道”或“我不应该做那件事情”中的“应该”。如果我们认为自己“应该”怎么样，在大多数的情况下，我们也就封闭了自我。因为“应该”意味着我们别无选择。这使我们感到无奈和沮丧。同时，又心有不甘，不愿屈服。
95. 自责是尚未满足的需要的可悲表达。
96. 经常责备自己、强迫自己将使我们“更像椅子而不像人”。非暴力沟通认为，对他人的指责反映了我们遇到了挫折——他人的行为不符合我们的需要。如果我们指责的那个人恰好是我们自己，那么，言下之意是：“我的行为不符合我的需要。”我相信，如果我们专注于需要是否得到满足以及得到怎样的满足，我们就更有可能从自我评价中获益。
97. 如果发现我们痛骂自己：“你看你，又把事情搞砸了！”我们马上就可以问：“我什么样的需要没有得到满足？”一旦意识到自己尚未满足的需要——很可能是多个层面的需要，我们的身心状态就会发生明显的变化。我们不再感到羞愧、内疚和沮丧，而开始体会到别的情感。不论它们是忧愁、失望、恐惧、悲伤、挫折感或别的——其目的都是推动我们去满足需要和追逐梦想。
98. 非暴力沟通鼓励我们直面人生的苦难：在遇到挫折时，充分体会人生的悲哀和内心的渴望。是的，感到遗憾是难免的。但它能帮助我们从经历中学习，而无须责备自己。我们意识到过去的行为违背了自己的需要及价值观，并允许这种觉察引发的情感充分流淌。一旦专注于尚未满足的需要，我们就会考虑如何满足它。反之，如果用苛刻的语言指责自己，我们不仅难以找到解决办法，而且容易陷于自我惩罚的痛苦中。
99. 非暴力沟通自我宽恕：感到遗憾时，我们试图了解过去的行为所要满足的需要。
100. 人的行为总是服务于自身的需要及价值观。
101. 当我们拥抱自己的各个方面，并理解它们所反映的需要及价值观，我们活在对自己深深的爱之中。
102. 我深信，出于对生命纯洁的爱，而不是出于恐惧、内疚、羞愧、职责或义务来选择生活，是爱惜自己的重要体现。
103. 不论你选择做什么，了解自己为什么要那样做。
104. 我们知道，如果不做某些事情，我们就会责备自己。我们认为不做那些事情是不对的、愚蠢的。可是，如果为了体面而循规蹈矩，我们最终难免会感到厌烦。
105. 最危险的行为也许是“因为别人的要求”我们不得不做。
106. 我相信，我们越是投入服务生命的乐趣中——服务生命是唯一的目的，我们也就越爱自己。
107. 非暴力沟通最重要的应用也许在于培育对自己的爱。当我们的表现不完美时，我们可以通过体会忧伤和自我宽恕，来看清个人成长的方向，以及避免自我惩罚。评价自己的行为时，我们专注于尚未满足的需要；这样，我们就不再依赖羞愧、内疚、恼怒或沮丧的心理来寻求改变，而让爱主导我们的学习和成长。
108. 充分表达愤怒的第一步是我们不再归咎于他人。如果我们认为“他让我很生气”，那么，我们难免就会指责他人。然而，实际情况是，我们心情并不取决于他人的行为。
109. 生气的原因在于我们的想法——对他人的评判和指责。
110. 如果在一个社会中，内疚被运用来控制人；那么，指责他人就容易成为一种习惯。同时，为了使这种手段奏效，我们可能就会认为一个人可以主导另一个人的情绪。
111. 听到不中听的话时，我们有四种选择：1．责备自己；2．指责他人；3．体会自己的感受和需要；4．体会他人的感受和需要。
112. 希望他人因为内疚发生改变，就是将刺激和原因混为一谈。
113. 假定我们约了个人，时间到了，她却没来。如果彼此的关系处于比较微妙的时期，我们可能会忧心忡忡。如果我们看重的是诚实守信，我们也许会觉得不耐烦。反之，如果我们想休息一会儿，我们可能就不会介意她来晚了。因此，同一件事情，不同的需要导致不同的感受。一旦意识到自己的需要——不论是友谊、诚信还是休息，我们就可以更加体贴自己。我们可能会有强烈的情绪，但不再生气。可是，如果意识不到自己尚未满足的需要，一心考虑别人的过错，我们难免就会生气。除了专注于自身的感受和需要，我们还可以选择去体会对方的感受和需要。此时，我们也不会感到生气。我们无须压抑愤怒，只要我们专注于他人的感受和需要，愤怒也就不再存在。
114. 在我看来，愤怒是我们的思维方式造成的。它的核心是尚未满足的需要。如果我们能够借助它来提醒自己——我们有需要没有得到满足，而我们的思维方式正使它难以得到满足，那愤怒就是有价值的。
115. 愤怒驱使我们去惩罚他人，而不是去满足需要。
116. 我们将会有意识地用“我生气是因为我需要……”来取代“我生气是因为他们……”。
117. 我生气的原因不在于别人做了什么，而在于我怎么看待对方及其行为。
118. 当我们意识到自己的需要，愤怒就转变为服务需要的情感。
119. 如果人们认为自己的痛苦是由其他人造成的，并认为那些人应该受到谴责或惩罚，那么，就像这位年轻的囚犯那样，他们播下了暴力的种子。
120. 指责一个人，往往使我们的愿望更难得到满足。
121. 指责他人有时可以使我们达到目的——出于害怕、内疚或惭愧，他们改变了自己的行为。
122. 批评和指责使人倾向于自我保护并变得更有攻击性。
123. 我们只是静静地体会自己。接着，想一想是什么想法使我们生气了。
124. 越是能够倾听他人，也越有机会被倾听。
125. 在大多数的情况下，在表达自己之前，我们需要先倾听他人。如果对方还处于某种情绪中，他们就很难静下心来体会我们的感受和需要。一旦我们用心倾听他们，并表达我们的理解，在得到倾听和理解之后，他们一般也就会开始留意我们的感受和需要。
126. 一旦意识到他人的感受和需要，我们就会发现彼此相同的人性。
127. 留意头脑中出现的暴力想法，而不评判它们。
128. 那位先生一直诉说着他的忧虑和不满。不经意间，他已经从犹太人谈到了黑人。看起来，他渴望有人了解他的痛苦。我静静地听着，大概十分钟后，他停了下来。他觉得我已经理解了他。
129. 人们常常觉得自己受到了指责，有时他们自己也同意，并开始恨自己——但这并不意味着他们会改变自己的行为。
130. 我们需要有足够的耐心来学习和运用非暴力沟通。在与人交往的过程中，我们的第一反应常常是习惯性的反应，因此，运用非暴力沟通有时是很别扭的事。然而，如果我们想要实现自己的人生选择，我们就要给自己充分的时间。
131. 练习把每一个指责都转化为尚未满足的需要。
132. 如果你希望自己在生气的时候也能运用非暴力沟通，我建议你做以下的练习。在前面，我们已经提到，我们生气是因为我们的想法——我们认为人们“应该”或“不应该”做什么，我们还给人贴上各种标签，并说长论短。请留意我们头脑中“我不喜欢抽烟的人……”之类的想法。然后，问自己：“我不喜欢他们……，是因为我什么样的需要没有得到满足？”通过这样的方式，我们就把注意力放在了尚未得到满足的需要，而不是考虑他人有什么过错。
133. 在生气时，批评和指责他人都无法真正传达我们的心声。如果想充分表达愤怒，我们就不能归咎于他人，而把注意力放在自己的感受和需要上。与批评和指责他人相比，直接说出我们的需要更有可能使我们的愿望得到满足。
134. 表达愤怒的四个步骤是：（1）停下来，除了呼吸，什么都别做；（2）想一想是什么想法使我们生气了；（3）体会自己的需要；（4）表达感受和尚未满足的需要。有时，在第3步和第4步之间，我们需要先倾听他人。在得到倾听和理解之后，他们也就可以静下心来体会我们的感受和需要。
135. 非暴力沟通认为，如果一个人做的事情会伤害到自己或他人，那是因为他不够成熟。为此，他需要得到帮助。如果我们不够成熟，我们可能会有以下的表现：（1）我们意识不到自己行为的后果；（2）我们认识不到，我们并不需要通过惩罚他人来满足自己的需要；（3）我们相信，我们有“权利”去惩罚或伤害他人，因为他们是罪有应得；（4）我们产生了幻觉，例如，听到“某种声音”叫我们去杀人。
136. 使用防卫性的强制力，是为了保护自己或他人，而不是为了惩罚、羞辱或谴责他人。
137. 我们希望痛苦能让他们：（1）意识到自己的过错；（2）感到懊悔；（3）改变行为。然而，在实际生活中，惩罚往往加强了对方的敌意和抵触心理，使双方的关系更加疏远。
138. 有的时候孩子拒绝做一件对他们有益的事情，只是因为他们不想在父母的压力面前屈服。其次，即使体罚能带来立竿见影的效果，这也并不意味着，其他方法无法达到同样的效果。最后，我还担心，体罚孩子会造成不良的社会影响。如果我们把暴力作为解决问题的办法，虽然孩子可能会去做我们要求的事，但这样做难道不是在鼓励孩子用暴力来解决冲突吗？
139. 当我们为了回避惩罚去做事情时，我们可能会忽视事情本身的价值，而陷于对失败的忧虑。如果员工的表现只是在服从管理层的命令，士气就会受到影响；或迟或早，工作效率就会降低。
140. 我希望他基于怎样的原因去做我想要他做的事情？
141. 了解别人基于什么样的原因来满足我们的愿望是至关重要的。
142. 在有些情形中，我们没有机会和他人交流，这时，我们也许需要使用强制力来保护自己和他人。我们这样做，是为了避免伤害，而不是为了惩罚他人。如果我们威胁他人或实施惩罚，人们常常会产生敌意和抵触心理。这样，彼此的关系将会疏远。同时，惩罚还可能使人忽视事情本身的意义，而把注意力放在不服从的后果上。如果我们试图通过惩罚来使人们认识自己的需要，那么，我们很可能适得其反。
143. 然而，对于大多数人来说，倾听和表达自己的需要并不容易。一般来说，我们的文化倾向于把个人需要看作是消极的、具有破坏性的。如果一个人公开表达自己的需要，就很可能被看作是自私的。
144. 专注于我们想要做的，而不是追究错在哪里。
145. 我感到惊讶的是，只要我不再批评和指责他人，而把注意力放在自己的感受和需要，我的心情就放松了许多。
146. 在情绪低落的时候，我们也许会怨天尤人。然而，如果我们以苛刻的态度对人对己，我们的心情也好不到哪里去。通过运用非暴力沟通，我们不再试图分析自己或他人有什么毛病，而是用心去了解我们的需要，这样，我们的内心将逐渐变得平和。一旦我们发现自己心底深处的愿望，并采取积极的行动，我们将会重获生活的热情。
147. 优雅地接受别人的感激。
148. 在别人表达感激时，人们通常有两种截然不同的反应。一种是自我膨胀，相信我们比别人优越；另一种是假谦虚，否定别人的欣赏，耸耸肩说：“哦，这没什么。”纳菲滋帮助我看到了，我们有别的方式来听取感激。如果我意识到我的能力是生命赋予我的，我就能够同时避免自我膨胀和假谦虚。
149. 虽然人们在听到感激时会不太自在，但绝大多数的人渴望得到他人的肯定和感激。
150. 我刚刚结束一个有100多人参加的研讨班，除了一个人，其他人都高度评价这次的研讨班。然而，我牢记的却是那个人的不满。
151. 约翰·鲍威尔（John Powell）在他的《爱的秘密》一书中讲到，对于没有在父亲活着的时候表达自己的感激，他十分伤心。这激起了我的强烈共鸣。如果无法向那些对我们的一生有极为重要影响的人表达感激，我们会感到多么悲哀啊！
152. 在赞扬他人时，我们很少揭示内心活动，而把自己放在了裁判的位置。赞扬也常常被人用来实现个人目的。非暴力沟通鼓励我们充分表达感激。在表达感激时，我们说出：（1）对我们有益的行为；（2）我们的哪些需要得到了满足；（3）我们的需要得到满足后，我们是什么样的心情。

1. 马克思以前的唯物论，离开人的社会性，离开人的历史发展，去观察认识问题，因此不能了解认识对社会实践的依赖关系，即认识对生产和阶级斗争的依赖关系。

2. 人的社会实践，不限于生产活动一种形式，还有多种其他的形式，阶级斗争，政治生活，科学和艺术的活动，总之社会实际生活的一切领域都是社会的人所参加的。因此，人的认识，在物质生活以外，还从政治生活文化生活中（与物质生活密切联系），在各种不同程度上，知道人和人的各种关系。

3. 马克思主义者认为人类社会的生产活动，是一步又一步地由低级向高级发展，因此，人们的认识，不论对于自然界方面，对于社会方面，也都是一步又一步地由低级向高级发展，即由浅入深，由片面到更多的方面。

4. 人们要想得到工作的胜利即得到预想的结果，一定要使自己的思想合于客观外界的规律性，如果不合，就会在实践中失败。人们经过失败之后，也就从失败取得教训，改正自己的思想使之适合于外界的规律性，人们就能变失败为胜利，所谓“失败者成功之母”，“吃一堑长一智”，就是这个道理。

5. 然而人的认识究竟怎样从实践发生，而又服务于实践呢？这只要看一看认识的发展过程就会明了的。原来人在实践过程中，开始只是看到过程中各个事物的现象方面，看到各个事物的片面，看到各个事物之间的外部联系。

6. 社会实践的继续，使人们在实践中引起感觉和印象的东西反复了多次，于是在人们的脑子里生起了一个认识过程中的突变（即飞跃），产生了概念。概念这种东西已经不是事物的现象，不是事物的各个片面，不是它们的外部联系，而是抓着了事物的本质，事物的全体，事物的内部联系了。概念同感觉，不但是数量上的差别，而且有了性质上的差别。

7. 认识的真正任务在于经过感觉而到达于思维，到达于逐步了解客观事物的内部矛盾，了解它的规律性，了解这一过程和那一过程间的内部联系，即到达于论理的认识。

8. 这种基于实践的由浅入深的辩证唯物论的关于认识发展过程的理论，在马克思主义以前，是没有一个人这样解决过的。

9. 指出了社会的人在他们的生产和阶级斗争的复杂的、经常反复的实践中，由感性认识到论理认识的推移的运动。

10. 感觉只解决现象问题，理论才解决本质问题。

11. 马克思、恩格斯、列宁、斯大林之所以能够作出他们的理论，除了他们的天才条件之外，主要地是他们亲自参加了当时的阶级斗争和科学实验的实践，没有这后一个条件，任何天才也是不能成功的。

12. 如果要直接地认识某种或某些事物，便只有亲身参加于变革现实、变革某种或某些事物的实践的斗争中，才能触到那种或那些事物的现象，也只有在亲身参加变革现实的实践的斗争中，才能暴露那种或那些事物的本质而理解它们。

13. 一切真知都是从直接经验发源的。

14. 就知识的总体说来，无论何种知识都是不能离开直接经验的。任何知识的来源，在于人的肉体感官对客观外界的感觉，否认了这个感觉，否认了直接经验，否认亲自参加变革现实的实践，他就不是唯物论者。

15. 中国人有一句老话：“不入虎穴，焉得虎子。”这句话对于人们的实践是真理，对于认识论也是真理。离开实践的认识是不可能的。

16. 中国人民对于帝国主义的认识也是这样。第一阶段是表面的感性的认识阶段，表现在太平天国运动和义和团运动等笼统的排外主义的斗争上。第二阶段才进到理性的认识阶段，看出了帝国主义内部和外部的各种矛盾，并看出了帝国主义联合中国买办阶级和封建阶级以压榨中国人民大众的实质，这种认识是从一九一九年五四运动前后才开始的。

17. 那个具体战争的规律性，懂得了战略和战术，因而能够有把握地去指导战争。此时，如果改换一个无经验的人去指导，又会要在吃了一些败仗之后（有了经验之后）才能理会战争的正确的规律。

18. 如果这个人在这项工作中经过了一个时期，他有了这项工作的经验了，而他又是一个肯虚心体察情况的人，不是一个主观地、片面地、表面地看问题的人，他就能够自己做出应该怎样进行工作的结论，他的工作勇气也就可以大大地提高了。只有那些主观地、片面地和表面地看问题的人，跑到一个地方，不问环境的情况，不看事情的全体（事情的历史和全部现状），也不触到事情的本质（事情的性质及此一事情和其他事情的内部联系），就自以为是地发号施令起来，这样的人是没有不跌交子的。

19. 认识的过程，第一步，是开始接触外界事情，属于感觉的阶段。第二步，是综合感觉的材料加以整理和改造，属于概念、判断和推理的阶段。只有感觉的材料十分丰富（不是零碎不全）和合于实际（不是错觉），才能根据这样的材料造出正确的概念和论理来。

20. 第二是认识有待于深化，认识的感性阶段有待于发展到理性阶段——这就是认识论的辩证法。如果以为认识可以停顿在低级的感性阶段，以为只有感性认识可靠，而理性认识是靠不住的，这便是重复了历史上的“经验论”的错误。

21. 庸俗的事务主义家不是这样，他们尊重经验而看轻理论，因而不能通观客观过程的全体，缺乏明确的方针，没有远大的前途，沾沾自喜于一得之功和一孔之见。这种人如果指导革命，就会引导革命走上碰壁的地步。

22. 理性认识依赖于感性认识，感性认识有待于发展到理性认识，这就是辩证唯物论的认识论。

23. 认识从实践始，经过实践得到了理论的认识，还须再回到实践去。

24. 人类认识的历史告诉我们，许多理论的真理性是不完全的，经过实践的检验而纠正了它们的不完全性。

25. 斯大林说得好：“理论若不和革命实践联系起来，就会变成无对象的理论，同样，实践若不以革命理论为指南，就会变成盲目的实践。”

26. 许多时候须反复失败过多次，才能纠正错误的认识，才能到达于和客观过程的规律性相符合，因而才能够变主观的东西为客观的东西，即在实践中得到预想的结果。

27. 革命时期情况的变化是很急速的，如果革命党人的认识不能随之而急速变化，就不能引导革命走向胜利。

28. 我们反对革命队伍中的顽固派，他们的思想不能随变化了的客观情况而前进，在历史上表现为右倾机会主义。这些人看不出矛盾的斗争已将客观过程推向前进了，而他们的认识仍然停止在旧阶段。一切顽固党的思想都有这样的特征。他们的思想离开了社会的实践，他们不能站在社会车轮的前头充任向导的工作，他们只知跟在车子后面怨恨车子走得太快了，企图把它向后拉，开倒车。

29. 我们也反对“左”翼空谈主义。他们的思想超过客观过程的一定发展阶段，有些把幻想看作真理，有些则把仅在将来有现实可能性的理想，勉强地放在现时来做，离开了当前大多数人的实践，离开了当前的现实性，在行动上表现为冒险主义。

30. 马克思主义者承认，在绝对的总的宇宙发展过程中，各个具体过程的发展都是相对的，因而在绝对真理的长河中，人们对于在各个一定发展阶段上的具体过程的认识只具有相对的真理性。无数相对的真理之总和，就是绝对的真理。客观过程的发展是充满着矛盾和斗争的发展，人的认识运动的发展也是充满着矛盾和斗争的发展。

31. 社会的发展到了今天的时代，正确地认识世界和改造世界的责任，已经历史地落在无产阶级及其政党的肩上。这种根据科学认识而定下来的改造世界的实践过程，在世界、在中国均已到达了一个历史的时节——自有历史以来未曾有过的重大时节，这就是整个儿地推翻世界和中国的黑暗面，把它们转变过来成为前所未有的光明世界。

32. 世界到了全人类都自觉地改造自己和改造世界的时候，那就是世界的共产主义时代。

33. 通过实践而发现真理，又通过实践而证实真理和发展真理。从感性认识而能动地发展到理性认识，又从理性认识而能动地指导革命实践，改造主观世界和客观世界。实践、认识、再实践、再认识，这种形式，循环往复以至无穷，而实践和认识之每一循环的内容，都比较地进到了高一级的程度。这就是辩证唯物论的全部认识论，这就是辩证唯物论的知行统一观。

1. 丹尼尔・平克在《驱动力 3.0》一书中有说：“服从让我们撑过白天，而投入才能让我们撑过夜晚。” 这告诉了我们一个很简单的事实：外驱让我们可以做好本职工作，而内驱才能让我们成就卓越。
2. 驱动力 2.0 的核心价值观是 “顺从”；而驱动力 3.0 的核心价值观是 “自主”。
3. 我们做管理工作的目标，归根结底，不就是 “群策群力打胜仗” 吗？“群策群力” 就是如何带好团队，“打胜仗” 就是如何取得好的业绩，“带人”+“做事”，齐了。
4. 想被提拔为一个管理者最好的方式，就是你首先成为一个实际上的管理者，我们常常把这样的晋升理念叫 “既定事实”，而这种理念在互联网行业里被广泛认同。
5. 无论你走哪条路上，你都会发现有些能力是共通的，比如规划、带人、沟通、执行等管理能力覆盖了全部 8 个方向。
6. 对于工程师思维特别重的管理者来说，他们尤其倚重技术；对于不懂技术的管理者来说，他们又特别迷信技术。
7. 做工程师的时候，技术是用来做事情的，掌握好技术的目的就是为了做好实施，看待技术是从如何运用的角度出发。而对于管理者来说，技术是达成目标的手段之一，所以看待技术是从如何评估的角度出发，评估该项技术是否是最合理的手段，以及如何选择才合理，并据此做出决策，因此常常被称为技术判断力。我们的老领导经常会告诫我们，即使做了管理，技术判断力不能丢，就是指这种能力。
8. 首先，把技术提到更高视角来看待。做技术的时候，把技术做好就是最大的目标；而做了管理之后，你会把技术作为一个手段来看待，看它究竟能为目标带来什么。但这并不意味着你就不再关心技术，只是关心的层次不同了，你开始需要借助每个人的技术能力去做更大的事情了。这很像在学习组装电脑，即便已经不需要关心主板、内存、CPU 的内部运行逻辑，但你还是要很清楚它们的功能是什么，接口什么样，以及从哪些维度去衡量一个主板的好坏、内存的好坏、CPU 的好坏，也得清楚在整台电脑中，哪个部件可能会是短板，等等。所以，技术转管理并不意味着不关心技术，只是更关心更大的目标和整体结果了。
9. 其次，换一种学习方式来掌握技术。你要深刻地认识到，亲自写代码固然是很好的学习技术的方式，但是作为 leader，你需要快速掌握更多的技术，并且快速判断该如何搭配使用，所以你一定得有更高效的学习方式才行。这里我介绍三个行之有效的做法：建立你的学习机制。你可以想想在团队内建立什么样的学习机制，可以帮助你借助团队的力量来提升技术判断力，并结合自己的情况来创建。请教专家。在了解某一个领域的情况时，借助你的平台，找你能找到的最厉害的专家高手进行请教，他们之所以成为高手，一般都能给出高屋建瓴、醍醐灌顶的认知。在这个知识型工作者的时代，和自己埋头思考相比，共创成果往往会出乎你想象，特别能增长见识，你可以看看在团队中如何建立共创机制。
10. 别忘了，自从你带团队的那一天起，你就已经不是一个人在战斗。所以，你可以依靠团队和更广的人脉，去拓展技术视野和技术判断力。常见的几个方式如下：建立技术学习机制。盘点你负责的业务，需要哪些方面的技术，成立一个或几个核心的技术小组，让团队对各个方向的技术保持敏感，要求小组定期做交流和分享，这样你就可以保持技术的敏感度。专项技术调研项目化。如果某项技术对团队的业务有重要的价值，可以专门立项做技术调研，并要求项目负责人做调研汇报。和技术大牛交流。越是厉害的技术人，越能深入浅出地把技术讲明白，所以针对某项技术找大牛取经，也是学习的好途径。你看，虽然实际操刀的时间少了，但是你和技术大牛的交流机会多了，一方面因为你有更大的影响力了，另一方面，你和大牛有了共同的诉求，就是把技术 “变现”，让技术产生价值。听取工作汇报。因为你带的是技术团队，大部分工作都和技术相关，在读员工的周报、季度汇报时，相互探讨，也是一种切磋和学习。总之，你会发现，技术管理人的技术水准的提升和保持，主要看能从周围人的身上汲取到多少信息和知识，而不再只是靠自学。
11. 站在工程师视角上，追求工作的极致品质，恰恰是一种良好的工匠精神。但是站在管理者视角上，就需要评估一段时间内的产出效率了。衡量一项工作 “到底需要花 5 天做到 70 分，还是 10 天做到 90 分”，是管理者的日常工作。90 分方案未必就比 70 分方案好，此时，就需要优秀工程师出身的你放弃一些执念了。一旦放松这个念头，你就会发现，完成一项工作，原来还有很多的手段可以选择。
12. 分工不是为了高效，而是为了能容纳更多的人来一起干更大、更复杂的事情，做简单的小事情，是不需要分工的。
13. 凝聚力即是团队协作的基础，又是团队协作的目标。强大的凝聚力，是战斗力强大的团队的重要特征之一。
14. 如果能够带出一个良好的团队，持续不断地把一件又一件的事情做好，才算是一个好的团队管理者。所以，团队产出是否可持续，是考量管理者价值的一个很重要的维度，它体现了这个团队是否健康，是否有耐力和韧劲。其中，耐力让团队走得远，韧劲让团队走得稳。
15. 提升一个团队的耐力和韧劲，有两个要素：梯队培养和团队文化。
16. 一个团队的文化价值观，主要来源于团队负责人或核心管理者。你是什么样的作风和价值观，你团队就会是什么样的，也就是说，你的团队文化和你喜欢什么样的文化关系不大，而和你是什么样的人关系很大。
17. 面对问题，如果你总是抱怨，那么和团队强调积极文化是不会成功的； 面对合作，如果你总是对抗，那么和团队强调紧密协作是不会成功的； 面对工作，如果你总是被动等待，那么和团队强调积极主动是不会成功的； 面对下属，如果你总是漠不关心，那么和团队强调温暖有爱也是不会成功的。
18. 你想打造什么样的团队文化，核心是从你身上的优秀品质中提炼，从而把你优秀的特质放大到整个团队。若你身上没有的特质，那就不适合作为团队的文化价值观去培育。
19. 很多管理者为了激发培养对象的成长动力，常用句式是，“如果你干得好，将会如何如何……” 我的建议是，只明确培养的意向和计划就足够了，最好不要作出成长之外的承诺。
20. 如果你团队有不少资历比你老的员工，或者有一些技术能力比你强的员工，那么我得首先恭喜你。因为这至少说明两个问题：第一，你真的是非常优秀，以至于你能被公司赏识来负责这样一个团队；第二，因为这些老资格和高能力员工的存在，你有机会做出更好的业绩。
21. 既然你被任命为这个团队的负责人，你就是此次时刻带领这个团队最合适的人。
22. 我曾经的上级传授给我一句话，非常有效，相信对于此时的你也一定会有帮助，她对我说：“你也许不是那个最强的人，但是你得相信，你是此时此刻做这事儿最合适的人。”
23. 对于提升员工个人能力来说，最关键的往往不是学习的方法，而是学习的意愿。
24. 主动学习的员工总会是少数派，不只是公司的员工如此，社会生活中的人们亦是如此，所以有人说，“学习是反人性的事情！”
25. 往往因为某个要素不具备就否定所有的可能性。
26. 给员工信心和耐心，允许他们犯错、走弯路。因为很多经验都是踩坑儿踩出来的，所以不能一出问题就劈头盖脸一顿批，甚至是剥夺其做事的机会。
27. 善用威者不轻怒，善用恩者不妄施。
28. 你要做的，不是和团队成员竞争、比较，也不是比团队每个人都强，而是要考虑如何让大家把自己的才智都发挥出来，去达成一个共同的团队目标。总之，你要做的不是管束和控制大家，而是引导和支持大家。
29. 你可能满足不了某员工所期望的工作内容，但是还有行为模式和思维模式方面可以考虑，比如某些人特别爱和人沟通协调，那就让他用沟通讨论的方式去工作；如果有人特别善于独立思考和筹划，那就发挥他的思维优势；有的人行动特别迅速，那就让他去快速启动一项工作。总之，千万别简单认为发挥员工优势，就是鼓励员工 “挑活”；优势是多层次的，所以让员工发挥优势这件事并不困难。
30. 这里我提供一个简单实用的方法，即尽量避免用 “任务性” 的语言，而多使用 “成果性” 的语言。比如你安排一项工作给员工，常见的说法是：“把项目 A 抓紧做一下吧，下周要发布。” 这在员工看起来，他收到了一项任务。但换成 “成果性” 的说法是：“项目 A 会帮我们验证一个结论，决定我们是否在这个方向上持续投入，下周就要做出决策，所以，你看下周能否搞定？” 显然，成果性的说法会让员工更清楚自己工作的价值，完成之后也会很有成就感。
31. 作为管理者，只有言行一致，保持承诺一致性，才能赢得团队的信任。
32. 每一个激励方案都需要去思考和设计，把外驱和内驱结合起来，把长期和短期结合起来，把业务推进和职业幸福集合起来，把个人工作和团队使命结合起来。
33. 大多管理者都能够想到这一点，就是在工作进展过程中要了解进度、评估风险，而不是任务交代完了就撒手不管了。
34. 既然是授权，事中最好不要干涉太多，只做约定好的 check 和支持就好。
35. 一线员工是用工作量来评估价值的，他们只要做出了自己该做的，就是有价值的；而管理者是用团队业绩来评估价值的，即便不是管理者个人的原因，只要结果是团队不出业绩，那么管理者的价值就很难体现。
36. 管理者分配工作的方式是直接交代要做什么，并不会和员工去分享和探讨这项工作的价值，以及对团队和公司意味着什么，所以起不到激励效果。
37. 作为管理者你可以亲身感受得到，总会有一批人因为工作没有价值而离职。他们不是矫情，而是真的需要看到自己给公司和社会带来什么价值。所以，管理者的一项重要修炼，就是去梳理团队的使命和项目的意义。
38. 对于新管理者，你在绩效评估和沟通之前，先审视一下自己的角色：你是这个团队的管理者，是这个团队的负责人，你是有责任来评价团队每个员工的工作表现和业绩的。你是站在团队的视角来看待这个问题，而不是站在任何一个成员的对立面来特别针对他。即便他做的也还不错，但是你如果还是把低绩效的名额给了他，那么你一定是有自己的依据的，所以这个绩效也的确是他应得的，你并不欠他什么。你有管理者的职业素养，有管理者的工作视角，也有令人信服的评价依据，你做出来的就是最公平和最恰当的决策。所以，你需要考虑的事情是，如何和他达成共识，期待并支持他也可以像其他同事一样，变得更加出色。 所以，你的角色不仅仅是一个评判者和告知者，还更是一个辅导者和支持者。
39. 希望我和初级管理者们澄清一个事情，那就是：“上级默认是需要管理者们主动向上沟通和反馈的，而非默认不需要。”
40. 相信你也听过这样一个说法：看似是两个人之间的沟通，其实至少是 “四个人” 之间的对话，哪 “四个人” 呢？也就是：你想表达的、你实际表达的、对方听到的和对方对于听到内容的理解，这其中每一步传递都会造成失真，所以很难领会到对方的真实意图也就情理之中了。
41. 向上沟通、向下沟通和横向沟通构成了管理沟通的主体，所以我把它们称为管理沟通的三大典型场景。
42. 管理者要做出好的业绩，就需要站高一层，站在自己上级的视角来和各个团队协同，以收获共同期待的成果。并且大部分时候，帮合作团队一起做好工作，也是为了自己的业绩，你并不会吃亏。
43. 工作中最好还是以做事为主，少考虑一些个人感受。如果就事论事地去沟通问题，反而会赢得更多合作者的尊重。
44. 不能默认对方一定能收到，而且不能默认对方理解的和你想的是一致的。
45. 对于你关心的问题，一定要去确认清楚，跟进到底，形成沟通闭环。
46. 影响力，是一种不使用强制性力量却能改变别人的看法和行为的能力。一般又分为职权影响力和非职权影响力。
47. 要想提升自己在这个因素上的影响力，不妨去盘点一下别人经常用什么正向的词来形容你，并进一步地把它们打磨得更加鲜明。一旦对方认同你的人品，就有了很好的信任基础。
48. 一旦违背了如下三个批评的原则，“促其改变” 的效果就很难达到： 人是 OK 的原则。即，对事不对人。批评事，不要打击人，更不能给人贴标签。 具体性原则。指出具体哪里做的不好，让对方容易认同。 面向未来的原则。体现负面的暂时性和过去时，并提供改变的 “出口”。
49. 我采取的策略是问自己这两个问题： 如果做，收益是否很大？收益越大，这个事情就越重要。 如果不做，损失是否很大？损失越大，这个事情就越紧急。
50. 可以靠经常能关注到的一个随身物件来提示。比如你的手环、戒指，甚至是手上的一个伤疤，只要你能时不时关注到，就可以。一旦看到这个物件，你就问一下自己 “我是不是在发怒”，这也是一种觉察。 每天写觉察日记，反思自己在情绪管理方面是否有所失误。我身边就有伙伴用这种方式并取得了比较好的效果。 可以和伙伴约定，请他帮忙提醒。一旦他发觉你情绪不对，都可以当场或事后提醒你，来加强觉察。 用你的重要关切来提醒。比如，你可以和你的上级约定，把这个季度的情绪化频次作为一项 KPI 纳入自己的《绩效计划》，从而让你心里总是悬着一根弦来不断提醒自己要注意情绪。细心的你一定发现了，这个方法显然也可以用于帮自己的下级来提升情绪管理的能力。事实上，我就用过，并且取得了很好的效果。
51. 作为管理者我们需要清楚一点，的确会有很多事情是我们掌控之外的，其中不乏不合理或不完善的。对于这样的情况，发泄抱怨则意味着我们内心深处已经对此无能无力了。而实际上，我们也许并不需要完美地解决这个问题，而只需要把一个 40 分的状态改善到 60 分就行了，或者即便没有改善到 60 分，我们也把事情往好的方向上推进了一点点，这也是我们的价值。而抱怨除了把负面情绪感染给团队之外，收获不到任何正向的价值。
52. “这个规定太不合理了，没法遵守！”—— 那么，怎么样就合理了？ “我们在指定日期肯定做不完，没戏！”—— 那么，什么条件满足之后，就能做完呢？或者，认为什么时候能做完？ “这个设计很不合理，完全不考虑用户体验！”—— 那么，怎么样会合理一些呢？ “团队的氛围太差了，郁闷！”—— 那么，怎么做氛围会变好一点点呢？
53. 我会问自己的初心：“你到底想要的是什么？你能为上级、下级和公司带来哪些价值呢？” 通过问自己这个问题，我会秉持一种帮助公司、帮助 CEO 和下属的初衷，把我们的利益全部统一起来，以至于从一开始就不担心上级不信任、下级不服气以及同级排挤的问题。因为，每个人都不会拒绝你给他带来支持和帮助的。
54. 遇到冲突时，跳出自己的角色来判断是非对错，通过审视初心来做决策，很容易让自己充满力量。
55. 不要指望按照头衔去筹划自己的工作，就可以满足上级和公司的期待。
56. 如果你不主动去争取你想要的，你就不得不接受一些你不想要的。
57. 其实，我们对于一个人的评价，从来都是有双重标准的，一个标准是 “及格”，另外一个标准是 “优秀”。所谓 “及格”，就是只要胜任工作的要求就好了；而 “优秀”，除了胜任工作要求，还需要脱颖而出，超出团队普通表现，成为整个团队的核心人物。
58. 罗伯特・迪尔茨的 “NLP 逻辑层次图”，一个人的行为、能力、价值观，都源于一个最根本的认知，就是自我角色的设定。
59. “7-2-1” 法则，即：10% 靠听课和看书自学，20% 靠相互交流和讨论，70% 靠工作实践。
60. 模仿，是人们学习新技能非常重要和常用的方式。当你尝试做管理的时候，也可能在不断模仿那些你认为 “最优秀” 的管理者，并希望像他们一样 “成功”。
61. 对于管理者来说，最大的客户就是上级，因此，价值最大化的核心就是去匹配上级和公司的期待。
62. 这是一种面向客户的视角，即，围绕客户的需要去发挥和提升自己的能力和价值。
63. 这个视角在 “求生存” 的时候特别好用，其逻辑是通过满足别人的期待，来获得自己生存的资源，因此也叫 “生存视角”。
64. 最核心的就是要厘清上级的期待并努力去兑现它，这对于在新的环境中 “生存” 下来是非常有效的，即是这个道理。
65. 职位头衔已经不再体现职责要求，我们需要从固化的职位要求中跳脱出来，从实际的工作需求去定义自己的职责和角色。
66. 我想说的是，无论是主动也好，被动也罢；无论是出于使命、兴趣也好，抑或是欲望、压力也罢，只要是在职场中，就有一个基本法则在发挥作用，那就是 “价值兑现”，即，你能收获多少回馈，取决于你能输出多少价值。这里的回馈不仅是指物质回馈，还包括成长感、成就感、幸福感等精神回馈。所以，无论是什么初衷，以及选择了什么样的职业道路，最终都会落在一个问题上：“我能否最大化地输出自己的价值？”
67. 即便如此，在最后的最后，我还是有两句话要交代：请耐心地给自己成长的时间。这个时代的快节奏带给我们很多的焦虑和不安，仿佛一不小心就会错过什么。其实，职业生涯就像一场 “马拉松”，很漫长，5 年或 10 年可以发生很多事，而你的生涯可能是 20 年、30 年，甚至可以像我一样，贯穿整个余生。在这么漫长的岁月中，肯定有人 “先胖”，有人 “后胖”，不用着急。成功其实很容易，因为所有的失败都不叫 “失败”，都只是 “尚未成功” 而已；只要有一次 “成功” 可以让你足慰平生，你就是个 “成功者”。互联网拉平了世界，你随时都有时间和机会去赢得自己的成功，或早或晚。用自己最擅长的姿势，开创属于自己的发展之路。不是前人走过的路才叫路，也没有什么规定好的 “管理之路” 是你必须要走的。因此，也就不存在所谓的 “弯路”，所有你走过的路都是你的成长之路，这条路是你自己开创的。事实上，所有的路上都有一条法则是奏效的，那就是 “价值兑换”，所以，做技术不重要，做管理也不重要，把技术和管理当成你职业的两条腿，在职场中输出自己最大的价值，才是最好的，才真正属于你。切记，不要被别人的路限制住，也不要被某个职位限制住，没有哪个职位可以定义你的职业发展。

如何提升项目管理能力？这个问题覆盖面很广，其实，很多时候方法都是通用的，这方面和学一门技术所运用的技巧是一样的，可以先实践后学习，以终为始，先解决当前遇到的问题，解决了之后再总结，久而久之就像涂鸦一样，慢慢这一块那一块也会涂完，而不是一开始就按顺序涂完整幅画。

在做事情的时候，有些知识不是立马就会用到的，学了之后没有应用，很快就会忘记，而且没有立马实践意味着没有产出，你没看到有什么显著的成果，就会打击积极性，便不利于你后续的学习。

其实，这个思路无形之中刚好契合了毛泽东《实践论》所说的，“通过实践而发现真理，又通过实践而证实真理和发展真理。从感性认识而能动地发展到理性认识，又从理性认识而能动地指导革命实践，改造主观世界和客观世界。实践、认识、再实践、再认识，这种形式，循环往复以至无穷，而实践和认识之每一循环的内容，都比较地进到了高一级的程度。这就是辩证唯物论的全部认识论，这就是辩证唯物论的知行统一观。”

所以，这也是我们项目计划为什么需要有复盘会议的原因，实践、认识、再实践、再认识，如此反复，不断地向真理靠近。

市面上相关项目管理的书籍很多，但是大部分都是一些方法技巧，我始终认为方法固然很重要，但是意识才是最核心的那部分，只有不断修炼意识层面，哪怕方法暂时掌握不到位，日积月累，终有一日也会有所成就。

所以，项目管理的书籍，我就只推荐一本，来自刘建国的《知行：技术人的管理之路》，主要内容就是程序员如何走上管理、为什么要做管理、怎么做好管理，全方位剖析会遇到的问题怎么解决等等，我觉得是很实用的一本书。

其他的，就是一些看起来好像和项目管理一点关系都没有，实际上关联密切的书籍，首先就是《实践论》，它是如此的重要，以致我不得不多次提及，除了这本书之外，还推荐《非暴力沟通》和《精力管理》，附录会有一些摘要，可以简单看一下，基本上可以总结为四个方面，覆盖项目管理所需的各项能力：方法、意识、沟通、身体。

其中，身体其实才是最重要的，它是一座高楼的地基。地基的好坏，直接影响到上层的建设。在项目管理上也是如此，它会关系到你能成长到哪一个阶段。

因为对于项目负责人而言，无论是手头上的开发任务，还是面对与多个部门的沟通协作，以及处理诸多繁琐事务，外加达成目标的压力，无不耗费巨大的精力和心力。

“身体是革命的本钱”，这句话大家都听过，所言非虚，在此就不再赘述了。

至此，从 2022 年 8 月开始编写这些内容，从开发人员到项目负责人再到项目总负责人，对遇到的各类项目问题都进行了梳理，并以个人浅见提供了一些解决方案，总结为一句话就是：结果导向，修己安人。

这个系列，基本上就告一段落了，如果后面有一些心得还是会持续更新的。

1. 前言

部门项目文档是使用 ShowDoc 进行管理的，为了技术文档的整洁以及易于阅读，根据当前实际情况，整理了一些文档编写规范。

标准的文档应包括 TOC 标题目录、说明栏、标题、子标题（如果需要）、内容，如下所示：

2. 标题

标题总共有 3 种样式，可以选择任意一种，视具体情况而定，但是最好不要混用。

# 一、样式1
# 1、样式2
# 1. 样式3

预览效果，如下所示：

如果只有一级标题，3 种样式都可以使用，如果有子标题，建议使用样式3。

# 1. 这是一级标题
## 1.1 这是二级标题
### 1.1.1 这是三级标题
### 1.1.2 这是三级标题
## 1.2 这是二级标题
## 1.3 这是二级标题
# 2. 这是一级标题

文档内容中显示的效果，如下所示：

文档大纲显示的目录样式，如下所示：

3. 代码块

Markdown 语法支持代码格式化，在文档中显示更为美观，方式是除了操作栏上面的快捷按钮 ，也可以头尾加上```实现，我们通常使用这个功能主要是为了在文档中贴上代码，但也会在其他情况下使用，比如一些命令或者很长的 Bug 报错信息。

1. 代码

const CounterApp = {
  data() {
    return {
      counter: 0
    }
  },
  mounted() {
    setInterval(() => {
      this.counter++
    }, 1000)
  }
}

2. 命令

npm install
npm run dev

3. Bug 报错信息

Uncaught TypeError: Cannot read property 'toggleRowSelection' of undefined

4. 文本高亮

文本高亮通常在输入英文单词时使用，一来为了强调重点，二来是为了界面美观。

1. 实现方式

我们创建了一份完整的构建 `Vue` 服务端渲染应用的指南。这份指南非常深入，适合已经熟悉 `Vue` 、 `webpack` 和 `Node.js` 开发的开发者阅读。请移步 `ssr.vuejs.org` 。

2. 实现效果

我们创建了一份完整的构建 Vue 服务端渲染应用的指南。这份指南非常深入，适合已经熟悉 Vue 、 webpack 和 Node.js 开发的开发者阅读。请移步 ssr.vuejs.org 。

5. 超链接

超链接的使用方式，方括号里是超链接显示的文本内容，圆括号是超链接具体的网址。

1. 实现方式

[ECMAScript 6](https://es6.ruanyifeng.com/)

2. 实现效果

ECMAScript 6

6. 插入图片

插入图片的使用方式和超链接方式很相似，只是在前面多个一个感叹号 ! 而已。但这种不是最便捷的，如果是在 ShowDoc 上面使用，直接复制图片，在文档中粘贴即可，会自动上传并回显图片的路径。

7. 应用模板

1. 解决方案文档，可以参照《Web应用实现在手机端访问和使用方案》
2. 技术笔记文档，可以参照《Sentry的基本使用》、《Linux与Windows跨平台文件共享实现》

在前面《25 - 项目需求如何有效梳理》文章中，已经说明过项目需求应如何依据实际情况进行梳理。不过，那是针对单个项目的情况。

倘若项目负责人负责多个项目，且这些项目之间存在一定关联，例如同属某个具体行业，此时，项目需求梳理就会面临问题。

该项目负责人所在团队有 10 人，负责项目 A、B 两个项目，这就需要两份需求文档、两个项目计划以及两个版本发布时间。

1. 项目 A 的需求文档和项目计划

2. 项目 B 的需求文档和项目计划

按理来说，这种安排并没有什么问题。然而，由于这两个项目均由这 10 个人负责，存在人员复用的情况，项目 A 的需求和计划一旦发生变化，就会对项目 B 的需求和计划制定产生影响。

对于项目负责人而言，项目管理的难度显著增加。一方面，需要在不同的项目文档里整理需求；另一方面，还需在不同项目中修改计划。

此外，还有两个版本发布时间，原本 10 个人负责的工作，却出现两个目标时间节点，无论是目标导向还是上下级沟通，都变得很复杂。

如何解决这一问题呢？

一方面要简化项目负责人对多个项目的管理工作，另一方面要让这 10 个项目成员更具目标感和凝聚力，设定唯一目标，即 10 个人要在规定的时间节点前完成安排的任务。

鉴于项目 A 和项目 B 同属一个行业，可以把它们转为子项目，重新创建一个总项目，下设子项目 A 和子项目 B，如此一来，就只需一份需求文档、一个项目计划和一个版本发布时间。

但这里存在一个问题，总项目的版本号只是用来做需求规划的，项目 A、项目 B 都有各自独立的版本号，并没有办法沿用总项目的版本号。那么，如何将它们与需求文档关联起来，以便追溯呢？

例如，项目 A 线上出现了 Bug，需要查看这个版本更新了哪些内容，才能判断 Bug 的影响范围。

假设总项目需求文档是 V1.0，而项目 A 当前版本是 V2.1，怎么在需求文档中查看项目 A 的 V2.1 迭代了哪些功能呢？

我能想到的是，只需要在总项目每个版本的需求文档里，在项目 A 旁标记当前版本号，并评估这些迭代功能是否需要升版本号即可。

如果要在该文档系统中列出项目 A 某个版本的全部需求（比如 V2.1 ），可以在搜索框使用【项目 A `2.1`】进行搜索，这样相关内容就能全部罗列出来。

最近，我发现有些事情安排下去后，如果我这边没有跟进到位，过一段时间，这件事情可能就突然没了下文。

起因是之前我和项目负责人沟通一件事，有个项目的原型和已有项目基本没什么差别，于是探讨如何复用和设计，以实现前端组件复用，减少工作量。

当时，我们在座位上沟通，也说好方案大概完成的时间。然而，过了一两周，我看项目需求文档时，发现上面压根没记录这件事。和他沟通后，他才又想起来好像有这么回事。

乍听之下，肯定觉得这是项目负责人的问题。但深入思考后，我才意识到，很可能我这边才是最大的问题。

为什么这么说呢？

因为我习惯在滴答清单上列出每天要做的任务，每做完一条就勾选掉。这本身没什么问题，问题在于对于安排型任务，我也是如此处理。

通常我会和项目负责人在座位上沟通，把事情的背景、要做什么、为什么这样做以及要达成什么结果都说明清楚，然后给出大概的完成时间。

之后，我就在滴答清单上把这条任务勾掉，觉得事情已经安排下去，就算做完了。

但这个事情进入下一个环节，会出现哪些情况呢？

如果项目负责人本身具备及时反馈的意识，那还好说。但要是项目负责人不重视，或者被其他事情干扰、疏忽了，而我这边又没有及时跟进，过了一两周甚至更久，才突然想起好像有这么一件事，那时可就晚了。

这个时候，我能去问责项目负责人吗？

其实也不是不行，但对方也有理由，这一两周也没闲着，只是事情太多太杂，忘记了而已。

通常都是这类理由，所以问责也于事无补，反正也改变不了现在这个结果。因此，没必要问责，还是要从最本质的问题出发，找到最根本的原因，再通过一些策略彻底解决这个问题。

首先，从我自身角度来说，就是要跟进到位。那怎么解决任务跟进的问题呢？

我想到一个方案，就是在企业微信上创建一个任务清单表格，把需求提出方、提出时间、任务内容、安排时间、计划完成时间、验收情况、进度情况都填写清楚，并实时更新。

每周都要梳理一遍上面的任务情况，再结合每两周一次的项目进度会议，及时更新任务进度。

如果出现任何问题，比如事情被遗忘、遇到困难、无法推进等等，及时沟通解决。等事情验收完成后，再在任务清单上标记已完成。我觉得这样就能解决上述问题。

总的来说，安排任务时，不能只是把任务分配下去就高枕无忧了。虽然每一条任务的发布和验收形成闭环是很理想的状态，但在这个过程中，及时跟进也至关重要。

1. 前言

项目总负责人究竟应该在什么时候介入项目呢？

这个问题的本质其实是在深入探讨，何时需要项目总负责人直接替代项目负责人做出关键决策，或者直接介入并解决项目推进过程中遇到的具体问题。

下面以项目负责人为张三、项目总负责人为王七的实际案例进行详细说明。

2. 事情起因

曾经有一次，客户在项目沟通群里反馈了一个问题，明确提到平台的地图功能没有正常显示出来。

当时正值周六，按照常规工作安排，大家都没有在公司上班，因此项目负责人张三可能没有及时留意到沟通群里的消息，也就没有在第一时间回复客户。

后来，有看到消息的同事将客户反馈的问题转发到了部门群，这样整个部门的人员都能看到客户的反馈内容了。

可即便如此，张三仍然没有在部门群里对客户的问题进行回复。

3. 张三为什么没有及时回复

事后了解到，他认为地图功能并不是由自己负责的项目团队开发的，而是属于其他项目团队的功能，自己负责的项目仅仅是在使用这个功能模块而已。

也就是说，他在内心将自己定位为功能使用方，所以觉得不应该由自己来回复客户，而应该由负责开发地图功能的相关人员来处理。

4. 王七为什么没有及时回复

事实上，项目总负责人王七在周六当天也看到了客户在沟通群里反馈的消息，但他同样没有及时回复客户，就这样任由问题持续发酵。

王七当时的想法是等着张三去处理这个问题 —— 因为在他看来，这是项目负责人职责范围内的事情。如果王七事事都介入处理，就相当于虽然已经对张三进行了授权，自己却又在一旁指手画脚，这样的做法显得有些奇怪。

不过事后回头来看，王七在这件事情上确实存在考虑不周全的问题，没有全面深入地看到问题的核心本质。

5. 从客户的视角看问题

换位思考，假设你自己就是那位客户，在沟通群里反馈问题之后过了很长时间都没有人回复，会作何感想呢？

而且需要注意的是，这次反馈问题的渠道不是工单渠道，而是群内的实时交流渠道，在这种情况下，客户即便不生气，心里也会十分不爽吧。

毕竟，客户在使用功能时遇到了问题，急需解决以便正常使用，而我们却没有给予足够的重视。

6. 张三的问题与改进

张三的做法乍一看似乎有一定的合理性，但他根本没有想明白关键问题所在 —— 对外和对内处理问题的方式是截然不同的。

在公司或者部门内部，上面提到的那种想法虽然存在一定问题，但还不是特别严重。

因为无论对外还是对内，项目负责人的职责本来就包括对项目整体的管理，一旦出现问题，第一责任人肯定还是要找到项目负责人，怎么会有出现问题先去找具体功能负责人的道理呢？

正确的处理流程应该是：客户的反馈先到达张三这里，然后由张三再去找对应的同事沟通并解决问题。在对外沟通时，个人所代表的不再是自己，而是整个公司。

因此，每一句话、每一个行为都需要用公司的标准来严格要求自己。

就算明知道问题属于其他项目组甚至其他部门，如果该部门的相关人员不在这个沟通群里，也应该先回复客户，比如可以说 “我先了解一下具体是什么问题”。

然后再去寻找对应的同事，不管是部门内部的还是其他部门的，都要积极去协商协调，最终把问题解决掉。

客户不会去关注你是哪个部门的，他们只知道你是这家公司的员工。

不管在公司内部具体是由谁负责这件事情，客户只需要你帮忙解决他们遇到的问题，仅此而已。

7. 王七的问题与改进

当客户反馈问题之后，已经过去了五六个小时，张三还是没有回复客户。

这个时候，王七可能觉得这是张三的职责所在，认为张三需要经历这样的事情，而这也正是导致王七没有直接介入沟通的原因，差不多就是想让张三通过这次犯错来积累工作经验。

不过，王七也犯了同样的错误：从想法本身来看没有问题，把全部职责交给张三，张三就应该承担起相应的责任。

但关键在于**要弄清楚是什么事情，不可能什么事情都能用来攒经验的。**就拿上面这件事情来说，客诉问题，一直是重中之重的事情，不可掉以轻心。

正如前面所提到的，客户不会去关心你公司内部的分工情况，他们只知道你是这家公司的员工，你在客户面前的任何表现，都直接关系到客户对这家公司的整体印象。

所以在这种情况下，当张三没有回复客户时，如果过了一两个小时，张三仍然没有回复，那么王七自己就需要直接介入，回复客户，并跟进这个事情，弄清楚到底是什么原因导致了这个问题，确保问题能有效解决。

至于要问责或弄清楚张三为什么没有及时回复客户等事情，可以等事情解决了之后再说，现在首要解决的是客户遇到的问题，一切以客户为先。

在项目管理中，我们常会制定一些规章制度用以约束行为，从而有效推进项目。但现实中，无论是开会沟通通知还是口头传达的要求，往往只能坚持一段时间，过后便会恢复原状。

正如那句话说的：“你无法要求别人做什么，除非他自己愿意去做。”

工作中亦是如此，即便强调过每天下班前要在项目任务系统填写当天日志，对方也只能坚持一阵子，时间一长便又故态复萌。

同理，项目计划需要实时更新，以避免信息同步不及时影响后续功能开发或决策制定，但很多人依旧未能遵守，大多是坚持一段时间后便打回原形。

这种现象很难单纯用对错来评判。回归本质，我们的核心目的在于：将所有问题公开化，通过即时沟通制定规章制度，确保各项目有效推进，避免延期，最终达成项目目标。

那么，该如何解决这些问题呢？发脾气或许能起到一定作用，但也要看对象，而且大多数情况下并不推荐。更合适的做法是找个会议室私下沟通清楚，避免当众批评，以免引发逆反心理，得不偿失。

因此，我们需要探寻有效的解决方法。就以任务日志缺填这一问题为例（实际情况中存在的问题远不止于此，此处仅作举例说明），可以采取以下措施：

首先，将规章制度以严谨的文字梳理成文档，并建立惩罚机制。例如，约定任务日志缺填每月不得超过 3 次，否则需赞助50 块钱到部门经费 ，同时，项目总负责人自己也需赞助 50 块钱。

这样做的目的在于：一方面，项目总负责人作为全部项目首要责任人，理应对项目中出现的任务问题负责；另一方面，避免将自己置于项目成员的对立面，减少摩擦，让大家感受到你与他们是站在同一阵线，制定这些规定只是为了更好地进行项目管理，而不是针对谁。

在落实过程中，月底统计时如果发现有人当月缺填超过 3 次，就需要当面沟通了解情况，探究缺填的原因。

沟通时要因人而异，大多数情况下，只要解释合理（无论真假），都按真实情况处理，并明确告知此次可以通融，但下个月如果再出现类似情况，将直接收取 50 块钱，不再给予额外机会。

因为，我们的目的并不是为了这 50 块钱，所以，给对方一次改正的机会，让对方感受到被尊重，后续会更愿意、自觉地遵守这些规章制度。

但凡事也有例外的，虽然应该不多。如果下个月对方依旧出现，任务日志缺填超过 3 次以上的情况，该如何处理？

这需要根据具体原因来判断：如果理由充分、合情合理，可暂时不收取费用；如果理由并不充分，则直接收取费用，并与对方一同扫码将费用赞助至部门经费，同时在部门群内公开，以消除大家对项目总负责人是否也一起赞助 50 块钱了的疑虑。

如果下个月仍然出现缺填且理由不充分，在要求对方赞助 50 块时态度还很恶劣，那么，就需要明确告诉对方：制定项目规章制度的目的是什么？任务日志的作用是什么 —— 让项目负责人能够实时了解每个人的工作情况、任务进度，以及是否存在影响项目推进的问题，以便及时采取其他方案。

如果对方依旧不服从，就需要强硬处理，因为规章制度刚落实时如果不及时拔除这根钉子，后续将难以服众。

总的来说，项目总负责人应以身作则，制定合理的规章制度，并通过实际沟通和客观判断，赢得大家的信任，促使大家养成良好习惯。

实际上，设置 50 块钱赞助部门经费的规定，重点并非在于金额多少，而是形成一种无形的约束。

理想状态下，一年可能就收个两三次，大概就 300 块钱左右。毕竟，钱好像不是很多，但是要让大家白白支出这笔钱，肯定觉得太亏了。相信这样应该能有效解决一些项目管理中遇到的问题。

我想起之前看《铁齿铜牙纪晓岚 4》时，有这样一段剧情：乾隆打算在凌烟阁挂上二十四幅功臣图，众人就谁排第一产生争执。乾隆使计让杜小月说出，若让纪晓岚进入军机部，也能像和珅一样出色，所以不同意和珅比纪晓岚厉害。乾隆顺水推舟，安排了角色互换的游戏，让纪晓岚去军机部，和珅去修四库全书。结果两人在处理不同部门事务时，因为缺乏经验，导致处处受阻，只能私下碰头商讨对策。

剧中，纪晓岚说皇上让自己查张廷玉的几块银两用在何处，觉得这点小事不必斤斤计较。和珅则表示，皇上安排的事情，最怕的不是大事，因为大事有章法可循，按章办理即可；最怕的是小事，没有先例，只能琢磨心思、见招拆招，所以对皇上安排的小事，要特别小心。

还有曾仕强先生在一期节目中说道：“如果老板让我去死，我到底去不去呢？” 他给出的回答是，先应承 “好的，老板”，然后自己不去就行了嘛。

从上述事例中，我们能得到什么启发呢？一方面要明白领导的用意，另一方面是不要直接拒绝领导。关键在于不要直接拒绝，而非完全不能拒绝。

其实核心还是 “先肯定后否决” 的策略，这和我们平时常用的标准反驳句式如出一辙 ——“你说的确实有道理，但是……”

如果是我，我会先一口答应下来，尤其是在多人场合。如果只有自己和领导两人沟通，拒绝的影响相对小一些；然而在多人场合直接拒绝，领导可能会觉得没面子。要是领导心眼小、心胸狭窄，日后难免会给你穿小鞋。所以，先痛快地答应 “好的”，然后过半小时左右去找领导，解释目前手头上的任务太多，若新任务时间紧迫，是否可以将其他任务暂缓？如果不能暂缓，多项任务同时推进实在难以完成，恐怕最后会顾此失彼。

这样做既能表明自己有积极完成任务的态度，又能说明客观条件不允许。领导的回应通常有两种：要么让你先暂缓其他任务，要么让你推迟新任务的完成时间，问题往往就能迎刃而解。当然，如果领导听不进建议，仍然一意孤行，直接干他就是了（哈哈哈，你敢信，我就敢说）。

由此可以延伸思考，领导安排任务时，必然有自己的考量。一般有两种情况：一是从当时的实际情况出发，认为由你负责更为合适；二是借此进行测试。培养一个人并非突然委以重任或提拔，而是通过日常工作中的突然考验，时不时来这么一下，看你瞬间的反应，从多个维度综合评估你是否值得信任、能否为我所用。

可能有人会说，公司的组织架构、管理方式和领导的性格等各方面情况都不一样，但我觉得核心逻辑是一样的 —— 先肯定后否决，只是在执行方式上，需根据实际情况调整。比如公司是扁平化管理，上下级没有明显的严格层级划分，而你对自己负责的项目情况又特别清楚，领导安排新的任务时，你完全可以直接当面解释目前的情况，说明加上新任务可能会导致的问题，而不必非要一口答应，等到半个小时之后才去找领导解释，那样做事就太死板了。

不过话说回来，工作和生活本就是一体的，但又不尽相同，人在上面的行事风格差异很大。工作上的这种测试是可以接受的，毕竟只是工作。但生活中类似的测试，真的不能接受，因为很没意思。

好像没有什么问题？其实，真正的产品需求文档，也就是俗称的 PRD 文档，是很规范的，就不说什么形式上的问题，比如文档信息、版本更新历史、名词解释等等。就光内容的要求，就很精细。就拿 APP 的 PRD 文档来说，是需要把原型的图片贴到文档里的，然后要对每个功能和交互进行说明，比如点击这个按钮，会出现什么弹窗，弹窗的布局是什么样子的，内容是什么，文本是什么颜色的，是使用什么字体的等等。比如，XiaoPiu 的官方示例：

这样详细的好处是，在之前的文章《16 - 项目的任务质量如何保证》中已经有过类似的叙述，那就是避免需求边界不清晰，导致后续的返工。

但是，对于我们现阶段而言，项目的需求应该怎么梳理呢？这个怎么说呢？如果是在大公司，分工比较明确，那么这样做无可厚非，精益求精未尝不可，但是，如果是中小型公司，或者只是一个部门，要自负盈亏，考虑到实际工作中的产出，或者说性价比，那么就感觉有点过度精细了，说好听点，是追求极致与差不多这个度怎么把控的问题，说直白点，是怎么利益最大化的问题。

所以，从实际情况出发，虽然 PRD 文档规范化，有诸多好处，但是投入产出比显然很低的，因为没有那么多人手把这个需求做到这么精细的程度，加上平时沟通也很及时，有什么问题及时沟通处理就行，而且，PRD 文档规范化还有一个重要的目的是，为了和其他部门或其他公司进行沟通交流使用的。

可是，只是我们部门内部使用的需求文档，就没必要这么精细了，只要能做好这件事情就行。但是，虽然是一句话需求，但还是有优化空间的，我们做不到整个文档规范化，但对这一句话的需求，可以规范化。

上面说的是 PRD 文档的规范问题，但其实，对于需求的整理，可以遵循需求的 INVEST 原则。需求的 INVEST 原则最早由 极限编程（XP）的倡导者 Bill Wake 提出。这一原则旨在指导敏捷开发中用户故事的拆分与编写，帮助团队更高效地管理需求，确保故事的可交付性和价值性。

INVEST 原则主要用于优化用户故事的描述，使其满足以下特性：

1. 独立性（Independent）：故事之间减少依赖，便于单独开发和测试。

2. 可协商性（Negotiable）：避免过早锁定细节，鼓励通过沟通逐步完善需求。

3. 有价值（Valuable）：每个故事必须为用户或客户提供明确价值，避免资源浪费。

4. 可估算（Estimable）：团队能评估工作量以制定迭代计划。

5. 短小（Small） ：单个故事工作量控制在几天内，以降低风险。

6. 可测试（Testable）：明确验收标准，确保功能可验证。

结合我们部门自身情况，需求来源其实很多的，所以可分为两种，一种是部门外，另一种是部门内，如果是部门外，需要加上角色；如果是部门内，角色可不加。可以简化为，是谁？要做什么？为什么？

这里就以设备管理功能，写一个示例参考：

深圳客户希望能看到自己有多少台设备，方便统计和日常维护。

1. 是谁：深圳客户
2. 要做什么：看到自己有多少台设备
3. 为什么：方便统计和日常维护

通过这种方式，既能保证需求的清晰性和可操作性，又能在现有资源条件下实现需求梳理的优化，为项目的顺利推进奠定基础。

项目发起测试时，首先要在 OA 填写软件测试申请单。填好之后，由项目负责人准备当前版本的测试用例，交给测试部门，同时沟通确定测试周期，之后才正式开始项目功能测试。

2. 线上版本出现明显的问题

最近有个线上平台，客户反馈说平台里有个列表的按钮怎么点都没反应，而且弹窗的样式也错乱了。可这个版本明明是测试通过才上线的，这就说明测试环节肯定出问题了。

3. 问题产生的原因分析

为什么会出现这种情况呢？

主要还是测试流程有漏洞。因为项目负责人提供给测试部门的测试用例，只包含了当前迭代的需求。所以测试的时候，测试人员就只测了新增加的功能，而出问题的那个功能是旧功能，因为不在迭代的需求范围内，所以压根就没测。

按理说，这个旧功能没做任何改动，怎么会出问题呢？

后来发现，在开发当前迭代需求的时候，有可能开发人员不小心动到了这个功能的代码，或者是在修复其他小问题的时候影响到了它。

还有可能是当前迭代需求其实和这个功能是有关联的，但我们只关注了迭代功能有没有完成，根本没管那些关联功能，这才导致问题在实际使用的时候暴露出来。

4. 测试流程改进办法

为了解决测试覆盖不全，又不想每一轮都全部测一遍浪费时间的问题，我们优化了测试流程：

项目负责人这边要提供完整的测试用例，还要标注清楚当前版本里哪些功能必须测试，哪些不用测试。

测试人员分三轮进行测试：

第一轮，不管标注的是不是必须测试，把平台所有功能的测试用例都过一遍；

第二轮，专门验证已经修复的 Bug，同时再把那些必须测的功能测一遍；

第三轮，等所有 Bug 都修好了，确定没什么大问题了，再把平台全部功能的测试用例再过一遍。

这样一来，既能保证测试全面，又不会做太多无用功。

项目当前版本（假设为1.0）开发完成之后，会提交给测试组进行测试，然后，开始进行下一个版本（假设为2.0）的研发工作。

但是，测试组测试周期可能要一两个月，期间会不断的反馈 Bug 到系统里，等项目当前版本（1.0） Bug 修复完成之后，再进行下一轮的测试。

这时，项目新的版本（2.0）功能开发进行中，每个人都已经有自己的开发任务了，时间也排好了，应该怎么安排？

还有，在 A 功能模块上修复 Bug，而同时又在 A 功能模块上开发新的功能，代码合并可能会冲突等等问题怎么处理？

2. 权衡任务调整的利弊

因为测试反馈 Bug 数量不是一个可控的事情，有时第一轮测试完成，都没几个 Bug，有时第一轮测试就反馈好几十个 Bug，完全可以衍生新的任务，评估个两三天去处理。

所以，如果你打算，暂停或推迟当前版本（2.0）的开发任务，而去执行修复上个版本（1.0）的 Bug 的任务，很有可能收益不大，因为可能都没有几个 Bug 让你修复。

但是，如果你完全对第一轮反馈的 Bug 不管不顾，又会影响到测试组的测试进度。

3. 基于测试周期的任务调整

上面说的，虽然测试反馈 Bug 的个数是不可控的，但庆幸的是，测试周期是明确的，比如第一轮具体是什么时间段，第二轮又是什么时间段，这些都是前期沟通好的，虽然偶有变数，但是大体上问题不大。

在这个基础之下，项目负责人就要根据测试轮次结束的时间，对当前反馈的 Bug 情况，进行任务上面的调整，比如第一轮测试反馈了 50 个 Bug，然后按功能模块划分清楚，以及哪些功能模块对应的负责人是谁，修复这些 Bug 需要多少工作量，新增一条修复 Bug 的任务在项目当前版本（2.0）计划中。

4. 测试环节的漏洞

但是，如果 Bug 特别多，花费了大量的时间，甚至影响到了当前版本（2.0）的开发进度怎么办？

这个时候，是否需要延长修复 Bug 的任务呢？

缩短开发的任务时间呢？

加加班？

这些方式可以解决这个问题，但是，治标不治本。

因为在这个功能到测试组介入参与测试时，其实，已经有过三个环节，对功能进行测试了。

一个是功能开发人员自测，编写测试用例，然后对开发的功能点一一测试。

另一个是功能开发任务验收，这个验收的工作就是根据功能开发人员提供的测试用例，验收人自行跑一下这个测试用例，看下有没有什么问题。

最后一个是项目负责人内测，就是项目当前版本（1.0）结束，要给测试组提测之前，把全部功能都测试一遍。

上面这三个环节，为什么不能发现和解决掉一些很明显的 Bug，而一定要测试组测试时才发现？

5. 优化测试流程

理想状态下，每一轮测试都不应反馈那么多 Bug 的，然后需要排两三天的时间去处理的，通过一两天差不多了，甚至在开发当前功能时抽个一天的时间解决掉就行。

所以，回答项目开发中应什么时候去修复测试反馈的 Bug 这个问题，那就是做好下面的流程：

1. 功能开发人员自测
2. 功能开发任务验收
3. 项目负责人内测

然后，等测试哪一天测试完成之后，评估一下反馈的 Bug 数量，补充一条修复 Bug 任务，同时，变更当前的开发任务时间。

理论上来说，这条修复 Bug 的任务时间也就一天左右，最多也就两天了，除非出现突发的不可控因素。

如果反馈的 Bug 特别多，需要的修复时间也很长，意味着上面三个环节压根没有做到位。

6. 代码合并问题的处理

这个问题，其实可以等版本 1.0 的测试全部通过，发布至线上环境之后，再把 1.0 的代码合并到 2.0 的分支（即当前的 `Dev 分支），解决掉冲突就可以了。

7. 整体流程

测试人员反馈的 Bug 一般都记录在 Bug 系统里进行管理，所以问题不大。发在沟通群里的，多个人看到了之后，会给功能负责人带来一定的约束力，通常问题也不大。

最大的问题是那种私底下一对一沟通反馈的 Bug。比如，项目负责人张三给项目成员李四发消息，反馈了一个功能上面的 Bug ，李四说记下来了。

如果李四解决了并反馈给张三，那还好；但如果李四不反馈，张三就不知道这个 Bug 的状态了。除非张三主动去问，否则谁也不知道这个 Bug 是否已经解决。

写到这里，我不由得感叹，要做好一件事情，各方面的协作都要到位。**任何一个流程没有有效执行，都会导致后续的环节发生变化，并需及时提供相应的对策，从而使简单的问题复杂化。**所以，制定清晰的流程并传达到位，是多么的重要。

首先，在推动从流程入手解决这个问题之前，要先分析一下：

为什么反馈 Bug 时要私底下一对一沟通呢？

为什么不直接发到沟通群里呢？

原因很简单，大家都是同事，低头不见抬头见。发现对方开发的功能出现了 Bug，虽然不是什么大事，毕竟，谁都不能保证自己开发的功能，一个 Bug 都没有。只是，发到项目沟通群里，当众指出别人的问题，不管对方心胸多么宽广，总会不高兴的，自然而然，都会觉得没必要做这种不讨好的事情，反正能解决掉这个 Bug 就行，是否是私底下一对一沟通反馈，没有那么重要。

我觉得换位思考，上面这样的原因是可以接受的，但是完全依赖人，而不是依赖流程，是不能彻底解决掉问题的。

所以，我们可以这样规定：

在 Bug 系统上进行管理，为项目创建一个对应的版本。在这个版本的开发时间段内，遇到的所有问题，以及别人反馈的 Bug，都记录在这个上面，而不是私下沟通。这样虽然是公开的，但是不去看就不会知道，不像在项目沟通群里，当众处刑。

因为 Bug 系统是和邮件关联的。比如你是项目负责人张三，在验收李四开发的一个功能时，发现了问题123，那么就在 Bug 系统记录，并分配给李四。

等李四解决掉 Bug 之后，就修改这个 Bug 的状态为 “已解决”，张三就知道 Bug 已经解决了，然后再去跟进，这样就形成了闭环。

那如果张三还是不把 Bug 记录到 Bug 系统，或者李四解决了 Bug 但没有在 Bug 系统上修改状态呢？

那就需要及时介入沟通了，不能听之任之。抓而不紧，等于不抓，出现问题要第一时间解决，表明你对这件事情很重视。

否则，大家都觉得可有可无，慢慢就变成做做样子应付了事，那通过流程化解决对 Bug 进行有效管理的初衷就无法达成了。

复盘会议通常是在项目某个版本完成开发并正式上线之后才召开的，但复盘工作其实并不是等到最后才开始的。项目负责人应该在项目前期就开始着手准备，在项目推进的过程中，持续记录各种各样的问题，这样在会议上就能有更充分的内容来进行讨论和总结经验。

当项目负责人要召开项目复盘会议的时候，需要把项目相关人员都通知到位，比如产品、后端、前端和测试等等。然后预订一个会议室，在群里发布会议通知，到时候按计划如期进行。

这个复盘会议对于项目负责人来说，一方面能够吸取项目管理方面的经验，另一方面也有助于提升项目团队的凝聚力。

在会议上，把项目开发过程中哪些是做得好的，哪些是做得不好的，依次都列出来，让大家一起讨论一下，有一个总结与反思的过程，也是一个一起分享成果的过程。

对于做得好的地方，那肯定是要表扬的；对于做得不好的地方，大家就再接再厉。

复盘会议上讨论的内容，基本上涵盖了项目版本周期的方方面面，目前主要总结了以下几点。

2. 任务完成情况

这个版本的项目任务计划制定得是否合理？哪些任务有多次变更的？已过期的任务具体原因又是什么？

3. 测试反馈BUG问题

把这个版本测试提出的 Bug 整理和归纳一下，分析一下具体的情况。哪些 Bug 是完全可以通过提前规划来避免的呢？比如输入框的校验，基本都没有，功能开发的时候，只是保证能用就行了，功能的边界完全没有自测。类似这种问题，就可以在会上进行讨论，然后达成共识，加入到开发规范里，后续就可以规避类似的问题了。

4. 会议记录

我们每次开会都有会议记录文档，然后会把反馈的问题都记录下来。这些文档在复盘的时候就会起到作用，可以从中吸取经验。看看有哪些问题是第一次出现的，那有没有对策可以避免再次出现呢？这些都是可以在复盘阶段解决的。

5. 技术笔记

技术笔记是开发过程中对功能难点进行总结的文档。遇到哪些功能解决不了的？后来又是怎么解决的？都可以在复盘会议上进行分享。

6. 群内反馈的问题

群里反馈的问题可不止是项目讨论群里的，还有其他客户群里的。客户反馈了哪些问题，又提出了哪些需求？后续我们的工作要怎么规划？

7. 总结

复盘的目的不是对过去的问责，而是对过去的反思和总结，并着眼于未来如何改善。

项目这个版本的功能已经完成了，事已至此，没必要深究谁没做好，然后让对方有心理负担。我们的目的一向是解决问题，这次没做好，下次做好不就行了，谁都有没做好的时候。

更重要的是，今天比昨天做好一点。更重要的是，着眼于未来，这个项目下一个版本能不能比上个版本做得更好一点？

我们统一每周周二开项目进度会议，每个项目的情况都不一样，有些问题就是需要讨论很久，所以时间是无法评估的。

我们不可能要求什么时间内一定要开完项目进度会议，只能说项目负责人需要知道项目进度会议的流程，并且逐渐按照流程执行。

一般情况下，每周开一次项目进度会议，任务通常不会太多，通常一次会议所需时间应该不会太长，但是我们把项目会议流程梳理之后就会发现，时间是大大超出我们预期的，如下所示：

• 项目进度情况（20 分钟）
• 问题反馈讨论（20 分钟）
• 任务验收
  • 功能演示（20 分钟）
  • 代码抽查（20 分钟）
  • 文档查看（10 分钟）
  • Bug 修复情况（10 分钟）
• 后续工作安排
  • 任务安排（20 分钟）
  • 加班情况（10 分钟）

项目人较多时，就需要 2 个小时左右；项目人较少时，也需要 1 个小时左右。我觉得项目会议时间在 1 - 2 个小时之内是可以接受的，但是开到 3 个小时以上就有点问题了。

要解决问题，最终还是要回到问题本身。项目进度会议时间过长，你的诉求到底是什么？最要解决的本质问题是什么？难道真的是项目时间过长吗？

那我直接规定每次开会不能超过某个时长就好了，没必要在这里纠结那么多。

所以说，本质的问题不在项目会议时间过长，而在于这个项目进度会议的时间是否产生了价值，是否有必要。

那我们要清楚，到底是哪些问题，容易导致项目进度会议时间拉长呢？

我想了一下，可能是这三种情况。

2. 没有在会前准备解决方案

有些问题没有在会前自己捋一遍，然后根据自己研究的结果，给出多个解决方案，并整理到文档中，然后发到项目讨论群里，而是自己闷头在研究，简单在脑里想了下，觉得想明白了，等到项目进度会议上再深入沟通。

在项目进度会议上，没有什么文档，大家就一起参与讨论了，只是口头沟通，然后七嘴八舌的，说什么都有，这样行不行，那样行不行？

讨论没有任何依据，只是凭感觉，反正你一句我一句，再加上一些闲话，最终浪费了很多时间。

正确的做法应该是，在会前要把自己研究或者想到的解决方案，整理到文档中，要列举至少两三个方案，并把每个方案的优说明缺点清楚，最后在总结一栏，把自己推荐的方案标明清楚，并说明你选择该方案的原因。

当然你可能会说，有些难题是在会上反馈出来的，哪有时间去准备解决方案文档，很多都是靠沟通交流得出的。

如果是这种情况，那么可以简单沟通一下，然后回去整理好解决方案文档，发到项目讨论群里，然后叫上相关人员在座位上过一下，然后把最终结论补上文档即可。

3. 无关话题太多以及范围过大

有时在项目进度例会上，很多时候沟通是没有依据的，也就是没有围绕项目当前的情况进行，总是一连串旁枝末节的话题，一个接一个没完没了。

你说这些话题有必要讨论吗？

当然有的，但是要看当前项目的情况和时机。比如有些规划是大半年以后的，有些甚至是几年后都不一定要做的，这些话题进行深入沟通可以增长个人的知识面，但是在当前没有什么意义，完全可以在私底下去了解。

如果觉得很有用处，可以在了解之后，叫上几个人在座位上探讨一番，而不是在项目进度会议上。

比如讨论 App 的功能，说着说着，又说到 Flutter 最近好像不太平，Flutter 组又裁员了，然后还在 GitHub 上面搞了一个社区的分支，单独维护，然后说不计划合并到 Google 的主分支上了，然后又讨论 Flutter 是不是要完蛋了？那我们后续开发 App 要换不要技术方案？那老项目要怎么维护？Android、iOS、鸿蒙、微信小程序这些跨平台要怎么解决等等。

完全没完没了，这些讨论当然有意义，但是，在项目进度例会上进行讨论，真的太不划算了。

正确的做法应该是，紧跟当前项目核心问题进行讨论。比如上面的例子，App 的某个功能，在使用或实现上是否出现了问题，以及怎么解决这些问题？不要把话题扩散太广，避免违背了这个会议的初衷。

这个会议的目的是要解决项目当前的问题，不是新闻热点讨论会议。

4. 会议主持人没有做好把控

上面的问题，虽然源头都是会议前没有准备问题的解决方案文档、无关话题太多以及范围过大，但是，真正可以解决掉这个问题的，当然还是要回归到项目负责人对会议开展的把控上。

一看到有任何苗头，就可以立马打断，把话题拉回项目自身，而不是放任不管，浪费白白太多时间。

项目进度例会，我们担心有些人不说，但又怕有些人说太多，所以还是要灵活把控这个尺度，鼓励少说的多说，控制说多的少说，但目的是一致的，为了能及时暴露项目当前存在的问题，以及讨论出解决这些问题的方案。

至于无关紧要之事，可以会后私下里沟通。

5. 总结

项目进度会议时间过长的问题，最终还是要回归到这个问题的诉求上，也就是说，如果我们能够做到会议前准备好要讨论的问题的解决方案文档、减少无关话题、项目负责人做好会议进行的把控工作，那么应该是可以解决这个问题的。

第一步，项目负责人把当前项目情况进行汇报，然后重点问题说一下。

第二步，每个项目成员在自己的座位上，说一下上周做的事情，下周计划做什么，遇到什么问题。

第三步，散会。

但是，不同的阶段关注的重点不一样。

在项目进度例会中，对当前所做的工作进行验收，是很重要的一环，这些也在《16-项目的任务质量如何保证》中，把前因后果也说明清楚了。

本篇主要是探讨让项目负责人把全部功能进行演示和让项目成员依次汇报任务进度和演示，这两种方式不同之处在哪里？

首先，我们要知道，参加会议的人，什么样的心态都有。有的人现在遇到了很多问题，亟需在会议上反馈出来，然后帮助他解决这些问题；有的人觉得我现在忙得很，又天天开会，真烦，能不能少开一点、少说一点，让我赶紧忙完，要不然就得加班了；有的人觉得真好啊，最好开一整天，又可以摸鱼了，等等。在这些心态之下，各人的反应也会不一样。但更深层的一点是，多一事不如少一事，你要让他主动去说，那太难了，你问了才会说，不问就不说，甚至你问了，也可能因为性格等各方面的原因，都不太愿意说太多。加上大部分人都在会上刷手机，不会有心思听那么多的。

在这样的情况之下，让项目负责人把全部任务进度进行汇报并演示可验收的功能，很难覆盖到其他项目成员。他们本身不会觉得和这个会议有什么太大的关系，反正就是听一听，看一看手机，到了时间散会就完事儿。也许有些人可能有问题要反馈，但是他不会主动去提。

所以，项目进度例会的整体流程就要进行调整：

第一步，项目负责人要对项目当前的情况进行汇报，比如延期风险高不高？有什么重点问题？说一下，同步下信息，以及后续要注意哪些方面，等等。

第二步，就是要项目成员依次到前面来，而不是在自己座位上。把自己上周完成了哪些任务说一下，哪些任务进度怎么样也说一下，然后是演示一下自己开发的功能或者一些技术文档，最后就是遇到了哪些问题？需要现在就讨论和解决，然后就是下周计划做什么？把这些信息都记录在会议记录文档上面。

一方面可以减少项目负责人需要全面深入细节的工作；另一方面，可以侧面给项目成员一点压力。因为每次项目进度例会都要说一下工作内容，你如果上周完全都不用心，那么工作自然没什么产出，这样你总不能胡编乱造吧。

冥冥之中，不需要谁整天盯着你工作，你自己清楚，无形之中，就会有约束力，也减少了项目负责人的管理工作。

第三步，项目负责人把项目成员过进度中反馈的待解决问题，都记录到会议记录文档里面。下次项目进度例会，会看下待解决的问题是否已经解决。

第四步，项目负责人要根据当前项目进度情况，再次强调要重点关注的点，然后评估下是否需要加班。如有需要，进行加班安排。

第五步，散会。

相信按上面这个流程，可以有效解决项目成员在会议上没有深入参与的问题，并且能起到日常工作的一些约束，加强自我管理的意识，达成期望的工作目标。

然而，深入分析后不难发现，这种做法存在一些潜在问题。首先，项目负责人可能对其他同事开发的功能并不熟悉；其次，项目负责人作为整个项目的负责人，在进行项目整体汇报时，若将主要演示职责交给开发人员，会导致职责划分不清晰，这不仅不利于项目负责人的个人成长，也不利于项目的顺利开展。

因此，项目功能演示环节最好由项目负责人全程主导，开发人员可适时进行补充。这样做的好处有三点：一是避免职责不清；二是增强项目负责人的责任感；三是促使项目负责人更深入地了解项目需求，因为只有真正理解项目需求，才能顺利进行演示，这也有助于后续的功能验收环节，其影响是多方面的。

归根结底，问题的根源在于项目需求与方案环节。项目负责人需要确保对项目需求有清晰、透彻的理解，虽然不一定亲自编写代码，但可以在脑海中模拟开发过程，至少要清楚功能的具体形态和使用方式。基于此，项目负责人可以在每周一提前浏览本周的任务，鉴于项目进度会议每周举行一次，本周需要实现的功能数量相对有限，亲自操作演示也不会花费过多时间，从而确保在周二的项目进度会议上能够清晰、准确地进行汇报。

对于那些能够在会议前完成合并的分支，其代码已成功合并至开发环境平台，此时仅需进行功能验收即可。然而，功能分支的代码需经过项目负责人的评审，但往往功能开发任务在当天刚刚完成，而项目负责人本身还承担着其他功能的开发任务，因此难以及时完成代码评审及合并工作。在这种情况下，该如何妥善处理呢？

一种可行的方案是Clone功能分支代码至本地，在本地环境中运行并进行验收。但这一流程存在诸多不便：需要Clone分支代码、安装依赖，且可能面临与本地环境不兼容的问题，还需进行微调才能成功运行，整个过程较为繁琐。在会议中花费大量时间进行此类操作显然毫无意义，那么如何简化这一流程呢？

一方面，可以在会议前与相关人员进行沟通，提前了解哪些任务已完成且已合并至Dev分支，哪些功能的代码尚未完成评审并合并至Dev分支。对于尚未合并的功能分支，可提前将其Clone至本地电脑，安装好依赖并成功运行，待开会时通过远程连接至本地电脑即可进行演示。

另一种方案是直接打开代码仓库GitLab，查看项目分支的代码，让负责功能开发的同事详细介绍该功能的实现方式以及代码的设计思路，这样既能解决上述问题，也能达到功能演示的目的。

此外，还可以考虑在现有的Dev、TEST、Staging、Master 四个环境之外，额外设立一个Preview环境。项目的各个功能分支，无论处于何种状态，均可立即合并至Preview环境。功能开发完成后，项目负责人可直接将该功能分支合并至Preview分支，解决合并冲突后通过CI/CD流水线自动部署至Preview环境，从而方便地进行功能演示。Preview环境主要用于功能演示，最终的代码合并仍需以Dev、TEST、Staging、Master 四个分支为主，项目负责人在完成代码评审后，需将功能分支代码合并至Dev分支。

通过以上提供的三种解决方案，包括项目负责人在会前做好准备工作、通过GitLab查看功能分支代码进行验收、提供Preview环境以便直接合并功能分支进行验收，相信可以解决会议上因代码没有合并，从而无法进行功能演示的问题。

项目的任务质量如何保证？在我看来，主要取决于以下这几个环节：需求要明确、任务开发时间要合理评估、任务需提供测试用例、在项目进度会议上进行功能演示。产品质量是生产出来的，不是检验出来的，不可能全都依赖于验收环节，毕竟那时已经晚了。验收环节只是为任务的质量加了一层防护，应从源头开始，就要不断地关注和解决存在的问题。

需求要明确

需求要明确，这一点在前面几篇文章中都反复提到过，这里就不再赘述了。简而言之，就是产品的需求要具体到可量化的程度。比如我要买苹果，应该是我要买10斤XXX牌子的苹果。

任务开发时间合理评估

在评估任务开发时间的时候，要根据实际情况，不能过于宽松。比如一个设备列表的功能排个两三天就差不多了，硬是排了一周多，这显然是有问题的。但也不能太严格，比如就给一天的时间，这就存心为难他人了，大可不必，实事求是就好了。

有人觉得开发任务只要时间够长，那么交付的功能质量一定就更好，实际上并非如此。人性本就如此，很少有人会提前完成任务，大部分人都会压到最后一刻才说做完了，不过，这也没什么可指摘的，人之常情。

所以，任务开发所需的时间，通常以一个“跳一跳能够够得到”的要求去评估即可。

**我们不会要求一个只能跑10公里的人去跑马拉松，我们只会要求他不断地跑到10公里、11公里和9公里，而不是他每次都只跑了5公里。**道理是一样的，没有什么是十全十美的，只希望每个人都能在自身能力范围内做到最好，仅此而已。

任务需提供测试用例

我们开发人员在开发完成之后，就匆忙提交任务进度为100%，意味着任务已经完成了。但是在验收人去验收的时候，还是经常发现这样或那样的问题。

为了解决这个问题，就需要把全部的问题都放到明面上，而不是藏着掖着，让大家都能清楚地知道，哪些功能确实是真的验收了。

这就需要开发人员在开发完成这个功能之后，提供一个自测报告，也就是在AgileTC测试用例管理平台编写这个功能的测试用例（在《AgileTC测试用例管理平台的基本使用》这篇文章中有介绍过如何使用），把全部功能要测试的点依次列出。

这样验收人在验收功能时，就可以根据这个测试用例，把全部功能都过一遍，有规范有依据，不会像之前那样混乱，到底哪些功能是没问题的，哪些功能是有问题的，一目了然，沟通效率也会更高。

以微信读书PC端的功能为例，图一为微信读书PC端的页面，图二为根据功能编写的测试用例，如下所示：

什么时候编写测试用例

上面提到的是在任务开发完成之后再编写测试用例，但如果在需求阶段就编写测试用例会不会有什么问题呢？

在需求阶段就编写测试用例，这种开发模式就是常说的TDD（测试驱动开发）模式。这个方式当然是可行的，但存在一个问题，就是最终交付的功能和最初的需求可能会有出入，导致之前编写的测试用例不能用了，需要重新编写。

首先，开发人员在需求阶段就编写测试用例，相当于在对需求进行分解，同时对需求也会更加了解，能和产品明确，达成共识，避免接下来出现返工的情况。

总体而言，测试用例等同于列出需求点，后续需求有变更，也不是全部测试用例都不能用了，很大概率只是个别测试用例进行微调而已。

所以，不管是在需求阶段还是开发完功能之后再编写，在我看来都可以的。

说到底，测试用例最终还是要围绕需求来编写，从需求中提炼出的测试要点才是真实有效的。所以，**对被测对象业务的熟悉程度，也决定了能否设计出高质量的测试用例。**毕竟，各功能点之间往往都是有关联的，会隐藏很多被我们忽略掉或者是想不到的测试用例。

在项目进度会议上进行功能演示

我们发现只有在项目进度会议上进行功能演示才会发现问题。开发人员通常口头上说“已经做完了”，这很有可能是片面的，并非开发人员存心欺瞒，只是每个人对需求的理解，有可能一开始就有差异，这种差异即便功能已经开发完成，还是可能会存在。

在项目进度会议上进行功能演示，整个项目团队的人员都可以看到，并且可以随时提出问题，虽然这样会增加会议的时间，但我相信这是值得的。

这其实也就是在敏捷开发模式中提到的Sprint Review环节，简单来说，就是解决颗粒度对齐的问题（笑），能让项目团队中的相关人员，包括但不限于产品、研发、测试和需求提出方等参与验收当前开发的功能，确认是否有需求理解偏差或潜在的需求调整，能够及时反馈和沟通，有助于项目下一步的功能优化和工作安排。

之前项目负责人去验收，实际上是不知道任务进度情况的，只有问了项目开发的同事才知道负责的任务完成了没有，项目负责人完全不知道有多少任务需要验收，完全是随机的状态，相应的其他事情的计划就又要变更了。那我们何不反过来，使用观察者模式，等开发同事完成任务后，给项目负责人发一下邮件或者企业微信的消息，一来形成闭环，二来强化开发同事任务是需要验收的这个意识。项目负责人这个时候立马去验收也可以，但不推荐，因为挨个去验收，精力就会分散，建议把可验收的任务整理记到下周一当天工作计划里，统一验收。后续等我们在线项目管理系统上线，里面就提供一个功能：如果开发同事任务完成，需提交技术文档（如有需要），然后把任务状态变更为待验收，这个时候，系统就会给项目负责人发一条可验收的邮件，相信可以有效解决这个问题。

召开项目进度会议的方式应依据部门的具体情况灵活安排。尽管一些部门的职能结构通常为项目总负责人、项目负责人，再到具体项目及其成员，但在实际召开项目进度会议时，通常有以下两种设计思路：一种是项目总负责人深度参与并引导会议；另一种则是授权项目负责人自行组织会议，而项目总负责人则另设专门的项目负责人会议。

项目负责人主导型会议

项目负责人主导项目进度会议的全过程。他们负责申请会议室、准备设备、在项目群中发布通知并召集相关人员参会，项目总负责人也会参与其中。会议中，无论是项目进度汇报、问题反馈、任务验收还是后续工作安排，均由项目负责人主导提出、讨论并解决问题，项目总负责人则主要扮演补充角色，例如指出潜在问题等。这种模式能够有效增强项目负责人的责任感，使其将项目视为自己的责任。换言之，项目负责人应明确，在项目事务中，他们行使的是权力而非义务。**权力是主动争取并愿意承担的事情，而义务则是他人强加的要求，二者意义截然不同。**许多项目负责人虽然参与了许多工作，但心态上仍与项目脱节，认为项目是上级安排的任务，只是机械地执行上级指令，而未意识到自己需要对项目的各个方面负责。

分层汇报机制会议

在这种会议模式下，项目负责人负责组织项目进度会议，而项目总负责人则主导召开项目负责人会议，用于听取各项目负责人的项目整体情况汇报。这种方式通常适用于规模较大的团队，且对项目负责人和项目总负责人的能力要求较高，实施起来并非易事。

为何项目会频繁出现加班的情况呢？究其根源究竟在哪里呢？从项目管理的角度出发，我认为项目负责人可能在以下几个关键环节存在不足之处，从而引发了加班现象的产生。

需求不够清晰明确

项目需求是否已经足够明确呢？例如，当我要开发设备列表这一功能时，上级给出的需求仅仅是一句“实现对设备的管理”，而没有细化到该功能的具体要求，比如页面默认应显示10条数据、需支持分页功能且分页选项为10、20、30、50和100条，还要支持按设备名称和设备ID进行搜索，列表要展示的表头包括设备名称、设备ID、设备型号等。

在需求沟通阶段，若未能明确需求的范围，就会使要做的工作存在过多不确定因素。就好比我要提一个需求，即“用一张纸剪一个圆”，如果只是简单地告诉对方“我要剪一个圈”，而对方仅凭感觉去剪，剪好后我却觉得不满意，要求剪得小一点，但又没有明确具体要多小，对方只能凭借自己的感觉不断尝试，直至剪出令我满意的结果为止。在这个过程中，对方其实一直在进行返工，这无疑就变相导致了加班的情况出现。

正确的做法应当是，在告知对方要剪一个圆时，直接将圆画在纸上，待双方沟通确认之后，对方只需剪一次即可，从而避免出现反复返工的问题。

项目缺乏充分的预研工作

在项目的预研阶段，项目负责人需要在脑海中对项目从无到有的整个过程进行全面且深入的分析，将可能出现的问题逐一梳理，并且提供相应的解决方案，而不是仅仅依据需求阶段沟通好的需求，就仓促地开始着手实施。

需求阶段的工作做到位只是基础的第一步，接下来的第二步就是要以终为始，从最终结果开始倒推，思考可能会遇到哪些问题呢？这个功能采用何种技术来实现呢？这个饼图应该使用哪个插件来制作呢？这个3D动画效果是选用哪个第三方库来实现，还是自行开发呢？天气数据又该使用哪个平台呢？客户提出的这个需求是否真的能够实现呢？类似这样的一系列问题都需要项目负责人提前想清楚，并且做到心中有数，甚至对于一些功能难点，还需要制作一个Demo来进行验证。

倘若在这一阶段没有做到位，仅根据需求评估项目的开发计划，并且向客户承诺交付的时间，那么在项目推进过程中，一旦发现存在无法解决的问题，或者某个环节比预期花费了更多时间，为了应对这种阻碍项目推进的突发状况，项目负责人往往只能被迫安排加班，否则就无法按照预期完成项目。简而言之，就是前期预研工作没有做到位，从而意外地遇到了隐藏的暗礁。

临时插入需求导致的问题

其实关于项目推进过程中出现紧急需求插入的情况，已经在《10-项目需求变更时如何处理》这篇文章中有所提及，当遇到这种情况时，应该如何妥善解决呢？这里就不再重复阐述了，只是想说明一下为何这种情况下会出现加班的情况。原因就在于项目负责人没有充分按照《10-项目需求变更时如何处理》中提到的方案去操作，而是盲目地接下来，完全不进行沟通，只要上级提出任务，就理所当然地认为上级是知晓当前项目情况的，如果自己有不同意见，可能会给上级留下不好的印象，会被认为是身为项目负责人，稍微增加一点工作量就开始抱怨。于是，就硬着头皮接受了任务，但此时已经有正在进行的工作了，新增的任务必然需要额外的人力和时间去完成，那么在这种情况下，只能安排加班，否则还能怎么办呢？最终项目没有如期达成，被上级批评，而项目负责人自己却感到非常委屈，明明项目团队天天都在加班，只是差了一点点就完成了，却还要被批评，心里十分不爽。这就是典型的吃力不讨好，没有及时与上级进行沟通。很多人总是错误地认为上级是全能全知的，上级的决策一定都是正确的，既然上级安排了临时任务，那一定是有其原因的，也一定知道我正在忙很多事情。这种想法是不可取的。类似这种情况，由于项目需求变更、临时插入紧急任务，一定要及时向上级反馈，不能等到事情搞砸了，再去找各种理由，即便理由再充分，但项目没有按照预期交付，这个结果就是工作没有做好。

关于加班的合理时机

说实话，其实我是很反对加班的。虽然我加班还挺多的，但并不是因为我加班多才反对的，主要是加班要加得有意义，加班本身不应成为目的。然而，许多人却将加班视为勤奋的象征。例如，有人会说：“我一个月加班近50个小时，这难道还不算努力吗？”我见过太多人在正常工作时间内拖沓，却把事情留到加班时间去完成，这种行为毫无意义。

加班应该是应对突发情况的手段，而不是常态。比如，当服务器突然宕机，或者线上平台的关键功能无法使用，严重影响用户体验时，这种紧急情况需要立即解决，加班是必要的。这种加班才是有意义的，因为它解决了实际问题，避免了更大的损失。

许多硬性安排的加班往往只是形式主义，大多数人只是在“摸鱼”，不会关注“今天把事情做完”的重要性，不会追求提高工作效率，只是在凑时长而已。

甚至有些人认为“我做得越快，不就是做得越多吗？”这种想法有一定道理，但关键在于如何利用时间。如果你担心完成任务太快会被认为无所事事，那么可以利用剩余时间学习新技术、阅读专业文章，提升自己，这才是更有意义的做法。

如果遇到问题，无法解决，应该怎么处理？其实，这个问题要从两个不同的视角来探讨：一个是项目成员的角度，另一个是项目负责人的角度。假设项目成员是李四、王五，项目负责人是张三。

及时反馈

比如项目成员李四，有一条功能开发的任务，工期为5天。在开发过程中，他遇到一个无法解决的问题，一个人琢磨了一两天，但始终无法突破，就这样卡在了这个点上。他的心路历程可能是这样的：一方面，他担心自己的技术能力不足，觉得这个问题在别人看来可能很简单，自己居然解决不了；另一方面，他想死磕到底，觉得遇到这样的技术难题，如果不解决就太不甘心了。这些想法本身没有问题，毕竟谁都不想被别人说技术菜，而死磕难题正是极客精神的体现，值得鼓励。

但问题在于，这种心态放在项目团队中可能会带来隐患。项目最终看的是产出和结果，而不是个人的技术表现。只要项目能够完成，其他因素都是次要的。从这个角度看，担心被人说技术菜、死磕技术难点，都变得毫无意义。因为解决问题的方式并不唯一，不一定非要从技术入手。比如，李四可以把问题及时反馈给项目负责人张三，由张三组织项目团队讨论，甚至与客户沟通，看看是否可以通过微调需求来解决问题。也许客户的需求，用另一种呈现方式同样可以满足，而无需纠结于技术实现本身。

有人可能会问，如果讨论后发现确实只能通过技术手段解决呢？如果项目负责人张三已经召集项目团队进行讨论，仍然没有解决方案，那又有什么可害怕的？大家绞尽脑汁都没能解决，怎么能说明李四技术很菜呢？如果有人质疑，他完全可以回怼：“你那么厉害，那你来试试看。”

所以，项目成员遇到问题，如果已经使出浑身解数，还是没能解决，要及时反馈给项目负责人，要从项目全局角度考虑问题，而不只是个人的维度。你及时反馈，虽然是别人给你的解决思路，但最终执行的是你，这条任务还是你来完成的，而你如期完成了这条任务。

小心“猴子”

上面是项目成员李四的角度，那么从项目负责人张三的角度来看呢？

如果项目成员不是像李四那样闷头死磕问题，而是遇到问题就立即反馈，比如王五，张三应该如何应对？

有些项目负责人可能会及时介入，觉得自己项目同事遇到了问题，自己当仁不让，当然要身先士卒，冲到最前面了。这个本来是很好的行为，出发点也是好的，但这样做的结果是，原本属于王五的开发任务可能完全变成了张三的工作。这就是我们常说的**“小心下属的猴子跳到上级身上”**的问题。王五可能因此变得依赖，而张三则疲于奔命，吃力不讨好。这种情况本质上取决于项目成员的性格和工作态度。如果是这种倾向明显的同事，张三首先要做的不是直接介入，而是反问王五“有好好研究过了吗？”，如果王五支支吾吾，那就先让他自己研究一下，不要遇到点小问题就退缩，如果王五说已经研究过了，那张三就需要及时调整王五任务的优先级，让王五先做其他事情，避免他无所事事，自己再介入。

意思就是说，对于项目成员反馈的问题，张三可以介入协助，但最好只提供解决问题的思路和建议，比如分享自己调研到的可行方案，然后交给王五去验证。张三的角色主要是引导作用，而不是直接接手去解决问题。他需要激发项目成员的主动性，让他们在遇到问题时真正动脑思考，而不是轻易放弃。如果最终仍然没有解决方案，张三可以召集相关同事讨论，甚至向上级反馈，让更高层来做决策。

所以，项目负责人在处理项目成员反馈的问题时，应避免替团队成员承担过多责任，而是通过引导和协调，激发他们的主观能动性。一来项目成员可以得到锻炼，二来项目负责人可以投入精力在更重要的事情上，这对于项目团队而言，是大有裨益的。

有人提议是否可以申请一些设备常驻我们部门，让项目相关人员在开发过程中能够随时试用设备，真实感受应用场景，同时遇到问题时可以立即用设备重现和排查。这个想法确实有一定道理，但仔细想想，设备本身也在不断迭代，如果设备长期放在我们部门，可能只能停留在某个版本，后续更新无法跟上，反而会限制我们的开发思路。此外，设备的使用频率主要集中在开发阶段，项目上线后很少再被关注，长期占用硬件资源可能造成浪费。

其实，我们的核心问题并不是设备是否常驻，而是如何让开发人员在开发阶段有机会试用设备，从而增强对业务的理解和对设备功能的熟悉。与其申请设备常驻，不如在开发阶段短期借用设备，确保开发人员在关键阶段能够充分接触和使用设备，同时避免资源的长期占用。这样既能满足开发需求，又能兼顾资源的合理利用。

项目遇到需求变更，通常都是新增需求，很少是减少需求的变更。简而言之，就是增加了工作量。而项目负责人面临的难题在于：如何在不影响整体计划的前提下，高效应对这种变化。需求变更的规模有大有小，不可一概而论。如果是小的变更，那无伤大雅，适当微调即可。但倘若是很大的变更，比如新增的功能开发需要一两周甚至更长时间，那么整个项目计划可能就需要推倒重做，这无可厚非。

我们要探讨的是介于这大小之间的需求变更——那些有机会在当前计划里解决掉的需求，比如增加了一周的工作量。你有信心能按当前制定的计划如期交付吗？现在的情况是，我们可能只是将需求变更分为大小两个情况：小的微调，大的立刻调整项目计划，然后项目上线时间就会变更。久而久之，这种处理方式可能会让人觉得理所当然。

事实上，大部分项目开发工作是有协商空间的，并未被完全限定死。遇到突发情况，比如客户需求变更，但交付时间没有任何商量余地时，项目负责人该怎么办？有人可能会说加班，但有时加班未必能解决问题。

也许现在我们可以慢慢培养这方面的意识和能力，在平时多积累这方面的经验，避免真正遇到事情时手忙脚乱、无从下手。也就是说，我们可以将需求变更分为三种情况：小的变更，微调即可；大的变更，比如需要增加两周工作量，那就变更项目计划；中等变更，比如需要增加一周工作量，我们先不急于调整计划 ，而是先想一想：有没有什么办法可以在不变更计划的情况下解决这个问题？然后将各种可能的解决方案列出来（1、2、3……），召集项目其他成员一起讨论。也许经过多轮讨论，我们就能找到解决方案。如果讨论后仍无法解决，再根据实际情况变更项目计划。

举个例子，设备管理模块的开发需要张三负责后端，李四负责前端。如果将他们的任务写在一起，当前进度显示为60%，我们无法直接了解具体情况。这个60%可能意味着后端已完成，只是前端还在开发；也可能是后端和前端都还未完成。这样一来，项目负责人就不得不去沟通询问，才能知道真实情况，这无疑降低了工作效率。

因此，项目开发计划里的任务最好是一人一条，拆分清晰。这样做的好处有两个：一是可以明确职责，避免出现责任不清的情况；二是任务状态会更加透明，项目负责人能够一目了然地掌握每个环节的进展，从而减少管理难度。

如下图所示，当任务拆分清晰后，我们可以立刻知道设备管理功能模块的后端开发进度为100%，已经完成，而前端开发进度为20%。这样一来，项目负责人就能根据这些信息及时调整计划，合理安排后续工作，确保项目顺利推进。

之前有APP项目就是这样的情况，本来APP功能已经开发好了，然后测试阶段，设备经常出现问题，可以用但是又不稳定，经常测到一半就测不下去了，然后反馈给到设备那边，改了好几次，觉得可以了，又继续测试了，后来还是不行。反复多次我才醒悟苗头不对，不能再这样下去了，立马中止项目测试，和设备那边沟通，设备需要确保完全没有问题，再继续这个项目的工作，可以说是血的教训。

这个问题之所以会造成那么大的影响，是因为我们在和他人协作的时候，没有和对方明确一个具体的时间节点，而是很含糊地回答道：“等某某完成了我才可以对接”，然后再问一句：“那他什么时候可以做完呢？过几天吧”，到底是几天？哪一天的？不知道呢。这样是有隐患的，因为这些模糊的信息，负责对接的开发同事完全就是看天吃饭了，任何结果完全是随机的。过几天，可能是一天，也可能是两天，甚至是一周或者更多，再者，项目负责人调整项目任务的时间也会变得很困难。

我们需要和对方明确一个具体的时间节点，比如前端同事需要问下后端的同事，接口是哪一天可以提供使用，而这个使用的意思，基本上是自测过的，不说一个Bug都没有，至少是相对稳定的。我们知道这个具体的时间节点之后，就可以先安排其他事情了，项目开发工作的开展就会很清晰，而不是完全混乱的。

项目负责人的开发任务应比项目成员提前3天左右时间结束，这个时候项目的其他功能还在继续开发，项目负责人可以借机着手准备下个阶段的任务（之所以是下个阶段，而不是下个版本，是因为有可能不是迭代这个项目了），将需求进行梳理分析，编写方案设计和制定开发计划，等到其他项目成员开发任务完成之后，就接着下个阶段的任务进行，项目负责人这时再回到当前项目，去做内部验收和提交测试申请，整个衔接是很清晰顺畅，不至于那么被动，捉襟见肘。

可能会造成项目延期，在上一篇文章《05-项目为什么总是延期》中已经分析过了，这里就不再赘述了，我们现在要探讨的是，如何制定一个项目计划呢？

在开始项目计划制定之前，可以先了解一下开发模式的相关知识，这部分主要是《【清华大学】项目管理的逻辑（全6讲）》里面的内容，有兴趣的可以去看一下，还是很不错的。

1. 瀑布式开发

预测型开发，在还没有开始着手编写代码前，就可以提前预知结果如何，之所以叫瀑布式，是因为整个开发流程都是有序的，就像水从上往下流，每一步做很到位就到下一阶段。

2. 迭代式开发

迭代式开发，顾名思义，就是一个版本接着一个版本进行迭代，先将项目整体框架搭建好，然后基础布局全部铺开，就好像画人物肖像一样，先勾勒草图，画出人物整体轮廓，然后才依次画出脑袋、眉毛、眼睛、鼻子、嘴巴等等，全部画出来之后，才是着色。

3. 增量式开发

增量式开发，咋听之下，与迭代式开发的意思一样，实际上是不一样的，增量式开发的意思是，每次只构建一点，每个阶段就交付一部分，然后组合在一起，还是用画人物肖像来举例子，一开始先画头发，画完之后上色，然后接着是眉毛，画好之后着色，以此类推，全部画好一个地方再接着画另一个地方，如下图所示：

4. 敏捷式开发

适应型开发，灵活性很高，需求可以随时提，然后放到需求池里，可能两周一个周期发一个版本。因为能干的活儿很有限，就像坐地铁一样，人很多，挤不上去那就下一趟，所以敏捷开发的思路就是，未必做得到，所以下个版本实现需求，可以有节奏地持续开发。

以上就是常用的开发模式，但是我们在实际应用中，应该怎么选择哪一种开发模式呢？为此有一个STACEY矩阵图可以作一些参考，如下所示：

从上图中可以知道，选择哪种开发模式，是基于需求和技术两个维度去评估的，所以项目负责人在编写项目需求与方案文档的时候，可能就可以做出判断了。说回我们自身，开发模式毕竟只是项目管理中的一种技巧，要深刻认识到它并不是万能的，如果掉入盲目迷信权威的陷阱，那么就太死板了，真正应用的时候，还是要考虑实际情况，在遵循基本原则的基础上，要明白事物变化的重要性，在变化的世界里使用不变的方法是不现实的，没有任何一种开发模式能够适用全部的项目。

现在部门按照项目来管理，每个人都比较清楚自己要做的事情，也没有那么多交叉的任务，所以变更理应很少才对，在制定项目计划的时候，我们可以把项目开发的周期全部列出，虽然项目计划通常都会有变更，但项目计划最好能够做到有始有终，把全部任务时间明确一下，然后项目交付时间基本就确定了，其中的任意环节有变更，很有可能是不会影响到项目交付时间的。我们可以把项目计划分为11个环节，如下所示：

1. 需求分析
2. 原型设计
3. 方案设计
4. 开发计划
5. 开发阶段
6. 下版计划（下一阶段任务计划）
7. 内部验收
8. 产品验收
9. 测试阶段
10. 模拟升级
11. 正式发布
12. 复盘会议

如下图所示，就是根据这11个环节制定的项目开发计划，虽然实际情况会有所出入，但是可以知道这个项目12月底基本上就可以交付了，有这样很清晰的时间节点，对于接下来的开发工作，会更有目标和方向感，其中经常出现任务变更，大多是在开发阶段，但是并不代表做好这个环节就没事了，接下来的环节如果遇到问题，也是会影响到项目交付的，所以怎么能管理好一个项目，是需要多方面去思考和解决问题的，并不是只做好开发任务环节就行了。

之所以会这样，是因为在项目推进过程中，我们聚焦的一直是解决项目当前遇到的难题，为了解决这个难题，不断地调整项目任务计划时间，明天后天下周下个月等等。也许我们可以转换一下思路：项目推进过程中，以终为始，以最终结果为导向，聚焦项目上线发布这个目标。为了达成这个目标，我们要采取不同的做事情方式，也就是多维度思考如何解决问题。

导致项目进度受阻的问题有大有小，如果是不可抗力的情况（比如有的项目需要用到设备，结果设备完全用不了），那当然没有办法，但这种情况相对来说还是比较少的。其他的那些问题就要想一下，是不是当下一定要解决，或者说一定要从技术层面解决才行呢？那当然不是，我们的需求只是解决问题，问题解决了就行，并不关心用了什么方式。就好像要从广州到北京，需求只是要去到北京，并不在乎你怎么过去，是要坐飞机、坐动车、自己开车或者打车什么都可以，只要能到北京就行。

在项目推进过程中，项目负责人遇到问题时，以前可能是这样思考的：“这个问题解决起来很困难，可能需要5天的时间，我要问一下，项目计划能不能变更，调整一下上线的时间？“现在的话，如果是以终为始，可能就需要这样思考了：“这个问题解决起来很困难，可能需要5天时间，这个版本计划11月15日上线，时间有点紧张——这个功能是不是必须的？一定是这个版本要加的么？能不能下个版本？为什么需要5天的时间，有没有其他更好的解决方案？5天的时间里，我是不是可以先做其他事情？测试阶段、发版阶段还有没有什么潜在的问题？第三方编译走通过了么？时间有点赶，问题有点多，可能要动员一下，让大家知道现在时间有点紧张，加加班才行了，宁愿赶在前面，也不要后面遇到问题了没时间解决。”

我们倾向于哪怕只是一点点可能性，也要挣扎一下，不要那么容易就缴械投降。还是要回到小平同志说的那句话：“不管黑猫白猫，能捉老鼠的就是好猫。”

这种状况容易导致项目管理出现诸多问题，表面上看似平静，实则处于一种失控状态，主要体现在以下几个方面：

1. 任务时间评估不到位：项目负责人由于对整体功能和需求缺乏深入了解，导致在评估任务所需时间时不够准确，经常需要变更任务计划，影响项目进度的稳定性。

2. 风险意识不足：由于对业务不够熟悉，项目负责人无法提前识别潜在的延期风险因素，也无法有效判断是否需要安排加班来应对可能出现的问题，从而增加了项目按时完成的不确定性。

3. 任务验收困难：在验收功能时，由于项目负责人对业务和需求不够了解，只能依赖开发同事的回答来判断功能是否实现以及是否与需求一致。这种情况下，验收工作往往流于形式，难以深入和全面地评估功能质量，导致验收工作的积极性和效果都不理想。

为了解决这些问题，项目负责人需要自行梳理一份详细的项目需求与功能实现文档。比如下图所示的文档格式。在文档中，将每个功能按照“是什么”、“为什么”、“怎么做”这三个问题进行清晰的梳理和记录。在项目推进过程中，一旦出现需求变更，应及时更新文档，确保项目负责人对项目的整体情况有清晰的把握和了解。

1. 开发能力

项目里自己负责开发的功能高质量完成，基本可以认为是可以直接给客户演示的标准：功能没有特别重大的Bug（例如不会突然崩溃或无法使用）；功能边界定义清晰（例如手机号输入有格式限制，且包含正确提示和异常处理）；界面交互流畅，避免出现逻辑混乱的页面跳转；视觉细节完善，连一个像素的偏差都会调整到位。

2. 方法论沉淀

项目里自己开发的模块业务非常熟悉，但其他人负责的部分了解不足；能够独立完成需求理解、方案设计、开发计划制定、内部验收、测试提交和项目上线全流程，对分配到的模块有完整把控力。

3. 产品化思维

对项目中所有业务需求的关联性和实现路径一清二楚；熟练使用项目涉及的硬件设备及相关配套产品；如果由你主导，能够完成产品需求文档和原型设计，并对需求合理性提出专业建议。

4. 技术全局观

突破单一技术栈限制，例如前端出身的负责人掌握后端核心技术逻辑，后端负责人熟悉前端核心实现原理，能够主导跨技术栈的方案设计与协作。

5. 市场价值洞察

从技术执行转向产品驱动，深入理解产品的市场定位与核心价值（例如清楚产品解决什么痛点、目标用户是谁）；关注产品的市场推广策略与用户增长，推动技术方案适配市场需求。

对于项目负责人而言，他需要明白项目管理的意义。根据我个人的一些经验，总结了以下三点，分别涉及一个项目完整的周期，即开始、过程和结束。

一致性

目标一致、步伐一致，项目中的全体成员都需要知道，我们的目标是什么？并将全部精力投入到达成目标的要事上面。在这个过程中，间接实现了项目降本增效，还有提高团队的凝聚力。

及时性

项目进行过程中，无时无刻都在发生变化，不管是项目制定的计划，还是遇到了业务或技术难点，及时了解到当下的情况，尽快解决问题，可以避免项目进度受阻。

高质性

项目完成并不意味着没有问题，质量如何保证，就需要项目负责人进行项目的验收，不然怎么知道已经完善了呢？

以上这三点都是对于项目而言，那么对于项目负责人来说，意义又在哪里呢？

那就是一个人的成功（做好事情）固然值得肯定，但如果他能将这种成功因地制宜地在团队其他人身上应验，那将意义深远。一方面，团队里的成员能力有所提升，对项目上面的工作肯定是有帮助的；另一方面，我们都知道每个人都有自己对世界的一套认知，怎么做事情，都有自己的方式，我们只是一直在摸索那条规律，不断应验和调整。如果其他人也适用，那至少说明，你的一整套理论是有可取之处的，越来越靠近那条规律；如果不适用，那也可以借机进行反思和完善，对你而言是大有裨益的。这也是教员《实践论》里提到的观点：“人类认识的历史告诉我们，许多理论的真理性是不完全的，经过实践的检验而纠正了它们的不完全性。”

这些内容是我在2022年8月编写的，当时在部门内部进行了分享，主要涉及项目管理知识和个人工作经验总结。最开始我是计划以写书的方式系统整理这些内容，但因种种原因一直搁置。现在我觉得，事情还是越早开始越好，因为不同阶段的工作重心会有变化。若一味拖延，可能错失深入处理细节的机会，而且时间越久，当初的感受和体会也会淡去，相应的观点也可能会有出入。因此，现在就开始着手整理吧。

你可能是项目中的开发能手，最佳情况也只是能保证自己负责开发的功能没有问题，其他的你是无法保证的。哪怕你承担了项目中全部的开发工作，测试阶段、验收阶段和发布阶段也是需要其他人协助的。假设这些你都可以自己完成，而且也做得很到位，但要是需要该项目在很短的时间内交付，想必你就没有办法了。一个人的能力不管多高，人的精力终究是有限的，任何事情能够得到一个比较满意的结果，都离不开众人的努力，对于项目而言也是如此。

在推进多项目管理过程中，反馈出来不少问题，我针对这些问题进行了分析，并且提供了一些相应的解决方案。不过这些方案不一定全对，只是我个人的一些反思总结和心得分享。我计划把内容分为意识、能力、方法、提升和附录这几个部分。意识主要是项目管理意识方面的探讨，意识是这一切的基础，意识没有到位，后面的其他方面做得再好，也是有局限性的，就像一棵大树，树根没有长好，枝干树叶的成长也是有限的。因为意识很重要，所以把它放在前面。能力主要是探讨项目管理应该具备哪些能力。方法主要是项目管理方法上面的探讨。至于附录，是一些有助于提升项目管理能力的书籍摘要。