友情提示

1、本文主要以 后端研发视角写的

2、本文纯属一家之言，仅供参考、慎重参考

3、本文主要探讨项目开发和配合。

一、岗位链条，上下游

需求-pm-前端-后端-测试-运维+boss。 

一荣俱荣，一损俱损。

除非遇到相关人士，不配合、持续不配合、强烈不配合，还是多出点力，先搞定问题比较稳妥。

二、前后端配合，合作典范

目前，和 前端的配合 非常顺畅了，合作过的且在职的，大概5人。

德坤 徐娜 春雨，基本都能秒懂。 

蒙蒙、明佳 沟通交流较少，基本也没问题。   

合作方式

1、列出某期需求的 ，对接 大概情况

21、前端联调done,2021-10-15

2、重点字段 逻辑说明，其它 不用废话太多

3、望文知意

username,realname,group，用最常见的英文单词

4、约定优于沟通

2、前后端分工和联调约定

三、同其它岗位，沟通现状

相比之下，同pm 、测试、 运维（IT支持，OA）的 沟通质量，稍微差点。

为啥沟通较差呢？

1、人

自身原因：性格等。

对方：性格、工作经验、思维方式等。

2、岗位

a、pm：不能用技术语言去交流，需要随时注意切换。

默契度可能不够。

项目开发积累的经验不同。思考认知，经常不同。

好消息：如果我说的有道理，列清楚逻辑123点，最后基本都愿意采纳我的方案。总体比较ok。

之前存在，xxx，方案不对，又比较坚持，就比较难受。只能，先这样。

b、测试：从部门、岗位、个人的角度，看问题，比较微妙。

对于项目，尤其是新项目，很难、不愿意、从进度和时间、项目总体角度去考虑。

客观的说：关注质量 远胜于 进度。

个人观点：没有进度，进度不行，质量、安全，都没用。

结论：现状如此，需要耐心沟通、耐心、耐心。。。

优秀人物举例

weibo.di，已离职的实习生，沟通非常顺畅，秒懂级别，主要体现：dms父子需求的树状结构和权限，构造各种场景的数据，先在小本本上画，推理，再录入构造真实数据。

工作非常细心，喜欢研究。

c、运维：存在不积极解决问题的情况

llw，工作非常认真，沟通非常顺畅，秒懂级别。

提出的问题，基本都搞定了，达到了预期效果。

反馈了问题，总是有反馈。

d、IT支持：主要是OA对接。

主要痛点：凡是遇到技术问题，尤其是代码相关的，只能靠自己，很少有建设性的对话。

这个岗位决定的，OA软件现状决定的。

提升自己是关键。

四、解决问题，参考工作方法

从个人角度、项目角度、解决问题的角度、利益角度，参考工作方法。

1、核心指南

1.1 主动远胜于被动

问题是客观存在的。不积极去解决，等被动找到自己的时候，更难受。

1.2 我能为对方做什么

帮助（协助、辅助）别人，就是帮助自己。

帮助别人，推动项目，最大的受益人是积极解决问题的人：工作能力、项目全局观、口碑、信任度等等。

1.3 解决问题

实事求是，多从解决问题的角度去思考问题，找到解决办法。

避免只从个人角度、岗位角度、小圈子的利益角度。

跳出个人局限性，站得高，看得远，长期更有利。

1.4 项目进度和质量

多从项目角度考虑问题，而不只是把自己的本质工作，干完就拉倒了。

讲道理，刚毕业的小兄弟，才只负责几个小模块，几个具体的功能点。

工作干完了，就自个玩自个的，就自个学自个的，这只能存在 实习生、职场新手。

1.5 用户角度

如果我是用户，如果我是客户，这个用起来，舒不舒服。能不能，很好的理解。

新功能，不参考FAQ帮助手册，能秒懂吗？

我的工作可以尽快搞定吗？商务、运营、职能岗位

如果我犯了错误，填错东西了，系统还能重新自动或手动修复么？

2、岗位

2.1 前端

a、前后端约定，工作习惯。

b、简化前端工作，尽可能少的业务逻辑。

c、各种文案配置接口，不要写死。

d、业务流程，及时讲解。（前端的工作，对业务的依赖不深，可能存在前端er不关注项目业务的情况。不知道业务，容易沟通费劲，缺少自测）

e、避免歧义。

f、勤跑腿，当面说。face to face。

2.2 产品

a、定位、定位、定位。

b、需求范围边界控制。尤其是每个版本，及时提醒。避免上线前，改动需求，反复改代码。

c、清晰度（避免一句话需求）。

d、业务逻辑（主要是复杂的，后端必须亲自分析梳理。如果遇到pm新人，要主导业务逻辑，以防跑偏）。

e、业务规则（要么pm整理，要么后端整理+pm确认。同业务逻辑一样，后端还是要整理的）

f、项目的核心：

外在：定位+需求+功能

内在：逻辑+规则+数据。

2.3 测试

a、提测和上线时间要约定好。

b、自测好，信任。避免提测了，核心逻辑跑不通，问题多多。

c、业务介绍，关键业务逻辑。

每次功能的大概实现逻辑，关键业务要提前解释沟通，复杂的功能模块需求，也可以先演示下工作流程。

d、bug随他提。

2.4 运维

a、需要尽可能提供多的信息，比如：xx内存不足，xx网络有问题。

b、提供分析和逻辑梳理

host没更新，可能的原因。nginx没重启，发生过。k8s疑似bug，也发生过。

c、问题不止是运维的，也是自己的。

服务器、内存、redis等问题，如果迟迟不能解决，要及时提醒对方，上报leader或主动求助。

小问题长时间不解决，容易变成大问题。比如，周会上xxx。

2.5 IT支持

a、没啥好的办法。

b、提升自己是关键。比如，之前遇到表单，多个表格的推送问题，理解有误+程序字段有误。

提供自己的分析能力，积极总结经验，不断摸索OA的规律。

一般只有新特性、新功能，偶尔会有问题。

c、凡是涉及到代码的，不要再找OAer了。

2.6 项目、管理、boss：进度问题

a、风险，及时提醒，反复提醒。

绝对要避免，进度出问题。

b、多项目时间冲突。

c、多项目联调

催~反复催。

肉肉的小伙子，总是会有的。

2021年10月14日

雷

北京，望京