新产品上线年终工作总结

时间:2023-12-08 07:33:39 心得体会 我要投稿
  • 相关推荐

新产品上线年终工作总结

  总结是在某一时期、某一项目或某些工作告一段落或者全部完成后进行回顾检查、分析评价,从而得出教训和一些规律性认识的一种书面材料,写总结有利于我们学习和工作能力的提高,快快来写一份总结吧。总结怎么写才能发挥它的作用呢?下面是小编帮大家整理的新产品上线年终工作总结,希望对大家有所帮助。

新产品上线年终工作总结

新产品上线年终工作总结1

  我觉得自己很幸运,能够有机会参与到一个全新产品的从无到有的一个过程,如果说可以把这看做是一个项目的话,那么对此有一点心得体会。

  在我所在的公司,一个新产品从无到有分为几个阶段:

  第一、产品运营提交策划

  第二、技术部门开发

  第三、全面测试、产品上线

  每个阶段在实施的过程中都会遇到各种各样的问题,而不同阶段所遇到的问题点又不尽相同。但有一点是相同的,那就是每个阶段在实施的过程中都会事先定好一个时间节点,以此来保证整个项目的如期进行。

  第一阶段:产品运营提交策划

  作为产品经理或产品策划来说,都希望出一个尽善尽美的产品,而老板不会给你做出一个尽善尽美产品的时间,这个时候就会有一个提交策划的时间点出来,也就是第一阶段的时间节点。那么作为产品经理为了能够如期提交策划,需要注意以下几点:

  1、控制好需求

  需求其实有两个极端,一个是尽善尽美,尽可能的让功能更友好,用户体验更佳;一个是尽早交付,一切改善性的需求都可以牺牲。只满足前者,提交策划的工期可能会不断的拖延,因为很多功能的工作量其实是在细节的优化,而不是主要流程的完成。只满足后者,很可能会出现一个让用户很不满意的产品。那么产品经理就要做到平衡好这两点。

  2、对需求说不

  你对一个需求说不,只要这个需求不是一个会造成其他功能依赖的核心需求,就算这个需求后面发现必须实现,你可以补上,总体工作量并没有增加。但是如果你花资源去完成了这个需求,后面却发现这个需求是不重要的或者可以简化的,那你已经浪费了一些工作量。两者的代价相比,明显前者的代价比较小。例如小说频道,之前花费了大量的资源去做小说,功能也比较完善,但是到了后期发现小说的背景与整个产品的背景选择发生冲突,最后在开发过程中围绕此问题讨论许久之后,决定放弃小说背景。

  3、深入了解官方渠道的软件审核机制

  由于在产品设计前期没有考虑到官方渠道上线的审核机制,导致充值页面反复驳回,产品技术浪费很多资源去做的充值到后期需要重新设计,并且对用户体验造成了很大不便。所以在产品设计之初需深入了解官方渠道的软件审核机制。

  4、整理好需求的优先级

  a.确定不变的需求应该先完成,如果策划去完成了一些功能,结果发现后面的需求要改,那前期的一些工作量已经浪费了。

  b.被其他需求依赖的需求应该先完成,只有这样,才能不挡住依赖它的需求的进展。比如登录功能,很多登录后的页面都需要当前登录的用户信息。

  c.主流程,或者核心需求应该先完成,改善性的需求应该后完成。比如信息列表页面,很多功能需要用户在信息列表里面进行选择。因此信息列表是核心需求。而在信息列表页里面一个列显示格式的美化,这属于改善性需求。

  5、不要让细节影响你的目标

  做产品的人很容易沉浸在功能的细节当中,为一些友好美观的显示,炫丽的功能或者很酷的设计浪费大把的时间,沉浸在细节当中很容易让人忘记工期,忘记产品的最终目标。这里不是说不让你去完善细节,而是这些细节方面的事情等产品核心功能完成之后,有大把的时间可以专注在细节方面。先把核心功能完成是目标。

  6、不做一半的功能

  如果我们做了2个功能,但是我们每个功能都做了一半没全部完成,那目前为止我们总计完成了多少个功能?1个?不是的,完成了0个。一个功能除非真正完成并且通过,不然你永远不能确定这个功能是不是还有一些遗漏的地方。所以我们做功能的时候,要确保我们在做的功能已经是真正完成了,我们再去接着做下一个功能。

  7、风险管控

  产品经理应该尽量在早期把所有的风险都列出来,一个一个解决。一个流畅的项目,从前期到后期风险点应该是倒三角形的,就是前期风险很多,后期风险越来越少。而项目管理不畅的,则是一个正三角形,上面风险少,到后期风险就多了。

  假设有一个点,你不确定他是不是有风险的,那即使我们在早期把它当做一个风险点重视起来,带来的代价也远远小于在后期等它爆发出来的时候再处理。

  例如,我们有一个充值功能,可以用支付宝或网银或点卡进行充值。这需要调用第三方接口,而跟外部协调都有一个不可控性存在,所以应该把这个风险点在事先重视起来。避免像网银充值那样,前期各个环节都增加了此功能,但在后期网银充值不可行,导致前期很多资源的浪费。

  第二阶段:技术部门开发

  第一阶段将策划如期提交到技术部门之后,接下来就是最重要的产品开发环节。而在此环节中在公司内部提到最多的就是开发的完成时间。

  计划完成时间与合理完成时间:

  这个开发的完成时间一般都是计划完成时间,而软件开发不是一个可以直接添加资源就可以加快速度的过程,其中包含很多其他客观因素,例如跟策划人员之间的沟通,产品流程不通,功能设计不合理,前后功能不一致等。由此导致在这个计划完成时间之外还隐藏着一个实际合理的完成日期,而在进展整个产品开发的过程当中,其实也是发现这个隐藏的合理完成日期的一个过程。

  从管理的`角度来讲,当然是尽可能的赶上计划的完成时间。但是因为多方面因素的影响,项目管理是一个欲速则不达的过程。如果这个计划完成日期早于这个实际合理完成日期,那你越往这个不合理的日期赶,工期内积累的问题就越多导致后期收尾的时候爆发,结果反而连合理完成日期都赶不上。

  影响工期拖延的几大因素:

  1、产品需求的不断更改

  影响工期最严重的因素就在于产品需求的不断更改。所以产品经理在技术开发期间,应严格避免策划需求的不断更改,严格按照产品的迭代周期进行开发,避免在技术开发的过程中,不断的优化产品细节。任何一款产品都不会尽善尽美的面市,都是一个需要不断优化的过程,所以所有产品的优化方案可等第一版本的产品面市之后,紧接着进行第二版本的优化。以此节约工期。

  2、未能及早的发现问题

  而在产品开发阶段虽然出力的主要是技术人员,但是整个产品是否能够如期诞生,最主要的责任在于产品经理,所以这其实是产品和技术协同发展的一个过程,也就是产品部门依赖外部的一个过程。而大家都知道,内部能处理的问题一般都是小问题,而需要外部人员处理的问题,才是大问题。因为外部人员不受你调配,他应承你的时间不一定是你满意的时间。即使是你满意的时间,也不一定真的就能确保在那个时间完成,就算真的完成了,也不一定就达到你想要的效果。

新产品上线年终工作总结2

  我觉得自己很幸运,能够有机会参与到一个全新产品的从无到有的一个过程,如果说可以把这看做是一个项目的话,那么对此有一点心得体会。

  在我所在的公司,一个新产品从无到有分为几个阶段:

  第一、产品运营提交策划

  第二、技术部门开发

  第三、全面测试、产品上线

  每个阶段在实施的过程中都会遇到各种各样的问题,而不同阶段所遇到的问题点又不尽相同。但有一点是相同的,那就是每个阶段在实施的过程中都会事先定好一个时间节点,以此来保证整个项目的如期进行。

  第一阶段:产品运营提交策划

  作为产品经理或产品策划来说,都希望出一个尽善尽美的产品,而老板不会给你做出一个尽善尽美产品的时间,这个时候就会有一个提交策划的时间点出来,也就是第一阶段的时间节点。那么作为产品经理为了能够如期提交策划,需要注意以下几点:

  1、控制好需求

  需求其实有两个极端,一个是尽善尽美,尽可能的让功能更友好,用户体验更佳;一个是尽早交付,一切改善性的需求都可以牺牲。只满足前者,提交策划的工期可能会不断的拖延,因为很多功能的工作量其实是在细节的优化,而不是主要流程的完成。只满足后者,很可能会出现一个让用户很不满意的产品。那么产品经理就要做到平衡好这两点。

  2、对需求说不

  你对一个需求说不,只要这个需求不是一个会造成其他功能依赖的核心需求,就算这个需求后面发现必须实现,你可以补上,总体工作量并没有增加。但是如果你花资源去完成了这个需求,后面却发现这个需求是不重要的或者可以简化的,那你已经浪费了一些工作量。两者的代价相比,明显前者的代价比较小。例如小说频道,之前花费了大量的资源去做小说,功能也比较完善,但是到了后期发现小说的背景与整个产品的背景选择发生冲突,最后在开发过程中围绕此问题讨论许久之后,决定放弃小说背景。

  3、深入了解官方渠道的软件审核机制

  由于在产品设计前期没有考虑到官方渠道上线的审核机制,导致充值页面反复驳回,产品技术浪费很多资源去做的充值到后期需要重新设计,并且对用户体验造成了很大不便。所以在产品设计之初需深入了解官方渠道的软件审核机制。

  4、整理好需求的优先级

  a.确定不变的需求应该先完成,如果策划去完成了一些功能,结果发现后面的需求要改,那前期的一些工作量已经浪费了。

  b.被其他需求依赖的需求应该先完成,只有这样,才能不挡住依赖它的需求的进展。比如登录功能,很多登录后的页面都需要当前登录的用户信息。

  c.主流程,或者核心需求应该先完成,改善性的需求应该后完成。比如信息列表页面,很多功能需要用户在信息列表里面进行选择。因此信息列表是核心需求。而在信息列表页里面一个列显示格式的美化,这属于改善性需求。

  5、不要让细节影响你的目标

  做产品的人很容易沉浸在功能的细节当中,为一些友好美观的显示,炫丽的功能或者很酷的设计浪费大把的时间,沉浸在细节当中很容易让人忘记工期,忘记产品的最终目标。这里不是说不让你去完善细节,而是这些细节方面的事情等产品核心功能完成之后,有大把的时间可以专注在细节方面。先把核心功能完成是目标。

  6、不做一半的功能

  如果我们做了2个功能,但是我们每个功能都做了一半没全部完成,那目前为止我们总计完成了多少个功能?1个?不是的,完成了0个。一个功能除非真正完成并且通过,不然你永远不能确定这个功能是不是还有一些遗漏的地方。所以我们做功能的时候,要确保我们在做的功能已经是真正完成了,我们再去接着做下一个功能。

  7、风险管控

  产品经理应该尽量在早期把所有的风险都列出来,一个一个解决。一个流畅的项目,从前期到后期风险点应该是倒三角形的,就是前期风险很多,后期风险越来越少。而项目管理不畅的,则是一个正三角形,上面风险少,到后期风险就多了。

  假设有一个点,你不确定他是不是有风险的,那即使我们在早期把它当做一个风险点重视起来,带来的代价也远远小于在后期等它爆发出来的时候再处理。

  例如,我们有一个充值功能,可以用支付宝或网银或点卡进行充值。这需要调用第三方接口,而跟外部协调都有一个不可控性存在,所以应该把这个风险点在事先重视起来。避免像网银充值那样,前期各个环节都增加了此功能,但在后期网银充值不可行,导致前期很多资源的浪费。

  第二阶段:技术部门开发

  第一阶段将策划如期提交到技术部门之后,接下来就是最重要的产品开发环节。而在此环节中在公司内部提到最多的就是开发的完成时间。

  计划完成时间与合理完成时间:

  这个开发的完成时间一般都是计划完成时间,而软件开发不是一个可以直接添加资源就可以加快速度的过程,其中包含很多其他客观因素,例如跟策划人员之间的.沟通,产品流程不通,功能设计不合理,前后功能不一致等。由此导致在这个计划完成时间之外还隐藏着一个实际合理的完成日期,而在进展整个产品开发的过程当中,其实也是发现这个隐藏的合理完成日期的一个过程。

  从管理的角度来讲,当然是尽可能的赶上计划的完成时间。但是因为多方面因素的影响,项目管理是一个欲速则不达的过程。如果这个计划完成日期早于这个实际合理完成日期,那你越往这个不合理的日期赶,工期内积累的问题就越多导致后期收尾的时候爆发,结果反而连合理完成日期都赶不上。

  影响工期拖延的几大因素:

  1、产品需求的不断更改

  影响工期最严重的因素就在于产品需求的不断更改。所以产品经理在技术开发期间,应严格避免策划需求的不断更改,严格按照产品的迭代周期进行开发,避免在技术开发的过程中,不断的优化产品细节。任何一款产品都不会尽善尽美的面市,都是一个需要不断优化的过程,所以所有产品的优化方案可等第一版本的产品面市之后,紧接着进行第二版本的优化。以此节约工期。

  2、未能及早的发现问题

  而在产品开发阶段虽然出力的主要是技术人员,但是整个产品是否能够如期诞生,最主要的责任在于产品经理,所以这其实是产品和技术协同发展的一个过程,也就是产品部门依赖外部的一个过程。而大家都知道,内部能处理的问题一般都是小问题,而需要外部人员处理的问题,才是大问题。因为外部人员不受你调配,他应承你的时间不一定是你满意的时间。即使是你满意的时间,也不一定真的就能确保在那个时间完成,就算真的完成了,也不一定就达到你想要的效果。

新产品上线年终工作总结3

  我觉得自己很幸运,能够有机会参与到一个全新产品的从无到有的一个过程,如果说可以把这看做是一个项目的话,那么对此有一点心得体会。

  在我所在的公司,一个新产品从无到有分为几个阶段:

  每个阶段在实施的过程中都会遇到各种各样的问题,而不同阶段所遇到的问题点又不尽相同。但有一点是相同的,那就是每个阶段在实施的过程中都会事先定好一个时间节点,以此来保证整个项目的如期进行。

  第一阶段:

  产品运营提交策划作为产品经理或产品策划来说,都希望出一个尽善尽美的产品,而老板不会给你做出一个尽善尽美产品的时间,这个时候就会有一个提交策划的时间点出来,也就是第一阶段的时间节点。那么作为产品经理为了能够如期提交策划,需要注意以下几点:

  1、控制好需求需求其实有两个极端,一个是尽善尽美,尽可能的让功能更友好,用户体验更佳;一个是尽早交付,一切改善性的需求都可以牺牲。只满足前者,提交策划的工期可能会不断的拖延,因为很多功能的工作量其实是在细节的优化,而不是主要流程的完成。只满足后者,很可能会出现一个让用户很不满意的产品。那么产品经理就要做到平衡好这两点。

  2、对需求说不你对一个需求说不,只要这个需求不是一个会造成其他功能依赖的核心需求,就算这个需求后面发现必须实现,你可以补上,总体工作量并没有增加。但是如果你花资源去完成了这个需求,后面却发现这个需求是不重要的或者可以简化的,那你已经浪费了一些工作量。两者的代价相比,明显前者的代价比较小。例如小说频道,之前花费了大量的资源去做小说,功能也比较完善,但是到了后期发现小说的背景与整个产品的背景选择发生冲突,最后在开发过程中围绕此问题讨论许久之后,决定放弃小说背景。

  3、深入了解官方渠道的软件审核机制由于在产品设计前期没有考虑到官方渠道上线的审核机制,导致充值页面反复驳回,产品技术浪费很多资源去做的充值到后期需要重新设计,并且对用户体验造成了很大不便。所以在产品设计之初需深入了解官方渠道的软件审核机制。

  4、整理好需求的优先级a.确定不变的需求应该先完成,如果策划去完成了一些功能,结果发现后面的需求要改,那前期的一些工作量已经浪费了。

  b.被其他需求依赖的需求应该先完成,只有这样,才能不挡住依赖它的需求的进展。比如登录功能,很多登录后的页面都需要当前登录的用户信息。

  c.主流程,或者核心需求应该先完成,改善性的需求应该后完成。比如信息列表页面,很多功能需要用户在信息列表里面进行选择。因此信息列表是核心需求。而在信息列表页里面一个列显示格式的美化,这属于改善性需求。

  5、不要让细节影响你的目标做产品的人很容易沉浸在功能的细节当中,为一些友好美观的显示,炫丽的功能或者很酷的设计浪费大把的时间,沉浸在细节当中很容易让人忘记工期,忘记产品的最终目标。这里不是说不让你去完善细节,而是这些细节方面的事情等产品核心功能完成之后,有大把的时间可以专注在细节方面。先把核心功能完成是目标。

  6、不做一半的功能如果我们做了2个功能,但是我们每个功能都做了一半没全部完成,那目前为止我们总计完成了多少个功能?1个?不是的,完成了0个。一个功能除非真正完成并且通过,不然你永远不能确定这个功能是不是还有一些遗漏的地方。所以我们做功能的时候,要确保我们在做的功能已经是真正完成了,我们再去接着做下一个功能。

  7、风险管控产品经理应该尽量在早期把所有的风险都列出来,一个一个解决。一个流畅的.项目,从前期到后期风险点应该是倒三角形的,就是前期风险很多,后期风险越来越少。而项目管理不畅的,则是一个正三角形,上面风险少,到后期风险就多了。

  假设有一个点,你不确定他是不是有风险的,那即使我们在早期把它当做一个风险点重视起来,带来的代价也远远小于在后期等它爆发出来的时候再处理。

  例如,我们有一个充值功能,可以用支付宝或网银或点卡进行充值。这需要调用第三方接口,而跟外部协调都有一个不可控性存在,所以应该把这个风险点在事先重视起来。避免像网银充值那样,前期各个环节都增加了此功能,但在后期网银充值不可行,导致前期很多资源的浪费。

  第二阶段:技术部门开发

  第一阶段将策划如期提交到技术部门之后,接下来就是最重要的产品开发环节。而在此环节中在公司内部提到最多的就是开发的完成时间。

  计划完成时间与合理完成时间:这个开发的完成时间一般都是计划完成时间,而软件开发不是一个可以直接添加资源就可以加快速度的过程,其中包含很多其他客观因素,例如跟策划人员之间的沟通,产品流程不通,功能设计不合理,前后功能不一致等。由此导致在这个计划完成时间之外还隐藏着一个实际合理的完成日期,而在进展整个产品开发的过程当中,其实也是发现这个隐藏的合理完成日期的一个过程。

  从管理的角度来讲,当然是尽可能的赶上计划的完成时间。但是因为多方面因素的影响,项目管理是一个欲速则不达的过程。如果这个计划完成日期早于这个实际合理完成日期,那你越往这个不合理的日期赶,工期内积累的问题就越多导致后期收尾的时候爆发,结果反而连合理完成日期都赶不上。

  影响工期拖延的几大因素:

  1、产品需求的不断更改

  影响工期最严重的因素就在于产品需求的不断更改。所以产品经理在技术开发期间,应严格避免策划需求的不断更改,严格按照产品的迭代周期进行开发,避免在技术开发的过程中,不断的优化产品细节。任何一款产品都不会尽善尽美的面市,都是一个需要不断优化的过程,所以所有产品的优化方案可等第一版本的产品面市之后,紧接着进行第二版本的优化。以此节约工期。

  2、未能及早的发现问题

  而在产品开发阶段虽然出力的主要是技术人员,但是整个产品是否能够如期诞生,最主要的责任在于产品经理,所以这其实是产品和技术协同发展的一个过程,也就是产品部门依赖外部的一个过程。而大家都知道,内部能处理的问题一般都是小问题,而需要外部人员处理的问题,才是大问题。因为外部人员不受你调配,他应承你的时间不一定是你满意的时间。即使是你满意的时间,也不一定真的就能确保在那个时间完成,就算真的完成了,也不一定就达到你想要的效果。

【新产品上线年终工作总结】相关文章:

新产品策划方案11-28

新产品推广策划书07-01

新产品营销策划书06-27

新产品试用协议书01-20

新产品营销策划书2篇【实用】11-13

年终的工作总结08-24

年终工作总结10-20

年终工作总结05-09

年终工作总结06-12