[原]我们的管理:产品经理与程序员协作

标签: | 发表时间:2014-03-07 17:10 | 作者:david_lv
出处:http://blog.csdn.net/david_lv
今天CTO顾问咨询团发了一个问题,是关于产品经理频繁改版 VS 程序员的事。那我就来以实践经历说说我们是怎么协调产品经理和程序员。


一、导向一致


协调的关键在于在大底线大导向大原则方面要一致。在一个层面一个角度上说话才能说到一起共同促进,否则各说各有理就没法走下去了。


我们的产品设计导向原则是:
1、功能的增加一定是为企业经营增值,把什么平衡制衡、风险、管控、成本先放放


2、一定要聚焦企业核心价值链,不搞边缘部门边缘人的边缘流程


3、场景化。也就是说你描述一项功能需求,一定要明确说明是什么样的企业(人员规模/营收规模/企业性质/地域),什么部门的什么岗位的什么流程的什么环节,目前面临什么业务问题,先不说软件缺陷先说业务问题,说完业务问题再提业务解决方案,然后再提IT改进解决方案。需要业务和IT一起并行改进


4、最简化、迭代改进。聚焦核心问题,最简化解决核心问题,周边需求先放放,不要太追求体系化,否则拔出萝卜带出泥一整就是大解决方案包,这样要解决一个核心问题就太复杂了。先把七寸打了


5、数据统计论证。说要增加一个功能需求,要给出实际客户统计。我们有需求管理系统、BUG管理系统,这两个系统可以客户、各个部门员工、渠道合作伙伴都可以登记需求和BUG。我们的系统也有业务使用日志收集引擎,自动记录用户日常使用习惯,并且这些日志都通过我们服务器后台的同步软件传输到我们的运维服务中心,我们每个季度会根据这些数据自动出每个客户的应用质量体检报告。这些都是数据。我们有这些数据来支撑一个需求是普遍需求还是个性化需求,需求的紧急重要程度如何。不能产品经理靠在一线的客户交流来判定客户是否需要。这个原则是和程序员同思维很重要的基础,大家看到数据就都心服口服了。


我们的技术设计导向原则是:
1、分离式、自封闭模块化。也就是说我们的每个功能每个代码层都能部署到不同的服务器上。功能和功能之间的关联(UI URL调用关联/业务逻辑接口关联/数据关联)都通过ESB中央企业服务总线来统一规格集中管理,不能形成直接互相调用,否则就成蜘蛛网了


2、低成本高效率高质量支撑产品实现。我们的导向是防止过度设计。由于我们有分离式、自封闭模块化、ESB中央服务总线的保证,所以在扩展性和管理性上还不错,所以不担心会出现临时方案的风险。所以有导向原则,就不会过度设计也不会很临时拼凑。


二、协作流程整合


我们的产品规划是三个版本持续滚动:现在正在开发的、下一个版本即将要开发的、下下个版本想要瞭望的。


我们是每两个月开一次产品规划讨论会。产品规划讨论会是由产品决策委员会负责。产品决策委员会是个跨部门跨层级的组织,有产品经理,有技术架构,有市场营销,有实施服务,有运维客服。能进入产品决策委员会的一般都是各条业务线的一线实干专家和各业务线的决策领导人。产品决策委员会CEO和COO都会参加,由各线产品经理进行汇报。


我们有专门的技术架构部门,我们也有每两个月开一次技术规划讨论会,就是根据产品经理的产品规划输出然后做技术架构的输入。与会者有产品经理、技术架构人员、测试经理(关系到测试)、实施服务(关系到安装部署配置的门槛)、运维支持(关系到问题查找/更新升级)。


所以经过这两个规划委员会,我们的产品和技术就走到了一起,这是顶层的设计。


我们的产品研发是预研制度。有专门的创新研发中心负责原型开发。从产品经理构思设计到最后真正产品,是一条非常长的路。先开发原型,然后在合作客户中做试点运行,必须东西南北各找一家,而且大中小客户各不同。经过这样的原型开发和试点改进才能决定是否可以进行专门立项做正式的新产品研发。不少原型产品做了几年都没能立项做正式新产品。


在开发原型的时候,技术架构人员同时也在做架构设计、技术预研攻克、技术原型代码。


等新产品正式开发时,技术难关已经都过了都验证了,这样新产品研发的风险就小很多了。中间出现小的技术风险,通过每周PM汇报会来暴露风险申请技术人员整合支援攻克,都有明确的流程,如果是紧急的技术异常问题会直接通报总监进行协调。
作者:david_lv 发表于2014-3-7 9:10:36 原文链接
阅读:29 评论:0 查看评论

相关 [管理 产品经理 程序员] 推荐:

[原]我们的管理:产品经理与程序员协作

- - 阿朱=行业趋势+开发管理+架构
今天CTO顾问咨询团发了一个问题,是关于产品经理频繁改版 VS 程序员的事. 那我就来以实践经历说说我们是怎么协调产品经理和程序员. 协调的关键在于在大底线大导向大原则方面要一致. 在一个层面一个角度上说话才能说到一起共同促进,否则各说各有理就没法走下去了. 1、功能的增加一定是为企业经营增值,把什么平衡制衡、风险、管控、成本先放放.

如何做一个程序员尊敬的产品经理

- - 花痴痴的网站 | 女程序员园地
一直以来,产品经理(PM)和程序员(DEV)好像都是冤家. 自己以前也是做技术的,很能够理解DEV们的小心思,他们其实是很鄙视PM的(或许没有鄙视那么严重,至少是认为PM不那么厉害吧. 目测10%以上的DEV心里都有过这个念头:老子以后写代码写腻了也能去做PM). DEV会觉得,PM的需求只需要3分钟拍脑袋想出来的,但是自己却需要花3天时间去实现,这是什么道理,更气人的是,未来的某一天,PM可能告诉自己某个地方得改,改回到原来需求描述的那样.

产品经理:嘿,程序员哥们,能尊重一下我么?

- - 一个产品经理的博客...
    产品经理如何搞定程序员.   产品经理和程序员这两个都是苦逼的岗位,但有时候两个苦逼还经常在一起较真,成为了2B,今天我们来聊聊产品经理如何搞定程序员,使两个苦逼不再苦逼,下面我们来看一个案例:.   小A是个程序员,小B是个产品经理,.   1.事儿都是程序员干的.   2.产品经理不会干还指挥我们干.

产品经理如何把握管理的职能

- - 设计之外 - UCD大社区
产品经理是一个管理的角色,这点应该有很多人赞同吧,虽然这个管理大部分不是人事和财务,而且做管理也木有头衔,主要是管理一个产品从概念到实现的过程,最终的产出物是一个有着特定功能,满足了人们某种需要或者欲望的产品或者服务. 既然是管理的角色,那么就从管理这个侧重点来说说产品经理应该怎么样去把握管理的职能.

产品经理也应该了解项目管理(一)

- - 人人都是产品经理
大家很多时候会因为与软件工程师,以及软件项目经理沟通不畅而烦恼.       “为什么你们的计划是这样排的,老板要求我们什么时候要上线,为什么你们要那么久.       “为什么你们的进度总是有问题.       “为什么你们bug这么多.       “为什么在这个阶段你就不能修改我们提的需求.        这些问题可能很多项目经理都会遇到,那么很多人遇到问题后,沟通不畅很多人会觉得很沮丧,很多人会很不解,当然有些人就会觉得这个工作没意义受夹板气.

» 产品过程管理 小威的世界——移动互联网产品经理 无线产品经理

- Temp - www.xwcool.com
产品部确实遇到了问题,但看到的还是积极解决的一面,产品部不是设计部,不再是个只会画原型的设计师,而应该对产品长期规划负责,对产品市场负责. 宁愿多做一点,少一点问题,而不应该由市场牵着东拼西凑出来的产品,更不是由每个不相关人员提出一个问题就应该为之解决的傀儡,产品经理需要强势,需要对整个产品强势,对于整个产品管理过程负责.

如何管理你的程序员

- kapster - 博客园新闻频道
  本文是从 How to manage your Programmers 这篇文章翻译而来.   以一个组织的形式完成项目、任务或实现某些目标,这被称作公司,这需要有完善的信息流转机制和长期的规划. 过程管理在这种组织里是一个非常复杂的问题. 这就是为什么这些年会出现了大量的诸如Scrum,. Kaizen, Kanban等技术和方法论来尽可能简化这个过程.

谷歌前产品经理谈创业团队管理:做好情景管理,控制团队规模

- - ITeye资讯频道
原文作者Tomasz Tunguz是Redpoint Ventures的风险投资人,曾在Google担任产品经理并参与过AdSense项目. 在文中,Tomasz Tunguz针对创业公司给出了2条极富实践性的建议: 针对不同类型的员工,做好激励和情景管理;努力平衡控制范围和管理职责范围(下文由 36Kr进行编译整理).

产品经理

- - 人月神话的BLOG
再谈下怎样能够算得上一个合格的产品经理,一个人不是说你能够有产品构思,能够画点原型,能够做团队和项目管理就是产品经理. 苏杰原来有本书叫《人人都是产品经理》,看了后大家可能会觉得做一个产品经理是挺容易的一件事情,但是自互联网提供和设置了大量的产品经理岗位后,产品经理这个词基本就烂大街了. 我们如何来界定一个产品经理,如果简单点来讲可以理解为 根据自己长期的项目和运营实践,通过自己的敏捷洞悉能力和分析能力,能够将当前的市场需求或潜在的市场需求转化为具体的产品需求,并能够核心的定义产品功能模型和价值输出,同时能够通过项目和团队管理的能力,凝聚一个小组形成一个真正的团队,将自己的产品构思付诸于最终产品实现的人.

周金根:程序员的个人管理

- zhoujg - 伯乐在线 -博客
  注:本文转载自周金根的博客.   在公司工作已经10年了,我看到过很多熟悉和陌生的面孔走去,也有后来又回来的,他们中有善于思考的人、也有浮躁的人,有老员工、也有新员工,有技术人员、也有管理人员. 每个人在工作中都会经历或者思考过”离职“这个问题,作为普通IT人员的我也同样逃不开这个词. 虽然曾有去寻找另一片绿地的想法,但我相信与其寻找远处的幸福,不如马上在脚下播种幸福,所以今天我仍旧只在一家公司工作过.