我所理解的前端 (2)

和UI的沟通,在工作中我们不应该是被动的实现UI的设计,而是应该合理化的提出自己的想法,不然日后返工浪费的是双方的时间,比如最开始刚来公司的时候,项目里对一些小图标的图片还在使用雪碧图,但很明显随着浏览器的支持越来越好,svg和字体图标慢慢占据主流,我在阿里巴巴图标库建了一个项目把UI也拉了进来,UI把他用到的图标直接添加进项目,前端直接从项目生成字体图标引入到项目,绝逼要比自己慢慢切图,扣图标,合并雪碧图要省事的多,而且用起来也特别爽,想改颜色就改颜色。再比如你需要做一个图表,用到了echarts,你完全可以让UI基于echarts去设计样式,而不是让他在那里自由发挥,因为你永远不知道设计师的脑子里装了多少创意,这样节省的是两个人的时间,不会出现他做好样式而你实现不了的尴尬。

沟通产品

一般来说程序员和产品经理之间是最难沟通的,只有相杀没有相爱,毕竟子曾经曰过:’这个需求很简单,怎么实现我不管,明天上线!’,

下面引用lensuntop的一篇文章,我觉得写的非常好

记得有一个段子:

产品汪:程序猿,我们来实现一个紧急需求?

程序猿:请说。

产品汪:请根据手机壳的颜色,来实现APP启动的颜色。

程序猿已经在风中凌乱。。。

从这个段子中多少能折射出产品和技术之间的各种激情“火花”。产品经理眼中简单的需求,而在我们看来是不可能实现的。而程序员也无法理解产品经理为什么要实现这样的需求。那么,站在一个程序员的角度应该怎么样和产品经理沟通呢?

1.深刻理解需求,清楚需求的动机和缘由

我们程序员一定会在问,产品经理为什么想要根据手机壳的颜色来动态实现APP启动时的颜色。既然想听解析,那就先别急着说出自己的结论——技术上无法实现!既然有疑问,那就先将自己的疑问解决。

2.换位思考

产品有产品的角度。作为程序员我们追求的是什么?逻辑正确,更快,更容易扩展。产品追求的是什么?说实话,我自己没有深刻去思考过这个问题。站在一个惯性的角度思考可以想到:一个产品为什么存在,他的存在能解决什么问题,他的用户体验好不好。这些才是决定一个产品的核心价值。毕竟工作性质影响了一个人的思维逻辑,所以这时候,我们能站在一个产品的角度去思考每一个需求,便显得尤其重要。

 

3.不放过每一个细节

作为程序员想必对这句话都是深深认同的。因为一个标点符号或者类型的错误,会导致一个自己意想不到的bug。产品经理在设计一个产品的时候,都是从大方向去想问题的,大方向没有错就行了,细节脱离不了大方向。这是他们想的。但是对于程序来说,却万万不能。因为一个细节的逻辑往往决定了整个大方向。举个例子:有一个需求,用户的作品需要提交审核,经过审核才可以让所有人看到。当产品经理交这个需求给你的时候,你能察觉到什么问题了吗?这里面有几个细节:1.用户提交审核后,用户可以不可以再编辑作品;2.作品是否会多次审核;3.需不需要记录审核历史;4.用户作品是否需要有版本的控制,如要产生版本,版本又是如何产生的;5.审核通过后,用户可以不可以再修改作品,若不可以,那么是不是其他人就看不见用户作品......话说回来这只是一个简单的逻辑需求!但是涉及的细节却是太多太多。我们往往在编码的时候写不下去,就是因为给的需求太模糊,没有细化到点上。

4.换一种方式说“不能实现”

不能实现,这句话想必我们都是经常说。但是直接对产品经理说,没准会让产品经理抓狂。因为我们会让他们觉得他们提出的任何需求,我们都不能实现。但是事实并非如此,因为不能实现是有条件的,比如时间不够。所以我们要先认同产品经理的观点(“能实现”),再提出自己实现他的需求的条件是什么。因为现实产品经理也不会经常犯傻,经常提出一些不合理的需求,但是面对需求,我们需要评估实现的时间,而且这个时间不是那么容易评估准确的。

5.当遇到不合理的需求时,积极寻求替换方案

就拿段子里面的需求来说,让我们提供几种APP皮肤给用户进行选择,肯定比原先的需求容易实现,而且也更加符合人性化。说另外一个故事,有家智能家居的公司,要实现厨房水龙头,根据人声说水温几度,就可以达到几度。换个角度想,你会感觉出40度和45度水的温差吗?而且根据人声判断,这又涉及到声音识别系统,你要兼容多少种语言?其实我就觉得左右切换就挺智能的,完全没有必要搞的那么复杂。所以程序员要找到一种更好更容易实现的方法。别给产品经理的想当然自乱阵脚。

6.必须遵循文档精神

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpdzfw.html