不用撕逼,这6点可以让问题和平解决

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

hebingjiejuad

有人认为,你在通过各种方式增加他们的工作量;而你却感觉,他们做的总不能如你所愿。抛开个人因素,这可能就是程序猿与产品汪撕逼的大部分原因。如果都能做下自我批评,便可以省去交流中的很多困扰,毕竟吵架需要两个人,而停止吵架只需要一个人。

一、所有交流的基础——需求文档

写过传统的需求文档,“说明”与“原型”不能在一个层次上展现,编写的人需要经常用些代词,比如简单一句说明“当没有售后信息时,售后项目列表为空,并显示提示语”,程序猿便要上下滑动的查看“售后信息页”与“这句说明”,造成视觉与思维的跳跃,不易阅读。最近直接在原型上进行标注,自认为效果会更好一点。

不管需求文档演变成什么形式,都不能省去重要的三个要素:内容、规则、交互。想起大话西游中唐僧对至尊宝说的话:你想要你就说嘛,你不说我怎么知道。不要感觉有些地方是常识,所以就不用在原型上标注,你没写,程序员可能就不做,或者做错。

小学考卷上的“现代文阅读”,答案各领风骚,每个人因为性格,态度,眼光……不一样,理解也会出现偏差,所以我们关于原型的说明要尽可能的通俗易懂。

Image

二、沟通要及时

沟通可以让信息对称,从而在做决定时保证一致性。比如:甲和乙约明天出去玩,甲知道明天有雨,所以建议去一个咖啡馆聊聊天,而乙不知道下雨,所以想去户外晒晒太阳。我想如果乙也知道明天的天气,应该会和甲有一样的想法。

沟通可以避免更多问题的产生,一个项目很多时候是协作完成的,当你想要改动某个地方时,你要想是否会影响到其他人负责的部分,并告知他们。

开发过程中要主动的询问程序猿是否有什么疑问,如果他们对需求理解错了,防止他们在错误的道路上越走越远……

三、创建自己的控件标准

最近的一个项目,负责后台系统的设计,因为开发时间紧张,且后台界面自古以来不受领导重视,便跳过UI让程序猿直接看着原型写界面。因此三个程序猿在三个页面做出了三个风格的搜索框,如下:

Image2

增加修改的次数就是在增加撕逼的概率,我们要尽量避免修改这种小问题。因此我想有的地方我们能不能放弃“个性”,也做一个想教科书一样的规范,总结控件可能会存在什么场景中,在某个场景里它的样子是什么。

四、态度要端正

态度决定你对一个事物的看法,比如:早上到公司发现大家的工位都被收拾的比较整洁,你心想这是谁啊,这么好。当你知道是你特别厌恶的一个同事做的,你可能会想Ta又在这假惺惺的显摆。因此我想到了关于对程序猿的态度。

1、如果程序猿抱怨“太复杂”“没必要”,除了他们想偷懒之外,是不是我们在设计时没有考虑开发成本,可不可以再想一想要实现同样的效果,有没有其他的方式?用最小的开发成本实现最大的用户体验,真是一件善事啊。

2、金无足赤,人无完人。一旦因为你设计上的错误需要修改需求,大胆的说:抱歉,是我们的错,想的不够周全,辛苦了。承认错误是可以获得原谅的最好方法。

五、第一批用户,尊重他们的意见

做产品最经常提到的就是”用户体验“,我们想要跳出产品思维,经常闭上眼睛,把自己YY成产品小白去体验,可是再怎么YY,也不是正宗小白。在产品上线之前,程序猿便是第一批用户,他们不会陷入产品思维,在开发时与产品直接接触,除去想要”偷懒“的意见,有态度的程序猿总能给我们带来惊喜。

一个课程学习平台,最初设计的流程中是这样的:上传—审核—发布—观看学习(页面中有举报功能),在跟程序猿讲解需求时,其中一个人就说既然后台审核通过了,为什么还会出现举报的情况呢?想想确实如此。

人人都是产品经理,人人都要培养自己的产品思维,人人都能够对产品提出一些意见,所以程序猿的意见也应该受到尊重。

六、有些问题确实是开发时才能发现问题

实践出真理这句话说得不错,不管原型的保真程度有多高,交互效果总不能和使用的程序一样,那么对着原型去感受使用的效果,有些问题就体现不出来(经验丰富的前辈除外),我们努力减少修改需求的次数,但不能保证完全正确,以此安慰菜鸟的我和同在菜鸟路上的他人。

总结:

我害怕孤单,但不能没有孤单,因为在孤单的时候可以去思考,去沉淀。我们看待一件事要往对自己好的方面去想,对自己好不是去否定别人都是错的,自己全是对的,对自己好是能让自己进步的。

 

本文由 @朕曾也是百姓 原创发布于人人都是产品经理 ,未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 2

登录后参与评论
  1. 产品经理要有胸怀,当其他同事小心眼、耍心机的时候一定要有个开放大度的心态。你的首要目标是把产品做好,永远记住。

    回复
    1. 回复

      好的,谢谢教诲

加载中