阅读 223
"BP"的几点思考

"BP"的几点思考

题图:pixabay

近半年来除了负责常规的工作编码外,还兼了一个另外的角色 【BP】。顾名思义,business partner。在我理解,同时兼顾了PM、PMO。这活儿可比安安静静的敲代码难搞太多了,拉齐、赋能、高效、理想态、中间态这些词儿一天到晚在脑子里转。深刻才有体会,回顾下,共勉。

下面在个人理解上分几个维度来思考。

业务上

搞清楚业务方要做什么事情。

就是理解业务方的需求,这个东西说难也难,说简单也简单。简单在于你只需要听清楚业务方的话术就行,难在在于经过你脑子思考之后,你怎么用最简单直接的话术描述出业务方要做什么事情。你能说清楚,说明你懂了。

搞清楚业务方的目标,要什么结果与收益。

业务方为什么要做这个需求,做这件事情有什么收益。业务方更加关注的是业务价值,所以我们在满足业务方关注的东西之外,在正常的交付之外,能有什么技术收益或是沉淀。这是我们需要考虑的东西。

发散思维,扩展业务方的需求。

这个其实是我瞎编的。怎么把收益扩大,在排期、人力、市场、数据的基础上做折中考虑。多个需求能否合并,代码、流程能否抽象通用。技术最终是为业务赋能的。这个思维方式是高阶技术人逃不掉的。

产品上

搞清楚参与的人及能拍板的人。

简单来说就是找准能负责的老板。让参与人员明白项目的重要性,心理上提高紧迫性和优先级。

需求点认知拉齐。

有时候,需求讲了很多次,各模块的同学还不知道自己要做啥。这个事情最好的办法就是各模块单独输出技术方案上评审。老板们关注的视角能在更上层的维度给项目把关。

制定总体技术方案及评审,各模块的技术方案及评审

继上面说的,让各模块自己梳理清楚要搞什么事情,自己负责的边界在哪里。以及该怎么与上下游协作,协作时关注哪些东西。同时,技术方案是否合理,折中考虑是什么?是否合理当场下定论。老板会替你撑场子。

定排期,留buffer。

最后就是定排期了。要求各模块给出自己的排期安排,但是大多数时候都没有一个统一的输出时间点。可以试试相邻上下游拉齐,最后总体拉齐。就算最后有gap,相邻上下游开发完后可以先开始联调嘛。

最后最重要的就是留buffer。切忌憨批做得快可以让老板刮目相看的思想,搞不好就等着跑路吧。

节奏上

不要信奉“先紧后松”,要“一直紧凑,一鼓作气”。

之前我也是信奉“先紧后松”的原则。觉得项目前期节奏紧凑些,后期视进度可以放松下节奏,不用逼那么紧。事实证明我错了,多团队协作的时候,各个团队不仅仅是只为你这个项目服务的。后期节奏放松的后果是:比如截止到周四,项目完成到95%,最后一点收尾的工作一定要在周五完成。不要拖到下周一,就算排期够也不要。一个周末过后,工作上的衔接成本是很高的。再打个比方,此次疫情高峰期的时候管控的特别严格,封路的封路,禁足的禁足。后期,力度不到位导致很多民众觉得快结束了没啥好担心的,都去逛公园了。如果有一例,全盘GG。

重沟通。包括向上汇报、团队间传递等机制。

沟通真的超级超级重要。包括上传下达,重要的节点或风险要跟老板汇报。老板、业务的策略也要及时传递到各团队。遇到跨团队分歧及不明确的点及时拉小会解决。会议的原则是:

  • 会前明确讨论需求点背景、目标及分界点
  • 感觉推不动的拉上老板,看看老板是怎么做的
  • 会后同步会议结论(邮件或群@全员)

日会日报机制。围绕核心目标、进展、风险等核心信息记录并同步。重要信息跟老板反馈。

日会是有点恶心。但是很有效。日报的作用是让项目组全体成员了解目前的进度及风险,提前做好心理准备。

把控上

找对的人。

出现问题了找能解决问题的人。写代码的人解决不了找上级,一级一级往上回递归。最后解决不了找自己的老板和业务。

搞清楚问题在哪里?再找对的人要合适的解决方案。

先搞清楚问题点在哪里。最好心里能有几个待选的解决方案,这样跟各模块的老板谈的时候比较有底气。同时,解决方案也不是一定要理想的方案。是要符合当前阶段,各团队都认可的合适的解决方案。

提前预估风险。至少及时暴露风险。

能在项目启动前预估到风险最好不过。当然很难,最次也要做到有问题出来或者说风险出来的时候,及时暴露给项目全员,打好预防针。

总结上

  1. 项目管理就是风险管理。
  2. 节奏把控推进一直紧。
  3. 会议原则有始有终。
  4. 理解、思考、沟通、传递、同步、制度。

其实上面都是我瞎编的。下一篇讲讲怎么写技术文档。

文章分类
代码人生
文章标签