教科书里讲的业务/需求分析

Posted 2021-02-10

最近读了几本BA的书，学到了很多方法论、案例、工具。但是，很多方法论和案例都来自美国作者、美国项目，多数情况是不太符合中国项目的实际情况的。
比如，要坐下来跟业务人员讨论业务，想办法发现业务目标，再做流程改进。这一点对于2B的应用或服务来说是极其困难的。

现实情况是，软件/IT部门服务于业务部门，业务部门不懂技术但非常强势，软件/IT部门话语权不高，外在表现大概会有需求频繁变更，做不切实际的发布计划，技术不得不做很多的妥协，或者陷入需求变更的泥潭。

另一种常见情况是，软件/IT部门将项目外包出去，或购买高度定制化产品，自己充当业务部门和项目方的沟通媒介，业务部门具体工作执行人员和负责实现的技术人员之间隔了业务主管、甲方主管、甲方主管的项目负责人、项目方销售、项目方售前，在中国的各级汇报制度下，业务分析人员和直接的业务执行人、技术架构/开发人员几乎没有可能坐在一起讨论真正的业务目标是什么，而且每经过一个中间人，信息就会损失10%～30%。像书里写的，跟业务人员一起工作生活，观察对方的工作情况，发现业务改进点，在国内外包或定制这种大环境下，也不太可能。

还有一种情况是，技术部门有钱有资源，但跟外包人员一样，也不懂业务。而且由于部门与部门之间天然的竞争关系，甚至不如业务部门自己找的外包服务人员了解自己公司的业务。

另一种情况是，甲方不知道自己的业务存在什么问题，也不知道怎么改进，乙方不懂自己的产品能卖给谁，销售人员“碰巧”发现了甲方潜在的需求，找来乙方，自己在中间充当业务需求分析师。

通常，外包公司会考虑到项目成本，支付给研发人员的工资不足以找到技术、沟通、业务分析水平都比较高的人，定制需求满天飞，却不能复用，往往是没有真正了解对方最核心最本质的需求，技术和业务的积累也不够，看似天天加班，实则效率很低。

互联网公司之所以强，强在技术和业务的结合，通过技术手段提高业务服务的质量和速度，之所以由盛转衰，也往往由于技术和业务的脱节，或者一起走向衰落。