产品经理对技术理解应该达到一个什么程度?

7 评论 17351 浏览 33 收藏 5 分钟

1.技术架构/实现方式

比如设计一个网站类的产品是使用什么编程语言开发的php,jsp或者Python。确定了编程语言以后你要知道整个产品项目中使用了什么开发框架,是团队自己研发的框架,还是使用市面上比较流行的框架。其次是数据库的选择,根据你们的业务需求是使用mysql这种关系型数据库还是mongodb这类非关系型数据库,最后就是服务器,服务器一般关心的问题就是稳定性,安全性,还有负载了。

根据不同需求选择服务器,

使用什么样的服务器?自己管理的,还是云。如果是云的话还要了解一些云服务和产品的内容,比如RDS,负载均衡,内容分发等等。

使用什么操作系统是window还是linux?Linux的话一般还分Ubuntu和redhat两个派系。

服务器的运行环境是怎样的?使用怎样的代理nginx,Apache还是tomcat或者为了实现高负载混合使用它们还是要自己用node来写一个更好更适用的。还要注意是否有其他插件需要支持。

如果是桌面级应用或者是手机APP这样的产品需求的东西还不一样,你还要考虑跨平台性以及其他细节问题。上述例子主要是网站产品主要依靠浏览器,平台兼容的考虑少一些。

2.技术特性

技术的生命周期:作为产品经理的你已经知道了产品是有生命周期的,那么其实我们生产产品使用的技术也是有生命周期的。假如项目周期比较长,比如10年吧,技术生命周期一般就2~3年,服务器操作系统生命周期会更长一些,,如果这部分能考虑到能节省很多重构成本。可是关键问题是这个问题本身就不太现实,我们很难预测2~3年以后我们的产品的样子。

技术的优缺点:作为PM你不用了解具体的实现方式,关键在于你要知道不同技术架构有什么优缺点,适合做什么事情。比如mysql和mongodb的区别,php和jsp的区别,它们的开发效率和健壮性怎么样,是不是符合我现阶段产品开发的需求。项目不大其实没区别,项目大的话就很明显了。

3.技术成本

不管怎么说作为PM掌控产品全局你要知道整个项目的技术开发成本是怎样的。其实都是项目管理里面的内容这里就不多说了,值得提的是程序员是个喜欢创造的工种,如果你只是设计好了让他们照着设计做他们会玩的很没乐趣的。要让他们也参与其中你会发现你的项目会比你想象中的进展要好。亲测,上个项目,我的开发团队就为客户提供了超出合同范围的各种各样的功能……重要的是这部分开发人员是愿意付出不计较成本的。(丫的,你们搞那么多功能就不怕有BUG客户再让咱们改吗????)

4.了解设计模式

其实才是整个业务架构里比较重要的东西,不过我现在理解的也不深刻,只能建议了。

一般你要先了解面向对象编程是怎么回事。

然后了解一些,单例模式,工厂方法模式,抽象工厂模式,建造者模式,原型模式,这类的设计模式。了解以后对你认识程序员的工作有所理解,最少忽悠不了你,你知道他们设计一个业务逻辑的流程是怎么样子的。这样就能做到心中有数了。

转自互联网的一些事

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 作为一个实习过两年开发,毕业后转产品的一年产品萌新来说…这些东西还是都懂的
    可能有些产品会觉得知道这些没啥用,但在工作中,产品部门经常因为不懂技术和开发没法一个频道沟通
    尤其是像后台产品,不懂技术,以后的学习成本会非常大

    来自江苏 回复
  2. 理想很丰满,现实很骨感,能做到这些的产品是凤毛麟角了

    来自浙江 回复
  3. 这了解的程度有点过头,基本上是全才了

    来自广东 回复
  4. 产品知道到这种程度,还只拿产品的薪水,那要么就是这人无私,要么就是刚洗了头。

    来自北京 回复
  5. 是该了解些技术,但是有点夸张了,不需要了解的这么深。。。

    来自上海 回复
  6. 这个说法片面,如果产品经理来决定这个,我想知道团队中的系统架构师在做什么?

    来自江苏 回复
    1. 架构师是这方面的决策者,而作为产品来说,你需要知道这些而已,知道他们的特性,这方便于未来对你工作时有一个更好的判断,尤其是在小型公司,更是如此。
      这篇文章其实没有那么深的概念,去查一查很多就能明白了,比如主流的开发语言是什么,比如java的主流框架是什么

      来自江苏 回复