> 3. 如果一个被点赞的帖子赞的比例超过一个值，那么每个点赞的用户都将获得经验。
> 4. 如果一个被点赞的帖子踩的比例超过一个值，那么所有对这个帖子点赞的用户直接降级。

这 2 点直接冲突吧，如果既有点赞，又有点踩的，都超过了一个值，该怎么办？

这最后不就演变成了“水军”和“真人”大战了吗？ “水军”如果要买“真人”的号(或者说买号、养号)，提高自己的攻击水平，该怎么办？“真人”个体能团结起来不被“水军”团体各个击破吗？

@anUglyDog 建议发帖时选好节点

@Livid 建议移动到"分享创造"节点

“递”“归”解释的很形象哦

标题太简短了，差点错过这么一篇好文。
说好文，不光是行文表达，更多是文字中透出楼主的独立思考，向往自由的思想。
引人思考的文章，给楼主点赞。

看了回复，决定给 Rust 种颗草。

@levelworm #11
嗯，数据相关的文档肯定是不能省的。我上面指的需求文档主要是程序逻辑相关的，比如业务逻辑。

至于你说的程序不支持相关的数据，按照我的理解，没有什么不支持的数据吧：
>表的每个字段都是汇总
为什么开发人员不能提供汇总后的数据，而需要你去拆分数据？
>有些数据服务器端拿不到，只有客户端才有
既然数据分析需要这些数据，为什么拿不到？如果要拿到，需要哪些工作？
>有些数据某些微服务才能输出但是这个战斗的程序不需要这个微服务，所以就没有相关数据
数据分析需要这些数据，这个问题不能够被技术解决吗？
>最后我还得把需求拆成几个需求，分别给不同的程序员，又放弃了几个特别困难的，最后才算是凑齐了大部分的需求
感觉你太委屈了。
作为一个开发，虽然我不懂具体你说的这些技术，但我能相当肯定，这些数据来源的问题是可以用技术解决的。可能你跟具体的开发人员中间，少了一个沟通的渠道，比如对接的人，或者说是一个对接的机制(比如敏捷会议)，以至于额外的工作都被你负担了。但你不懂开发啊，这些技术细节交给你处理就不合理。

另外，友情提醒一下啊：
> 比如说 telemetry 从 Kafka 进来，需要丢到 Vertica 里，这个表应该是什么样的？ telemetry 里哪些部分需要进什么表，表和表之间关系是什么
从这句话，可以发现你的表达方式是可以改进的。因为这里面的几个名词，甚至对于一般开发人员来说，都是无法理解的，如果把它们换成可以被理解的概念，是不是好一些？ 这就引申出一点： 如果你与你们公司的开发沟通，能不能采用一种大家都可以理解的中间语言，来避免“鸡同鸭讲”的现象？你也就不用去学习那么多开发的东西了。

@HeyXiao #1
@SilenceRE
对，拆分子任务可以只拆当下要做的，只需要第一步(first action)就足够了。目标就是克服跨出第一步的阻碍。
有时，心理总想着定个时间把这个任务结束，把任务**集中**安排到某几天，心理压力很大，不喜欢的任务集中程度太高很容易产生厌烦，反而进展甚微。还不如把它们分散到不同的时间里，每天都有一点进展。

@levelworm #7 >
问题是，你这是在迁就研发啊，效率的瓶颈不在你这里。研发为什么不能理解你说的需求呢？是他们不上心，还是说你没有解释的很清晰？ 我觉得不论是哪个，解决的的根本之道都不在于你是否去进修计算机。

可能问题还在于项目的流程吧。你自己也提到过之前的项目流程比较乱。有没有了解过“敏捷开发”这种项目流程，它跟你理想中的项目小组挺像——每个成员都充分参与项目的讨论，充分理解需求，充分沟通。你一直在说的“需求文档”，在这种项目流程里面，根本没有那么重要。贴一下敏捷宣言：

“个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。”

@levelworm #7 >

不懂游戏这块，你说的数据建模，是针对的游戏本身的数值平衡，还是针对的游戏玩家数据呢？
做业务分析的话，懂一些程序肯定能有所帮助。不过我觉得，大部分时候，知道大概就足够了吧。比如我的业务需要保存这块、这块和这块的数据，在需要的时候能把这些数据调出来以供分析。至于研发用什么框架用什么数据库，我不需要关心啊。难道研发能说，你这个需求不合理，这 3 种数据不能一起拿，会影响效率？？也就是说，提靠谱的需求，需要了解研发的架构吗？？
你说的这些给我的感觉是，你因为感觉无法亲手控制研发的工作，又感觉没办法给研发解释清楚自己所理解的东西，以至于他们没办法充分配合，当然也可能因为研发本身就没有什么积极性，所以，你想要自己去学习一下程序世界里的概念，然后用这些概念去和开发人员沟通。

> “第三个会是在写下需求文档之后，和研发以及数据库组进行沟通，敲定所需要的 telemetry 和数据库表的结构”
很好奇为什么需要你做这件事。做项目管理的为何要关心数据库表的结构呢？这就是导致你“大部分时间其实都花在和研发的沟通上”的缘由吧。需求表达清楚了，自然由研发来设计相应的框架，难道还要根据研发使用的框架来修改需求吗？即使需要这样，也应该与一个研发的代表来讨论沟通啊。

@chenyu8674 我也试过这种方法，挺好用。当然，对于软件开发之外的任务就不太行了

公事公办。为啥不能说呢？
想想你们公司不发工资也不发通知是什么感觉：
/t/762415

我也有类似的想法：
点子：历史知识的可视化，/t/703099

恭喜楼主。
话说“恶斗黑中介”这节，很多北漂都经历过吧。

@drunkdog 描述很形象，哈哈。“不发通知”这个动作很奇葩。公事公办，不知道有什么不能说的。

@drunkdog #4, 也是类似的情况？
@coderluan 说的是。哎，我又在发泄情绪了。

根据你之前发的主题，你做的 app 应该可以同时具备发射端和接收端。这样根据发射端和接收端的时间差的变化就可以实现啊。
发射端把发射时的时间发送到接收端，接收端用接收时的时间减去它，得到声音传播的时间 dt1
后续类似地得到 dt2, dt3...，可以知道是靠近还是走远了。
这个时间差应该是毫秒级别的吧，就是不知道硬件能不能处理