周不疑

又一个WordPress站点

张小盒为什么普通人觉得很容易实现的技术,却让程序员一筹莫展?-菜鸟教程

为什么普通人觉得很容易实现的技术,却让程序员一筹莫展?-菜鸟教程
每一个用户,其实就是一位“产品经理”,用户在使用产品的时候,只要形成了足够多的主观感受(好/坏),并有意愿表达出这种意愿。那么,用户其实就是在承担“产品经理”的职责。
下面,我就说几例,产品经理和程序员之间,因为对“简单”的理解不同,互相伤害的故事吧:第一种“简单”:没有厘清可供对方理解的地方
出现“简单”一词,很可能是因为相关技术点没有厘清。
没厘清技术点,贸然开工会导致研发过程中沟通频繁、研发目标难以明确以使交活时有较大几率陷入扯皮风险、具体研发时间无法估算。
场景一:这个位置温立三,用来摆放用户头像,简单做一下就好。
分析:将需求点转化为技术点的能力,是产品经理与游戏系统策划的基本功。队友基本功不行,这单需求也未必就没救,关键就看需求点是否明确。
针对需求点明确的情况,如例句,可以用追问的方式细化以挽救。如:
头像多大,本间贵史多少乘多少?
——大概400*400吧。
目前定不了是吗?
——是的。
你刚说400*400,长宽比例固定是1:1吗?
——我想想……不一定,具体要等界面Demo出来后再看易用性。大小不写死,我清楚了。
只在这一个界面用吗隐讳的意思,其他View会有头像展示吗?
——可能会。那写的时候还要照顾下复用性,清楚了。
看你画的是矩形,确定是矩形边框吗张小盒?
——不,是圆角。
圆角弧度多少?
——额,我要再确定下。
头像上有可能会叠其他东西吗,比如,加个V?
——会有类似的。我本来是想做到VIP系统再提。
可以看出,即使是一个简单的头像,尺寸、形状、身份表示等等,在技术开发那一端石川云子,都会被拆分成不同的需求来实现。
一些新手产品经理,站在和普通用户几乎差不多的角度,把许多组建看成一个模块,“一股脑儿”地要求技术人员帮他实现。这个时候,经验丰富一些的程序员,就会帮他理清一下思路,把该拆分的需求拆分,这样不但可以立马解决“需求→实现”,也可以让这个新手产品经理有所进步。
不靠谱度:★☆☆☆☆ —— 起码知道要的是什么第二种“简单”,缺少设计实现
软件开发是一个非常复杂的行当,制定需求→绘原稿→出设计图→程序实现是最基本的四个步骤,但普通人,往往会直接忽略前三个步骤,所以每当他们脑洞大开之时,他们就会产生这样的想法:
“就差一个程序员了!”
举个简单的例子吧:
1. (同行介绍来的土豪)你好,我要做个股票分析软件,我这儿有一套完整的公式,来给各支股评分,你出个手机版的就行,界面就是那种最普通的,重点是功能要齐全。
翻译:听说你们会写代码?界面也给一块儿画了吧。
分析:一般碰到这种“大白”,合计下看够不够再雇俩人一块儿干,一个做UI,另一个负责跟他沟通,明确他的每个需求点。
2. (公司领导)小王,你上个项目做的不错爱信精机,年末了听说我爱过你,交给你一个小需求,让你去做吧。就是做个简单的公众号应用,接上公司的CRM系统,有重要事项时给相关负责人发个推送就行了……
小王问领导详情,领导有以下两种回复:
啊,你平时带着做就行,啥?产品经理?这么简单个玩意儿,还用的着产品经理?你管我要案子?流程逻辑?界面图?后台API?没有没有,你自己开脑洞去吧!
项目做完了,年景不好接不来啥单子,后面俩月没你事儿了,年底要发奖金了澍怎么读。让你做这个,是故意刁难你,识相点的,赶紧辞职吧,别耽误大好前程,公司也得“节流”不是?
不靠谱度:★★★☆☆ ——程序员可不是“万能”的第三种“简单”,蹭人情
“我这个项目很容易实现,两千够了吧?”
“这么简单的小需求苏太华系,你报价一个月?”
“不就是把Flash转成H5,用来在微信里分享的吗,你要我这么多!”
没啥好分析的,直接和他说“拜拜”吧。
不靠谱度:★★★★★ —— “帮个忙嘛,这顿饭我请!”
亲身经历
真人真事,就发生在我身上。
有一次过年回老家,来了个亲戚。
哎,小李啊,听说你现在是程序员啊。哎呦,厉害啊……
吧啦吧啦一大堆……
你帮我做一个软件呗,很简单校园仙侠传,就是你弟弟(他儿子)天天玩手机。这一个软件,可以让我随时看到他在哪里,用手机做什么,最好还能看到他的摄像头扭痧。我之前有这样的程序,不过现在要花钱了,这对你来说应该很快就搞定了吧。还有,最好别让你弟弟发现有这个程序。
第一我是Python,C系列的狗,好歹你也找个Java狗吧。第二,有这样的软件你还让我再给你写?我定制个软件都是收费的啊,况且比市面上的软件价格要高很多(定制跟商业化的软件收费肯定有差距,一个人独自承担跟很多人分担,相信大家懂)。第三,你说的这个东西就是个木马啊。
我说我不能做,内心其实在想,那个软件收你多少钱,我替你付了。
没然后了。
总结
实际上,并没有特定的“看起来简单实际上难以实现”的需求。
只有项目开发者才有评判具体需求实现难易的权利。即便是同项目组的程序员之间互相提需求,在不清楚对方代码结构的前提下,也没有足够的信息量去评判实现难易度麦野沈利。
内行尚且如此,就更不要提,外行对内行产生的粗浅认识了。
好人难当,程序员难做。
来自:http://codebay.cn/post/4061.html