产品经理跟程序员是上下级关系

产品经理跟程序员是上下级关系,第1张

因为成为产品经理,能学到非常多的知识,在不同的层面

产品经理软技能:

个人魅力:包括沟通能力,领导能力,愿景能力,感染能力,审美能力等等;

产品修养:产品修养包括混迹产品社区,运营社区,优秀产品群;

互联网修养:了解互联网现状,跟踪互联网热点,跟踪互联网前沿,混迹互联网社区。

项目管理

产品经理的一个重要角色是项目经理,产品经理需要对整个项目的结果负责,包括按时交付,合格交付,成本控制。

项目经理需要熟练项目的5大过程组和10大工作领域,对于互联网产品经理来说,主要内容包括:

项目沟通:沟通是互联网开发中产品经理最重要的工作,包括和上级,开发人员,运营人员等等;

总体进度计划:项目的总体进度,例如产品设计,UI设计,各个模块开发,测试进度,部署等等,产品经理必须把握整体的进度,针对节点进行审核;

开发详细计划:开发详细计划是总体进度计划的一部分,一般来说开发计划是技术经理维护,但是产品经理必须进行整体把控;

项目控制:项目干系人,风险,进度,质量等等控制。

协助推广

产品开发出来必须推广到市场,否则产品就是一个实验品。产品经理不需要完全负责运营推广,但是必须对运营人员提供必备的支持。

基本工作如下:

基础运营数据:获取产品的基础运营数据,例如下载量,用户量,支付金额,留存;

埋点:埋点的一种获取产品运营数据的重要方法,他可以分析页面点击,页面转化等等;

业务数据:业务数据例如订单情况,售后订单,销量等等;

竞品分析:和市面上相似产品对比分析;

Swot分析:了解本产品的优势、弱势、机遇、挑战。

迭代开发

第一个版本做出来后,产品进入迭代开发阶段,一般迭代周期是2个星期;迭代开发就是将从产品规划到运营过程进行浓缩,每个迭代周期开发少量的功能。

基本的工作如下:

收集需求:收集产品的需求,哪些需求进行迭代开发;

需求排序:针对需求进行排序,高优先级的尽快开发,优先级低的稍晚开发;

细节功能设计:第一个版本的功能进行细化,例如效果细化,交互细化等等;

迭代计划:维护整个迭代过程的项目计划。

根植行业

产品都有很强的行业属性,必须熟悉本行业才能设计本行业需要的产品,否则就是空想。

我们需要了解行业现状,熟悉行业痛点,熟悉行业热点,并且还得了解相关行业,此外需要熟悉相关的法规,道德,加入行业圈子,多逛行业论坛。

个人魅力

上述讲的是产品经理硬技能,下面介绍一下软技能,软技能更多的是个人的修养问题,但是这些会影响到产品经理的整个职业生涯。

个人魅力包括个人领导能力,沟通能力,愿景能力,洞察能力,审美能力,感染能力。拥有强大个人魅力的产品经理才能成为整个产品的领导者,才能激励整个项目成员,提高团队效率。

产品修养

产品经理需要提高产品修养能力。

产品修养包括:

与高人为伍:有时高人的一句指点胜过你苦思冥想一个月,产品经理需要向前辈,向领导,同级组织成员请教,请教他们你不熟悉的内容;

与实践者为伍:不要和空想者为伍,而是和实践者为伍,产品的使用对象均是实践者,实践者的想法将会提高你整个产品的境界;

产品社区:例如产品壹佰,pmcaff,多看一下帖子提高自身修养,此外多加入一些QQ群;

运营工具:例如应用雷达,酷传,APP annie,ASO 100,百度指数等,运营工具可以用来分析产品的运营数据。

互联网修养

一个互联网人,必须熟悉互联网,有一定的互联网修养,多看新闻,多参加一些沙龙,提高自身的互联网修养。

了解互联网现状:熟悉当前中国和世界上优秀的互联网公司,多了解互联网当前现状,例如阿里巴巴,腾讯,百度,小米,华为,360等;

跟踪互联网热点:当前互联网热点,例如项目热点,投资热点这些,可以查看36kr,虎嗅,这些社区提高了互联网热点现状;

跟踪互联网前沿:例如vr/ar,物联网,智能设备等等;

大数据平台:常见的例如易观数据,talkingdata,这些互联网大数据平台会提供部分免费的行业分析报告,了解互联网大数据对产品整体把控有一定的帮助。

如果需要学习,可以看下这几个软件:

1脑图工具:百度脑图

2文档共享:蓝湖、Axure等软件

3项目管理:jira

经常有人问我:“嗨,费杰你好!请问阿里巴巴的需求文档怎么写?“,但很少听到人谈:“嗨,哥们你好!请问产品经理怎么和程序员打交道?”你回去稍微琢磨了一下,心里就会得到下面三种情况:1) 很多产品经理之前就是程序员,所以非常了解程序员是什么样的一个状态;2) 很多产品经理还停留在关注自己产品规划、设计本身,缺乏对团队配合的思考;3) 很多产品经理,其实是有和程序员打交道的实践技巧、心得的,但没有重视和分享。事实上在很多产品研发体系下,产品经理和程序员因为思考方式、关注范围、职能职责的差异,导致了沟通上的困难。如何更好的与程序员建立起一座畅通的桥梁也是每位产品经理需要思考的问题。一般情况下,产品经理和程序员沟通困难大概的原因:�0�21、得到信息不对称;�0�2�0�2产品经理得到的信息一般集中在:商业需求、商业策略、战略方向、产品规划、运营数据、整体营收、目标任务等方面。产品经理往往在根据公司现阶段的情况,以及市场的竞争情况,做一些产品策略或者一些产品的方案的策划、发起、实施。

所以这个过程中,产品经理扮演的角色是翻译:“市场需求、商业需求”,成为:“产品需求”,所有的信息全部围绕需求本身。为什么要做需求?怎么做需求?先做什么需求、后做什么?基于怎么样一个思路去推送产品进行实施、从一个利益平衡获得空间增长指标后达到另外一个利益平衡。程序员不一样,很多时候程序员得到的信息是:有一个需求,可能是小需求、产品需求、或大到项目需求,然后得到一系列需求列表,然后产品经理会让程序员看:“需求”哪些通过code改改就可以实现,哪些是需要开发可以实现,哪些是技术或构架或因为成本的原因不能实现。

所以在这个过程中,程序员扮演的角色是翻译:“产品需求”,成为:“技术语言”的评估,所有的信息全部围绕开发需求本身。如何开发这些需求?是沟通数据库增加字段?调用接口?开发新的接口?需要开发组件?重新构架引擎?来实现满足或支撑这些需求?那这个时候问题来了,很多情况下我们只是把程序员当做一个写代码,通过编程语言来 *** 作计算机完成需求的工具了。�0�22、沟通语言不对称;�0�2�0�2说到两者沟通的语言,这肯定是困扰产品经理本身的。产品经理的语言是:“描述“、”形容“,我也见过很多产品经理,很多人的需求文档就是漫天飞舞的文字,一整段的描述+描述,不要说程序员看不清,可能过段时间连自己都看不清楚。除了书面语言,产品经理的沟通语言也是含糊的,没有太多的逻辑去组织,很多时候总是试图去述说一个需求,被程序员的一个计算机术语而打断。程序员的语言,更偏向于技术化。很多产品经理做过技术,有技术背景,但是还有很多产品经理不懂得技术。所以在这个时候,程序员在解说或回答一个需求的时候,会把自己习以为常的变量、函数、实现方式说出来。于是很多产品经理听到:“Sdk、webshell、select、api、组件、插件、控件“等等的时候会云里雾里,那这个时候问题来了,很多情况下我们总站在自己的立场上、自己的世界里认为别人也懂自己在说什么?实际呢?大家都是听得一半一半,沟通没有彻底到位。�0�23、思考角度不对称�0�2�0�2产品经理思考的角度在于产品本身,对技术的细节、技术的性能没有太多的发言权。很多产品经理要是的实现的业务逻辑,不管程序员是采用:c++ 、java、php、Python、找开源代码改的,还是自己写的都没有关系。程序员只要在约定的时间里,把约定的业务逻辑开发出来就可以,产品经理不去会考虑目前服务器的配置、程序员手上任务的配置、技术能力的情况,要的是结果。而且很情愿的认为团队中的工程师都是世界上最好的工程师,想做什么都可以做,对因为技术原因而不能支持实现需求不能接受。程序员思考的角度有点区别,我也看到不到程序员本身对产品追求完美对需求的背景、意义去研究了解;但很多程序员还是停留在自己接单子任务一样来一个做一个的境界,做好了自己玩自己的。程序员考虑程序实现的方式同样的一个请求是get还是post,程序员考虑代码的性能,从而采取不一样的方案去实现需求,考虑请求并发量压力和安全性。但是很多情况下,程序员对技术的理解会导致有一些业务需求满足不了,不是因为不能实现,是因为实现了觉得是废代码,或者构架不完美了。那这个时候问题来了,很多情况下到底倾斜谁的立场上思考问题?我之前也会碰到很多情况程序员就程序的角度说业务需求不合理,产品经理说程序员消极罢工、霸得蛮。�0�24、考核标准不对称;�0�2�0�2谁也不尿谁,哼!你能把我怎么样。产品经理和程序员有为完全沟通或误会的时候,极端情况下,有一方会罢工。这个时候主要是2个角色的各个考核标准不一样,所以在很多情况下显得非常的无奈。产品经理很可能考核的是方案和上线的时间、产品上线后的数据;而工程师考核的是程序的性能、很多时候产品经理催的急要的急,但程序员每天的时间有限,还是得慢慢构架慢慢开发,程序员开发时间少了,未知的执行BUG没考虑过是要负责的。这个时候问题又来了,产品经理天天干着急!咋办?以上是我结合几年来的工作经验总结出来的,当然这4大因素把很多共性的因素概况进来了。当然过程中还是会因为很多产品经理或程序员本身(个性)的沟通技巧、态度、情商等因素导致的沟通不倡,影响了彼此之间的默契。其实仔细的分析一下,产品经理和程序员打交道的过程中不管是共性的因素还是个性的因素,也不是想象中那么困难。通过一些努力之后,我们总是会找到一些快速和程序员建立沟通桥梁的办法。我个观点如下:�0�21、 要看到项目层面,不要只看需求本身。�0�2�0�2上面说到的几点不管是:“信息不对称“、”沟通的语言不对称“、”思考角度不对称“还是”考核的标准不对称“是我们常见的几个客观隐私。把几个因素抽取出来剖析,发现还是由于我们站问题的视角的高度不一致造成的。产品经理只是看到自己得到了商业的需求,策划了产品的需求,接下来会把很多事情抛给程序员做了,那还是站在需求方的角色中。那如果真正的是站在意识层面的项目经理的角度,这个时候看待问题的视眼会广很多。这个时候你就想着为了做这个项目这个需求,程序员是不是明白了为什么要做?是不是对这哪些需求的优先级有了重要的认识?作为产品经理我用怎么样一种表达方式程序员更明白?是不是需要把时间点等划定?目前程序员的资源和服务器情况允许他们能做的空间是多大?怎么样才能拉动他们的积极性更好的完成这个项目?适当的时候,需要帮助程序员做哪些申请或让步?对产品经理来说,同样张罗一件事情,同样会了得到一个结果,但是中间的过程很可能是完全不一样的。所以因为思考角度仅仅从做完一个需求死磨硬泡上升到,站在项目的角度去考虑各个关节的风险点、时间点,得到的效果是完全不一样的。�0�22、从理解程序员开始,换位思考会更好。�0�2�0�2一直在问一个问题:“程序员是什么一群人?“就和问自己:”产品经理是什么一群人?“一样,有点好笑、有点幼稚。从小工到专家,从CSDN到走出软件作坊,发现很多很多非常优秀的程序员的心声。程序员是什么样一群人?像切西瓜一样一刀一刀切:写php的写Java的写windows C的写liunx C的写C++的编程水平一般的编程水平还行的编程水平牛逼的编程水平大师级的构架牛的数据库牛的勤奋的懒于思考的不会JavaScript的积极的喜欢钻研的……好像都不太合适,因为你找不到解决和工程师沟通的好的办法。而且这些很多是外在的条件,随随都在改变。看到很多朋友一年之间经历几个大项目水平突然猛进,态度、一些特点也变得完全不一样。这个时候你需要的是了解和掌握程序员,作为职场的人,和我们一样的人共同需要的一些特点。如下4点:1) 是不是特别想被肯定、获得尊重;理解、肯定、尊重。这3个词或许非常的空但确确实实是一个非常好的方子。静下心来走近程序员,听听他们的心声、他们的抱怨,或许产品经理和程序员的距离将不再是那么遥远。虽然很多时候我们讲德行说尊重,但真正领悟到心里、落实到行动、表现在态度上的完全不一样的。真正,你是不是一言、一行本真理解、肯定、尊重程序员的,程序员是有感知的。2) 是不是想给产品提供自己的建议,而不是仅仅做一个编程的机器;很多程序员对产品非常热爱、对产品有独特的想法,但多数又局限于技术情节对产品的建议常常被忽视。相信很多程序员都希望参与产品,通过自己的专长改变产品,进而打磨出一款完美的产品。所以产品经理也可以适当的给程序员一点发挥的空间,特别是在技术创新、产品需要技术驱动的方面,在商业可控的层面让程序员发挥排头兵的作用。这样程序员会开足马力投入到开发实施的过程中。3) 是不是不仅仅和人任务指派,需求更多的和谐的人与人之间的沟通建立。产品经理和程序员两者之间没有一个良好的沟通,只是基于做与不做,做好做不好,什么时候做好,这样的功利性沟通肯定是不可靠的。往往两者因默契不够,或一方因沟通技巧不足、对待工作态度不够积极,造成矛盾。建立一个人与人之间的良好沟通,帮助产品经理或程序员更好的认知对方、了解对方,这样无论是在平时的沟通过程,还是在项目的合作过程中更好的促进了解、达成共致都会有一个前提保障。4)是不是需要别人的帮助,让他在非技术领域获得真知。看到很多产品经理朋友和程序员打成一片,和程序员一天聊天、抽烟、一起下班打游戏、打球,甚至有些时候产品头脑风暴的时候要去几个有产品情节的工程师参与前期的讨论,效果都不错。可能这些现象从另外一个层面来解决我们上面的一些疑惑。3、产品经理要改善心智,不断自我学习。�0�2�0�2最近突然觉得说得想的,有点像哲学。群里的一个朋友说了, 其实哲学就是我们生活一些事情表现出来的道路。产品经理跟程序员打交道也好,对待生活也好,我个人认为是产品经理对哲学的认识、理解、应用。产品经理越往下走,抛开产品技能本身不谈,沉淀商业以及人脉资源,都是需要以一种良好、可靠的思维方式去支撑的,也就是所说的心智模型。很多时候产品经理改善心智可以不断的增强一些事物的判断。如:遇到程序员的拒绝的、不行的理由,这个时候你通过分析起码要判断得出来,这个是程序员隔个人的态度问题,还是流程问题,有一点微妙的。所以产品经理需要不断的学习,学习提高软技能。说到学习,回应这篇《产品经理怎么样和程序员打交道》中,程序员常用的一些技术原理、技术术语得去学习一下、研究一下。Right OK, End !

EVT:工程验证测试。DVT:设计验证测试。

PVT:小批量过程验证测试。TP:在一定时期内的总产量。

PP:小批量生产。MP:量产阶段。

一般流程是:EVT(工程验证测试)→DVT(设计验证测试)→MVT(生产验证测试)→PP(中试生产)→MP(导入量产)。

扩展资料:

新产品开发是一项极其复杂的工作,从根据用户需要提出设想到正式生产产品投放市场为止,其中经历许多阶段。产品开发的程序是指从提出产品构思到正式投入生产的整个过程。

(1)调查研究阶段

这个阶段主要是提出新产品构思以及新产品的原理、结构、功能、材料和工艺方面的开发设想和总体方案。

(2)新产品开发的构思创意阶段

在这一阶段,要根据社会调查掌握的市场需求情况以及企业本身条件,充分考虑用户的使用要求和竞争对手的动向,有针对性地提出开发新产品的设想和构思。主要来自用户、企业职工以及专业科研人员。

新产品创意包括三个方面的内容:产品构思、构思筛选和产品概念的形成。

(3)新产品设计阶段

产品设计是指从确定产品设计任务书起到确定产品结构为止的一系列技术工作的准备和管理,是产品开发的重要环节,是产品生产过程的开始,必须严格遵循“三段设计”程序——初步设计阶段、技术设计阶段以及工作图设计阶段。

(4)新产品试制与评价鉴定阶段

新产品试制阶段又分为样品试制和小批试制阶段。

(5)生产技术准备阶段

在这个阶段,应完成全部工作图的设计,确定各种零部件的技术要求。

(6)正式生产和销售阶段

新产品的市场开发既是新产品开发过程的终点,又是下一代新产品再开发的起点。通过市场开发,可确切地了解开发的产品是否适应需要以及适应的程度;分析与产品开发有关的市场情报可为开发产品决策、为改进下一批(代)产品、为提高开发研制水平提供依据,同时还可取得有关潜在市场大小的数据资料

以上就是关于产品经理跟程序员是上下级关系全部的内容,包括:产品经理跟程序员是上下级关系、产品经理怎么和程序员打交道【3】、产品开发的流程有几个步骤等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zz/10105484.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-05
下一篇 2023-05-05

发表评论

登录后才能评论

评论列表(0条)

保存