BA如何应对管理层试图减少你的分析时间?
作为经验丰富的业务分析师，我们经常被要求估计特定任务可能需要多长时间。如果您在一个不断尝试用更少资源完成更多工作的环境中工作，那么您可能也经历了必须为大量分析工作合理化估算的艰巨任务。
考虑以下情况：
80小时-记录AS-IS业务流程
150小时-引出和记录要求
100小时-记录业务和系统流程
400小时-编写功能/设计规范
总共730小时
稍后你会发现，管理层的高要求是500小时。
这是业务分析师现在被问到的问题：
是否需要150个小时来获取和文档化需求？你能在100小时内完成吗？如何编写功能和设计规格？你能在350个小时做吗？通常，业务分析员会以“我猜是这样”作为响应，但后来才发现工作进度落后，他们需要整整730小时，甚至更多！
所以，业务分析师应养成提供更详细的工作分解结构和估算的习惯。通过将每个任务分解为更细粒度的子任务，可以实现许多好处。
1.估计更细粒度的任务时，估计导致的误差水平往往更小。业务分析师对6或8小时任务需要多长时间才能完成，与估计400小时任务大不相同。你怎么知道它需要400小时，或360小时，或440小时？
2.管理层几乎从不质疑非常细粒度的任务。你有没有听过一个经理看着一个有50个或更多个任务的工作分解结构，然后说，这个任务真的需要8个小时吗，或者你能在6个小时内完成吗？这有几个原因。首先，他们对你估算小任务的能力有更大的信心。第二，即便节省两个小时，也相差不大。相比之下，他们看到一个400小时的任务，就认为他们可以减少40或60小时。现在就是这样。
3.更精细的工作分解结构使每个人在完成工作时步调一致。这揭示了，如果团队只关注高级别任务，就可能忽视一些相互依赖关系。
一个好的经验法则是，在估计时，没有一项任务应该大于40小时。如果你知道你的管理层有重推估算的习惯，确保没有一项任务超过20个小时，大多数任务都少于8-12小时。
当然，随着工作的完成，您可以而且应该重新评估估算，然后从分析过程的一个阶段转移到另一个阶段。一旦记录了AS-IS流程并且需求的引出和文档化已经完成，就会知道更多内容。此时，可以重新估算剩余的工作，并就是否实施所有要求或是否推迟低优先级要求的工作做出决定。