新闻

如何成为一名受技术员欢迎的产品经理

时间:2015-02-27 09:32:26

如今,用户体验这个词已经渗透到越来越多的行业,贯穿于整个企业的研发、推广和市场运作。RD(研发)和 PM(产品经理)之间的矛盾与协作,也时常成为互联网行业里的热门话题。PM 方面文科出身偏感性的居多,时常看到他们分享经验(RD 一般直接骂 PM 是傻X),但考虑到他们的知识体系和思维习惯,这些分享大多没啥营养,缺少参考价值。

如何成为一名受技术员欢迎的产品经理

  那么如何缓解RD和PM之间的矛盾,成为一名受程序员欢迎的产品经理呢?

  一、了解web产品的一些技术知识:

  1、B/S结构:

  首先要讲到是Web产品的结构,Web产品是属于B/S结构 (Browser/Server,浏览器/服务器),这种结构我们只需要考虑到服务器的 负载而不用担心用户设备的性能,因为很多事浏览器已经帮我们解决了,当然这种结构模式拥有一个无比头疼的问题,那就是跨浏览器的兼容,当然这是前端工程师 的事了(嘿嘿),不过,作为产品经理,必须要知道哦,例如有些功能特效在IE6浏览器里,那就…

  对于B/S,是要考虑浏览器和服务器两端的性能的。在浏览器上跑JS,载入瀑布流页面,大 量图片等都可能 过多的消耗资源,逻辑不合理的页面甚至会不断消耗导致浏览器崩溃。产品经理在制定性能规格的时候,页面打开时间其实是B和S双方的考核,所以现在有 lazy loading这样的技术从用户体验上加速

  2、技术框架(PHP框架):

  技术框架太偏向于技术层面的知识了,不过对于产品经理来说,如果能够掌握相关原理,那么在以后的产品规划中,能够帮助我们做很多资源整合和资源复用的工作,减少技术资源成本,当然这些更多是技术负责人考虑的问题了,但是如果我们PM也懂原理知识的话,在沟通上就方便多了。

  3、模板引擎:

  模板引擎最典型的案例就是CMS系统的架构,通过模板引擎让我们实现了前端界面和系统架构分离,无论任何一方的升级改良都不会影响到另一方。WordPress主题就是模板文件,由模板文件定义前端界面的展现风格,模板标签调用数据,实现数据内容的显示。

  通常最基本的模板引擎文件分为:首页、列表页、内容页。由于每一页的头部和尾部是一样的,所以这三页又拆分成:头部、中间内容、尾部。三页共用头尾部,只是中间内容不一样。如果你了解Axure软件的话,应该能够明白,这和Axure软件中的Masters是一样的原理。

  4、插件扩展:

  一般情况下,技术框架都会有一套内在的API接口,用于实现一些相对独立的技术功能,例如计划任务。这个技术知识没有统一的理解,也会根据不同的产 品需求有不一样的结构规划,主要应用在平台级产品中,例如WordPress就有一套系统插件的机制,如果有兴趣可以看看官方的相关介绍,这里我就不多介 绍了。

  5、CMS:

  每一位产品经理都应该非常了解CMS系统的架构,因为这是一套最基本且可扩展性很强的平台级产品架构。推荐PM们在自己的电脑里配置一 个PHP环境,多多下载体验一些Web产品,多了解各种类型的产品结构,这对我们以后规划产品时非常有帮助的。这篇文章里讲到的所有知识在CMS系统里都 有体现。

  6、开源程序 :

  开源的英文是Open Source,意思是开放源码,也就是说开源程序是一个开放源代码的程序,技术框架就是一种开源的项目,很多热心的个人或组织将自己积累的技术框架开源出来,提供给大家使用。

  Discuz(被腾讯收购)、PHPWind(被阿里巴巴收购)、PHPCms(被盛大收购)、ThinkSNS(功能类似新浪微博,但是开发出来比新浪微博早)、WordPress(应用最多的Blog系统,国内各大公司的UED团队博客都是使用的这套系统)、EmpireCMS和DedeCMS(国内知名的CMS系统)

  7、API(应用程序编程接口):

  随着移动互联网和开放平台的发展,产品的多方面拓展需求增强,因此产品规划中对API的需求也会更加重要,因此API的相关知识对于PM也是相当重要的。

  二、不要假传圣旨狐假虎威:

  偏偏很多 PM 还特别喜欢用“我觉得……”这种句式跟 RD 交流,遇到挑战往往也没法拿出数据、竞品设计进一步讨论,只能说“总会有人……”“像我这样……”,甚至继续“我觉得……”。他们忽视了一个问题:大家的 命运都和产品息息相关。RD 对产品的关注程度,倾注的情感,并不比 PM 少。RD 对产品的期望,也不比 PM 低。这个时候,如果 PM 拿来的一份说不清好坏甚至脑残设计,那被抵制或消极对待就是自然而然了。除了直接合作的 RD 以外,争取交几个 RD 朋友,提需求之前,请他们先帮忙评估下开发成本,再去跟自己的 RD 沟通时会有准备的多。

  PM 一定要树立自己的专业性权威性,要让 RD 相信,这个需求是有利的,是有效的,是可以给自己带来奖金的,那么积极配合就是水到渠成的事儿了。

  三、理解程序员:

  理解,就是“PM 动动嘴,RD 跑断腿”了。能理解这一点,其它也都好理解了。任何需求都有开发成本,这个开发成本,往往连同是 RD 的其他人都无法准确估测,更何况缺少技术背景的 PM。所以很多 PM 提需求提得很随意,明显没有经过深思熟虑(或者明显没有和更高阶的 PM 进行讨论,或者没有和其它需求方确认);改得更随意,而且常常伴着一句:“你就那个那个啥一下,很简单。”坦白告诉你,听到这句话 RD 没拿出刀砍死你说明他爱你。想改善的话,开工之前多沟通,降低返工可能性;提出需求时尊重 RD 的判断,共同拟定阶段性目标;开工后尽力维持计划,等等。

  四、避免误区:切忌打嘴炮

  请搜索 下“产品经理自我修养”,搜出来一堆心灵鸡汤。这些文章几乎可以作为产品经理“假大空”的代表,正是这些文章误导了很多初入行的新人。

  作为有必要时常和 RD 打交道的 PM,一定要务实,想法要落地,提出的东西要有具体执行细节,有考量标准。不能满嘴跑火车,动不动战略布局就,动不动就拽名词(“破坏式创新”),动不动 就引名言。我们的目的既简单又统一,把产品做好,把运营做好,提升用户体验,抓住用户,增加活跃用户,最终流量变现,大家分钱。这之间,需要的是一个又一 个具体的需求,一点又一点持续的改进,合理规划的统计点,用数据支撑的每步选择。而且前面说过,RD 可能嘴笨,其实很聪明,并且有点优越感,PM 拿不出真材实料只靠嘴炮很快就被归到不靠谱那类了。

  总结:其实 PM 和 RD 不是仇人,相反,二者的切身利益息息相关。PM 希望找到给力 RD 的同时,无数 RD 也在期盼上天赐予一个靠谱的 PM。RD 不善表达的居多,也懒得跟“外行人”废话,所以常常只表现出对 PM 很冷淡甚至敌视。其实他们并不是不愿意做功能或者不接受改需求,只是需要一些更说的过去的理由而已。

  获取 RD 信任之后会发现他们都很好相处,而只要做到以上几点,受到 RD 们欢迎也是必然的。

  
loading

官方微博

电话:020-38677071

Email: service@eastdraw.com

地址:广州市天河区五山路141号尚德大厦A座20层2008室

立即咨询
在线咨询