weekly-summary-20200712

今天看到一句话：选择比努力更重要的一个理解：做大事与做小事的难度是一样的，但是回报是不一样的。

这句话我不完全认同，但是还是部分认同。这和跳出舒适区有相通之处。

数学家理查德·汉明（Richard Hamming）总是问其他领域的科学家：”你的领域中最重要的问题是什么？”，然后问第二个问题：”你为什么不研究它们？”

我们的问题：没有明确业务方向

我其实就一个事情没想清楚，那就是业务方向。

明确业务方向->明确需要什么样的人->明确需要多少人->明确招聘需求->干就是了！

没看透问题，盲目跳坑

之前跳进可视化的坑，现在我又继续跳入 B2C 组件化这个坑了……

我没有看清楚问题，我们面向的是 ToC 业务，而不是内部业务。在这种业务下，组件化能解决的问题太有限了，因为业务定制化程度太高了。

一件事你看清楚了才是机会，没看清楚就是火坑，千万不要随意跳进去。

如何快速实现一个新项目

关键在于能否把黑盒变成白盒，即把可能存在风险的地方全部弄清楚，信息透明化。

另外有一些务必要注意的具体的点，这里也记录下：

需要在初期确定的内容

谁总体负责这个项目？具体有哪些人参与这个项目？如何分工？

开发环境是否能快速搞定？

数据模拟问题，得找个有经验的同事才行，统一放在 yapi 上

可抽取为组件的内容有哪些？做好分工

项目如何集成？合并代码的方式和时间点？

进度管理(用什么工具、例会机制、如何信息透明化)

每天的阶段性目标和任务分解

几个注意事项

分解文档一定要细致、细致、再细致，细致到心里绝对有底

什么样才是一份绝对 OK 的任务分解文档？
我们应该在这上面投入至少 8 小时的时间，而且应该每天复盘修改

数据先行

一定要先把数据结构确定好，并明确数据提供时间

不要用新技术、不要用新技术

新技术=未知因素=不可控

功能分级

对功能做好重要等级的划分，在必要的时候，可以砍掉部分功能，优先完成一个可上的极简版本。

测试并行

可以给每个人划分好自己的分支，然后完成一个提测一个，让测试人员可以无缝衔接、多功能并行测试。

我是不是在搞可视化？

领导对于可视化组的期望和真正的可视化出现了分歧。接下去的路怎么走，我得慎之又慎，否则一不小心就会无法满足预期。

领导多了，路就难走了，因为每个领导的想法不一样，会导致方向越来越模糊。

接下去的工作计划

找各个主管聊，聊他们目前遇到的问题，作为我们的需求来源

重新制定 B2C 基建和数据统计目标，量化数值直接写到 968 上面，给大家节约了多少时间

想几个牛逼的点子，分配专人搞起来！

找数据方聊一下，ZY、TZW 他们；为什么牛逼？怎么搞的？

特别是 TZW 的知识图谱团队。

把所有前端资源拉过来，整合起来

每天五分之一时间用来聊，各种聊

不要埋头搞！不要埋头搞！不要埋头搞！

不要自我感觉良好，避免沉没成本
一定要经常找领导沟通
我在走 ZP 的道路，警惕！

数据可视化的 7 层理解模型

1、能看到的都是数据可视化，能解决任何问题

2、知道折柱饼，能用

3、正确使用折柱饼

4、关系、地理、3D，横向扩展

5、与其他学科进行结合，比如智能化、个性化

6、未知

7、未知

生活(live)还是生存(survive)

我现在是在 survive，而不是真正的生活。