• 程序员与产品之间应该如何配合,什么时候技术为重,什么时候产品为重?


    原创不易,求分享、求一键三连

    如图所示,产品狗在一次与程序员的战斗中吃了亏,后续马上想要找回场子!

    技术的“劣根性”

    近期有一个不好的Case,在一些跨部门的项目工作时,产研会有很密切的配合。一般情况没问题,但面对三不管或公共类事务,比如GR提过来的业务合规问题,技术同学会重复问到某个产品同学一些问题,碰到一些拿不准的问题,还会要求产品同学去找法务、财务等部门确定。

    典型费力不讨好且边界不清晰的事情,谁做都可以,但谁都不愿意做,也没有机制去鼓励。这个时候产品同学的小Leader就不高兴了,随口说了一句:为什么他自己不去问,这不是技术的劣根性吗?

    这个“技术的劣根性”是很刺耳的指责和乱打标签的行为,稍有不慎容易引发团队对立,特地去查了下定义:

    劣根性,是指长期养成的、根深蒂固的不良习性。劣根性是一种心理反应,某些劣根性是人潜意识的判断

    这里举两个例子:

    1. 他的失败完全是来自于怠惰的劣根性;
    2. 他的失败完全来自于没有担当的劣根性;

    我品了品所谓技术同学的“劣根性”,好像有点意思,但又不完全是一回事......

    为什么这么说呢,我们先来看看产品的故事。

    产品的“虚假性”

    神奇的需求

    如果把产品和技术比喻成2个人,如果都是妹子就是塑料姐妹花,如果都是汉子就是表面兄弟,如果是异性那就是一段孽缘!

    刚才的比喻建立在2个人平等的基础之上,实际情况就值得玩味了,产研、产研,产研一家亲,确实是一家,一个充满矛盾的家庭,而且很显然 ——  产品在这个家庭中扮演着父亲的角色。

    这个家庭中最突出的矛盾点是需求,技术理想中的需求,一次版本迭代起码几十页,满屏的文字说明、各种条件、各种权限考虑得妥妥的,就像一个前凸后翘的美女让人忍不住想赶紧把需求做出来的冲动。

    可现实是残酷的呀,多数的需求就是一张图,图里面有那么些页面,然后页面旁边写了一些不多的文字,这就像一个五官模糊且精神错乱的女子,还是个飞机场,没料!而技术已经渐渐接受了这种设定,总结来说就是:

    开局单图,流程靠猜,细节靠改,极品交互,一秒刷爆,需求pk,产品为王。

    技术如果反馈开发有难度,或者消耗资源太多等问题时,一个个直达灵魂深处的哲学问题就来了:

    1. 为什么微信可以?
    2. 为什么淘宝可以?
    3. 为什么今日头条可以?

    一通排比酣畅淋漓,几个反问扣入心扉,作为晚辈,技术能说什么呢?爸爸的角色很入戏,中国式长辈的通病都继承了。

    平静的下午

    一个平静的午后,突然微信、钉钉里,你被@了。

    这bug太严重了,用户操作多别扭呀,赶紧查查怎么回事儿,今天必须解决!

    技术一脸懵逼,这功能做了很久了呀,怎么突然bug了?赶紧把上古时期的需求翻出来,找了半天,咦,需求不就是让这么做得吗?

    产品:嗨,目前的逻辑仔细想想还确实有他的道理。那个,正好我加个东西,工作量很小的,一起改了吧。

    技术:可是现在业务都排满了,来不及了呀 !

    产品:这东西对咱们家很重要,你不想看到你爸爸失望的表情吧?

    技术:可是......

    产品:可是啥?晚点睡嘛,小孩子不可以顶嘴哟!

    和而不群,相爱相杀, 一团和气,群而不和,似乎已经成了我们的文化!

    经过多年发展一些产品是这样的:

    毫无征兆的发你一张图,告诉你:新功能来啦!

    仔细一看,这图上确实有那么几个页面,旁边写了些备注。

    技术问:需求出完了吗?

    产品回答:没有,不过咱们马上过需求。

    开发中产品说:这儿要改,另外我们要加个东西,不过现在还没想好。

    加完需求产品又说;辛苦大家,一定要保证上线时间!

    提测后,产品:开发质量不行呀!

    人人都是产品经理

    大家可以网上搜搜产品经理,我去搜了一下,下面出来一个网址,标题是:

    「想成为年薪30万的产品经理吗?」旁边一按钮,“测测我能否学”,好奇的点了一下,出来一个聊天框,我还没说话,对面就发来消息:

    可以的!产品经理0基础,无门槛,一学就会!

    我尼玛,难道真的印证了一句话:人人都是产品经理?

    最近产品部又在招人,我就帮帮忙给咱们产品岗位写了一个招聘信息:

    1)具备规划产品的能力(不具备也行),但我们更注重熟练更换功能模块在app中出现的位置,同样的功能,一会儿在这儿、一会儿在那儿,每个版本都给用户带来新鲜感,虽然几个大版本过去了,仔细一看还是原来的配方熟悉的味道,主题词都想好了:勿忘初心

    2)输出高质量的需求文档,但我们相信创造性的工作是需要时间和打磨的,所以你可以在开发过程中随时增加需求,修改流程,补充细节。页面不完整是设计的事,延期是程序员的事,而你只需追求极致,这个文案可以是永远年轻

    3)符合团队文化,作为高贵的产品经理,切记要随时45度角仰望天空,你是灯塔,你的使命是改变行业未来,不要让业务方和程序员限制了你的想象力,大胆的创造需求,永远的热泪盈眶。

    虽然我在胡说八道,但是大家是不是感觉很真实?产品被黑,主要有2点 :

    1. 不管程序员死活 ;
    2. 不管产品死活;

    我只能证明第一点,第二点就看各位老板的判断了。但老板也不是什么好东西,我们可以看下一个故事!

    老板的“狗性”

    在我还年轻那两年,一直把老板作为公司大家庭里的长辈,但后面发现为老不尊的事情时有发生!

    可不可以不睡觉

    记得一次在北京出差赶项目的时候,第一天加班加到12点。然后自己作死没睡觉,谁知道第二天又通宵,第三天又战了一天到发版。

    接近三天没睡觉,很刺激,整个人有种高潮后的颓废感。但是这件事情一般不敢拿出来说,要是被老板知道「研发真的可以不睡觉」,那我不是把大家给害了吗?

    但这件事还是被传了出去。有次通宵加班,天亮后看见老板出来晃悠,戴着耳机,听着摇滚,在研发周围走来走去。研发好些都趴下了,我也确实扛不住就趴着睡了,睡得迷迷糊糊的感觉有人说有bug,我立马又坐起来了。

    老板见状,说道:嘿,你们看,他又起来了!

    然后拿着手机就拍,和我小时候第一次见耍猴一样激动。我一直不明白为什么老板如此激动,自从我做Leader后,终于想通了,当时老板其实想说的是:嘿!这孙子又活了死而复生,当然激动嘛。

    老板也有爱

    但老板其实也是很不错的,为了和研发增进感情、拉近关系,主动提出大家一起打CS,老板打得很高兴,打完就出去吃饭了,还好心给我们点了不少外卖,我一直记得那天加班到很晚......

    而且老板和大多数长辈有一样的爱好,喜欢在家庭群里面发鸡汤、并附上一段很精妙的解读。想必转发之前都是深思熟虑,解读也是反复斟酌。其实老板不必这么费劲,下次可以试试转个《天线宝宝》,群里一样会有很多人给你点赞,因为我们真的没有点开。

    话说这个家庭群也很奇怪,就算老板不说话,工作日活跃依旧很高,而且每到周五活跃翻倍。不过里面只说1句话 :加班餐到了。周五翻倍是因为多了下午茶。

    透过现象看本质,这是什么?日常互动与促活的完美案例啊!

    很久以前老板发了条朋友圈,总结起来就是劝身边的朋友注意身体,不要用百米冲刺的速度跑马拉松。当时看了之后心里很矛盾,把老板当朋友吧,不加班怕被炒鱿鱼;不听他的话,继续拼命加班,朋友又没得做了,这可真难办!

    内卷时代的产品与技术

    技术>产品阶段

    接下来进入正题,这里抛一些问题出来:

    1. 业务型公司,技术容易成为公司大佬吗?
    2. 你们碰到写需求的是产品吗?

    首先回答第一个问题,就我的认知当中,业务型公司,靠技术做到不可替代的大佬很难,因为很多问题根本就不是技术能解决的,如果不熟悉业务的话,根本不能跟公司高层同频对话。

    其次各位平时遇到写需求的“产品”其实更适合称之为交互产品,他们要么在执行真正产品——老板的意志,要么在帮不靠谱的业务方整理需求,所以一线的技术遇到的产品更多是传话筒,这一点要明白。

    初期,因为是传话筒,很难有自己的意志,夹到技术和上层之间,对上毫无话语权,对下各种被喷,这些同学真实的工作体验其实很糟糕!

    这个阶段,如果一个有业务意识的技术Leader站出来,完全可以将产品收入囊中,这也是案例一的一个解法:那种场景下完全不需要产品经理角色了,扩大技术边界让一些技术Leader成为业务工程师即可。

    相信我,他们的需求看上去糟糕,其实技术同学无比喜欢。

    产品>技术阶段

    毕竟靠近老板和业务方,传话筒的好处就是信息量极大,所以一定会有聪明的交互产品“悟了”,开始真正思考产品的问题,这就和前一阶段的所谓产品拉开距离了:

    产品是通过不断的输入,找到不同的排列组合,产生对用户更有效、更高效、更可及的解法。

    所以产品是要解决真实世界存在的问题的,这种问题可以是:

    1. 业务的中间商如何去除;
    2. 中后台的效能如何量化;
    3. 项目的ROI如何确定;
    4. LTV效率如何提升;

    说个大白话是你要开一个饭馆,这个饭馆要开哪里、提供什么样的服务、怎么吸引流量等等,全部是产品经理真正需要思考的事情,而这一切很难!但在当今时代却无比的需要这样的人出现!

    没有独立思考的产品是虚假的产品。真实世界需要的是有独立思考能力的人,谁有独立思考能力,谁就是真正的产品经理!

    为什么越来越难了

    正常来说,五年就能把两个技术人员的差距拉到足够小!而拉进产品这个差距可能只需要两年!

    互联网这个行业这么多年了,这么多个五年了,技术除了最顶尖的一批人,其他人差距不会太大。而技术这批人比较聪明横向能力建设也是无敌的:

    1. 管理天赋觉醒,团队管理+项目管理,能承担很好的全局推动事项;
    2. 业务天赋觉醒,技术转产品,思考真实世界的问题;

    所以新的技术卷老的技术,老的技术卷所有产品,这一切自然而然的就开始了。

    如果回到10年前,技术不会做交互的工作,市场上可被挖掘的需求依旧很多,产品不用动脑子,就能取得很大的成功。

    但,这种简单的事情,没有了!!!

    投机倒把的事情没有了,信息差创造价值的事情变少了,简单的事情变少了,剩下的都是被惯坏了的真实世界:

    怎么办?

    锻炼独立思考的能力,锻炼全局问题处理的能力,不要有投机取巧的心理,一力降十会的事情会越来越少了。

    产研应该携手成为公司的核心驱动力,这里对产研的要求是,提供给运营的产品或者方法,是真实世界可用的产品,解决真正的问题。

    很多时候我们去做一件很难的事,就会想有没有什么取巧的办法可以绕过去,剑走偏锋嘛。

    但很难的事,多数时候是绕不过去的,是需要硬刚的,是需要碰得头破血流的,什么明哲保身、什么以退为进,在这些事情上是行不通的。今天能退,总有不能退的时候,那么何时来面对这一切呢?

    过程中会有很多“意见”和建议,不要不听但也不要全听,有你的节奏有你的主线,持续做,不过是解决问题罢了!

    自己跟自己较劲,其次跟同事较劲,其次跟老板较劲,然后推平这一路所有的阻碍,最后与真实世界对话,面对真实的市场,跟市场较劲!

    技术做什么创新?

    技术的价值在于场景应用,跟产品输入不足类似,技术对业务思考较少,对所谓业务场景化创新是完全没想法,这是真正的劣根性所在!

    走出代码世界,更多的参与真实世界,多见一见业务的发展和困难,是技术第一梯队最需要做的事情。

    一切能够被代码化和算法实现的,我们都应该去关注,任何能被技术解决的问题都应该优先考虑技术,这里具体的一些场景可以是:

    1)我们能不能根据技术手段比如爬虫,拿到用户的数据,给不同的医生打不同的标签,对几百万用户做一个分层管理,有了这个分层和标签系统后,产品端再针对不同类型的用户提供不同的定制服务,标签、分类做得好,才可能做出精准的千人前面服务;

    2)一些数据打通成本很高,技术上能不能打通公安系统与业务系统(比如酒店系统、银行系统),我们能通过人脸识别,精准的知道这个用户到底是谁,在哪从事什么工作,再做进一步产品设计;

    3)AI化可以替代哪些人工的工作,可以替代这些人工工作到什么地步,是部分替代增加效率,还是完全替代降低成本,当前每次交易成功都有百分之多少的人工成本,技术能将这个成本降低到什么程度?

    ......

    — 结语 —

    说到最后,产研多是打工人,分别心可以有,但还是为共同的目标奋战吧!文中多是真实案例,如果被提到了,我说的就是真实的故事!

    好了,今天的分享就到这,喜欢的同学可以四连支持:

    想要更多交流可以加微信群:

  • 相关阅读:
    SpringMVC 注解大全
    Maven实战--- dependencies与dependencyManagement的区别
    SpringMVC5.2.0 使用到 WebDataBinderFactory.createDataBinder 方法的类
    Spring DataBinder
    mysql 查询主键外键
    objectMapper.canSerialize SpringMVC实体转JSON字符串
    整合SSM时启动Tomcat报nested exception is java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/exc/InvalidDefinitionException
    synchronizeOnSession
    init-method afterPropertiesSet BeanPostProcessor 执行顺序
    SpringMVC中重定向参数的使用以及原理解析 RedirectAttributes
  • 原文地址:https://www.cnblogs.com/yexiaochai/p/16164941.html
Copyright © 2020-2023  润新知