公益机构技术研发的沟通

原创
2023/02/18 11:10
阅读数 142

公益团队技术研发中一些沟通的梗

机缘之下拯救过好几个最后一根稻草都没的公益项目,或者是培育成长了,然后拿去折腾,搞的半死又救活的项目,总结一下,希望对大家选择时有点助益。

、必要条件:

公益团队的技术负责人必须对研发项目高度认可,并且在整个公益团队对研发目标的业务场景有最高的认知水平。缺少此条件,沟通会成为最大成本和障碍...

、好的需求沟通。

2.1沟通态度。

唯唯诺诺,回复问题基本是“没问题”,“行”,话说的好听,舒服。从沟通来讲,太舒服的沟通,没有矛盾,没有问题,没有解决矛盾的办法,是不符合常识的,要谨慎。技术角度业务场景总是决定技术上不能完全按理性状态直接兑现,或者成本相对高昂,都会导致需要折中处理,就会讨论或者争论。即使同一业务场景面对不同用户群体,如“老人”“小孩”技术解决方案也会相差甚远。

2.2 沟通的内容

具体,聚焦。具体到用户,聚焦到解决用户具体问题,具体研发的结果指向半年、两年以内要解决的问题,业务总是在发展中变化和变化中发展,不同的用户规模,需求会很大不同,工作人员增加,用户分化出不同群体...系统在成长,而非一成不变。

2.3 沟通的结果:“落地”相关沟通交互是必须有的

一方面双方言之有物,决定了是否“落地有声”,另一方面也是在同步对“业务场景”的知识和认知。如果谈完之后,回顾一下发现什么都不需要做,那双方肯定是有一方问题,要么甲方没有亮需求,要么乙方不能具象业务场景,没有理解需求,谈不出落地具体方案。沟通一定会有反馈,如形成会议记录,形成设计原型,形成数据库设计,对某项困难的建模....

2.4 心理定位

2.4.1 乙方在甲方的心理定位:甲方没意识到接受信息的乙方对自己真正的困难是一无所知即非同事,又非朋友,哪里来的理解?所以乙方在甲方心理定位应该是“他啥都不懂,需要我为他仔细叙说每一个常用场景,重点要吐槽我工作中的困难”。此时乙方沟通期间反馈是在给一些常用方案,提供一些建议。沟通后还需要适时总结,把沟通结果作为“知识”传递到所有人,达成“共识”。反之,如果一开始没有足够的可靠数据证据就认为“乙方”很行,那就是一种假象的理解,实际上是被忽悠了,很常见。

2.4.2 甲方在乙方心理定位:甲方对技术是一无所知的,他们忽略的细节,就是我们系统架构最大的bug,也是最大成本输出,我一定要和他沟通清楚。

举个常见例子:

甲方的需求:这款产品有可能改价格。这一句话包含多个技术实现选择:

1)用户购买产品后,平台如果修改了价格,之前购买的产品价格也会跟着变动

2)保留了用户购买时价格,但是如果我浏览这款产品详情,看到是新的价格和对应的描述

3)保留了用户时所有信息,并告诉你有新的产品可选择。

上面三种选择对技术设计的要求天差地远,可以影响到整个"购物"的设计,如果选择3

的理解,对应的业务层面,与之相关的采购销售统计,用户数据分析等等很多层面变化,对应技术层面表结构和关系的变化等等,成本是10倍增加。---这是甲方不得不“被说服”的理由,乙方留的退路。有时候拒绝你的人才是不坑你的人。

、好的技术沟通

各方面满足37原则。

3.1 不追求完美。够用,满足当下业务场景是一个基本原则。软件研发是一个实业领域,但是又很容易变虚。

3.1.1 首先一个梗,就是追求设计的美观,“美”在普通人眼里是没有标准的,是一种直觉,基本没有人承认自己审美差。问题是多数人认可某人“审美超出一般水平”,但是非设计行业的人是没办法把这种“美”用语言规范化的描述出来;另一方面“美感”多数人是受环境影响,每天都会有不同的“美的感觉”。通过感觉沟通低效,是设计阶段的大敌。

3.1.2 另外一个梗,愿景不要太远,立足半年或者2年内。软件太细的粒度设计,在设计上就会冗余,极大的浪费时间成本,沟通效率低下。检验的第一原则还是从实践中来到实践中去,不同阶段引入用户测试,坚持37原则非常重要。

3.2 共同面对困难

3.2.1 甲方:就事论事,任何工作都是解决问题,创造效益。脱离这一点就是别有目的。

3.2.2 技术人员:讲原因,讲解决方案。如果面对研发困难,如成本,bug,技术难点等等。行业都有公认的技术标准,或者一些常用方案但是往往技术能力不够的团队,就会把球扔给甲方(需),如需求不明确;或责难到一些非人类上,如服务器系统性能太差,带宽太小,甚至云服务器本身的不稳定等等......理由都是对的,但是最终有没有合理的“解决方案”,就是判断是否“撒谎”的标准。99%的困难是有解决方案,或者折中方案,剩下1%是当解决方案成本大于项目整体成本时放弃。

3.2.3 常见两大困难解决:

需求不明确:沟通有问题,提出一些加强沟通方案就好,如增加会议频次,加强标准术语的定制(通俗说法就是大家谈话时,统一使用的术语),及时总结并公示...保持所有参与项目人员在需求的认知(知识)上一致,并且快速传达到每个人。

非人类理由:一般都会有证据,如观察服务器内存,带宽流量等等,有证据就是可信的,购买硬件就是解决方案。

3.3 需求争议

面对“需求争议”,第一现场是唯一解决方案,检验真理的唯一标准就是实践。

3.4 面对bug

上线就是死刑,多数小型研发都是这个状态,往往也想不明白,为什么自己千辛万苦测试了没有bug,钱也花了,上线后就问题一堆,甚至直接宕机,而技术团队总能给出“你能接受的原因”。分析起来维度太多了,建议公益团队做研发,上线前测试请第三方技术团队参与。

最简单的判断:上线后用户使用,技术原因障碍在30个以内是可接受的,15个以内说明技术很优秀;单个bug解决速度超过1小时,甲方乙方参与的人都是浆糊。

 

 

 

 

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部