6月个人工作小结（下）

利用点子交换来收集解决方案

在工作坊中解决方案的发散和收敛，通常我们会用到me we us的方法进行发散，收敛的部分会用到投票、飞镖盘、五指峰的方式来进行收敛。

在解决方案阶段，从每个人的心理感受来说，其实都希望自己的解决方案被接受被认可，这样才能触发他的行动承诺度。除了小组讨论投票达成共识外，更好的方法是激发大家自己的认可。

这一点在六顶思考帽中比较明显，大家共同去判断每个观点的好处是什么，而不是去一味地守护自己的观点。借鉴这个思路，其实点子交换就是在讨论解决方案环节比较有效的发散，促进大家相互理解的方式。

我们仍然可以采用me we us的方式进行，在me的阶段让大家头脑书写，想想针对于这些问题自己的解决方案是什么？在we的阶段我们进行分组并进行多轮的流转，在小组中你需要去讲述、倾听、完善。讲述指的是你要向别人讲你想法的一些背景以及缘由，倾听是你要听别人的想法，听到别人的背景和缘由。完善是指在你的卡片上记录你听到的最有效的方法。

通过这种操作方式，每个人都能找到最好的解决方法，且是自己认可的，尽管这个点子不是由你产生的。这样带来的好处是让每个人都能理解其他人的观点，接纳其他人的观点。在最后us的阶段，每个小组选出最重要的解决方案。并且进行大组汇报。

定性指标和定量指标

产品数据分析过程中，指标是非常重要的一部分，那在整个产品生命周期中会有哪些指标产生吗？最常见的分类就是：定性指标和定量指标。

在我们的产品还没有上线之前，我们没有办法拿到定量的数据分析。所以我们更多要依赖于定性的访谈来获得一些洞察。用户访谈和问卷调查都是常见的定性指标的收集方式。在产品上线之后，根据我们的关键埋点数据去洞察用户对于产品的使用情况得出结论。

基于能力和脆弱建立信任

团队协作的基石是相互信任。建立信任的方式有三个层级：1找到共同点，基于兴趣爱好和生活经历；2基于专业能力；3基于脆弱；

基于能力是让大家对你的专业感产生信任，类似于简历中写得哪些光环和title；基于脆弱的方式是相互分享脆弱的部分：你经历的重大挑战、你生活中一些失败但有恐惧的事情。基于脆弱的方式需要大家有一定的熟悉度，同时提供安全的环境促进大家的表达。

在回顾会中我通常会设计类似的环节来促进团队的信任感产生。例如：非正式自己介绍、投名状、生命中最难忘的一件事等。

如何利用钉钉的生产力工具提升工作效率

今天偶然的机会尝试钉钉推出的钉闪会工具，感觉发现了一个新的天地，可以应用在自己的工作中提升协同效率。

首先这个工具将整个会议的过程结构化了，分为会前的材料准备工作，会中的会议议程以及会后的行动事项三个部分。这样的好处是拉起参会者的上下文，并且与沟通工具打通，能够及时地通知大家。极大的减轻信息不对称带来的损害。举个例子来说，我在发起一次会议时，会将会前都准备书写下来，需要准备的部分艾特对应的人，他们会收到钉钉提醒。

同时准备好会议的议程，利用好会议的计时器工具，控制整个会议的时间，同时会议的各个模块可以利用到在线的丰富文档来进行，例如思维导图，白板，多维表格、语音转文字等等生产力工具。

最最重要的是，在线会议时不用共享自己的桌面来协作。可以直接共享钉钉在线文档，提高分享的效率，减少卡顿。

不要把迭代开发变成单纯的增量开发

最近在团队的项目中，我们尝试将项目进行分迭代交付，遇到比较大的阻碍，引起了我的一些反思。背景是开发团队习惯将项目进行一次性开发完成，但是测试团队又会统计团队的需求交付情况，大项目一次性会存在某个迭代交付数量陡增的情况。这对团队的数据展示上来说不太好看。

我原本的计划是借此契机将团队所要做的事情进行拆分。但是研发和测试团队对这种拆分方式比较抵触，抵触的原因在于拆分后测试只能测零散的部分，觉得意义不大，同时还会增加回归的工作量。站在测试的角度也能理解，因为我每个功能模块这一部分之后，最终集成起来我还得再测一次，感觉上是工作量变多了，是一种低效的工作方式。

顺着这个思路，我们要去推动团队需求拆分，是非常挑战的一件事情，因为开发和测试同学的意识上还没有接受我们的目标是整个团队所做的事情价值最大化。而不是某个岗位上尽量少做一些事情，进行局部优化。

那如何推动团队进行需求拆分这个实践呢？我觉得首先要说明需求拆分的好处在哪里。第1个是优先级，更明确不用耦合在一起；第2个是更早的交付对拿到反馈有帮助；第3个是尽早地集成降低项目的风险。

其次需求拆分的关键突破口在于产品，在我们锁定发布需求的范围时如果能有效的拆分，对于研发团队来说会有很大的帮助。因为他们会下意识的认为发布范围就是我们要交付的一个完整项目，如果能将产品进行多次拆分，那就能推动团队进行迭代式的开发。

这里有一个误区是千万不要引导产品进行单独的增量式开发。因为我们每个版本的交付应该是能完整满足客户期望的，而不是一个某个场景下的一个功能点，而且每个版本包含什么样的功能，是我们可以通过用户故事地图等方式拆分出来的。

掌握po和scrum master的技能之后更容易推动，敏捷实践的落地

在最近技术日的项目上，我尝试结合po和scrum master的技能，去推动项目组的敏捷实践。当你有一定的决策权的时候去推动敏捷实践，很容易拿到相应的结果并推行落地。

因为正确的敏捷实践是能为团队带来好的结果的，比如我们通过用户旅程地图去构建我们的产品方案。通过各种头脑风暴的发散和收敛，去构建具体的解决方案。在项目的交付阶段，我们通过看板进行可视化管理及时反馈暴露风险。同时对需求进行拆解帮助我们最小粒度的去跟踪和交付拿到结果。

当我作为产品负责人的时候，需求拆分是一件很简单的事情，自然而然就能发生。但是在实际的软件产品中，我们的产品经理并没有敏捷产品管理的经验，他们对于需求拆分上缺乏很多的经验和思维上的转变。

所有的事情不管你开心或者不开心，都朝着原有的轨道在发展

最近能够明显地感觉到事情的发展规律。就拿换城市发展来说，当你决定换一个城市生活的的时候，很多事情其实都已经可以预见了是必然发生的事情。但是对于这些必然发生的事情，我们的情绪似乎非常的容易波动、容易受影响，这也是导致我们烦躁的原因之一。

举个例子来说，换城市生活会面对很多绕不开的问题。明知道这些问题绕不开，仍然让我非常被动地去应对。那为什么不掌握主动权？用积极的态度去面对这些事情呢？开心会过完这一天，不开心也会过完这一天。我们唯一能控制的是自己的内心，自己的情绪，自己的态度。

永远比你服务的技术一号位多想一步

作为PMO来说，你要辅导的是你的技术一号位，提升他的管理能力。在这个视角下来看，你应该对整个部门的管理工作有更好的视角和风险预判，而不是等到你的技术一号位发现问题来找你。最好的方式是你想在前面，提前找到解决方案，等你的技术1号位找你的时候，你已经在着手推动解决了。

为什么质量这么重要？

首先质量问题会影响用户的满意度。一个带有质量问题的线上系统会影响客户的使用流程，严重会在甚至会阻塞用户的流程。客户的满意度决定了客户会不会流失，会不会继续使用你们的产品。

客户满意度影响了整个业务和研发团队协作的信任感。如果信任感丢失了带来的问题就是协作上的不通畅，业务团队希望研发有更多的流程来保证质量，这对整个团队的协作来说是不利的。

其次线上质量问题会再来返工。线上质量问题随之而来的就要重新写代码进行修复，那重新写代码涉及到的沟通成本，代码时间成本都是浪费。

在某些场景下我们会对质量有一些妥协。例如从0到1做一个产品的时候，我们需要质量保证到什么样的程度是值得商讨的。因为初期我们的客户群体其实非常小的一部分，这个时候大范围的关注质量是不是也没有必要，就像我们常说的允许带bug上线，什么场景下允许带bug上线？

综上所述，质量保证是一定要做的，但是需要什么样的质量标准，这个是在不同场景上下要定义清楚的。

全文完。