这是学习笔记的第 1832篇文章
今天从腾讯云组织的开发者大会归来，感受还是蛮多的。
这是一个面向开发者的技术大会，所以内容和范围相比运维圈要丰富的多。
今天来参会的一个亮点是参会证是引入了IOT技术的新玩意，引入了物联网平台开发实现。可以通过扫码得到自己的专属铭牌，还可以查看会场的传感器状态。。。
今天来参会的一个重要原因是作为入选的社区专家，腾讯启动了一个新的社区计划，简称TVP.
启动仪式由几位重量级人物开启，包括我们常听的鸟哥，极客邦的池建强老师，58CTO邢宏宇老师，蘑菇街的顶天老师和腾讯云副总龙哥。
首批入选的专家大头贴，能看到我在哪里吗？
在技术分享之外，我对这个现场的嘉宾问答交流环节很感兴趣，里面聊到了很多大家经常关注的一些问题。
有三个问题印象尤其深刻。
第一个是技术发展的预测，这个问题的回答最后落实到了一些实处，预测未来的一种方式就是回顾历史，在技术建议上，陈皓老师说到，我们现在需要追求的应该是更快，更好，更便宜。能够快速的支持和响应业务，使用更少的人做更多的事情是我们工作的一个方向，从历史的进程来说，每一次工业革命的改进底层都是自动化，当然这个过程中也有很多的技术债需要补。
第二个是开源社区回馈的问题。 近期Neo4j选择了企业版闭源，Redis,Kafka,MongoDB也选择了修改开源协议，对于开源社区的讨论很多，对于云厂商的角色和开源回馈成为大家讨论的焦点。几位专家都给出了一些独到的见解。1.开源软件收到社区的喜爱，因为客户场景的差异，云平台是充分检验开源软件的一个好的平台，而对于开发者来说，选择了云产品，提高了效率，而为什么不去选择企业版的特性，这个换一个角度，其实是有些开源产品的企业版功能没有打动开发者。当然在一些云厂商和大厂对于技术的支持力度是很大的，存在一种现状是对于大厂所提交的patch，原厂的处理效率会有延迟，同时有些特性和功能是基于特定的客户的场景，对于原厂的角度来说，这个feature就不是一种必选方式了，在协作和沟通上也会存在一些差异。而最根本的这是商业法则使然，很多开源项目并不如我们想象的那么纯粹，里面也会有利益的权衡，在这种平衡之中，必然就会有利益的差别，而选择修改协议是一种原厂的一种处理方式，本身也是为了商业价值而考虑。
第三个问题是从一个前段时间的小视频做引子，是一个产品经理和开发因为一个奇怪的需求而大打出手，对于产品经理和研发的关系，大家可谓讨论出了一系列的妙招。
我林林总总收集下俩，大体有如下的一些建议。
-
腾讯云龙哥的建议是产品经理和开发的目标要对齐，在目标对齐的情况下，才能使得双方的目标感更强
-
蘑菇街顶天老师的建议是产品经理和开发可以角色互换，通过这种工作方式能够更加深刻和切实的体会两种工作类型的思考方式和差异
陈皓老师总结了两点，
-
一个是信条，首先开发和产品经理聊，需要明确要什么不要什么，为什么会有很多冲突，就是因为开发支持了需求，但是产品后续还要这些还要那些，所以在开始的时候就明确的定好边界，尤其是哪些不要需要聊清楚，在后续才会使得需求方向和内容有所收敛。
-
一个是排期，考虑产品的需求需要从业务影响力和时间成本上来考量，如果一个产品需求业务影响力不高，而且时间成本高，那么这件事情的可行性是需要打上问号的。而对于哪些业务影响力高，时间成本不高的事情，是需要优先去处理的。
池老师给了3点建议：
-
第一个是产品不要经常催开发，不要问行不行，一催一问就出事。
-
第二个是产品经理和开发要彼此尊重，在尊重的前提下，问题的处理才会相对理性克制。
-
在工作中我们需要做减法，需求有很多种实现维度，但是我们需要对需求做减法，让需求实现最精要的部分。
-
主持人小姐姐给了一个额外的建议，那就是我们可以在工位使用一个收款二维码，这样每一次沟通都有一个成本，大家才会更加珍惜每一次的沟通，当然是开玩笑的了。
关于这个部分，陈皓老师举了一个例子。说论坛里面有一个人提问，说怎么截取一个字符串最后三位，结果大家聊了好半天，突然有一个人问为什么有这样一个需求，最后才知道这个网友是想截断文件的扩展名，但是显然有些文件扩展名不是三位，这样一来明确了需求，其实我们的处理方式从逻辑出发才会回归问题的本源。
关于逻辑需要补充一个我个人今天想到的一个小案例。比如我们知道郭美美，大体知道这样两个信息
1.她唱过一些歌曲，比如《不怕不怕》
2.参与过红十字会的一些网络舆论，网络影响不大好
但是这两个信息组合起来，其实很容易犯逻辑错误，这其实是两个不同的人，只是名字都叫做郭美美而已。
而我们的工作中偏理这种核心逻辑的事情其实很普遍，绯闻如此，误解也是如此。
