您的位置:华夏互联>>媒体报道>>汪照发总经理接受《程序员》杂志权威专访

备案详细流程 CN域名申请说明

汪照发总经理接受《程序员》杂志权威专访

作者:office 来源: 发布时间:2014-05-16 点击数:

摘要:互联网时代需求多变,关于产品设计与开发实现的各种矛盾吐槽不少。技术人员该怎样参与到产品设计讨论环节也值得深思。CTO俱乐部会员,上海逐一软件总经理、首席架构师汪照发总结了项目交流的三个误区和四点经验。

很多时候,程序员与产品经理在一个项目上的感观是完全不同的,就如两个盲人摸象,一个希望摸出牛来,一个希望摸出面包来,显然二者都是不够理性的。


CTO俱乐部会员,上海逐一软件科技有限公司总经理、首席架构师 汪照发


所以在项目管理中,我们要引入迭代和增量。迭代让软件不断完善某个特性,增量支持逐步交付所有特性。二者结合起来使用,可以不断修整逼近真实需求,提早暴露及规避风险。项目交流中,往往遇到的问题有以下三个误区。


误区一:技术人员不断推翻产品经理的需求


在一些传统企业中,技术人员往往是权威,而产品经理往往是新聘或提拔的高管,无论是产品经理还是技术骨干,都受其职业规划和眼光的影响,并不能对整个公司或整个项目进行高瞻远瞩的规划,而企业的决策者们游离于技术骨干与产品经理之间,往往造成整个项目的需求和目标崩溃。

这种现象最后往往表现为:产品通过实施已经做好了,最后在技术人员那变成了“服务器不支持部署”,最终不了了之;或表现为:产品经理好不容易做好了一个需求,且能够实施,会上宣讲完后,技术骨干说“销售部早就试过这种技术,现在的客户端也不支持,培训销售人员使用软件至少要三个月”,使整个需求崩塌。


误区二:技术人员过度或过高解读产品经理的需求


过高解读需求事实上也是对需求的漠视。

我们经常遇到的现象是:当项目周期到了,审视整个项目进度却没有达到一半,开会讨论时收集的意见是“产品经理不是说UI界面很重要吗?我们已经设计了8套界面,至于软件核心我们还没有开工”、“这套产品我们规划了手机、PC和平板三个介质,所以我们分别在三个平台上进行了测试,软件代码还没有开始”。


误区三:技术人员对需求无动于衷


技术人员对需求无动于衷的现象往往表现为:你让我做移动项目吗?但我的PC客户端还在开发呢?你要的写代码,可我们还在做上个项目的培训呢。

对于上述三种误区,需求与开发的不对称,关键在于责任、目标与绩效。我们很容易理解,如果一个新项目突然给一个守旧的团队来实施,而且告知如果实施不达成就会受到惩罚,又或者告知如果实施成功将不再采用旧的标准来维系软件,可想而知整个项目组成员的抵触心理是何等强大。

要解决交流误差,并营造出快乐的沟通氛围、实施出优秀的作品,也并非没有解决之道。我多年从事Web开发和团队管理,在此分享四点经验。


经验一:专职做专事——不要对技术人员有复合事务要求或过高奢求


人们往往容易犯的错误是对别人有过高的需求。我们当然希望保洁员阿姨都能写出优秀的代码,上得了厅堂、下得了厨房,但这种求大求全的现象,往往最后什么也做不成。

所以在管理团队过程中,告诉团队:你不需要有过多的实施,你只需要专心做一件事,而且下班后就开开心心回家,第二天一早会有递增需求清单等你实施,绝不会让一个程序员去做“需求收集”,也不会让一个美工去“顺便写下CSS”这样的需求。

看起来这种思路很保守,但事实是有效和安全的。不可能要求所有成员都是复合型人才,员工什么都能做还打工干嘛,早就自己去当老板了。


经验二:不管结果如何,你先给我做出来,责任我来承担


项目经理或产品经理对于责任的担当是第一位的,作为经理要灌输给团队的理念是:你只要按我的需求做好事情,所有责任我会来担当。唯有如此,才能建立起一个敢进敢退的团队,而不应简单地将责任推诿给成员。

承担责任的前提并不仅仅是勇气或魄力,更需要智慧。往往经理能看到的层面,不是其他成员能看到的。可以设想当年iPhone研发时,分别在屏幕、传感、移动互联网等技术上投入,而原本从事PC开发的麦金塔团队成员并不能理解,但事后这些技术都很好地整合到了产品上。

在我们的项目管理中也同样需要“暗箱推进、事后串联”的能力。比如前瞻性地安排成员在UI、硬件、软件、需求等多方面并行开发,而事后可以良好地将这些技术“干货”整合起来,即使团队成员有离散,也不会影响整个项目。


经验三:同衣同袍、上下齐心


有什么比平等更重要呢?和团队成员一起上班、下班、一起吃快餐、一起找解决方案,远比一纸公文或是高高在上更有效。不要奢望通过远程电话会议、QQ、邮件能解决一切交流问题,面对面的交流,永远是最重要的传感渠道。


经验四:可以不说话,但有工具可以让你参与


有人说:需求有差异、实施有软肋,那就开会解决呗。“程序猿”们往往是口头表达的弱者,或是漠视口头交流(事实上他们不是没能力交流,而且往往在会上一言不发、会后牢骚万千,并在社交网络上活跃异常),原因很简单“写代码都已经很累了,为什么还要交流这么多”、“我又不是经理,为什么要参与交流”、“我只赚代码编程的钱,又没有人付我参与交流的报酬”。

针对这样的现象,经理应该允许并给予充分的尊重,我们要做的是:允许哑巴成员,但我会有其他的工具让你参与。包括线上调查、月报周报、团队拓展、日志记录、报表收集,甚至是生日Party等场合,在与员工同衣同袍的基础上,充分地让员工得到交流,从而解决交流的鸿沟。



原文来源:http://www.csdn.net/article/2014-05-06/2819643-How-To-Get-To-Participate-In-Product-Design


责任编辑:本站编辑 发表评论>>