上一篇中，我们从推导出团队的高绩效需要团队纪律来保证。

团队纪律=共识+个人纪律

共识意味着团队中的每一位成员，都清楚自身的角色；参与制定及评审工作目标、团队目标与个人目标；根据实际工作需要，识别出适合团队的工作流程与标准，并为团队工作的达成制定详细且资源平衡的计划——在意识层面，形成高度统一的认知与理解。

而个人纪律意味着，每一位团队成员都要为共识的达成，作出自身切实可行的工作承诺，从执行层面，保证共识的达成，从而保证团队作出的工作承诺得以兑现。

切实可行的工作承诺源自团队成员对自身工作水平的理解。在缺乏对自身工作水平的具体表征之前，我们通常会凭感觉作出工作承诺。这种感觉可能来自于类似工作的经验、其他同事的经验、环境的压力、或者盲目的乐观与悲观……无论出于哪一种感觉，用这种方式作出的工作承诺，大多具有不稳定性。这种不稳定会导致个人的工作时快时慢、时好时坏，令个人工作承诺的兑现变得薄弱起来。

软件开发是一个团队高度协作的工作过程。一旦个人的工作承诺被不断地打破，就会打乱团队的工作节奏——变更、延期、缺陷等问题接踵而至。团队和组织就被迫要在质量、成本与进度之间进行平衡，最终走上质量债务累积的不归路。

怎么才能提高个人纪律，让个人在作出和兑现工作承诺时，靠谱起来呢？只有明确个人是如何进行工作的，才能有改进和提升的抓手。

诚如我们用过程来刻画项目一样。过程也可以用来刻画个人的工作，我们称之为“个人工作过程”。软件工作的过程无外乎开发、部署、运维三大阶段，每个阶段内的具体工作过程也基本确定。作为过程中的个人，直接跟着项目过程走便是了，哪里还需要什么个人工作过程呢?

这个问题非常典型，它暴露了软件项目管理中，一个极为普遍的误区。很多人认为，为项目制定的工作过程等同于个人可以直接拿来操作的工作步骤。实则完全不是这么回事。项目的过程是站在项目的角度制定的，以项目组为单位，不仅涉及众多角色，还会跨团队、跨职能。因此，在项目过程面前个人是极为渺小的，参照项目过程开展工作的个人很有可能是无从下手的。举个例子。下面是一个软件的交付过程，包含两个子过程（建立交付计划与执行交付），涉及服务组、管理层与客户三类角色。

从工作过程的角度来看，上图已经比较完善地反映出了软件交付阶段的主体工作过程。可在交付工程师Danny的眼里，还有一堆疑问。比如如何建立出符合要求的交付计划？针对不同的服务请求，如何做出具体的处理？何时进行满意度调查，都需要问哪些问题？什么时间进行理性巡检与维护？如何调试与排除故障？编写绩效报告需要涉及哪些内容？以上所有工作是不是我都要做？遇到问题，可以找谁寻求支援？……

面对这一脑门子的问号，即使Danny承诺尽心尽力为客户服务，怕也是心有余而力不足。而客户对整体软件交付过程的质量，也就不会那么满意。因此，为了保证团队承诺的实现，团队中的个人需要对自己的工作过程进行梳理与定义，形成一份既符合项目过程，又能切实指导自身工作的个人工作过程。比如：

交付工程师A：接到服务请求→记录请求事件→查看问题列表→判断自行解决或转交其他工程师→解决并跟踪服务进程→针对不同服务类型调用不同的满意度调查问卷→进行满意度回访→记录数据并提交→关闭服务请求

交付工程师B：接到需求工单→依据问题列表，判断自行解决或转交其他工程师→问题处理→记录并提交处理过程中的相关信息→关闭工单→查看满意度反馈

交付工程师 C：根据计划或服务请求进行系统巡检与维护→记录巡检与维护中发现的问题→提交巡检与维护报告→获知问题处理的计划与结果→根据处理计划与结果进行系统处理→关闭本次巡检与维护→查看绩效或满意度反馈

有了细化的“个人工作过程”便会不再盲目。不仅可以据此判断出个人工作承诺是否靠谱，还能因此保持个人工作表现的稳定性。每次都以相同的策略和方法处理工作，既可以有效的检验个人工作过程设计的效能，也可以积累与复用工作经验，改善个人的工作效率与结果。

当团队中担任类似工作的个人均建立起个人工作过程后，团队便可根据不同的绩效表现发现与推广优秀的工作实践，从而将个人经验转变为团队经验，提升整个团队的绩效表现。

形成这种不断发展的个人工作过程，便是我们所说的“个人纪律”。高绩效是个相对概念，有了不断进取的个人，加上齐心协力的共识，才能保证团队在工作中合力最大化，从而不断地追求与挑战更高的绩效目标。

反过来说，追求高绩效的成功经验，将加固团队对工作共识的认知，鼓舞团队成员积极进取、改善自我与团队的工作过程，形成正向的激励与改进循环。