产品经理对技术理解应该达到一个什么程度?
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.了解设计模式
其实才是整个业务架构里比较重要的东西,不过我现在理解的也不深刻,只能建议了。
一般你要先了解面向对象编程是怎么回事。
然后了解一些,单例模式,工厂方法模式,抽象工厂模式,建造者模式,原型模式,这类的设计模式。了解以后对你认识程序员的工作有所理解,最少忽悠不了你,你知道他们设计一个业务逻辑的流程是怎么样子的。这样就能做到心中有数了。
转自互联网的一些事
作为一个实习过两年开发,毕业后转产品的一年产品萌新来说…这些东西还是都懂的
可能有些产品会觉得知道这些没啥用,但在工作中,产品部门经常因为不懂技术和开发没法一个频道沟通
尤其是像后台产品,不懂技术,以后的学习成本会非常大
理想很丰满,现实很骨感,能做到这些的产品是凤毛麟角了
这了解的程度有点过头,基本上是全才了
产品知道到这种程度,还只拿产品的薪水,那要么就是这人无私,要么就是刚洗了头。
是该了解些技术,但是有点夸张了,不需要了解的这么深。。。
这个说法片面,如果产品经理来决定这个,我想知道团队中的系统架构师在做什么?
架构师是这方面的决策者,而作为产品来说,你需要知道这些而已,知道他们的特性,这方便于未来对你工作时有一个更好的判断,尤其是在小型公司,更是如此。
这篇文章其实没有那么深的概念,去查一查很多就能明白了,比如主流的开发语言是什么,比如java的主流框架是什么