别问这个功能需要多久做完？
不要总去问基层员工，这个功能需要多久做完。如果问了得不到想要的结果，也不要暴跳如雷。
当然这个很容易引起争议，也不是绝对真理，单纯就是发泄情绪。直接放结论吧，如果领导真的关心一个功能什么时候能做完，需要多久，请去问项目经理或开发组长。
设想一个场景吧，客户打电话/发微信谈到一个功能，或者反应一个Bug。/*这里没提邮件，因为很多客户Low到不用这种延时性质并需要组织文字的通讯手段*/。于是领导/经理直接杀到一线开发人员那里，开免提，放语音，点大图，然后问出经典问题:这个需要多久完事？
然后开发人员一脸懵逼又战战兢兢，首先前因后果就不太清楚。等听明白咋回事，立刻盘算着手头的活，再加上现场这个，在心里对优先级来一场冒泡排序；随后迅速来一个极大似然估计，猜个完工时间 /*是猜的，根据测不准原理，不要觉得自己算的时间很科学*/。然后再盘算一下，报的时间长了不行，看领导脸色有点不豫，时间短了也不行，干不完容易背锅。最后深吸一口气，用果断的口气说首先然后其次，综上我估计大约一周完事。领导比较满意，还是X工说话痛快，不像那个孙工，每次问多久完事都告诉我做起来才知道，就是不给个准信。
还是那句老笑话，由于不能拿狗做实验，很多人不认为软件工程是门科学。
我们年轻的时候都学过时间等于路程除以速度，那总的软件路程未知，解决问题的速度未知，算出来的时间有个屁用啊。我敢给，你敢信么？
基层员工的工程管理本来就难做，很少有人是怠速运转的 /*怠速工作请推荐给我*/。很多人同时负责几个项目，或许接活的时候基本都能评估新工作对自己手头的活的影响。但是，很少有人能从全局考虑，自己是否处在关键路径上，自己的变动是否会对全局有影响。处于关键路径上的人，非常容易发生一人加活，全组后延。实际上只有广义上的项目经理才有权去给时间。
其次是功能难度，听完一个功能描述，就能给出准确的时间，这其实非常的需要水准。很多人给出的时间不准，要么考虑不到天外飞仙的Bug，要么考虑不到可以参照的家底，要么低估了上游产出的延迟，要么高估了自己开发的效率。前期摸鱼飞弹后期疯狂加班，压哨完工看说我估计一周多准，那后续改Bug的时间再算上看看呢？实际上只有架构师或成熟的开发组长才有权给速度。
更难做的是预期管理。领导表面上说就是想了解个大致完工情况，心里有个数就行，没啥别的想法。但是当员工真的给你个时间，你就不可避免的去估算多了还是少了。你表面上没有期望，但是就像抛硬币的瞬间往往暴漏了内心真实的选择，估算的那一刻起，也不自觉的将时间长短与员工能力隐形挂钩，然后没想到的是这个时间因素是如此的不靠谱，建立在其上的期望更是无稽之谈。
所以当面临一个新功能的时候，最理想情况还是项目经理跟开发组长约定时间并布置。他们理应对项目理解更全面，对功能把握更深刻，手里有资源可以调度抗风险。而基层员工只能自己硬抗，而多报时间又是个非常有风险的做法，次数多了容易失去领导的信任。
当然以上都是理想状况，实际上我作为基层员工，也不指望真空中的球形鸡有什么帮助。基本上我参照市场上跟我同等工资人员的解决问题速度，估一个稍短的时间。为什么估更短的时间，是为了证明我能力比工资强一点点，而且估时间长了容易加倍摸鱼。
要是玩脱了怎么办，很简单，按照如下步骤
做完整版->做核心框架->做可演示UI->辞职
依次执行即可