当你掌握了上一篇的任务排期后，你对项目开始之前的安排已经可以做到游刃有余了，这篇我们就开始讲讲项目进行中的处理办法。
在软件管理的过程中，观察软件进行的过程，并对此作出反应是至关重要的，这能保证项目时刻按照你的预期进行，有问题也可以及时调整。
一个好的观察方式与模型是必不可少的，而观察的目的是为了依据情形做出对应的反馈，一个优秀的观察反馈模型如下：
这些事情做的意义何在呢？我们分别介绍下，依据实际场景来进行具体分析。
一、摄入
1、观察
摄入就是观察项目的进程，但这其中有观察的区别：
- 普通人：观察事物的表象
- 优秀的人：通过表象看到事物的本质
比如开发进度没有按照预期进行，一般情况下你只是观察到了这种情况，而优秀的人可以观察到没有按照预期的真实原因，不止是听当事者所说会有自己的判断。
观察可以分为3个时间点。
- 开发模块初期的观察：此时的观察目的是为了确保开发人员已经进入模块开发
- 开发模块中期的观察：此时的观察目的是为了确保任务按期进行，如果有延期风险提前暴露预防。
- 开发模块后期的观察：此时的观察目的是确保模块可以按期提测，如果此时出问题，解决方案就只能是通过加班让项目按期提测了。
这个观察不止在开发过程中，测试过程也包含在内。
2、反馈
观察的目的是为了根据观察的结果做出相应的反馈动作，例如，项目延期了，如果你的观察结果是项目延期是因为员工工作太过懈怠，那么你就可以采取每日工作进度汇报的方式来处理此问题。
整个观察反馈模型，不止适用于开发、测试过程，甚至在产品设计、到达顾客时依然适用，其模型如下：
（1）反馈的作用：
通过反馈，你可以让事物朝着你做期望的方向去发展，比如，如果是进度慢了，那么你可以每天去考核跟踪进度，如果是代码质量失控了，你可以去考核代码质量是否过关，并将代码质量与他们的绩效挂钩，那么他们就会按照你的反馈去做相应的事情，让事情朝着你所期望的方向发展。
当然反馈是需要技巧的，不是简单的插入，那太鲁莽，反而可能事与愿违。
这就涉及到第三个技巧：赋予意义
3、赋予意义
作为一个PM，需要观察的人员是整个项目组的人员，那太多了，他们包含开发、测试、前端、跨部门的远程合作调用等等。他们之间肯定会讨论、甚至有可能发生争吵，这些被你观察到之后，你应当先思考发生这些事情的意义，然后才能决定是否介入，以及如何介入。
可能发生的讨论有如下几种情况：
- 两个人在讨论业务如何处理：这是好事无需介入
- 两个人在互相指责：在两人联调的过程中，如果出现一个人指责另一个人说他技术水平不专业，此时你根据判断
-
- 如果他确实如被人所说的不专业，不要当场去告诉他应当如何去做，因为此时他正处在被人否定的情况，你过去就算是真的为他好的方式，也会火上浇油，会让他心灰意冷，甚至无法接受，你应该等他心情平复下来后，后面遇到合适的机会再提起。
-
- 如果他是被污蔑了，你也不适合插手，因为你的插手也只是打抱不平，而且两边都是你的成员。
- 两个人发生了激烈的讨论：此时你还是不适合插手，因为你无法完全了解情况，而且此时两人可能都怒火攻心，不是插手最佳时机。
- 一人因为了解的情况错误而去指责别人：这种情况是唯一一种情况你可以当时插手的，而且是在你知道正确情况的状况下。例如：开发A对产品B说，这个业务不是这样的逻辑把，而你此时正了解情况，你可以说，这个业务逻辑是没错的，当时定的就是这个方案。
我还是觉得作为一个PM，小的事情少插手，否则你根本忙不过来，在进度与质量把控上可以使用观察反馈的方式及时纠正
其实这套理论不止适用于软件管理，在许多方面它都是灵丹妙药：
- 你通过对于女孩子的感情进展的前中后期观察，采取不同的反馈措施
- 你通过对子女各个年龄段的观察，采取与他们沟通的方式等等，这简直是一条生活处事指南
重点是你的观察一定是要赋予意义的，不能为了观察而观察，否则你观察到的东西将毫无用处，比如你观察一个程序员写了103行代码或是104行代码，对于项目的进程没有任何意义。
4、沉淀文档
在项目完成前或者在技术方案准确确定下来后，沉淀技术方案文档是很有必要的，这可以让你的工作后续有人把控，确保这是一个可以让任何人了解的任务
这套操作为何能够生效？
有人说人性是善的，也有人说人性是恶的，关于人性的剖析，老舍先生有一部作品叫做《茶馆》，里面对人性进行了深刻的剖析，我看的是“于是之”老先生演的电影《茶馆》
茶馆 茶馆
，你会深刻意识到人性是多么可怕。
然而，有一样东西却在人性之上，可以利用人性，指导人性，叫做利益。俗话说的好“没有永恒的朋友，只有永恒的利益”。公司作为发放工资的一方，自然可以通过个性化的绩效考核，赏罚标准，控制员工按照你所预期的方向前进
