业务分析师自己的故事

最近疫情爆发，我和在美国的闺蜜聊天，问她那边的情况，聊天中，她说现在处境很尴尬，因为她的老公在思科工作，是做硬件产品的软件自动化测试的，而她因为身体原因，辞职了，去美国做全职太太，而思科正在裁员，她老公没有在第一批裁员中被裁掉，但是裁员的幅度是45%，先裁员了25%，还有20%会在第二批实施，她担心做测试比较容易被裁掉。然后她问我现在在做什么， 我说我转型做了BA, 她就问什么是BA? 我有点吃惊，因为她之前和她老公一样是做硬件产品的软件测试的，也算是有IT项目经验的，难道他们原来的项目没有BA? 她以为我在做PM. 由此， 我发现BA这个角色, 还真是一个模糊的角色，因为我转型做BA之前的团队也没有BA这个角色，而有一个类似的角色叫PDM, 而现在所在的团队有BA这个角色， 却没有PDM或者PM这个角色，只有DEV,QA,BA以及一个claster master, 而PM的工作是没有规定是谁去做的， BA往往承担了这个工作。

BA是什么？

那么BA是一个什么样的角色呢？

根据软件需求（第三版），业务分析师是一个角色，而不一定是一个头衔。业务分析师的首要职责是获取、分析、记录和验证项目干系人的需要。有一点很重要，如果某人在做业务分析师的同时身兼项目经理角色，她的这两项工作是完全不同的。项目经理需要根据业务分析师所定义的工作来创建和管理计划，包括进度和资源需要。项目经理必须要协助管理范围，并且随着范围的演化来处理规划的变更。她可能此刻还在履行项目管理的角色，而下一刻又要改变职责，执行分析实践。而这些角色完全不同，对技能的要求也各不相同。有些敏捷团队发现， 设置一名分析师好处多多。业务分析师能代表客户兵理解其需求，同时还能完成业务分析师的其他本职任务，不管工作头衔是什么，业务分析师都必须要有技能、知识和人格魅力，才能圆满完成工作。有研究表明，相比初出茅庐的分析师，经验丰富的分析师可以将项目的整个工作减少三分之一。

软件需求（第三版）

我的BA工作经验

如果说上面对BA只是纯粹的知识分享，那么接下来我想和大家分享一下我在做BA的工作中沉淀下来的，我自己对BA的理解。

在做BA之前，我做过QA, DEV,SUPPORT和PM的工作，因为之前的团队没有BA这个角色，我对BA的工作是不了解的，当时只是觉得需求的质量不高，团队对这点多有诟病，有的时候需求是由一些刚大学毕业的同事提供的，这些同事对系统不了解，对业务也不甚了解， 在这种情况下，开发团队做的工作往往返工率很高，返工也会打击团队的士气，而我在做开发的时候，注重的是如果把需求实现，不会特别在意需求是不是好的需求，很多时候也无从判断，而QA的角色更是在后面，往往在接收需求的时候还在忙之前的测试，很多时候是需求人员先提供需求让开发做可行性评估已经开发量评估，到测试时，测试人员接收的需求往往是滞后的，那么测试的重点就是保证测试的结果和开发的需求是一致的，SUPPORT就更尴尬了，看的是开发的代码，也不清楚为什么要这样开发，除了逻辑上可以判断是否正确，很多时候，看出来问题也是要问回开发人员，如果support不力，容易容易处在歧视链的下游。做PM让我有机会接触原始的需求，从而从宏观上去安排资源开展项目。我在工作期间，也花了三年时间在中山大学攻读项目管理硕士。不论从实际的工作角度还是从项目管理的学术角度，我了解到好的需求对项目的成败至关重要，而我自己也对BA的工作比较感兴趣，所以一直希望有一个机会可以尝试BA的角色。

2017年9月， 我的老板告诉我， 有一个机会可以转去另一个团队做BA, 不过要通过经理的面试才可以，问我有没有兴趣，我告诉他我有兴趣，心里还有点小激动，我有机会成为BA了，这不就是我想要的吗！

当时我还在带一个项目，2019年10月8日上线，上线当天我一直在支持上线相关事宜，上线很顺利，项目的质量也很可靠，辛苦了半年多，对我来说，这个周日给我之前的工作划上了一个圆满的句号。

而我在9月份也通过了面试，顺利地在2019年10月9日加入了新的团队，开始了崭新的BA历程。旧同事听说我转型做了BA，也觉得挺好的，他们都觉得BA的工作比较有挑战性，是一份不容易做好的工作，而我自己是一个喜欢尝试新事物，乐于接受挑战的人，除了BA的工作我比较感兴趣，另一方面，面试我的经理也是一个我一直比较钦佩的人，之后也是我的领导，能在她带的团队工作也是一份很宝贵的经历。所以我非常珍惜这个机会，从心底里想把BA这份工作做好。

在这个新的团队里， 有从一毕业就加入这个团队的同事，也有像我一样从其他角色转型过来的同事，一毕业就加入这个团队的同事对不同的角色可能不会有切身的体会，对我而言，DEV、QA、SUPPORT的工作偏向幕后，主要是和技术打交道，而BA的工作更偏向台前，主要是和人打交道。我自己做技术这么多年，感觉是生活在象牙塔里面，而BA的工作使我感觉到我成为了一个更好的“自然人”，以前研究技术的技能，大部分是用于工作中，而BA的技能则是工作和生活都是通用的。我之前以为BA的一个需求就一点内容，告诉开发团队就行了，其他时间都在做什么呢？ 记得加入新团队的第一天，我问我所在小组的“前辈”（虽然年龄还没有我大），BA每天都做一些什么工作？她大致说了一些，我似懂非懂，但是从接手第一个需求，我才渐渐理解了BA的工作。记得我第一次给团队讲需求时，一个偌大的会议室，20多个人听我讲需求，虽然我的需求比较简单，而是“前辈”们已经在前面讲了类似的需求，相当于给我做了铺垫，但是轮到我去讲时，心脏还是砰砰地剧烈跳动，期间还有团队成员提问， 我也是极尽努力紧张得要命才回答好度过的，所以要做好BA至少要做好两件事：

1） 能够自如地面对公众讲话

2）你的需求必须非常清楚，这样你才能应对别人的提问

关于第一点，BA团队有weekly meeting, 每个人都有机会主持会议和分享自己的工作，其实这对新人来说是很宝贵的机会，一个团队的人都花时间来听新人的分享，其实新人分享的东西可能是很浅显的，但是团队有这个氛围来包容新人，给足够的机会去锻炼自己的公众讲话能力，练得多了，这个能力也就自然提高了，我自己也是从心跳加速，手心冒汗，牙齿打颤到现在的比较自如，这都得益于平时的锻炼，同事们的包容。

其实第一个需求并不是我自己写的， 而是“前辈”基本弄清楚， 然后转手给我， 我去讲的。第二个需求，就是我自己写的，但是通过内部评审的，到第二个需求时，团队成员又提了一个比较有争议的问题，我们决定会后再讨论， 我和我的“前辈”们内部讨论时，说可能有几个选择，然后说“就看需求是怎样的”， 我的“前辈”就说“那就看你怎么决定了”， 我才突然意识到，对了， 我现在就是给需求的那个人了， 而不是等别人给需求的角色了，此时，我感受到了肩上的担子是沉甸甸的，以前我的工作是“把事情做对”，也就是别人给了需求， 我把它实施对， 而现在，我的工作是“做对的事情”，如果我给的需求是错的，后果将是一个团队的损失，我猛然记起我原来的团队，一个同事因为需求的原则性错误导致项目的方向都错了，这个同事因为这件事而离职了。

有了第二个需求，就会有第二十个，第二百个。通过同事们的帮助和自己的努力钻研，半年后，我就自己独立承担了一个比较复杂的项目，因为工期紧，任务重，我自己也相对来说是新手，经验不够，当时压力非常大，对项目的复杂度没有准确的估计，做事情也乱了章法，但是通过“前辈”的提点，我认识到了问题所在，自己也做了复盘，重新鼓起勇气直面困难，并且投入了大量的业余时间， 可以说为了这个项目， 一年多以来都处在超负荷状态，基本没有休息时间， 2019年的春节以及其他假期大部分都在加班中度过，2020年1月底春节前，项目的pilot 阶段终于顺利上线，然后2月份全面上线，上线过程还支持了一个星期的夜班，做了2个比较大的修复， 这两个修复也不是需求问题引起的， 上线总体平稳，3周夜班support后，领导高心地宣布上线成功，是一个happy ending.