如何界定业务逻辑与技术细节

日常的需求评审中,产品经理与开发人员往往会陷入业务逻辑与技术细节的纷争,开发人员觉得这是业务逻辑,要产品定;产品觉得这是技术细节,开发说了算。双发各执一词,吵得不可开交。

尽管需求评审的意义就在于聊清楚细节,但也未必所有细节都要等到会上才能聊清楚,这些争吵总会有些规律可循。

其实业务逻辑与技术细节的边界是非常清晰的,只是有时大家本着多为对方着想的态度,操多心而已。那么这个边界在哪里呢?对了,就是“技术”二字。

产品经理可以了解技术细节,甚至精通某项技术都没关系,但是在产品研发的过程中,是不需要“侵入”技术的。或者说,不需要为技术着想。产品经理需要技术给出的是可行性,即能做还是不能做的问题。而能做要怎么做,就不必关心。如果说不能做,要砍我需求,我倒要问问你是要闹哪样了。

技术研发可以了解业务逻辑,但不能替产品定夺产品形态,更不能在许多产品细节上“先斩后奏”。再敏捷的团队,只要有产品经理存在,就一定是产品来定夺。对于设计师也是一样,既然有设计师存在,就要尊重设计师的工作,在下游实现阶段随意修改设计是不合适的。

举几个常见的例子:

  1. 某个系统错误 PRD 里没写,开发人员自己加上了文案“啊哦~系统开小差了~”;
  2. 某个设计师没空,开发人员自己根据色系搭配了个按钮颜色;
  3. 某个产品觉得这个特性可能系统性能不好,决定不做了;

乍一看这些例子对敏捷开发是有利的,一定程度上可以加快系统上线,不必拘泥细节。但细想起来,就会有问题。

比如,例 1 中的系统假如是个正式严谨的系统,这样的文案就很有问题,而开发人员可能更倾向于使用自己喜欢的语气,未必会考虑真实用户的角色和使用场景,这里就可能给用户造成不适;

例 2 中的例子,我们可能是觉得设计师太忙了,不便打扰。但是系统上线之后,设计师看到的第一反应可能是“什么鬼?这谁设计的...”。设计师可能会感到不受尊重,也可能会因为没有把关好设计而受到批评;

例 3 就更典型了,我们好心的产品经理觉得性能不好,就砍掉了的需求,真的性能不好吗?性能问题无法解决吗?即使真的有无法逾越的障碍,也不应该在产品构想的阶段成为阻碍,没有必要在这个阶段考虑技术细节。

好,你说让我只管可行性,那你说到底能不能做吧?!先等等,能做,但是 ... 你要知道,可行性与实现成本的区别也是常见的陷阱。

什么是可行性?你可以理解为就是能做不能做。但能做是有条件的,不能做也要具体场景具体分析。如果一个特性要求必须 3 天上线,但实现成本要 6 天,能做吗?如果说能,程序员加加班就行了。皆大欢喜;如果说不能,凭什么?6 天怎么来的?不能再快点吗?大不了我陪你一起加班?能。

其实,只要双方心平气和加强沟通,没有做不了的事儿~ 你觉得呢?

作者 | 姬小光 来源 | 姬小光 [ ID: hi-laser ]

识别二维码获取更多干货文章 ↓↓↓

原文发布于微信公众号 - 姬小光(hi-laser)

原文发表时间:2019-04-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券