各位请问怎么提升评估需求的能力？经常产品一句话需求，然后问我多少天能做完，虽然这个看似很难，应该有方法的对吧？这属于哪方面的能力呢，看什么书能够提升呢，求指点

[0x0208v0]

如题，自己大多数时候都评估不准，我觉得是自己对需求理解的不够好，自己业务能力太差了，怎么提升呢兄弟们

[murmur]

那说明你还是干的太少，逼撕的不够

[PythonYXY]

一般工期往多排

[oneisall8955]

拆解把所有接口都列出来，每一个接口都估算时间排期

[lucays]

简单啊，以之前的经验，每次估工时后实际多花的时间，然后把这次心里估算的工时加上这个时间就好了

[janus77]

干的多了就会了，正常情况下一般产品一句话出来你脑海里就有一个初步技术方案了，剩下的就是评估这些技术方案的难度和工作量，以及坑

[xuanbg]

把需求先画个思维导图，拆解到接口，然后你就基本知道要做多久了。

[wu67]

多写点代码大概就知道了, 然后在你能做完的时间基础上加半天到两天, 预留给踩坑的处理时间.
除非是你从没接触过的领域或者技术方案, 那时间可能就给不出

[wu67]

另外排期应该是个粗略的评估, 可能提前完成也可能超期, 它不应该是硬性时间, 不然这规则就是专门用来打破的了, 所以压力不用太大

[MJZ1995]

我就是产品啊，这话不就是 PUA 你啊，我一直会在开发的自我评估时间上多加两天。都是打工的，别搞那么紧张嘛。。

[Hurriance]

取决于对当前项目的熟悉程度，需要更多时间接触业务吧，看书倒不一定能起到很大作用，每个人接触的业务还是不太一样的。一般来讲肯定是需要多评估几天的，因为指不定中途需要处理其他的问题，例如线上问题、紧急需求，这多出来的几天都是合理的安排。产品可能也只是需要一个大概的回复来安排他的工作而已，我倒觉得不用在这点太纠结。

[edis0n0]

7 楼的基础上再加一周到半个月摸鱼的时间

[azarasi]

只能靠经验累积

[44670]

提升评估需求的能力的方法有很多，但最重要的一点是：要认真理解客户的需求。这可以通过多次沟通和问询来实现，以确保您对需求的理解是正确的。

另外，您还可以通过下列方式来提升自己的评估能力：

学习相关技能：您可以通过学习相关的项目管理方法论，例如敏捷开发方法，来增强自己的评估能力。

积累经验：随着您参与更多项目，您会积累更多的经验，这样就能更准确地评估需求。

寻求指导：如果您感到自己的评估能力不足，不妨寻求更有经验的人的指导。他们可能会教您一些有用的技巧和方法，帮助您提高评估能力。

在提高评估能力的同时，您也可以通过学习业务知识来提升自己的业务能力。学习相关的业务理论和实践经验可以帮助您更好地理解客户的需求，从而更准确地评估项目。

[Cavolo]

@44670 老 GPT 了

[fengjianxinghun]

问了下 ChatGPT AI
答：
为了提升评估需求的能力，您可以尝试以下方法：

1. 学习如何进行需求分析和评估。可以阅读有关敏捷方法论的相关书籍，了解如何拆分大型需求为多个小型需求，并估算每个需求的时间成本。

2. 充分了解需求。当您收到一个新的需求时，请详细询问客户，了解他们的真正需求是什么，并确保您清楚地理解了需求的所有细节。

3. 与团队协作。在评估需求时，应该与您的团队进行协作，共同分析需求，并给出估算。这样，您就可以利用团队成员的专业知识，更准确地估算需求的时间成本。

4. 收集历史数据。收集和分析历史数据，可以帮助您更准确地估算新需求的时间成本。您可以回顾以前完成的项目，了解实际用时与估算用时之间

[GuangXiN]

你要学会回答：「给我一点时间和小组同事讨论一下告诉你」

[mcfog]

1. 一般而言在你不熟练的时候，把任务规模拆小是个很好的方向，建议粒度可以到半天，注意上班以后开机新建文件夹创建一个空白项目的消耗也是半天，如果公司有什么仓库要申请，权限要申请，那就是一天
2. 证明你的多个小任务合并起来就能完成整个需求，一般而言这个证明也可以叫做“技术文档”，因此，在技术文档完成之前，不要承诺任何排期
3. 你一定会被施加出排期的压力，这个时候不要违背第二点的原则，比较靠谱的应对方式是给出排期的排期，也就是你需要多久能把技术文档输出。另外，你应该特别关注的是你的前置依赖，把这些作为阻塞项抛出来请求其他人的帮助，包括产品需求不明确、对接的其他技术团队不明确或者不了解需求、环境部署和以前不一样需要运维参与等等
4. 无论团队层面是否有复盘，每次需求上线后，可以自己复盘一下当初的排期是否有没有考虑周全的地方，下次排期更准需要改进什么
5. 我个人从来不做乘法或者预留名为 buffer 的时间，技术工作的总体方向应该是持续消灭不确定性，我认为留 buffer 是与此背道而驰的。也非常不利于团队之间的信任感和自己的持续进步。
有其他部门或客观情况导致需求做的慢，我不会去争取什么 buffer ，而是直接摆到台面上，比如：预计这个项目开发需要 3 天，联调需要 10 天，联调特别慢的原因是基于过往与 XX 团队调试的经验预估的。 而不是模糊的说什么预计多少天 buffer 多少天之类的。
留模糊的 buffer 那么磋商排期就是菜场买菜讨价还价；而明确的时间细分出来，要缩短哪一块的时间就哪一块是提高效率还是砍掉不做还是怎么处理

[LaGeNanRen]

经常产品一句话需求，然后问我多少天能做完
——评估工期应该在原型评审之后，如果当时有问题可以再进行一轮技术评审，然后大家订出工期。凭别人一句话讲个需求，谁也不能给出合理的预期时间
腼腆的人常常会自我调整来适应事和物，但有些时候你也需要思考，到底是谁的问题

[ruiyinjinqu]

我们一般是先需求评审，确定需求是否合理，从业务层面看是否重复开发，是否有必要；再项目评审，确定项目的技术难度和大致要多少接口，从技术层面提出问题；再组内讨论，看数据层，服务层是否满足需求；最后，就写项目工时，排期文档... 当然这是对大的整体需求；小的需求就看接口数，然后有疑问了再去争取时间

[cs3230524]

你是一个程序员，你为什么做项目经理的工作？让项目经理出需求文档啊，再牛的大神也评估不了一句话需求。

[GiantHard]

先凭感觉给出一个排期，然后报告的时候就乘 2 。例如，需要开发一个新的接口，你估计自己全身心投入需要 2 天完成，那么就报告要 4 天。

在工作中，尝试度量实际用掉的时间。可以用 wakatime （自动记录编程时长），或者间歇日志（ interstitial journal ，手动记录每项工作的用时）。

定期回顾，例如每周、每月回顾一下自己做了些什么，这个过程需要自己有意识地去感知自己在哪些方面用了超出预期的时间，区分导致超期的因素——是必然还是偶然。类似自身技术能力、对项目技术的熟悉程度等可以被自己主观影响的因素，往往是导致必然超期的原因；类似临时加塞需求、开发过程中遭遇需求变更这些意料之外的情况，通常是导致“偶然”超期的原因。

根据上面的回顾制定改进项，例如，如果是因为自己对项目不够熟悉，造成超时，那么应该花点时间熟悉项目（或者下次评估的时候，多给自己一些时间）；如果是因为自己身兼数职，开发过程需要反复切换工作上下文，那么可以尝试拒绝掉一些工作（或者下次评估的时候，多给自己一些切换工作状态的时间，也就是常说的 buffer ）。因为必然因素是容易预测的，偶然因素的影响总是不可预测的，所以需要**降低必然因素的影响，减少偶然因素的数量**（或者根据这些因素调整最开始提到的工时预估时长）。

书籍的话没啥好推荐的，关于这方面的书籍好像更偏向项目管理了。面向个人开发者的内容，我推荐极客时间上的《 10x 程序员工作法》。