ThoughtWorks BA初体验 | TW洞见
今日洞见
文章作者来自ThoughtWorks：张明赟，图片来自ThoughtWorks。
本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。
写这篇文章的初衷是总结下我在ThoughtWorks三个月的时光，从完全没有需求分析的背景到现阶段的收获和尝试，也希望我自己的经历能给其它同事提供一些参考。
在开始之前介绍下目前项目的背景，我所在的是一个公司内部产品项目，它是一套内部商机管理系统，主要目的是辅助CP管理商机，并为公司运营前景预测提供数据支持。因此很幸运的有接触最终用户的机会，会有从收集需求到分析，再到设计，实现，反馈的一系列过程。作为一个BA，有机会接触到需求收集的所有步骤，并得以在现实中验证自己的想法。
我遇到的困惑
在加入ThoughtWorks之前，我在另一家外企做过QA和PM，加入之初，一直在思索两个问题：之前多年的经验，是否就此放弃了呢？另外，作为一个从未做过需求分析的人，该怎么样上手BA的工作？
第一个问题很快得到了解答，之前的工作经验为BA的工作带来了两个很好的视角，一个是全局观，必须从系统层面来理解产品，另一个是持续的发问视角，这么做是否正确。因此经验并没有浪费，而是作为一种习惯带入了现在的工作，促进了我快速去进入BA的角色。
第二个问题就比较困难，在最初的一个多月中，我迷迷茫茫不太清楚团队对我的需求是什么，做事也有点犹犹豫豫缩手缩脚。心态上，又很期待自己能尽快的全盘负起责，于是出现了矛盾，一方面对产品的业务背景不甚了了，说不出个所以然，另一方面又的陷入了各种会议，讨论，kick off，desk check的包围。日子过得忙碌而混沌。
出了些什么问题？
一个月结束的时候，做了头一次interview++，相比于我的一头热情和不知所谓的忙碌，头一次反馈反应平平，团队里的大伙们意见挺多，主要出在了这几个方面：
一是信息的传递做的不到位，没有组织足够的分享会，导致大家对近期远期目标都有种雾里看花，朦朦胧胧的感觉，好像明白，其实又不怎么清楚。
二是优先级的排序不够明确，大伙在选卡的时候就没有标准，这样一来做的卡片零零散散，发布计划就只能一推再推。
三是促进决策的能力不强，开发团队对BA的要求是方向盘，遇到岔路的时候，BA需要引导客户做出正确的选择，这个时候意见不够明确会带来团队的各种疑问和挫败感，其实说到底还是因为当时业务知识了解不够深，对用户的观察了解也还没有开始做，导致自己给出的意见没有足够的依据，当然也就没有足够的指导性。对于敏捷实践缺乏了解也导致我没有很好的利用起各种敏捷流程来帮助自己做出安排和传递信息。
改进和收获
幸运的是我来到了一个非常热情而积极的团队，有资深的tech lead，有积极发问又乐于助人的QA，时时想着推动组织的进步的sennior Dev们，还有热血积极的new graduate。
经过几轮反馈，我梳理出了团队对BA的需求——写清楚故事卡，告诉大家做卡背后的原因，在实现和设计遇到需要决策的地方引导客户做出决策，组织好发布计划和未来短期内开发的计划，为工作计划排好优先级，以及做好各方的沟通工作。理清楚自己要做的事情之后，就不再那么浮躁的一味往前冲了，静下心来，给自己一个过程，不再担心挫败感，通过一件一件的完成来找到信心。
首先要提升的是熟悉业务。
业务总是BA工作的重中之重，加深对现在产品的了解，思考产品的核心商业价值，为什么做一个feature，如何做？初听起来不怎么接地气，实际上在工作了三个月后，我感觉，还真是这样的。听起来不接地气的大概是这个名词：商业价值，其实说白了，就是怎么对用户有用，怎么好用，做一件事能给用户带来什么价值。再或者遇到排列优先级的时候，需要做决定的时候，商业价值就是那个指针，作为BA需要时时思考商业价值，以确保我们实现的是在已知范围内最有价值的东西。在这个基础上，再加上观察用户，了解用户。我们的设计，都来源于对最终用户的信息收集加上stakeholder的期望，并且常常做用户测试来验证设计原型，这无疑是很好的基础。即使在这样的条件下，我个人也觉得，仅仅这些输入不够保证我在决策引导中总能做出正确的选择，有条件的情况下做一些用户访谈，使用性测试，维护和用户之间的联系，时常获取反馈，是BA应该要做的事情，只有更好的了解用户，才能理解商业价值，并且对产品有清晰的认识。实际上持续的观察和了解用户对设计来说大有好处，能直接的帮我们摒弃一些不必要的花哨功能而集中在用户最有需求的方面。
BA是项目团队和客户之间的桥梁，是一位帮助我了解role的同事对我说的－Facilitator是各方面的接口，在这个role上，需要双向的理解和视角。
在团队内部，BA一方面代表客户讲述需要什么样的产品，什么样的功能，以及最常见的使用情况应该是怎么样的。帮助开发人员能更好的参与到整个过程中，也使得他们能在理解用户行为的基础上保证更好的实现产品的功能。一方面要站在团队的角度，思索如何将抽象的需求具体化，再细分成可实现的小块。有时候也会参与决策实现的细节，在双向理解的基础上，发挥沟通技巧，促使需求变得容易理解和实现。
对客户甚至更广泛的外界来说，BA是他们理解团队的渠道，例如一个功能点，设计背后的思想，这样实现的原因以及带来的优势，需要BA去传答。并且聆听他们的反馈，作为优化设计的输入。
正因为能够获取这些信息，BA需要把知道的这些组织好传递给团队。在之后的工作中，我尽可能的分享我所知道的一起：把它写在故事卡里，写在分享的文档里，在站会上讲收到的最新消息，在回复反馈邮件的时候请大家来看，定期组织planning meeting给大家分享近期计划，在kick off的时候讲背后的故事，我渐渐习惯了不断的分享。
最后是对敏捷流程的熟悉和应用。
大家告诉了我什么是IPM，什么是4 Amigos，什么是Retro，还有什么是Kanban，什么叫TDD，敏捷里面怎么做estimation，怎么做release plan，而用上这些之后，的确，工作变得更加顺畅了，定期的敏捷实践让越来越好变得可能。
*4 Amigos: 是4个小伙伴的意思，其实就是BA，QA，Tech lead，UX一起来讨论需求的内容，还有排列做卡的优先级等等。
三个月的时间确实学到了很多，要达到团队对BA的期待，良好的沟通能力是基础，逻辑能力在分析问题以及向团队／客户展示设计思想的时候十分有用，观察和思考应该是一种长期习惯。还有更多东西是有待去实践的，比如作为一个BA，积极的去了解用户，跟用户沟通，做每张卡之前深入的思考，建立在对用户了解的基础上的决策，还有更好的和stakeholder的沟通，还没有体验过的inception，等等等等，未来的日子期待自己做的更好。
回复201501-201512，获取当月精彩洞见合辑
如：想看5月精彩洞见合辑，请回复 201505
若你想去 TW洞见网站阅读所有洞见文章，复制网址在浏览器打开：insights.thoughtworkers.org