81前后端等上下游岗位配合的思考和参考工作方法,望文知意,约定优于沟通

Posted 小雷FansUnion

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了81前后端等上下游岗位配合的思考和参考工作方法,望文知意,约定优于沟通相关的知识,希望对你有一定的参考价值。

友情提示

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日

北京,望京

以上是关于81前后端等上下游岗位配合的思考和参考工作方法,望文知意,约定优于沟通的主要内容,如果未能解决你的问题,请参考以下文章

发布android工程师岗位职责都有哪些

初次走上技术管理岗位的思考总结,建议收藏

初次走上技术管理岗位的思考总结

系统运维岗位职责

web前端开发工程师岗位职责

30岁的思考