这个周末参加了为期两天的MPD工作坊，听了五场演讲，先把每场演讲的重点内容介绍给大家，后面有空再进行单项深入细化。
第一场 微信红包背后的项目
讲师是微信红包的项目经理，主要结合敏捷的思想讲了腾讯软件项目管理的一些经验，包括需求收集，不同规模需求的执行流程，团队的组织激励等。围绕红包最近为提升可用性，将数据中心从2中心-——4中心——12中心的改造项目。
都是大公司，组织架构和流程工具和我们公司也差不多，也在推敏捷。讲师应该管理经验很丰富，但是演讲经验不足，回答问题时的内容比PPT讲的内容更精彩。
印象比较深刻的是，他们把开发量大于3周的需求归入为大项目，小于3周的归入日常运营项目。两者流程不同。大项目使用瀑布型开发模式，严格的评审流程和文档要求。日常运营只需一页纸说明。大项目和日常运营项目分开，不同的leader。
将需求分为提测，提发，发布上线三个阶段，每个阶段定义不同准则，和我们类似。老需求都通过自动化测试跑，只有新需求才用到人工测试。
另外一个就是感觉产品经理很重要，产品经理要对业务负责，UX,UI都直接由产品经理管理。
他有一个观点我很赞同，当交付时间与质量发生冲突时，一定要以质量优先，再急，也要进行充分的设计，仔细的开发和严谨的测试。
第二场 体验动力模型驱动产品迭代
因为上午一场听了后，觉得产品经理这个角色很重要，而我们在做eflow产品化时，产品经理这个角色一直模糊，所以下午临时换到到产品经理专题，是腾讯的产品经理。
讲师经历还是比较丰富，先在新蛋，后来跳到腾讯，又从腾讯出来创业，创业失败后又回腾讯重新当起产品经理，而且好像做得还不错。从这点觉得腾讯的文化还是挺好的。
产品经理更偏市场化，与人接触更多，所以演讲的形式也更容易抓住听众。让我整个下午都没打瞌睡。
有三点比较重要，可以在我们产品的需求识别和设计时进行借鉴。
一是回归熟悉感，加强体验撮合机制。我的理解是开发新产品时，如果能够将这个新产品与用户曾经熟悉的一种体验相结合，唤起用户的回忆和认同感，就比较容易让用户接受。
二是将用户分成大致三种类型，主动型，被动型，中间型，挖掘不同类型用户的需求，根据用户的这三种特点，从用户需求动力和产品体验动力，找到他的需求点，以及使用产品的方式。用户的需求动力，是做一个产品的出发点，而产品体验动力，是产品能生存下去的关键，适合在产品迭代时进行。
三是介绍了一种产品或产品需求的体验动力评分机制，从动力持续性，动力强弱，指向是否明确三个纬度打分，在综合评论分，可以基本判断一种产品的生存度。这是分析提取产品过需求判断产品价值的方法，让我联想到需求实例化，是在需求明确的情况下，分析需求怎么做的方法。
理论讲完了，就是一个产品迭代的工作坊，题目是对微信的黄金红包进行迭代。因为和自己做的项目差别较大，并且我也还一直心念念着之前计划听的关于运营的课程，我趁着茶歇时间转场了。
第三场 技术的精细化运营
我转到测试运维专题的“技术的精细化运营”讲座。因为时间已经过半，所以只能从中间开始听。讲师又是来自腾讯，是腾讯的架构师。
整个课程分成五个部分，我是从带宽的精细化运营这一节开始听的。熊晋江老师从带宽构成拆解，运营数据分析，发现问题，给出优化建议，持续推进等几个方面，层层剥茧，介绍了腾讯视频通信的带宽优化过程。既要保用户通话质量，又要最大化减少流量成本，分析了相同运营商用户通话，和不同运营商用户通话场景下的不同策略；又从视频图片压缩的优化，小视频是否要关闭自动播放，错峰使用等多个方面介绍了带宽优化思路，确实很对技术人员的胃口。
虽然他讲的场景在我们的系统中可能用不上，但是这种精益的思路是值得借鉴的。我也很赞同他授课时提到的用移动化的思路来做产品和运维。
感觉这个主题是整个课程中技术水平最高的，讲师也介绍了很多干货，最重要的是里面提到的一些思路和方法论，比如，抓大放小，削峰填谷等，都很值得借鉴。可惜没能完整地听，希望其他听的的同事可以再分享。
第四场 华为全云化战略的背后-Cloud native
周日上午听的是架构专场，是前华为的的架构师讲解，主题是“华为的云化战略”。实际上华为的内容简单带过，主要是介绍云化的起源和普遍知识，架构演进的思路，云化架构下的组织变化，分布式的一些基本概念，比如数据一致性，分布式缓存等内容。东西还是很多，很能答疑解惑。
关于架构的演进，需要考虑成本因素，和实施的可能性，不是一开始就要云化。而架构不是设计出来的，而是在运营中逐渐改善的。我比较赞同他的一个观点是，包括云化，或者敏捷，其实有些事情我们早就在这样做，只是大家不注意经验的总结和传递，反而由一些咨询公司提出出概念，包装，再来给大家做咨询。
软件架构影响组织架构。理想的云化是去中心化，那么理想的组织也要去中心化，大家都是全栈工程师，测试也由开发来做，运维的角色也要慢慢消失，由技术和流程，而不是某些人来保证产品的发布质量。架构由团队作决策，所有人都端到端负责。
微服务的拆分是一个逐步演进的过程，有收益才拆分，要拆成合适的粒度。服务的拆分，有数据驱动，领域驱动，要从成本和业务复杂度来考虑。原则上，新业务，通用业务，核心业务，边界明显的业务，独立属性的业务优先拆分；拆分服务时，尽量采用垂直拆分，从实用性考虑，服务之间调用关系单一，每个服务对应一个数据库。
有一点我很关注的是，Design for failure。就是微服务化后，需要为失败作设计，预想周围的一切都不可靠，可能失败，所以要考虑容错，熔断。并且，需要考虑重要过程，不重要的不能影响重要的，类似服务分级吧。确实需要在系统开发时考虑进去。
总之，这堂课理论和知识点丰富，可惜少了我之前预计华为项目的实例，后来还专门问了个问题，也答复得很笼统，没有透露一点华为的项目情况，真是保密意识强啊。腾讯就要Open很多，介绍的很多是自己项目的例子，这可能是互联网的文化吧。
第五场
最后选的主题也是架构方面的，是58同城介绍的互联网高可用架构，也和分布式，微服务相关。
也讲到了服务的切分，他的观点是按业务模块进行切分比较适中。对于服务分级，要按照服务的重要性进行分级，并且，主服务不能依赖次级服务。
不过和上午的主题侧重点不同，除了介绍架构的演进过程，后面重点介绍了58同城在实现RPC框架，服务发现，服务治理方面的实践。比较偏细节，PPT也写得详细，这里就不多说了。不过我听了后，觉得有必要请我们云平台的同学再给我培训下，这几个方面，我们自己是怎么实现的，用的什么技术方案。
两天听下来，感觉演讲者的水平还参差不齐，有些也没我们部门的牛人同事强，不过三人行必有我师，还是能从每场主题演讲中得到很多启发，特别是把架构演进和云化系统地梳理了一下。
另外觉得我们部门在项目管理，架构方面其实做得也挺好的，基本上是跟上了目前比较主流的理念。 技术和软件管理方法发展很快，大家都在摸着石头过河，做各种尝试，大家也都犯过错，没有一蹴而就，没有标准答案，持续改进是唯一正确的道路。
后面几天应该会收到这次大会的所有ppt，到时候再分享给大家。