当前位置 : 主页 > 编程语言 > 其它开发 >

研发的那些事4

来源:互联网 收集:自由互联 发布时间:2022-05-25
记得刚工作的那会儿,提到PM就是指Program Manager 或 Project Manager,是带领一群程序员去开发软件的家伙。而另一个PM产品经理(Product Manger)则多少不为人知。但是最近几年,随着几个互联网

记得刚工作的那会儿,提到PM就是指Program Manager 或 Project Manager,是带领一群程序员去开发软件的家伙。而另一个PM产品经理(Product Manger)则多少不为人知。但是最近几年,随着几个互联网大佬的爆发,产品经理开始风生水起,PM的第一解释逐渐被其取代了。现在,整个IT行业,但凡做产品的,皆有产品经理的身影。

产品经理需要确保做正确的事情,开发的东东有高ROI,满足市场、客户的需求。项目经理则要保证正确的做事,能按期做出符合要求的东东。在绝大多数企业,这个过程就像是一个2人三方的游戏。

首先,作为神一样存在的BOSS宣布:一系列财务、市场指标和一些与长期战略有关的目标。还常常会提出要出XX产品(当然,BOSS的产品只是个商业概念),XXX时间必须发布,画下一条红线,越线则死,成功则生(赏)。下图,“神”画下了红线:

image

游戏开始,产品经理先登场,将BOSS的愿望图纸化,绘出血肉筋骨。一般需要从商业,市场和产品三个层次考虑,主要有:

  1. 商业,需要遵从公司的总体商业目标,考虑具体的投资回报和产品的商业模式,并绘制一个产品的高层愿景。
  2. 市场,需要根据公司总体业务,分析目标行业和客户,理解他们的业务,工作流程,发现问题(有什么新问题需要解决,以处理的问题解决的是否满意),确定机会。
  3. 产品,确定产品针对的细分市场,目标客户。针对的市场机会要做的具体功能,及路线图、版本计划、运营规划等。

以上内容主要变成三分文档BRD、MRD和PRD(也有公司会根据需要合),作为立项时的需要双方遵守的契约。下图:立项及契约。

image

接着,产品经理开始推动立项过程,固定具体的产品范围要求项目经理对发布结果承诺哦。通常产品经理会在PRD中塞入尽可能多的功能,因为:

  1. 要求多多益善是人类的弱点
  2. 他们代表了客户,得为他们争取竟可能多的利益^_^
  3. 尽可能多的写下来,当出问题时,可以转嫁责任给项目经理(研发团队),先求无过。(博弈论,人性的弱点,潜规则,天知道…)

过程中,项目经理则尽可能减少、简化功能,因为:

  1. 实现太复杂,会影响发布
  2. 少做是人类的弱点
  3. 没有要求做,当客户愤怒时,可以转嫁责任给产品经理,先求无过。($#@%$^…)

  

双方通过一轮轮的评审,不断在产品范围上拉锯,时间则在向红线不断逼近…下图,立项的时间在评审中不断游移:

image

终于,双方达成共识了(虽然实际很可能是双方都累了,无暇再考虑细节,就这么模糊的定了)。产品经理长舒一口气,他只需等待发布,其余交给项目经理了。

但是,从立项到发布,期间还有N长时间,似漫漫长夜,让人恐惧,因为将发布的东东,现在还是一堆纸 …后续都是技术活,产品经理有心也无力了。

image

立项结束,项目经理接过指挥权。熟练的将任务分解为分析、设计、编码和测试阶段,逐步明晰需求,细化设计然后实现,期间可能还会输出诸如SRS、HLD甚至LLD等文档,确认是否走在正确的路上。但是,通常会发现:

  1. 产品需求模糊且广大,细化需求工作力量巨大,导致需求分析时间冗长。
  2. 需求分析累了或用时太多,必须加快进度,不得不开始设计。
  3. 然后因为需求模糊,导致设计时再需求和设计间来回摇摆,耗时同样冗长,还可能因为设计问题缩水、遗漏需求。
  4. 因为时间原因,急忙开始编码,期间发现很多需求、设计问题,导致时间冗长,压缩了测试时间。
  5. 因为发布日期临近,匆匆测试,急忙上市

image

终于,产品发布了,但是客户不满意,缺少重要甚至必须的功能,性能不佳等等,问题一堆。游戏终局常见情况是:

image

当然,神也是会发雷霆之怒的…

上一篇:Nginx模块开发入门
下一篇:没有了
网友评论