项目经验 | 一定要多思考，过脑子
前言
老妹是一个数据开发同学，最近在参与一个中台项目的实时数据建设，这也是她第一次完全的投入到一个项目体系当中（之前都是在某一个项目中负责一小块）。
就在做这个项目的过程中，遇到了一些问题。
比如可行性调研和技术方案的细节也七七八八的写了不少，但是实际上需求整体的推进进度很慢，迟迟没有进入到开发阶段。
依赖的上游接口不确定，整个项目的推进就暂停了。
和上游沟通了半天，但是聊完之后发现好像没有什么可行的结论。
总的来说就是，需求推进慢，推进方向不正确，导致浪费了很多时间。
于是老妹抱着这些问题找到了羊老狗。
需求提出
需求评审阶段之前好像还有一个阶段，提出需求阶段？？？
开会时候说的【这个可以提成需求】？？？不太理解，这里是否有一个阶段？？？
需求评审阶段
需求评审阶段非常重要，需要根据目前的能力合理评估需求
- A：哪部分需求，以目前的能力经验能评估可行性或者收益很低的，可以直接同步出去；
- B：哪部分需求能做，但是从长远来看，目前做完的结果只是一种过渡方案，可能 1-2 个月之后就会有代替方案的项目，这部分可以支持
，但是没必要为了做成而去支持复杂模块，不必要投入全部人力做这类临时的方案； - C：哪部分可以做，并且从长远来看，收益很高的，这部分我们可以深度调研方案。
分别举例如下
A
- 目前从技术上是不可行的，或者从资源层面是不可行的，比如我们目前的能力是能抗住 100w qps 的压力，但是需求可能是 1000w qps；
- 分析场景上不合理，我是数据人，有的数据需求可能从分析场景上不合理，比如这个场景其实是算 pv 就可以得出结论的，但是需求是 uv，这类就没有必要，而且 uv 相对 pv 肯定更加耗时耗力。
B
- 我目前是做实时数据的，用数据举例。目前的项目有两种方案：第一种方案是实时数据产出 A 维度数据到 OLAP 中，后端在查询 OLAP 时填充 B、C 维度，最后在看板展示数据；但是目前由于人力问题，后端没法支持完成。
因此就有了第二中方案，第二种方案是实时数据产出 A、B、C 维度数据到 OLAP 中，但是数据源没有 B、C 维度，B、C 维度的数据只有后端才存储，所以实时这边需要去存储了 B、C 维度的维表当中做关联操作，并且关联存在一定的难度。
这类情况下，实时关联 B、C 只是一个过渡方案，从长期来看，其实这部分没必要因为一个临时方案，而过度投入人力在收益很小的这个方案里面，可以做一些舍弃。
C
- 从长远来看可以做，之后会有越来越多的业务需要使用我们产出的数据，那么我们就可以针对这些业务做通用化模型建设，收益高。即使多加一些人力在这类需求上也可以。
以上这些情况在需求评审阶段，都需要对产品有一定的观点输出，可以表达我们的观点，技术可以做什么和技术应该做什么。
需求评审完成之后，就可以进入需求技术方案调研阶段。
需求技术方案调研阶段
技术方案调研 + 设计（5W 1H）
我们和上游能够沟通的内容是哪些？比如数据就是加字段，能不能同步一些表？？还能做什么沟通？？
排期能不能沟通，应不应该沟通，应不应该自己去沟通，或者最好什么时候去沟通？比如等整体的技术方案确定下来，确定了工作量，然后去定排期
和产品能够沟通的东西是哪些？
需求合理性？
需求目前遇到的问题？
需求的技术方案可行性？
得等技术方案完全确认才能够评估工作量？
和上下游能够沟通的东西是哪些？
能否做支持？
整体就是 5W 1H 的方式去调研整个技术方案。
首先第一点，最最最重要的就是一定要有目的的盘东西。我最终要产出什么（WHAT），我的上游依赖是什么（WHAT）。
举例：需要产出的东西 - 目前手上有的东西 = 上游依赖。只要明确了目的，其实这部分东西很快就能够盘清楚。
第二点，我们盘清楚上游依赖之后，就是需要去想一下这些上游依赖可能存在的提供方式。
举例：这些上游依赖是必须都要其他上游提供吗？能不能通过一些其他的方式自己进行实现？
第三点，如果目前的技术方案满足不了需求，那么还有没有其他的方式进行实现，一定要多想可行性方案，可以多提供方案，但是方案的优劣可以让产品进行取舍抉择。
举例：比如数据上面需要一些维度数据，我之前可能就评估各类方法去关联维表去填充这些维度信息。其实还可以推动上游数据去添加这些维度数据。
让可行性方案变多，我们只需要去评估可行性方案的优劣。
推动上游去做改动时，一定要通过业务角度解释这些数据的通用性，不可能每来一次需求添加一次，那样会被喷，上下游压力都很大。
第四点，数据人遇到问题时能使用数据说话就使用数据说话，包括方案的可行性等。
举例：调研后发现，这个实现成本很高，反馈的时候一定要用数据说话，比如成本达到 xxx，使用 xxx 台机器，这个成本是不是可控的。尽量避免技术方案评审时只能反馈实现成本很高。
第五点，遇到问题时一定需要尽早的抛出问题，推动各方解决问题，而不能 block 在自己这里。
举例：比如在技术方案上，自己可以先和 tech leader 详细讨论，一定注意详细讨论的前提是自己对整个项目目前的需求理解一定要到位，理解有问题的地方及时和产品沟通，明确理解需求。
我就犯过比较明显的错误，经常会被 tech leader 问你调研的这个东西合不合理，有什么价值，这个东西能不能用其他的东西进行替代，或者你的方案为什么是这样的，这只是一个过渡的方案，我们有没有必要去完全按照需求要求的产出。
第六点，技术调研过程中，如果遇到上下游依赖的话，可以先和上下游方进行沟通，与上下游沟通一定要把握一个度，这部分可以慢慢学习理解。
需要站在自己做的事情的全局上和未来的通用性上去思考问题，不但要思考自己的东西，还要站在上下游的角度上思考问题。
举例：沟通时可以和上游确认这部分上游能不能做支持，哪部分能帮忙支持，哪部分不能支持。站在对方的角度上想问题，比如自己需要的某些字段或者数据，其实站在上下游的角度上是不需要的，这个就需要多考量。
上下游支持如果还存在难度的话，那就需要和产品同步目前的整体问题，让产品去推动各方或者是做一些取舍。
第七点，方案的每个细节都需要确认。做数据，那么数据每个字段都得清清楚楚的列出计算逻辑才算需求调研完成！！！不然很容易出现口径不一致和可行性问题。
通过上述几个步骤之后，都要最终和产品确认我们产出最终交付物。
这里结束之后，其实我们自己大致的工作量也就大致可以评估出来了，工作量是一个很迷的东西，如果工作经验不长的话，很难估计一个准确的工作量。
不一定就是利用现在手上有的东西去做需求，还可以去推动其他上下游去支持需求。
做项目时，没必要一口吃一个胖子，也没有必要钻一些牛角尖，有些东西比较难做，我们可以先实现简单的，后续再优化方案，进行迭代，没有什么项目是一次性能做完美的。
需求排期
Question
1.什么时候可以进入排期阶段？
技术方案敲定后排人力，按照项目上下游情况排期？
2.排期的时候如果依赖上游，上游的排期应该怎么沟通？或者我们和上游能够沟通的内容是哪些？
上游的排期不应该自己去沟通。但是产品又会问，你拍的这个期有和上游沟通吗？
3.有哪些方式去做排期？
倒排：比如产品希望这个需求或者功能在某个时间点上线，那么我们就需要按照这个时间点，往前排。如果有上游依赖，还需要定下来上游依赖最晚给到的时间点。
举例：比如产品希望 11.30 号整体上线，如果开发、自测需要 5 人天，联调预估需要 2 人天的话，我们就就可以排 11.22 开始开发，并且还需要根据上游依赖的强弱指定上游依赖给到的时间，比如 11.23 号给到。
最后还需要留一定的 buffer 给自己，避免中途出现问题。
正排：这种情况下，一般都没有给定的截止日期。
3.为什么要这样划分排期？
排期一般划分为一下几个：
- 开发
- 自测
- 联调
- 回测
- 上线
很多情况下，尤其是多个项目组合作的项目，一般都只能排到联调
4.排期过程中容易忽略的关键点？
- 上下游依赖：上下游依赖很重要，上下游如果一旦发生 delay，咱的排期可能就会受到很大的影响。资源、上下游接口等等等等。
- 风险控制：一定要说明风险点。比如资源，上游依赖，上线前的前置依赖等。最好可以有一个 checklist，根据经验列举自己在开发过程中可能会遇到的各类问题。
5.所有的东西不能都以 mock 的形式进行，比如为了赶排期，复杂项目的联调全部使用 mock 数据就会存在问题
开发
1.开发过程中最需要注意的就是单测的编写，一定要记得编写单测，保证每个单元的代码都是正确的
2.数据开发完成后需要验数，验数过程是很重要的
