BA·十二时辰
楔子
随着近期《长安十二时辰》的热播，着实让年轻的鲜肉演员和历史厚重的长安城又火了一把。作为一名暂时驻扎长安本地的小筋肉 BA（Business Analyst - 需求分析师），特此根据个人的 BA 经历编纂本篇《BA 十二时辰》，来揭示鲜为人知的Thoughtworks BA 一天…
辰时 ( 7：00 - 9：00 )
伴随着多个闹铃的交响，正式开始由需求驱动的一天。
BA们的主要工作就是围绕需求展开的，他们需要将业务与用户的需求转化为系统（软件）需求，并保证最终的系统（软件）能满足业务与用户需求，并带来相应的业务价值。
在完成洗漱早餐等基本事项之后，考虑到今天依旧会进行多方会谈，为进一步提升自身气场及专业感，于是决定将休闲 T 恤换成了带领子的 Polo 衫（拒绝立领）。
戴上 Airpod，前往车站。一些情况下耳机是没有音频播放的，主要是为了能够及时接到客户或团队成员的紧急电话而随时待机。
如果通勤时不拥挤，则会在车上打开 36 氪、PMCAFF 等互联网资讯 APP，阅读昨天互联网和 IT 圈的重磅新闻以及产品运营的花边轶事，以掌握一些新的行业趋势和需要今后避免的玩火操作。
每天多关注一下自己所服务的客户公司新闻也是十分必要的，这样可以进一步了解：
- 客户的公司层级的战略动向
- 客户公司相关的紧急事件
从而：- 在提供方案时能够有更多的理论根据
- 提前思考紧急事件的处理方案
到达单位或客户现场之后，和同事和客户们打个招呼，一边进行简单的闲谈，一边查看一下自己的邮箱和待办事项，做到今天要完成的事情心理有数。
巳时 （ 9：00 - 11：00 ）
和「一岸三地」的团队成员们开始每日站立会议。在自己发言时，简要向团队同步昨日工作内容以及目前项目上的需求状态，当然还有今日工作动向，以便保证团队成员间的密切协作。在倾听他人更新时，应注意是否有需要自己配合补充的业务信息和会后需跟踪澄清的需求。
和客户及供应商开每日站立会议，由于有些项目涉及的客户和其他 Vendor 众多，所以有时需要额外的每日站立会议来拉通信息。在这些会议中，除了更新目前自己团队的进度以及说明需要其他供应商团队协助配合的地方，确保项目整体进度不受影响。同时也需要认真倾听客户的业务发展方向和其他供应商的新变化，识别业务机会和由改动带来的风险。
会后回到团队中，先和相关团队成员快速同步在刚刚的站立会议中获取的有价值的内容。之后和 Dev、QA、UX 一起 Kick off 一个卡（User story），使交付团队保持高效运作与密切协作。
在整个 Story kick off 过程中，需要让 Dev 同事来主导开卡过程。Dev 同事需要讲清楚这张卡的 scope 和目标，以及用来判定这张卡完成的验收场景和验收标准。同时，可以与在场的团队成员一起讨论和澄清卡中较为复杂的地方或特殊的细节，确保参与人员都能就这张卡的核心功能达成一致。
在整个Story kick off过程中，需要让Dev同事来Drive开卡过程。Dev同事应讲清楚这张卡的Scope和目标，以及用来判定这张卡完成的验收场景和验收标准。同时，可以与在场的团队成员一起讨论和澄清卡中较为复杂或特殊的细节，确保参与人员都能就这张卡的核心功能达成一致。
午时 （ 11：00 - 13：00 ）
回复客户们对目前已完成（已上线）功能细节的疑问，并告知其之前为什么这么做，这么做有什么好处，这么做可以如何支持之后的产品迭代和数据采集。
不少客户都会对之前做出的决定或拍板的结果产生或多或少的遗忘。
当客户遗忘时，他们很可能会询问BA相应的业务细节。为应对这种情况:
- 一方面BA们可以加强记忆，锻炼自己成为“最强大脑”
- 另一方面也可以将每次与客户确认后的内容记录在Jira等需求流程管理工具中或用邮件发送给干系人。这样就可做到有证可依，降低由于干系人遗忘业务内容而带来的项目交付风险。
不遗余力的提醒团队成员去吃饭，防止同事们因深陷工作不可自拔而产生的：
- 因正值打卡公司大量人员前往餐厅而面临的食堂拥挤需排长队的暴躁情绪
- 因错过吃饭时间而面临无饭可吃的抑郁情绪
- 因多种不良因素导致的团队士气低迷等情况
在午饭后偷看大家「吃鸡」的同时适当提醒团队成员have a noon break。据不完全数据统计表明，简短的午休可以提升个体的幸福感并有一定几率在午休后获得超凡的灵感，以助个人自我价值的实现和项目的高效交付。
未时 （ 13：00 - 15：00 ）
与客户和其他客户Vendor讨论目前集成阶段中遇到Block和解决方案，该过程通常较难在一次会议中就将其完全确定下来，所以整个讨论集成的过程费时费脑。
在项目中遇到多方集成是很正常的事情，在前期需进行多轮信息沟通及约定：
- 包括描述澄清己方需求
- 了解部分对方业务及数据信息
- 了解己方和对方的特殊业务逻辑
- 划定本次集成业务范围和联调时间
- 约定信息交互文档和信息变更的通知方式
- ...
在中期执行中遇到的多方信息数据不透明，与某方约定开发的接口变更未通知及由于对方特殊业务未传递而导致的集成开发障碍等情况也是十分常见。
减少相应问题的方法，我个人建议除了在前期做出明确的沟通和约定之外，自己需尽可能多的去了解与该集成相关的业务上下文并主动去求证集成方业务或技术人员。
多次的求证挖掘可能会激活对方的「遗忘信息」，减少由于忽略特殊业务逻辑导致的返工浪费问题。当出现相关信息更迭时，需要通过邮件等方式进行记录，以保证信息的更新及留存。
在后期联调过程中，双方接口不通，集成方到达规定时间但功能未开发完等现象可能逐一显现，在一些极端情况下已经到了使用技术方式短期内无法解决的地步。在这种情况下，初期的约定和中期的信息记录都可以成为解决或划分以上问题的良好佐证，建议可以携带佐证并和团队成员一起讨论问题解决策略。
申时 （ 15：00 - 17：00 ）
和UX同事讨论设计客户紧急提出的线上临时运营方案。BA先描述目前客户需要解决的紧急运营问题（如基于H5页面和微信平台的某活动分享功能），之后辅以线框图等方式与UX同事传递并讨论该方案中需要呈现的信息、数据以及期望发生的交互等内容。
当与UX达成业务方案的一致性后，建议也与TL double check 一下刚刚设计业务方案是否可行，从技术角度上是否有实现困难等事宜。
同时也与PM就紧急功能的排期和团队内部安排进行沟通，通过需求置换等方式在满足解决客户紧急问题的同时，保持正常敏捷迭代的交付节奏。
督促大家去have a break或吃一些水果，补充一些能量。
见缝插针，在开发人员准备好环境之后，与团队成员一起完成一张功能卡的Desk check。
开发人员在完成需求开发之后，对照Kick off时团队讨论一致的验收标准向团队的BA、QA以及UX展示完成的功能。在进行功能验证同时，也可进一步简单讨论部分细节的修正。
BA需要留意在开发之前提出的需求是否实现，有没有自己和开发人员理解或和系统呈现不一致的地方，以及是否有需求遗漏。快速验证，减少不必要的浪费。
酉时 17：00 - 19：00
和客户及其他部门成员一起参加新方案设计评审会议，并识别新方案对原有系统的影响以及带来的价值和风险。
BA在客户提出新的业务方案时最好要秉着“兼听则明,偏信则暗”的心态去倾听。
一方面新的业务一定会带来额外的工作量，非常多的细节确认和原有系统的集成和冲突。在这个场景下，熟悉业务和系统的BA可以就比较明确且影响到业务流和数据的地方向客户提出疑问并一同寻求解决方案；
另一方面新的业务带来的是更加深刻的业务理解和更多的业务机会。仔细倾听新的业务，建立同理心，站在客户的角度去探寻客户真正诉求并提供有价值的建议，这也正是BA的一个重要价值所在。
下班之前再检查维护一下收件箱和今日的待办事项，确保当前高优先级的事情都在掌控之内。
戌时 （ 19：00 - 21：00 ）
吃完晚饭回到家，累了一天了，感觉有些困，先睡一会儿...
亥时 （ 21：00 - 23：00 ）
休息之后，一边复盘今天发生过的事情，一边写卡。
在一些日常事务及干系人复杂的项目中，由于白天时间经常被客户会议、团队日常交付合作及异常事件处理等事情占满，所以可能当回家之后才会冷静头脑，开开心心的分析下一环节的User story（写卡）。
复盘时发现了白天的一些信息缺失，赶紧记录下来，方便明天进行追溯。
子时 （ 23：00 - 01：00 ）
打开在线课程列表，选择学习一门自己曾经被贩卖了焦虑之后而决定购买的课程，开始了边熬夜边学习（边玩手机）的充实旅程...
丑时 （ 01：00 - 03：00 ）
由于长期被“只要我不睡觉，今天就永远不会过去”的心态报复性熬夜，现在的我已经不能承受晚睡带来的不良影响。为了明天的头脑清醒和情绪稳定，需要尽快强迫自己尽快睡觉休息。
寅时 （ 03：00 - 05：00 ）
做梦，梦到由于系统业务流程被毫无逻辑的更改，不得不和多方论证对峙。
卯时 （ 05：00 - 07：00 ）
继续做梦，梦到上一个时辰的论战取得成功，自己坚守的立场被尊重接受，今夜做梦也会笑~
岂不知东方鱼肚白出，又一个新的轮回就此开始...
结语
以上内容均根据自身BA经历耦合而成，尝试从其中一个角度揭示出大家身边勤勤恳恳（不写代码）的BA，在Thoughtworks日常工作的一天都在做什么。
凌晨一点，都市的夜行动物们结束了一天的工作，在家熬夜肝剧，纷纷露出血丝眼和黑眼圈，这就是传统的丑时。
