本文是我读 《程序员修炼之道》的读书笔记。

我们在和别人沟通需求时，经常会被问到这项工作何时可以完成，我们如何能够比较合理回答这类问题呢？作者的观点我总结如下：

不要回复太精确时间

比如你可能回答这个需求需要12个工作日，这么精准的回答会让需求方误以为就需要12个工作日，也会让你陷入被动的局面，作者推荐回答一个时间范围，比如 10-12个工作日， 2-3个月，在回答时也需要考虑完成任务的前置条件，比如“如果不堵车我将会在20分钟内到达” 这样的话就是把前提讲出，这样就让需求方有了一个基于前提的心里预期，那么过了20分钟还没有到，那么肯定是堵车了，这样的沟通就会很高效；

如何合理的时间评估

我们需要对需求建立一个合理的评估模型，那么什么是评估模型呢？ 比如我们评估一个http请求需要耗时多久？可以根据服务器的流量，业务代码处理的复杂度，数据库的使用情况综合起来进行评估，再比如我们需要评估一个项目需要耗时多久？ 我们需要对项目的需求进行拆解，分散到需求分析、架构设计、前端开发、后端开发、集成测试、性能测试、部署运维等环节，每个环节还可以再进行拆解，类似这样的做法就是建立评估模型；

基于组件的时间评估

基于组件的角度去思考问题，每个组件可以有哪些输入，每个输入会有怎么样的输出，组件之间是如何联动的？ 一个组件的输出是另一个组件的输入，我们把这些组件的输入进行组织，形成一个输入参数列表，给出每一个种类的输入会有怎样的工作量；再把多个组件互相组合，比如A组件有M个输入，B组件有N个输入，当A组件和B组件组合一起工作的时候，是否就会有 M*N中可能性？

自我的总结

这些实用的方法都是需要平时不断总结才能很好的运用，作者没有讲技术，而是讲做技术的人该如何和技术以外的世界打交道，这里没有很深奥的知识，都是很朴实无华的做事的基本原理，把这些做事的原理和软件开发中的一些场景相结合，让我们多一个视角去观察、理解自己手头的工作该如何可以做的更好