7
管理上的判断和技术上的判断
source link: https://zhuanlan.zhihu.com/p/196527824
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
11 条评论
写下你的评论...
- 李浩博08-25
堆资源这种适合已经有竞争对手趟过雷，可行性没什么大的问题，只解决工程实施的问题，但是一旦进入前沿未知领域，还是需要分散方向，多点开花快速迭代。
知乎用户08-25所有的提前判断，都是失去正确方向的开始。
- 技术上的判断只能判断它能不能做到，无法判断要不要投入做出结果。管理是判断要不要投入。不能把这两种判断进行比较，因为本就不在一个层次上。技术判断的结果即使是反对，也是帮助管理者发现问题，从而纠正策略来达成结果。
我认为文中两种决策函数的 D 在不同角色视角下是无法等价的。即使问题表述看起来一样，管理和技术对 D 的概念认知还是有差异。 但两者最终还是面对相同的目标：到底如何决策。
技术上这个能不能做到的判断会反馈出需要什么资源的条件, 这个也就又影响管理端的思考根据了.
知乎用户08-25有了最优化的目标才能找到合适的决策函数，所以问题关键在于真实的需求是什么。：）
- 大马08-25
估时这件事情其实有好几个场景，不同的场景要求是不一样的。
场景1：老板想到一个主意，想初步知道投入会有多大。
这种情况需要和PM先同步对需求的理解，然后根据技术负责人的经验拍脑袋给个大概的预估就行了。技术负责人要做的事情是挖掘一下这个需求，看看有没有什么落地的风险和遗漏的点。
场景2：PM给了产品文档，做方案评审，通过之后要做项目估时，想知道什么时候能上线
这种情况下，产品已经比较详细的定义了需求，技术依然是根据自己的经验去简单拆解一下需求，拍脑袋评估时间，只是此时发生遗漏的概率已经大大减少，所以评估时间会更准确一些。
场景3：方案设计已经，技术方案评审完，需要各个参与方估时，确定联调上线时间
这种情况下，技术层面的不确定性应该也已经被（大部分）消灭了。评估应该是最准确的，当时实际执行过程中依然会充满不确定性，可能一个bug验收就卡了1~2天都是常有的事情。
- 小清新08-25架构更关心怎样实现，避免让管理的美好预期落空。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK