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流程并且需求的引出和文档化已经完成,就会知道更多内容。此时,可以重新估算剩余的工作,并就是否实施所有要求或是否推迟低优先级要求的工作做出决定。   

业务分析设计

猜你喜欢