题图：pixabay
近半年来除了负责常规的工作编码外，还兼了一个另外的角色 【BP】。顾名思义，business partner。在我理解，同时兼顾了PM、PMO。这活儿可比安安静静的敲代码难搞太多了，拉齐、赋能、高效、理想态、中间态这些词儿一天到晚在脑子里转。深刻才有体会，回顾下，共勉。
下面在个人理解上分几个维度来思考。
业务上
搞清楚业务方要做什么事情。
就是理解业务方的需求，这个东西说难也难，说简单也简单。简单在于你只需要听清楚业务方的话术就行，难在在于经过你脑子思考之后，你怎么用最简单直接的话术描述出业务方要做什么事情。你能说清楚，说明你懂了。
搞清楚业务方的目标，要什么结果与收益。
业务方为什么要做这个需求，做这件事情有什么收益。业务方更加关注的是业务价值，所以我们在满足业务方关注的东西之外，在正常的交付之外，能有什么技术收益或是沉淀。这是我们需要考虑的东西。
发散思维，扩展业务方的需求。
这个其实是我瞎编的。怎么把收益扩大，在排期、人力、市场、数据的基础上做折中考虑。多个需求能否合并，代码、流程能否抽象通用。技术最终是为业务赋能的。这个思维方式是高阶技术人逃不掉的。
产品上
搞清楚参与的人及能拍板的人。
简单来说就是找准能负责的老板。让参与人员明白项目的重要性，心理上提高紧迫性和优先级。
需求点认知拉齐。
有时候，需求讲了很多次，各模块的同学还不知道自己要做啥。这个事情最好的办法就是各模块单独输出技术方案上评审。老板们关注的视角能在更上层的维度给项目把关。
制定总体技术方案及评审，各模块的技术方案及评审
继上面说的，让各模块自己梳理清楚要搞什么事情，自己负责的边界在哪里。以及该怎么与上下游协作，协作时关注哪些东西。同时，技术方案是否合理，折中考虑是什么？是否合理当场下定论。老板会替你撑场子。
定排期，留buffer。
最后就是定排期了。要求各模块给出自己的排期安排，但是大多数时候都没有一个统一的输出时间点。可以试试相邻上下游拉齐，最后总体拉齐。就算最后有gap，相邻上下游开发完后可以先开始联调嘛。
最后最重要的就是留buffer。切忌憨批做得快可以让老板刮目相看的思想，搞不好就等着跑路吧。
节奏上
不要信奉“先紧后松”，要“一直紧凑，一鼓作气”。
之前我也是信奉“先紧后松”的原则。觉得项目前期节奏紧凑些，后期视进度可以放松下节奏，不用逼那么紧。事实证明我错了，多团队协作的时候，各个团队不仅仅是只为你这个项目服务的。后期节奏放松的后果是：比如截止到周四，项目完成到95%，最后一点收尾的工作一定要在周五完成。不要拖到下周一，就算排期够也不要。一个周末过后，工作上的衔接成本是很高的。再打个比方，此次疫情高峰期的时候管控的特别严格，封路的封路，禁足的禁足。后期，力度不到位导致很多民众觉得快结束了没啥好担心的，都去逛公园了。如果有一例，全盘GG。
重沟通。包括向上汇报、团队间传递等机制。
沟通真的超级超级重要。包括上传下达，重要的节点或风险要跟老板汇报。老板、业务的策略也要及时传递到各团队。遇到跨团队分歧及不明确的点及时拉小会解决。会议的原则是：
- 会前明确讨论需求点背景、目标及分界点
- 感觉推不动的拉上老板，看看老板是怎么做的
- 会后同步会议结论（邮件或群@全员）
日会日报机制。围绕核心目标、进展、风险等核心信息记录并同步。重要信息跟老板反馈。
日会是有点恶心。但是很有效。日报的作用是让项目组全体成员了解目前的进度及风险，提前做好心理准备。
把控上
找对的人。
出现问题了找能解决问题的人。写代码的人解决不了找上级，一级一级往上回递归。最后解决不了找自己的老板和业务。
搞清楚问题在哪里？再找对的人要合适的解决方案。
先搞清楚问题点在哪里。最好心里能有几个待选的解决方案，这样跟各模块的老板谈的时候比较有底气。同时，解决方案也不是一定要理想的方案。是要符合当前阶段，各团队都认可的合适的解决方案。
提前预估风险。至少及时暴露风险。
能在项目启动前预估到风险最好不过。当然很难，最次也要做到有问题出来或者说风险出来的时候，及时暴露给项目全员，打好预防针。
总结上
- 项目管理就是风险管理。
- 节奏把控推进一直紧。
- 会议原则有始有终。
- 理解、思考、沟通、传递、同步、制度。
其实上面都是我瞎编的。下一篇讲讲怎么写技术文档。