今天的四个分会场的选择还挺难的，问了问部门的另一个同事，得知他全天都准备窝在云计算那个分会场。我想了想，干脆等后续听他们分享吧。
于是自由了，第一堂选择的是产品设计思维的《产品人七诫》，是一个资深的需求咨询师的分享，非常非常有趣。
产品人七诫
徐峰
一、别把自己当用户（用户研究）
用户总是在改变。把自己代入用户的角色后，反而看不到用户真实的需求。
徐峰解释了用户行为不同的原因是：不同用户成长经历不同，产生了不同的价值观，导致了不同的行为模式，也就产生了不同的需求。拿90后使用炒股软件作为例子，90后的受调查者表示现在的炒股软件不好用，因为没有购物车的功能，选好的股票不能放在购物车里，等行情好了直接填数字交易。这就是典型的淘宝思维。
于是不仅感叹，等产品经理的产品经验提升了，你就老了。
接着说起几个主要用户群体的特征：
信权威——>1966年前生人。电视购物抓住了这带人的需求，现在这代人开始懂电视是假的，但是开始信微信
信自己——>1966-1979年生人，特征是保守，责任感爆棚。
开放式信任——>80后（缺物质，因为物质而跳槽），90后（缺精神，因为精神不满而跳槽）
未来主流用户——>平面化，二次元文化。
就目前来说，产品经理已经很难通过问问题来明确需求，而是需要思考和分析。因为痛点不一定能被用户识别，因为痛习惯了。产品经理寻找的是尖叫点。
但是对于ToB的产品，无法用人级的用户分类，而是企业级的用户分类。找出业界标杆而后分析。
二、别把方案当需求（需求）
Want——>Need——>Win
Want是方案级需求
Need是问题级需求
Win是人性级需求（比如美图秀秀，把生活变美好的人性需求）
该如何识别这几个需求呢？
方案级：描述出来的东西如果偏向于系统实现。
问题级：描述出来有明确需求，体现用户做完得到的价值。
人性级：偏向哲学和内心的情怀。
三、别把功能当场景（策划）
所有场景都可以分解为四个维度：不同意图，不同时间，不同地点，不同周边
所有设计应该站在场景上，而不是功能上。
四、别把好看当好用（体验）
用户体验有三个层级：
- 有用（能解决问题）
- 好用（合预期）
- 爱用（对脾气）有个性有价值观有脾气，但是有铁粉就会有黑粉
徐峰表示这个涉及到了认知心理学对人类和产品的看法（推荐《设计心理学》）。
听到这里，我才意识到光有好的设计不一定能吸引到用户。这个世界上最主要的还是人性。
五、别把盈利当模式（生态）
举例：淘宝的评价模式，曾经是拉平商家的功能，现在为新商家带来了压力。
六、别把改变当创新（自然）
先提出个问题：为什么微信支付慢慢变强？
支付宝为什么变强，因为有电商。
而微信支付的变强点是红包。红包功能火遍中国，这就是符合用户的自然。从社交做到支付，逢年过节，红白喜事的红包就是世情。
而支付宝想从支付做到社交，结果出现了前一段时间的社区模式，也出现了750事件。从钱做到社交，自然变成了金钱至上。
七、别把偶然当必然（超越）
现在很多产品说风口，其实风口只是一个现象级的机会，不足以承载一个持续性产品。也不要把产品的成功归结为必然，很多产品其实都是偶然。
作为产品经理，多研究一下产品为什么失败，能得到的经验更多。
录音已发，闲时听听吧。
http://pan.baidu.com/share/link?shareid=2509342503&uk=3190277041
听完这节演讲，另一个分会场的讲座已经开始了，可是没想到是个广告………干货有限，只记录了一点。
容器
Rancher
Docker、Mesos和kubernetes是目前三大主流容器编排引擎，其中Kubenetes是目前最流行的容器编排引擎，其热度和贡献者均大幅度领先，而Docker拥有最大的用户群体，是事实上的容器行业标准
容器技术在企业落地，需要考虑包括编排调度在内的多个层面，包括网络存储监控日志安全等等。
目前来看，云仅仅是实现了快速部署，但是其上面的软件安装并没有实现。因此云+容器才能实现环境快速部署。容器在企业环境投产是容器应用普及的必然结果，开发，打包，测试，部署，运维均放在容器里。保证环境的一致。
广告时间：Rancher容器管理平台，国内用户有平安科技，广发证券等。不过搜了下Rancher真的是一家很厉害的公司。
第三个演讲是新浪的大数据作用在IT运维领域
当研发和运维遇上大数据
新浪 凌霄
在新浪前期，做运维时有一些问题，主要反映在用户投诉问题定位慢上。
以此为背景，新浪it团队审视it基础架构，发现了几个孤岛：
- 信息孤岛
各类应用单独开发，接口规范不通用，难以整合。 - 数据孤岛
各个应用间的数据互相隔离，没有整合在一起。解决方法就是将日志集中存储 - 逻辑孤岛
常常出现开发认为接口返回就没问题，产品认为返回的不正确有问题造成的逻辑不认同。团队间协作不足。
因此新浪的数据团队建立了一个数据分析平台（图）
通过平台进行数据驱动的故障定位，过程为：
发现问题——》定位问题——》反馈问题——》解决问题
但是，单单进行简单的数据收集是不足的。日志需要整合，养成，才能变成带有足够信息的数据。
例如：WWW日志+GEOIP,CMDB+基础监控+业务信息=更有价值的多维数据
拿到有效的数据后，告警系统就可以开始运行了。这里有个误区，通常来说，公司都希望告警系统可以足够灵敏，但告警是不是越快越好呢？
对于探测类告警，如果太灵敏，可能产生报警风暴。（如设置CPU阈值大于50%）
对于定位类报警，如果太灵敏，可能由于告太多导致局部干扰性。
因此，有效报警是需要人工介入的报警。
最后，新浪分享了数据驱动中数据团队的定位：
当问题产生时，几个部门根据数据进行协作。而数据团队是创造一些处理数据的工具，并输出工程师为业务团队进行数据分析支持。
中午终于吃到了会展的午餐ರ_ರ
下午的课我仍然选择了产品设计思维，这节课的思路很新颖，在进行产品设计的时候，会将用户全部的行为完全考虑，而后思考在每一个环节能为用户做什么。
从产品设计到服务设计
From Product design to service design
讲师在自己的公众号上也针对这个专题写了一篇文章，可以看看：http://mp.weixin.qq.com/s/wFSDXYdPWmDhi67FiHAe-w
对于一个线上和线下结合的app来说，决定用户体验的不仅仅是app是否好用。比如百度外卖，如果送餐送的慢了，用户怪的仍然是这个产品。
产品不等于解决方案。
产品设计时画出故事线，演进客户行为而后研究得到需求。这就是SERVICE DESIGN。让设计不仅仅停留在产品层面，更专注体验和交互关系。让用户感觉到“好用”。
推荐一本书：《思考快与慢》
服务设计原则有四个：
- 用户视角
- 整体性
- 具象为实物
- 集体创造
如何进行服务设计？
1.用户画像
例如一个常见PERSONA：CBD女白领，大学本科，非本地人，24-32岁，月收入5000元以上
这样就够么？
好的用户画像应该包括：背景资料，故事，和产品的故事，期望，关心的话题，怎么向别人推荐我们的产品
画像并非一个实际用户，去现实中观察，别把自己当用户。
2.用户旅程图
在一个服务中，通过某种媒介产生价值交换的那一刻，称之为一个接触点，由接触点按顺序组织的一个流程图就是用户旅程图。
3.蓝图
蓝图是一种用可视化的方法详细、全面的描述用户体验传递过程。包含前台传递、后台传递、支持处理等过程，需要关注前后台的相互关联。
4.设计最小可行性服务
从简单的办公室O2O开始，在办公室拉几个人开始模拟。
朋友圈测试，在朋友圈拉人体验产品。
5.数据收集与验证
7-11的数据收集：所谓在必经之路上收集
因为7-11在收银机上做了限制，结账时柜员不按一下客人的年龄段钱箱弹不出来。
需注意：主动收集数据不如被动收集数据；解读数据比收集数据更重要。
最后一张ppt作为这个演讲的收尾。
录音分享
http://pan.baidu.com/share/link?shareid=2555560816&uk=3190277041
大会我听的最后一个演讲是Mesos在Qunar的应用。主要是通过Mesos,docker等实现了弹性扩展和日志数据采集和分析。因为有点太专业，没怎么记录，但是最后加了讲师的微信，后续交流一下。
整理笔记好累(╯‵□′)╯︵┻━┻
