产品经理应该具备的开发知识制度.pdf

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
产品经理应该具备的开发知识 博友一根弦留言,说讲讲《产品经理应该具备的开发知识》了解开发人员的工作流程, 沟通、 协调起来会更加顺畅, 这回就定制一下这个话题。 一般当工程师接到产品开发需求的 时候,最直接想知道的几个问题是: 这个是一款什么产品? 产品是怎么样的一个产品, 这个产品的背景的由来是什么。 什么时候确定下来的?谁确 定下来的?我们为什么要做这做个产品, 做与不做对目前有什么区别。 这个产品在整个体系 中扮演的角色是? —-这个直接让工程师知道要做的对象是什么,进而才会有很清晰的概念 存在。 这个产品的意义是什么? 产品的意义在于哪里, 通过开放这个产品能产生什么?又改变什么?帮助用户方面做什 么样的提升?帮助我们商业层面又有多少的帮助 ?—这个直接决定了工程师是不是认可做这 个事情的价值,能不能让他们很兴奋、全身心的投入进来做这件事情。 这个产品到底要做哪些事情? 这个产品到底要做哪些事情, 几个关键的应用场景、 关键的应用业务是什么?哪些事情 是最主要预先要解决的?哪些事情是相对不重要的? –这个直接决定了工程师是否觉得业务 是不是很具体,是不是可以很好从系统的角度去抽象业务,进行系统设计。 这个产品具体的实现逻辑是什么? 具体实现的逻辑,就是在开发产品的时候,把关键业务、 主场景、 关键业务逻辑梳理出 来,希望通过什么样的方式去实现。 —这个直接决定了工程师可以初步的评估你这个产品方 案的可行性,现有框架的对实现逻辑是不是支持,也决定了要支撑这个逻辑的实现成本。 这个产品的产品经理是谁? 这个产品经理是谁也是很重要的,产品经理是不是 OK ?是不是可以好配合?好沟通? 产品技术的专业技能怎么样?是不是有激情? –这个直接决定了工程师是不是喜欢和你打交 道,是不是认可你,认可你的产品的一个重要因子。 这个产品需要我们多长时间做出来 ? 资源总是有限的、 大产品分项目做, 小产品一个项目开发周期搞定。 但是多少时间要做 出来,还是非常客观的一个评估条件。 —这个直接决定了工程师在评估完开发成本后决定是 不是缺人要加人进来,是不是需要非常规,敏捷开发等等。 以上这些问题, 都是你在给工程师提交需求之前一定要想明白的。 第一: 如果你自己都 想不明白, 描述清楚这个产品到底是什么样的产品,要做什么不做什么,意义在哪里, 具体 怎么做?那势必给别人的感觉是你没有想明白, 那别人怎么会相信你, 信服你。 继而开足马 力的支持你配合你。 第二、 这些问题也是你换位思考的一个方式。 产品经理如果一直站在产品经理的视角看 问题, 那肯定会忽视了很多事情的细节、 很简单的工程师也是一群需要尊重需要肯定, 喜欢 做有挑战事情的人, 你如果都不重视工程师对项目开发的感受, 人家凭什么要重视你对产品 的感受,一样的道理。 第三、 大家的目标都是要完成目标、 有成就感,那么产品经理就得要多走一步,因为整 个事情是围绕你始终的, 你要让你自己兴奋起来, 全身心的投入带动所有工程师全身心的投 入。大家使命一致,这也是很重要的一个方面,绝对不能忽视。 曾经在《产品经理怎么样和工程师打交道》一文中有写过一些相关的跟工程师的理解, 大家有兴趣的再回顾一下。接下来步入正题,讲一讲产品开发人员的相关知识。 产品开发流程,

文档评论(0)

kxg2020 + 关注
实名认证
内容提供者

至若春和景明,波澜不惊,上下天光,一碧万顷,沙鸥翔集,锦鳞游泳,岸芷汀兰,郁郁青青。

1亿VIP精品文档

相关文档