共同创建的分享交流场域
- 从关注自己、关注他人和关注系统的场域建设开始:
早上的评估活动，从教主的开场开始:每个人介绍自己的名字，介绍自己和项目相关的三个点，要求有一个点是假的，另外两个点是真实的，其他听的人，需要在描述完后猜测出哪一个描述信息是错误的。
这样一个简单的开场:
关注到个人:每个人先回到自己，这好像是我们很容易忽略的部分，大部分时候我们总是很急切的坐在一起想要把问题解决，却忘记把关注点收回一些在自己身上。
关注到他人:因为需要识别其他人描述点里的虚假信息，所以我们需要仔细聆听他人的描述。短短几分钟能快速加深相互之间的连接，建立起一个安全和轻松的交流场域。
关注到系统:每个人介绍时，是跟项目相关，自然而然话题就可以带入到我们今天项目评估的不少关键事件和关键信息上来，分享过程中，甚至还会有一些关于公司、关于成研所这个大的系统的关注。
- 贴合项目实际情况的利益相关项目典型案例分享
项目介绍完整体情况后，新文很自然而然的过度到一个典型案例的分享。关于我们的利益相关方，也是一直和我们每天打交道的项目，关于他们的改进整体的介绍。期间重点介绍了CI工具链的改进效果以及他们的思考。以及测试分层、测试用例设计等的思考和落地。
因为介绍的项目和我们有太大的相关性，所以一方面给予我们不少启示，另一方面也给我们不少信心。可以看看当别人有类似的痛点和问题时，是如何一步一步来进行改进的。
通过这种利益相关方典型案例分享的方式来触发项目对自己改进的一些思考。这种评估方式对于已经比较成熟的项目会更有借鉴的价值。
五个启示:
需求、测试、开发三大工程域，我们现在也有了三个COP作为支撑，包括引入需求实例化和MFQ后，在需求分析和传递质量上的改进是明显的，结合MFQ后，在测试防护这块的效果也不错。但他们和测试分层，测试设计的结合，目前看来依然还有可为。这好像是，我们已经走了90公里，最后10公里路中间遇到一些坎，没有迈过去，整体的效果就会有折扣。
关于这块，会涉及到开发和QA的更高的协作，涉及到我们 QA在设计用例时对于当前系统的自动化分层的能力边界的把控。如果能解决这最后一公里的问题，便可以把三大工程领域的改进很灵活的融会贯通起来，想必一定会比现在有事半功倍的效果。关于取舍和优先级:平台面临需求众多，在质量改进过程中，也要学会需求的分级，对于“关键和重点”需求，各项质量保证活动一定要做扎实，做到位。对于“一般或轻微”需求，可以稍作简化，在保证最小投入的情况下的最大收益。
另外一方面，MFQ的用例设计也需要分层，在做MFQ的时候，需要考虑哪些用例在哪一层去进行自动化的覆盖，定下来，就是一个承诺，承诺就一定要完成。如果用例和场景太多，又是在有限时间内去做，就需要考虑区分用例和场景的优先级。识别出用户真实的场景里，哪一些用例是必须要保证的，同样的道理，也是优先级的问题。80-20原则:项目要想办法提升交付价值，这一条，今年我们做的一条关键需求就让大家尝到了甜头。一条关键需求就能大大提升客户满意度。20%的投入却能带来80%的收益。在提升产品竞争力的这件事情上，如何能够精准识别出用户的痛点，并解决，就能让我们以较小的投入换取极大的收益。当然，最重要的就是需要更贴近用户，作为平台的项目，更精准的把握用户的需求，解决用户痛点。
CI和工具链的建设:前两年做的工具链改造能满足这两年的项目需求，但再继续往前走一步，CI的工具链就会成为一个新的瓶颈，云化变成了一个必然的趋势。
包括从深度复盘的度量数据来看，我们明天想要在代码的质量上去做改进。就需要CI工具链的强有力支撑，包括个人流水线的引入，包括每个人提交代码的质量和风险通过工具能移动的进行一些数据分析，而能够很精准的从数据分析出，一个团队，甚至是每一个人在代码质量上的一些问题，再基于这样的数据去做改进也是一个很好的点，而这些都和我们配置管理工具链的支撑息息相关。我们的改进就是不断拓展我们的能力边界:拿测试COP的一种可能的运作方式来举例，相关的几个核心成员专家，可以一次拿一个疑难的用例设计案例来进行研讨，在大家的能力范围内去输出一个最好的案例。以此不断扩展到更多的人，后面当遇到新的瓶颈时，再用这样的方式把相关人都聚集在一起，也许一开始我们并不能做到很完美。但，我们做到的，就代表着我们这一群人的一个能力边界，大家一起相互支撑和碰撞，不断探索和学习，提升的过程也就是不断拓展我们的能力边界的过程。
仅以此文，纪念一下一起走在项目改进路上的小伙伴。今天的分享真的感觉我们棒棒哒，今天的沟通和交流也给我们很多启示，祝愿我们明年有更多更棒的成绩。
小伙伴们，晚安啦！
