您的位置: 首页 > 技术文档 > 网站建设 > PM与工程师
数据是一种信仰 回到列表 社区初建十四条
 PM与工程师

作者:纯银 时间: 2011-04-13 文档类型:合作网站提供 来自:纯银

过节前看到一篇文章,讲产品项目就应该由工程师来主导,但国内让PM去驱动项目,搞得乱七八糟,很恼火,怎么可能做出一款好产品来呢?

很显然,写这篇文章的是一位愤怒的工程师,Angry Engineer!我跟他至少有两点共鸣:

1、国内的PM确实常常折腾工程师,甚至不乏“把工程师当工具对待”的情况。
2、如果工程师有开阔的产品视野与全面的设计素养,知行合一,由工程师来驱动项目是一个完美的选择。

可惜由于教育环境的问题,国内通才太少。一个优秀的工程师,同时又是一个优秀的PM,凤毛麟角,只能人任其长,各自做自己拿手的活儿。这时候更擅长需求分析与产品设计的PM来驱动项目,也是不得已的选择。

说来惭愧。需求不靠谱,或是来来回回修改,折腾工程师的事儿我也做过不少,直到最近一年多才算是大有好转。我应该忏悔……虽然能做好PM的工程师极少,靠谱的PM其实也不算多,最后大家都得写周报对不对?

在产品行业远远不够成熟的现阶段,痛苦的来回折腾难以避免。但最起码,PM应该把工程师作为伙伴而不是工具,想法设法地站到一条战壕里去,争取他们的理解。因此抛开难以鉴定的需求的对错,仅仅从协作流程的改进上,我积累了以下的经验。

首先要得到工程师对整个项目的认同。每个月都有一场一小时的部门月会,对着PPT,我来讲下个月乃至下个阶段,我们的任务规划是什么,目标设置又是什么,详细解释制定规划与目标的原因,近景与远景分析,为咩做这件事情为咩这样去设计等等。希望工程师能认可他即将做的事情是有价值的,值得为之而努力的。为接下来PM与工程师的沟通做好铺垫。

月会上还有一个环节,详细分析本月发生的所有数据,尤其是最近发布的新功能的数据。这个环节也是为工程师准备的,使他们了解自己的工作能产生多少实际效果。

至于月会上送出的新功能礼品(以前讲过许多次),最开始是为工程师专设的彩蛋,再后来才将PM与运营包括了进来。我得承认自己对工程师偏心眼,因为有信心能激励PM与运营,却出于沟通深度不足,需要借助更多的手段来激励工程师投入项目。

项目任务分两种,大版本与小模块。对于大版本,在基本框架定下来之后,PM提前向工程师讲解,听取技术视角对设计方向的建议。整个设计过程中还会反复讨论三五次,为技术上的合理性征求意见。小模块则在策划案基本敲定之后,与工程师共同确认一次,视觉稿出来后再通报一次。(所以PM与工程师坐得近是很有必要的)

我曾经在部门月会上公开承诺说,任何一个需求,只要工程师认为是不合理的,都可以停下来不做。直到PM能说服工程师为止。如果死活谈不下来,才由我和技术经理出面来协调。强硬要求服从的情况在我这里基本上没有,被工程师说服倒是时有发生,按工程师提出的意见来改方案。我也常常跟PM讲,小分歧你们都听工程师的,没有必要坚持己见。你让他爽一点,开发速度就快一点,大家都获益。再说你多听听技术伙伴的意见有什么不好呢?帮助你转换思考的角度,共同找到提高开发效率的方法。

最后方案定下来了,PM说OK,工程师也觉得方向大致没错,细节基本合理;进度方面则由工程师进行评估。PM觉得时间太长接受不了,再找到我和技术经理一起商量,看是分阶段砍需求呢,还是加把力加点班。除了极少数紧急修复任务外,不会由PM单方面确定开发时间安排。包括一系列任务的优先级安排,也由PM先提草案,工程师根据开发情况来调整顺序,再共同确认。

在PM提出需求的整个流程里,始终在进行不断的协商,保证工程师对任务是理解并且接受的,不会出现抗拒,或者是麻木的心态。如果遇到突发性的需求变更,更加会向工程师反复解释,请求谅解,因为浪费了他们的工作成果而心存歉意。为此而花费的时间对比更高的开发效率,稳赚不赔。虽说具体协作时还有一些不到位的地方,但态度总归是好的,基本的效果也是有的。

当然,这套流程的实施得具备两个前提。第一是有稳定的团队,如果变成提单协作,这个月一起干下个月分道扬镳,那就不可能实现共同的项目归属感。第二是工程师的个人素质基本靠谱,沟通顺畅;尤其是技术经理可以服众,协调好分歧而不护短。比如说一个功能能不能做,至少开发多久,我和PM都搞不掂,主要靠技术经理来做最终判断;如果出现开发过程中的失误,或是不按照约定好的方案进行开发,则由技术经理进行处罚。我对开发组更多作行政管理,全靠这位技术核心伙伴来负责业务管理,他也会更深入地参与到产品的结构设计,任务规划里来。

这样做,也就撇开了把工程师当工具对待的嫌疑。我觉得把任何同事当工具都挺可耻。怎样才算是伙伴呢?比如交流必要的信息,理解对方;比如能站在对方立场去换位思考;比如多一点点鼓励与帮助。

换个角度看,我这边曾经出现过由工程师来提出大致构思,PM认可并负责细节设计,再由这位工程师来实现的情况。结果皆大欢喜。我后来多次在月会或别的场合征求工程师的创意,换一换视角,引入新鲜的想法与灵感。即便想法不一致,也会非常温和地解释反对原因,绝不可能一口否决。唯恐工程师们默不出声闷头干活——听不到技术伙伴的意见是多大的损失啊。

今上有敕云:“科学发展观的核心是和谐发展。”

原文:http://firecacada.blog.163.com/blog/static/70743762011117114451722/

本文链接:http://www.blueidea.com/tech/site/2011/8399.asp 

出处:纯银
责任编辑:bluehearts

◎进入论坛网站综合网页制作版块参加讨论

相关文章
《网络工程师考试疑难问题解答》
作者文章
显性内容决定论
产品经理是炮灰
关键字搜索 常规搜索 推荐文档
热门搜索:CSS Fireworks 设计比赛 网页制作 web标准 用户体验 UE photoshop Dreamweaver Studio8 Flash 手绘 CG
站点最新 站点最新列表
周大福“敬•自然”设计大赛开启
国际体验设计大会7月将在京举行
中国国防科技信息中心标志征集
云计算如何让安全问题可控
云计算是多数企业唯一拥抱互联网的机会
阿里行云
云手机年终巨献,送礼标配299起
阿里巴巴CTO王坚的"云和互联网观"
1499元买真八核 云OS双蛋大促
首届COCO桌面手机主题设计大赛
栏目最新 栏目最新列表
浅谈JavaScript编程语言的编码规范
如何在illustrator中绘制台历
Ps简单绘制一个可爱的铅笔图标
数据同步算法研究
用ps作简单的作品展示页面
CSS定位机制之一:普通流
25个最佳最闪亮的Eclipse开发项目
Illustrator中制作针线缝制文字效果
Photoshop制作印刷凹凸字体
VS2010中创建自定义SQL Rule

蓝色理想版权申明:除部分特别声明不要转载,或者授权我站独家播发的文章外,大家可以自由转载我站点的原创文章,但原作者和来自我站的链接必须保留(非我站原创的,按照原来自一节,自行链接)。文章版权归我站和作者共有。

转载要求:转载之图片、文件,链接请不要盗链到本站,且不准打上各自站点的水印,亦不能抹去我站点水印。

特别注意:本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有,文章若有侵犯作者版权,请与我们联系,我们将立即删除修改。

您的评论
用户名:  口令:
说明:输入正确的用户名和密码才能参与评论。如果您不是本站会员,你可以注册 为本站会员。
注意:文章中的链接、内容等需要修改的错误,请用报告错误,以利文档及时修改。
不评分 1 2 3 4 5
注意:请不要在评论中含与内容无关的广告链接,违者封ID
请您注意:
·不良评论请用报告管理员,以利管理员及时删除。
·尊重网上道德,遵守中华人民共和国的各项有关法律法规
·承担一切因您的行为而直接或间接导致的民事或刑事法律责任
·本站评论管理人员有权保留或删除其管辖评论中的任意内容
·您在本站发表的作品,本站有权在网站内转载或引用
·参与本评论即表明您已经阅读并接受上述条款
推荐文档 | 打印文档 | 评论文档 | 报告错误  
专业书推荐 更多内容
网站可用性测试及优化指南
《写给大家看的色彩书1》
《跟我去香港》
众妙之门—网站UI 设计之道
《Flex 4.0 RIA开发宝典》
《赢在设计》
犀利开发—jQuery内核详解与实践
作品集 更多内容

杂⑦杂⑧ Gold NORMANA V2