wkiwi的博客

如何看待产品与开发关系

发布时间:3个月前热度: 69 ℃评论数:

本文中主要阐述的问题包括:


1、是不是只要没有技术上的实现问题,开发者就不应该对产品经理提出质疑?

2、需求文档、功能文档、最新而最全的原型设计文档,这些要求过时了吗?

3、产品经理进阶建议。



软件工程领域,本着分工合作高效进行的管理方式,每个人只要做好自己的分内事就行。当产品经理召集开发人员进行各种评审会的时候,其实是想让开发人员好好分析下,会不会出现逻辑问题。至于在产品设计上,开发还是比较人微言轻的。产品负责将这次的版本迭代做出来,让功能能够覆盖相关的需求,让开发人员确认过没有逻辑问题的情况下就可以进行到开发阶段了。如果开发人员产品设计上有过多的啰嗦,产品就会问你“是否有实现逻辑的问题?如果没有的话,就按这样设计的做就行了。”

关于这种情况,在软件实施管理的知识来说,是正确的。乔布斯也说过:

大致的意思就是,“你必须从用户体验开始,然后用技术实现它们。而不是反过来先去考虑技术。”

但是,如果一位产品经理代表的并不是用户体验(只是自己的主张),而拿这句话来搪塞勤劳的开发人员,那真的很让人烦恼。

首先,在现在的软件工程行业,开发人员为了能够更好的面向对象思考问题,也会面向对象的组件化开发。举一个简单的例子,如果一个app项目中有好几处可以提供给用户选取时间的功能,因为考虑到现有的3处地方都是一样的,为了以后的组件化开发,一个负责的开发人员会把这个“选取时间”的控件封装好,以便下一次直接使用。可是糟糕的是,下一次的版本迭代中也有一个地方需要提供时间选择功能,但是产品将这个时间选择界面的样式改变了,以前其他地方用到的时间选择样式依然按以前的来。对于这种情况,开发人员真的是好难过。但是,开发者要拥抱改变。这无可厚非,但是请说出这次为什么就要改变样式?以前的样式不符合吗?。。。“不好意思,这个不是你们开发考虑的问题,你只需要告诉我能不能做出来就好了。设计上的问题,不用你们操心。”产品会这样告诉你。

类似的情况还有:当开发人员指出产品的设计漏洞时,产品会以一种“战略性的鄙视”告诉你,“你所说的我们早都考虑过了,但是这一次的版本迭代我们先这样做~”唉,真是厉害。

上面说了这么多,我只是想替勤劳的开发人员说句公道话。首先请理解软件工程行业的组件化思维,组件化思维不仅是开发要做的事情,产品、UI、测试等人员都是需要进修的一门课。然后,在开发人员把常用控件组件化好以后(按道理来说,应该由产品提出哪些控件需要组件化,尽早的统一好样式和功能让开发封装好),产品却还要进行改动。其实,开发人员不是不愿意改动,而是,他们只是想确定下你是不是认真的?是否真的有这方面的需求?是否真的需要改进?那之前的样式是否需要统一起来,还是区别处理?这些问题,开发只是想确定好产品经理是认真思考过的,而不是“看产品经理当时的心情”。

其实,如果开发与产品经理之间的关系到了这种不信任的地步,这样下去就会出现两者情况:第一种是,开发和产品经理不和气,经常会为了产品的设计发生争执。其实这种情况,至少说明开发还是比较负责的态度,如果真是第二种情况,那就没希望了。第二种情况就是,以后产品怎么设计,开发就怎么做,产品本身的事不再关心。产品想怎么改都行,反正只要有时间,没有什么是开发不出来的(软件行业,又不是研究行业),最终受到损失的是公司。

上面说了这么多,包括有时发生的产品经理和开发人员发生暴力事件。都说明了一点,现在大部分的软件工程行业,或者直接说是互联网公司吧,产品经理的话语权没有放置在合适的层次。当然什么事情都有两面性,当这位产品经理的能力得到大家的一致认可,并且通过了各方面的考验,那么赋予这位产品经理更好的执行权是可以的。否则,还是乖乖的按照正常流程执行会比较好。所谓的正常流程就是说,学习西方的管理方式,制度为上,而不是人治。

敏捷开发提倡口头交流这种高效方式,但是并不是说就从此以后就不需要文档了。所以,需求文档、功能文档、完整的原型设计文档是不可少的。

产品与开发的关系

栏目导航

  1. 杂谈
  2. PHP
  3. 建站
  4. WEB前端

手机扫码访问