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

简介: 作为开发者,你都听产品经理的,做的累不累?

想必做过几年开发的小伙伴都碰到过产品经理各种需求,各种上线前需要改东西的情况。简直无语!下面我给大家盘点一下最让开发者无语的几种情况。


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

讲道理,成熟的公司,一个新版本的需求都是提前讨论制定好的,就算是改动也是小改动,但是这是成熟的公司,估计很少的公司能做到上线前不改任何需求的。


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


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


二.需求反复变

不清楚大家有没有碰到过一个功能让你反复改好几次界面的情况,开始设计一个界面直接就开始做,做了一半发现逻辑对不上,然后去讨论,完了回来重头写。折腾半天,时间浪费了,最后问你怎么一个功能做了这么久?是不是效率太低了?


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


三.产品设计无限拖延

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

当然上面说的不是敏捷开发的步骤...

很多时候两个周的开发周期,前面几步就被用掉了一周,开发拿到效果图已经是第二周了...开发前期很多时候能做的事情很有限...有时候根据大概描述先做也很不清晰,做出来后面看到效果图,基本也要重新改动一遍,改动小的除外,所以有时候开发的时间非常紧迫。so  加班 加班 加班

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

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

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

当然有很多时候这都是没办法的事情...大部分时候都是要按照需求做...

更有夸张的时候,我们做完马上要发布了,要求重新做一版..

五.产品开发时间卡的非常死

很多情况,我们开发的时候都会排一个时间表,大家严格按照时间表执行,但是这个时间表上面罗列出来的功能和我们真正的开发时间往往相差很多。一个支付功能问你做过没有,你说做过,那可能只给你1天时间,第二天产品经理就过来问 支付调通了没有...

让你负责整个项目,列出一大堆功能,问你20天能上线吗?你这就是赤裸裸的让我加班啊...

就算是开发时间够,开发过程中难免出现这样那样的问题。总要有一些处理其他问题的时间吧,万一开发环境突然搞乱了,或者电脑出了问题需要重装环境。又或者大家一起合作有同事把代码提交错了,覆盖了自己的代码。各种情况都有可能耽误开发时间。有的公司还各种开会,一个会一上午就没了...

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

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

六.简单功能复杂化

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


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


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


我在第一家公司的时候,老板提出这样一个概念,就是做一款可以配置的app,就一个项目...听好是一个项目,不允许拷贝多个项目然后修改,因为不好维护...


老板大概意思就是   首页的图片文字,主界面的模块功能点等都是动态的 所有的能看到的界面都可以在后台服务器配置...


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


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


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


这个产品的缺点:


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


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


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


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


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


程序员成功的关键有很多因素,碰到一个好的产品经理设计出一款好产品,你就算做的工作很少,也一样可以成功。


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


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


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


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


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


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


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


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


相关文章
|
2月前
|
前端开发 JavaScript 数据库
探索后端开发:从新手到专家的旅程
【9月更文挑战第35天】在数字世界的后台,后端开发是支撑起整个互联网的骨架。本文将带你走进后端的世界,从基础概念到高级应用,一起探索如何构建强大而灵活的后端系统。无论你是初学者还是有经验的开发者,都能在这段旅程中找到新的启示和成长的机会。
|
2月前
|
JSON 前端开发 测试技术
API接口 |产品经理一定要懂的10%技术知识
作为产品经理,掌握约10%的技术知识对处理API相关工作至关重要。这包括理解API的基本概念及其作为数据交换的桥梁作用;熟悉JSON和XML两种主要数据格式及其特点;了解常见HTTP请求方法(GET、POST、PUT、DELETE)及响应状态码;关注API安全性,如认证授权和数据加密;掌握API版本管理和错误处理技巧;重视性能优化,以提升用户体验;参与API联调测试,确保稳定可靠;并与前后端团队紧密协作,选择合适的第三方API服务,推动产品高效开发。
|
安全 测试技术 API
产品经理必学技术接口文档知识,提高工作效率
产品经理和开发人员之间的高效沟通和协作是项目成功的关键因素之一。在产品开发的不同阶段,产品经理需要了解开发工作的进度与掌握需求变化,以确保团队在同一方向上协作,以最大化项目的成功。
产品经理必学技术接口文档知识,提高工作效率
|
前端开发 开发者
开发者眼中的优秀产品经理是哪样?
本人作为一名开发人员,可以说打交道最多的就是产品和测试,尤其是新需求出来的时候,开需求讨论会,产品和一线开发人员在会讨论的交锋,很值得思考。那么接下来就来聊聊为什么会出现这种情况。
170 1
开发者眼中的优秀产品经理是哪样?
【团队技术知识分享 一】技术分享规范指南
【团队技术知识分享 一】技术分享规范指南
421 0
|
前端开发 JavaScript 开发者
开发者指南:如何在工作中投入?
开发者指南:如何在工作中投入?
107 0
|
运维 Cloud Native 多模数据库
探秘!在阿里云做产品经理是怎样的体验?
许力(仁威) 阿里云数据库产品事业部高级产品经理,目前负责阿里云原生多模数据库Lindorm产品
770 0
探秘!在阿里云做产品经理是怎样的体验?
|
运维 架构师 Java
开发团队组成 | 学习笔记
快速学习开发团队组成
199 0
|
安全 算法 数据库
|
机器学习/深度学习 前端开发 JavaScript
这项技能产品经理不会提,但技术人必须懂! | 开发者必读(110期)
最炫的技术新知、最热门的大咖公开课、最有趣的开发者活动、最实用的工具干货,就在《开发者必读》!
1405 0
下一篇
DataWorks