【开发】技术方案实现与评审

【开发】技术方案实现与评审

1、方案评审

目的：证明你的能力符合目标职级的要求。证明你日常善于思考、善于分析，有创造力。

内容：方案是什么，怎么做的，怎么讲给不了解的评委听。

1.1 What（方案的设计与推导）

• 不要堆列产品功能， 要讲推导的过程，同时推导要能够自洽。

1.2 How（方法论，思考，沉淀）

更关注这个，也就是How

• 没重点：调理清晰，重点突出几个点，再侧重性的讲。不要整篇wiki的念。

== 目标的case

流程更清晰
问题：没有站在用户的视角上考虑，贴了过多的代码细节，没有清晰的步骤呈现，内容逻辑上缺乏衔接。
改进：要以给小白讲懂为目标，大体框架和逻辑增加推导的过程，不要只讲细节的逻辑。

需要突出事情的价值
问题：没有把难点和价值讲清楚，点太小，太多了，都是case，没有目标和价值。
改进：对用户屏蔽了复杂度，降低了成本，是我们的价值，但是方案评审的时候还需要呈现出实现上的复杂度。

控制演讲时间
问题：总共30分钟的演讲，语速很快，但10分钟过去时仍然在讲开头。
改进：合理的选择跳过不重要的内容，把控好时间，如果被挑战就回复自己在讲方案推导。

• 没难点：困难和解决。要给出分析过程 ，比如为什么取值1000？怎么选择的？

==推导的case

结论的推导
问题：讲解方案时不要只讲结论和做了什么，不然大家会认为本来就是应该这么做的，降低了其他工作的价值。
改进：要先有问题引入，然后一步一步的推导。比如为什么要注册项目，为什么要怎么做，怎么想到这个流程的。

对比维度的推导
问题：对比的方案数量不够，维度不足，维度选取也有待改善。
改进：至少要对比3个以上，同时需要补充维度的推导过程，为什么选取的这些维度。

衔接的推导
问题：衔接过于生硬、缺少思路和引导，上来就贴一张图，直接从一个主题跳到了另一个主题。
改进：可以加个冒号进行衔接，解释一下为什么这么做的，方案怎么推导过来的，不要用结论往回套。

...

• 没亮点：方案对比，这么做有什么好处。

==例子的case

例子更具体
改进：举详细的例子增加自己的价值，如用户接入时遇到xx问题，如各步骤原先用户的耗时，现在的耗时。

例子更合适
问题：只贴了photoshop的图，用简单的图片举了几个常见的场景，不能贴切的帮助整体思路的理解。
改进：例子需要更贴切实际场景，增加明确指向的内容和推导的过程，讲清楚问题是什么，以及如何解决的。

例子突出价值
问题：顺着文档念和单纯的介绍流程，没有突出产品的用户价值和实现难点。
改进：重视讲而不是念。通过举例子铺垫，如别人以前接入一个项目需要xxx，现在只需要xxx，通过对比突出我们的优势。

1.3 表达（具象，抽象，再泛化）

• 具体表达：先具象（细节先让人有印象），再抽象（专业名词，结构化思维），再泛化（具体的例子）

• 被挑战：

  • 答不上来的问题，都可以重新来重复整体思路。学会"答非所问"，要能够回归问题本身的解决方案上

    ”我们整个项目最终的目的是要呈现出xxxx“

• 被深挖：

  • 点赞，感谢补充，然后给出解释和思考。 “感觉XX的补充，这个问题我是之前是这么考虑的“
  • 做的好的，反复重提。 ”这个确实考虑不周全，但是另一个点上，我们做到了xxxx“
  • ”我认为这个原因，主要有以下三点“

• 心态： “我觉得XX哥你挑战的这个点挺好的，这个问题我是这样想的…….”

==表达的case

压测应对
问题：有时候的挑战只是单纯的压测，并不是说这个方案有问题或者不好，但是如果没回答上来就会扣印象分
改进：按照自己的思路灵活应对，将问题解释清楚即可，侧重强调方案好的一面。

2、方案实现

（仅供参考）

1、背景

2、现状

• 2.1 目前XXX状态

• 2.2 用户使用数据的场景

• 2.3 业界的解决方案

• 2.4 与XXX的区别

3、目标

• 3.1 总体目标
• 3.2 用户关心哪些
• 3.3 XXX的呈现方式

4、方案

• 4.1 数据源调研

• 4.2 数据表概念模型

• 4.3 XXX数据入库

• 4.4 XXX数仓分层设计

• 4.5 数据计算

  • 4.5.1 任务的拆分与组合

  • 4.5.2 拆分视角方案

  • 4.5.3 多维度汇总方案

  • 4.5.4 一对多关系方案

  • 4.5.5 数据压缩方案

  • 4.5.6 其他踩坑与改进方案

• 4.6 前端联调 & 交互优化

• 4.7 项目复盘

5、可测试性设计

• 5.1 准确性 — XX系统

• 5.2 可观测性 — 质量规则

6、工作成果