【2021】技术人员的Secret Toolbox

之前我们谈到过能让产品经理在技术人员,包括工程师/设计师眼中迅速变Low的事情,其中有一点是“逼着技术团队承诺”,有同学不理解,问:

 

技术负责人对开发时间进行评估,并且给出排期承诺,是必须的吧?

答:我更倾向于认为承诺是传统瀑布模型下的模式,开发明确的任务、技术也成熟,可以提前计算好,但互联网的敏捷模式下,很多时候会做着做着发现坑、做着做着需求有不得已的变化,所以应该技术和产品一起做【预测】,心里想着目标,一起面对变化。最核心的区别,承诺是技术对产品的责任,预测是两边一起承担责任。

 

当然,这里面有个前提,就是技术同学要很靠谱。

 

而更可怕的一点,还没说,那就是容易逼出一系列可怕的大招——

技术人员的Secret Toolbox

技术人员的Secret Toolbox
技术人员的Secret Toolbox

Copy&Paste,不假思索的“复用”,满足当前需求就好,不考虑逻辑的可扩展,比如A和B现在1对1,不考虑将来有可能1对N,即使是业务上已经做出提示的时候;

Hardcode,写死代码,不用配置文件、变量,当你发现某个参数不妥,想要多改几次试试的时候,发现工作量超乎想象,而且怎么都改不干净;

Less Testing,听来一个很搞笑的故事,某位技术同学写完代码做单元测试,第一次没过,百思不得其解,于是再跑一次看看,结果过了,再跑,又过了,于是,就认为第一次是幻觉;

Skip Error Handling,不考虑异常情况,假设用户都是正常使用(当然,在某些情况下,业务方认可的时候确实可以这样做),举个最简单的例子,输入框没有做安全上限的长度控制,用户可以直接把程序搞挂;

Descope,偷摸减需求,不举例了,真的会有,验收的时候产品经理负责,发现了还好,但有时候只验收主要场景是发现不了的;

Less Review,减少设计评审、代码Review等,我们认为强技术可以少评审,但会动用secret toolbox的同学往往并不是很厉害的人物;

No Autotest,无测试自动化,工欲善其事必先利其器,磨刀不误砍柴工,一直不磨刀,整体效率就一直上不去;

……

还有啥招,技术同学不妨自爆……

 

这样做,本次交付的时候,会看着很美,需求都满足了,这时候产品经理还会暗爽——就是要逼吧,你看,逼一逼都做出来了,下次继续……

但往后,做着做着,你会发现整个技术团队越来越不愿意承诺了,承诺的越来越难达到了,经常延期?效率好像越来越低?出活越来越少?那就是因为填坑的时间占比越来越大了。

 

最终有一天,技术Leader面露难色的找到你,说:

“兄弟,业务发展太快了,技术架构跟不上,要重构了”

“啊,要多久”

“两个月,一半的兄弟都要参与”

“不可能,因为……”

“必须重构了,不然说不准什么时候就挂了”

……

熟悉吧,over。

iamsujie 微信公众号二维码
iamsujie 微信公众号二维码

【1019】我给运营的“提需求的模板”

一直以来,产品人员和运营人员似乎都是死对头。产品总觉得运营怎么想到一出是一出,没逻辑,乱提需求,变化无常;运营也觉得产品总是不给力,不懂KPI的压力,不帮忙实现这么简单的功能……

其实,最近我又碰到了这样的问题,所以,和运营一起讨论,制定了一个“提需求的模板”,来帮助大家化干戈为玉帛。我觉得,矛盾的一大根源就在于,运营提的需求经常就是“解决方案”了(或者更专业的,我们叫做产品功能)——要把页面结构改一下,要加几个按钮神马的,这时候,产品就会很郁闷——那还要我干嘛,你直接去找开发得了。产品希望知道的是,这个解决方案背后的那个问题(或者更专业的,我们叫做用户需求)。然后,由产品来做把用户需求转化为产品功能这件事,这才是产品经理的核心职责(而不是细化功能这种事,没错,我指的是写PRD什么的)。

所以,我给出的模板,要能说清楚这么几件事:

目标用户:这件事,是为谁而做的,一旦运营开始从这里起步思考,就可以自己排除掉很多需求了;

问题描述:目标用户碰到的痛点,只说“何时/何地,怎么难受”即可;

严重程度:对问题严重程度的判断,“高//低”即可,具体的判断方法,可以根据用户重要程度(这个比较主观,需要团队一起讨论达成共识,我们的产品是为哪几类用户服务的,他们的优先级排序是什么,这是产品原则的关键内容),问题出现的次数、频率等因素(相对客观,比较好办)考虑;

现有方案:现在是如何解决此问题的,我会认为,一个值得解决的问题,通常已经有人着手解决了,所以也一定已经有一些解决方案,而没有现有方案的问题,通常不严重;

建议方案:建议的产品改进 ,这点其实是借运营的脑帮助思考一下,产品不一定采纳;

价值描述:改进方案带来的额外价值,比如:省时间;能更精准的找到某某……

改进成本:建议方案的成本评估,“高//低”,同样,仅供参考。

产品拿到一堆这样的需求以后,在根据性价比为主要参考因素,决定接下来做什么。最后,给个理想化的公式——

性价比 = 严重程度/改进成本,问题(用户需求)决定严重程度,解决方案(产品功能)决定改进成本。