• 作为开发人员,你都听产品经理的,做的累不累?


    想必做过几年开发的小伙伴都碰到过产品经理各种需求。各种上线前须要改东西的情况。

    简直无语。以下我给大家盘点一下最让开发人员无语的几种情况。


    一. 上线前一天或者几个小时,提出新的需求

    讲道理,成熟的公司。一个新版本号的需求都是提前讨论制定好的,就算是修改也是小修改。可是这是成熟的公司,预计非常少的公司能做到上线前不改不论什么需求的。

    非常多开发的兄弟上线前几个小时还能拿到新的需求文档。然后就是各种写程序。可是这样的情况非常难保证不出一点问题。完了搞不好就被经理各种批,这么小的错误也能犯。

    由于上线前。大部分情况都是在改bug,一边改着bug,还要应对随时来的“”小的修改“”。反正说多了都是泪...


    二.需求重复变 

    不清楚大家有没有碰到过一个功能让你重复改好几次界面的情况,開始设计一个界面直接就開始做,做了一半发现逻辑对不上。然后去讨论,完了回来重头写。

    折腾半天,时间浪费了,最后问你怎么一个功能做了这么久?是不是效率太低了?

    我当时真的想拍桌子问问产品。你能不能開始就把功能这个逻辑都设计对?锅都让开发背了...

    三.产品设计无限迟延

    一个产品开发新版本号流程大概是:提出需求->依据需求UI做出效果图->然后产品和UI依据效果图做出小调整->定稿,UI切图->开发依据效果图开发

    当然上面说的不是敏捷开发的步骤...
    非常多时候两个周的开发周期,前面几步就被用掉了一周,开发拿到效果图已经是第二周了...开发前期非常多时候能做的事情非常有限...有时候依据大概描写叙述先做也非常不清晰,做出来后面看到效果图。基本也要又一次修改一遍。修改小的除外,所以有时候开发的时间非常紧迫。so  加班 加班 加班

    四.产品设计不够总体化考虑

    好多时候产品经理提出新的功能或者需求都会去參考其他的app。假设是一个经验不太够的产品,他每次设计出来的东西和整个产品都不一定能相应上,比方 :好几种颜色的标题栏。首页风格常常会变 一会九宫格布局 ,一会儿tab标签栏布局(一种是activity跳转,一种是fragment碎片),好几种风格的筛选数据的效果。

    我们一般开发非常多功能都有一个共用的概念,比方程序的标题栏等都是继承一个。假设效果不一样,我们就要单独处理。导致程序可维护性不高。

    当然有非常多时候这都是没办法的事情...大部分时候都是要依照需求做...
    更有夸张的时候。我们做完立即要公布了。要求又一次做一版..

    五.产品开发时间卡的很死

    非常多情况,我们开发的时候都会排一个时间表,大家严格依照时间表运行,可是这个时间表上面罗列出来的功能和我们真正的开发时间往往相差非常多。一个支付功能问你做过没有,你说做过。那可能仅仅给你1天时间,第二天产品经理就过来问 支付调通了没有...
    让你负责整个项目。列出一大堆功能,问你20天能上线吗?你这就是赤裸裸的让我加班啊...
    就算是开发时间够,开发过程中难免出现这样那样的问题。总要有一些处理其它问题的时间吧。万一开发环境突然搞乱了,或者电脑出了问题须要重装环境。

    又或者大家一起合作有同事把代码提交错了,覆盖了自己的代码。各种情况都有可能耽误开发时间。有的公司还各种开会,一个会一上午就没了...

    有些负责人还要去面试。面试回来就被问进度怎么样了?要不就是带些新人,帮助他解决这个问题或者解说业务 这都须要时间啊!

    有排计划的时候把这些都考虑进去的吗?产品负责人仅仅会说,这点功能怎么这么久还没跑通?

    六.简单功能复杂化

    举个样例  一个选择城市的功能,可能公司产品就支持3个城市,大家在做这个程序的时候,一般有点经验的都会考虑 这个城市以后添加了怎么办,肯定不能够在程序里面写死。这个必须动态控制,不能以后添加一个城市我们就提交一次app吧。 这么想讲道理没有问题。然后获取一个城市列表(3个固定城市)加一次网络请求server。然后产品经理过来发现,你这么做有问题啊,就这么三条数据每次进这个界面还有正在载入数据(一般网络请求假设网络慢的时候,都有载入中提示...),然后让你改,说体验不好....然后你就要想办法了。这个不能写死。还不能每次都载入,那么仅仅能第一次载入完存本地了,下次推断本地有就不请求server了...好然后高兴的写去了,写完想想有漏洞,假设server这个时候有增删改就麻烦了。比方 多个城市。少个城市,改了当中一个城市的名字...这个本地就和server相应不上了,然后还要再加入对本地数据更新的逻辑......

    后来,这个app再也没有支持过别的城市,白白加了这么多复杂的逻辑...

    我总认为功能尽量越简单去实现越好,不要为了一个简单的小功能去影响整个产品的体验....

    我在第一家公司的时候。老板提出这样一个概念。就是做一款能够配置的app。就一个项目...听好是一个项目,不同意拷贝多个项目然后改动,由于不好维护...

    老板大概意思就是   首页的图片文字,主界面的模块功能点等都是动态的 全部的能看到的界面都能够在后台server配置...

    说白了就是:app上全部的地方都要从后台请求字段 ,然后依据定义好的字段的值 去控制app的显示....这样就会产生出来非常多app... 餐饮,医疗。交通,购物....

    老板的概念是:定制化全能app...

    大家想一下这个难度有多大。然后缺点有多少.

    这个产品的缺点:

      1.app内逻辑以及请求太多,影响app的流畅度及体验

      2.从产品角度考虑,配置出来的app缺乏个性化,功能界面效果非常单一。

      3.产品过于复杂。导致app本身过大。(基本全部第三方的sdk都会用到,jar包就几十个) 

    我理解的好的产品应该是: 设计简单、操作流畅、功能简单易用、稳定性高、用户体验好, 这些都非常关键。

    所以一些功能从产品经理设计出来的那一刻就注定是失败的。开发多努力都毫无意义...

    程序猿成功的关键有非常多因素,碰到一个好的产品经理设计出一款好产品,你就算做的工作非常少。也一样能够成功。

    可是你碰到坑人的产品经理设计出坑人的产品。你多优秀都会被埋没....想必这也是非常多大神都愿意去大公司的原因...的确产品好。自己做的也没有那么累...

    小公司什么奇葩都有...


    说了这么多,我总认为基本几年的开发都碰到过类似的情况。那么我们开发假设总是被产品牵着鼻子走,做的累不累?

    我们开发要怎么面对这些问题呢。我提出我自己的几点看法(有问题及时提出指正):

    1.我们尽量要參与需求的制定及讨论,尽量对一些不合理的地方及时从开发的角度提出自己的意见。

    2.当需求制定出来的时候,我们拿到效果图,不要着急做。要脑子里面先想想哪里有问题,不合理,总体流程能不能跑通。

    想通了在做。

    3.当产品上线前,尽量不要做一些没有太多意义的小功能。精力都放在处理关键bug,问题上。功能能不加就不加。

    4.提前制定好计划。当需求重复改的时候,要及时和上级沟通交流,调整时间计划,避免后期时间计划相应不上。

    临时就想到这些了。后面想到再补充,希望大家也能够多多提出自己的看法。

    都谈谈自己碰到的奇葩无语的事情。


    欢迎大家增加我的开发群:454430053

  • 相关阅读:
    13.ng-value
    Android 下使用 JSON 实现 HTTP 请求,外加几个示例!
    PHP完整的AES加解密算法使用及例子(256位)
    常用对称加密算法(DES/AES)类(PHP)
    随机字符串生成算法
    JAVA实现AES加密
    Base64的好处
    什么是VC、PE、LP、GP?
    mysql update操作
    iOS开发:用DES对字符串加解密
  • 原文地址:https://www.cnblogs.com/wzzkaifa/p/7376047.html
Copyright © 2020-2023  润新知