论坛首页 综合技术论坛

十几杆枪如何应对几十个项目-做好产品化

浏览 15054 次
精华帖 (7) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (9)
作者 正文
   发表时间:2010-07-19   最后修改:2010-07-19
zgsheng 写道
都写的好长啊.
个人建议:
一、将开发部门分为实施团队、产品团队。产品团队负责产品核心功能研发,实施团队负责客户化研发。如果实施过程中遇到产品通用功能增加、产品级bug,则交由产品团队完成。实施团队的项目经理,一定要能控制客户需求,这个是实施项目经理的基本技能。
二、顶住压力做产品,这个往往是技术人员的想法。公司的生存和盈利是靠项目的。实施还要做下去。专心做产品是不可能的,产品只能在实施中优化,而不可能闭上门专门做产品,尤其是企业应用。
三、客户领导要看,下周就要演示。这样的事交给售前部门自己解决。要相信他们,他们自己一定能解决。
四、BUG太多,项目经理埋怨研发,研发埋怨测试。 这个太不可思议了,bug太多,研发埋怨测试?应该还是需求不清,研发开发的功能,测试认为不应该是这样的,结果搞成bug了吧。测试也要适当学业务滴。
个人感觉,你们的产品还在初级阶段,目前处在最难熬的时候,产品不成型,项目管理也不成型,项目经理经验不足。。。熬个两三年,就好了。


非常感谢您的建议,辛苦了!

1: 将开发部门分为产品团队和项目团队的确是一个不错的想法,关键是两个团队如何协调资源和管理。
2:基于项目做产品我们做了四年了,这样很被动,每次等到演示的时候,用户总提出新的需求,而这些需求往往未在产品中规划过。软件的成功在于无成本的复制,基于项目来做产品始终成本太大,所以最终目标必须产品化,产品化并不是闭门造车,而是需要走出去了解客户战略,烦恼,挑战,奶酪和业务流程等,从而输出业务架构,再由业务架构输出数据架构,再由数据架构输出应用架构,再由应用架构输出技术架构,这也是所谓的EA方法论。
3:这个提议很好,我们也尝试过,但是大多情况下销售和售前都不能解决,因为他们也不希望得罪客户。这个问题我认为是项目经理从一开始未意识到这个风险的存在,所以等到发生的时候,会措手不及。
4:测试的问题也和产品本身的性质有关,我们开发的产品因为需要的资源太多而公司却不能提供,所以很多问题只有到现场才能测试和重现,而有时候我们也只能通过远程桌面来解决问题。
5:的确我们做了好几年,产品化是处于初级阶段,也是今年才开始提上日程,我觉得最主要的原因是未做充分的共享和团队积累,大量的经验都掌握在个人手上,随着离职而流失。
0 请登录后投票
   发表时间:2010-07-19   最后修改:2010-07-19
要搞产品,最重要的是有产品经理,我自己的体会来说,用项目经理当产品经理是相当的杯具

1、视野和能力不全面。
技术性的项目经理会从技术上考虑问题,服务型的项目经理会从客户角度考虑问题,某类型的项目经理总是从帮老板压榨的角度考虑问题……
最后和其他人沟通的时候,不是争执不下就是被人牵着鼻子走
产品经理至少需要在2-3个以上不同性质的团队干过或则用心观察过才行

2、人微言轻
几个用户提出了不同的个性化需求,而且:立刻!马上!明天就要!
或者
销售帮你忽悠客户了一大堆功能,告诉你先做着
或者
实施说开发做的功能有问题,开发说实施不会用

要命的是如果公司里的这些人属于不同的部门,除了不同的部门经理外还有不同的主管副总
理论上意见不合的话,只有总经理才有决策权

成功的产品经理总是能管着这些团队,而不是当这些团队的皮球
管不到产品生命周期中涉及的所有领域不能算产品经理
如果组织结构不是产品开发模式(而且也要有能力坐上那位置去),不要指望做出啥产品


3、不能坚持
坚持不下去,就是做出来也很快就会项目化
未必是个人或者团队坚持不下去,原因很多,考核制度、组织架构、高层战略等


总之,如果老板真的想出产品,这是条任重道远的路
组织结构、考核制度都要有所倾斜,找一个熟悉本行业的老手或者花3年以上的代价在公司内有计划地培养一个,再配上有相当基础的团队

楼主的情况,似乎没有解决企业的生存问题,这样有任何可以看到的利润,研发必定容易向这些利润客户倾斜,
因此研发过程会天生的倾向项目化。
在这时如果脱离项目强行搞个产品出来,容易资金链断裂,客户流失,没准企业就死了
首先公司要在维持目前项目的同时,还有精力投资产品研发

0 请登录后投票
   发表时间:2010-07-19   最后修改:2010-07-19
seeckt 写道
要搞产品,最重要的是有产品经理,我自己的体会来说,用项目经理当产品经理是相当的杯具

1、视野和能力不全面。
技术性的项目经理会从技术上考虑问题,服务型的项目经理会从客户角度考虑问题,某类型的项目经理总是从帮老板压榨的角度考虑问题……
最后和其他人沟通的时候,不是争执不下就是被人牵着鼻子走
产品经理至少需要在2-3个以上不同性质的团队干过或则用心观察过才行

2、人微言轻
几个用户提出了不同的个性化需求,而且:立刻!马上!明天就要!
或者
销售帮你忽悠客户了一大堆功能,告诉你先做着
或者
实施说开发做的功能有问题,开发说实施不会用

要命的是如果公司里的这些人属于不同的部门,除了不同的部门经理外还有不同的主管副总
理论上意见不合的话,只有总经理才有决策权

成功的产品经理总是能管着这些团队,而不是当这些团队的皮球
管不到产品生命周期中涉及的所有领域不能算产品经理
如果组织结构不是产品开发模式(而且也要有能力坐上那位置去),不要指望做出啥产品


3、不能坚持
坚持不下去,就是做出来也很快就会项目化
未必是个人或者团队坚持不下去,原因很多,考核制度、组织架构、高层战略等


总之,如果老板真的想出产品,这是条任重道远的路
组织结构、考核制度都要有所倾斜,找一个熟悉本行业的老手或者花3年以上的代价在公司内有计划地培养一个,再配上有相当基础的团队

楼主的情况,似乎没有解决企业的生存问题,这样有任何可以看到的利润,研发必定容易向这些利润客户倾斜,
因此研发过程会天生的倾向项目化。
在这时如果脱离项目强行搞个产品出来,容易资金链断裂,客户流失,没准企业就死了
首先公司要在维持目前项目的同时,还有精力投资产品研发


的确如您所说,目前做产品永远是愿景大于实际,项目支持的优先级永远是最高。
目前公司是有产品的,也是在逐渐的基于产品做项目的过程中,进展还不错,因为目前这个阶段项目比较少,有产品经理支援项目并汇总各个项目的需求,研发能静下心来在公司统一将这些需求开发到产品中。
的确需要产品经理这样的职位来统一协调各部门,所以我从研发组长的位置转职到产品经理的职位上。这个职位最大的优点就是没有权利,只能靠能力和权威去协调各个部门,这中间遇到的困难非常多,目前没有把主要精力花在客户研究方面,而是在做做各个项目的支持工作。
也的确需要组织结构是产品开发模式,这样才能自上而下的进行制度变革。
0 请登录后投票
   发表时间:2010-07-19  
其实我个人觉得上述的各位大哥阐述的都有道理。但是我个人的认为:
  几十杆枪应对几十个项目并非不可能的事情。干好的基本在于:产品经理和项目经理如何提高使用枪的士气。如何给他们士气。如何在遇到失败、不成熟的产品或项目而能给开发人员成就和凝聚力。如何很好的计划好项目。如何将十几把枪训练成像陆战队那样有战斗力。成事者能很好的把握和创建天时、地利、人和。现在IT的管理缺乏的就是很好掌握天时、地利、人和的协调人员或者管理人员。大部分都是没有很好的计划,出现问题互相指责。团体人员不和气。天天加班导致人员疲惫。没有很好的计划。没有成就感等等。这些中任何一种情绪或者气氛出现在团队中都是很危险的事情。
0 请登录后投票
   发表时间:2010-07-20  
jiangduxi 写道
其实我个人觉得上述的各位大哥阐述的都有道理。但是我个人的认为:
  几十杆枪应对几十个项目并非不可能的事情。干好的基本在于:产品经理和项目经理如何提高使用枪的士气。如何给他们士气。如何在遇到失败、不成熟的产品或项目而能给开发人员成就和凝聚力。如何很好的计划好项目。如何将十几把枪训练成像陆战队那样有战斗力。成事者能很好的把握和创建天时、地利、人和。现在IT的管理缺乏的就是很好掌握天时、地利、人和的协调人员或者管理人员。大部分都是没有很好的计划,出现问题互相指责。团体人员不和气。天天加班导致人员疲惫。没有很好的计划。没有成就感等等。这些中任何一种情绪或者气氛出现在团队中都是很危险的事情。

您说到的团队的力量这点也很重要,如何将团队形成斯巴达克方阵,这必须好好研究如何带队伍。
1:如何形成优秀的团队。
    这需要很健全的员工培养计划(就像斯巴达人的教育,从婴儿抓起,团队也必须从面试抓起,一粒老鼠屎打坏一窝粥,我们是有惨痛经历的)
2:如何形成团队的文化,
    如知识和经验的共享,具体表现形式为结对编程,培训和师傅带徒弟。乐于沟通,如吃饭会议,队长中午请大家吃饭,顺便聊聊工作,生活和感情(说实话大家都会被这些问题困扰)。激励队员,如当面表扬,邮件表扬,奖励图书,让其演讲工作所得等。
3:如何形成强大的团队战斗力,使得团队力量最大化的向一点发出。
    这需要角色分工明确,每个角色都有自己的服务目录,专业人干专业事,使工作流程化制度化。如:之前我们的团队总是会搞不清一个文档该是由谁负责编写,而且写完之后质量也不怎么样。
4:如何形成良好的团队环境。
    这取决于队长及每一位员工的修养,每个人的个性和天性不一样,大家必须得摒除自己的特性,以适应团队环境,不能融入团队的人必须得被剔除掉。
0 请登录后投票
   发表时间:2010-07-20  
做产品很不容易,从组织结构上看将产品研发团队同项目实施团队分开是比较合理的作法,这是因为:产品需要的功能要求和技术投入,同项目开发的优先级本身是存在冲突的。对于高层领导当然是多、快、好、省,但是你认真观察下,实践中从目标考核上看,项目讲的是快、省,而产品讲的是多、好。

当然,分开后就面临协调问题。
如果项目还可以勉强算利润中心,那产品研发则是成本中心了(针对在本贴中讨论的场景,据说互联网企业的研发算是利润中心,听说而已)。公司内部不同部门的视角不同,就会导致工作上冲突。

针对楼主的情况,产品只能放低身段去支持项目。

1.把产品研发的投入到项目中,项目经理通常不会有意见,因为通常不占他的项目编制项目经理会说这是帮助提升产品)。

但这就直接影响到产品开发进度,产品经理的压力就很大了。
其实在这种情况下,只能熬了,一是靠产品研发人员在项目过程就尽量按产品设计的要求做,多预留些设计;而是产品经理要争取人员的轮换,把投入的研发人员拉回来。

2.在设计上,产品设计上多考虑项目的定制化能力,提供多种层次的定制化能力。

本质上做产品除去技术因素外,更多的是组织因素,产品经理很关键。。。。。。

5 请登录后投票
   发表时间:2010-07-20  
jiangduxi 写道
其实我个人觉得上述的各位大哥阐述的都有道理。但是我个人的认为:
  几十杆枪应对几十个项目并非不可能的事情。干好的基本在于:产品经理和项目经理如何提高使用枪的士气。如何给他们士气。如何在遇到失败、不成熟的产品或项目而能给开发人员成就和凝聚力。如何很好的计划好项目。如何将十几把枪训练成像陆战队那样有战斗力。成事者能很好的把握和创建天时、地利、人和。现在IT的管理缺乏的就是很好掌握天时、地利、人和的协调人员或者管理人员。大部分都是没有很好的计划,出现问题互相指责。团体人员不和气。天天加班导致人员疲惫。没有很好的计划。没有成就感等等。这些中任何一种情绪或者气氛出现在团队中都是很危险的事情。


道理是很明白,但就是难以实践,不同部门面临的考核压力不同,工作时的目标就不尽相同,一旦出问题开始清算责任更是要撇清自己,保护自己部门/组的兄弟们。
0 请登录后投票
   发表时间:2010-07-20   最后修改:2010-07-20
yimlin 写道
做产品很不容易,从组织结构上看将产品研发团队同项目实施团队分开是比较合理的作法,这是因为:产品需要的功能要求和技术投入,同项目开发的优先级本身是存在冲突的。对于高层领导当然是多、快、好、省,但是你认真观察下,实践中从目标考核上看,项目讲的是快、省,而产品讲的是多、好。

当然,分开后就面临协调问题。
如果项目还可以勉强算利润中心,那产品研发则是成本中心了(针对在本贴中讨论的场景,据说互联网企业的研发算是利润中心,听说而已)。公司内部不同部门的视角不同,就会导致工作上冲突。

针对楼主的情况,产品只能放低身段去支持项目。

1.把产品研发的投入到项目中,项目经理通常不会有意见,因为通常不占他的项目编制项目经理会说这是帮助提升产品)。

但这就直接影响到产品开发进度,产品经理的压力就很大了。
其实在这种情况下,只能熬了,一是靠产品研发人员在项目过程就尽量按产品设计的要求做,多预留些设计;而是产品经理要争取人员的轮换,把投入的研发人员拉回来。

2.在设计上,产品设计上多考虑项目的定制化能力,提供多种层次的定制化能力。

本质上做产品除去技术因素外,更多的是组织因素,产品经理很关键。。。。。。


   这位仁兄对产品和项目的理解非常到位。

   我们之前把产品研发投入到项目当中去过,不过力度比较大,每个项目都有产品研发现场支持,大一点的项目甚至几个研发在现场开发,不过我们的目的是为了让研发走出去,多接触项目,这样对于产品和项目的理解会更加到位和深入,以便于产品的研发,但是这样带来的问题就是产品半年未升级一个版本。
  
   产品研发是二线部门,不直接面对客户,所以压力不是很大,对于质量的关注和产品的扩展性不是那么重视,这就导致了一线人员非常的恼火和痛苦,明明是二线研发引起的问题,最后却由自己承担和收场,所以有效的将压力传递给二线人员,这对于项目和产品的帮助将会非常大。

   至于您提到的第二点,这个建议非常好,客户的需求通常就那么几种,产品有很好的扩展性和定制能力,就容易满足大多数项目的需求了,所以产品化也需要在这方面多下工夫。
0 请登录后投票
   发表时间:2010-07-20   最后修改:2010-07-20
和我现在的情况比较像,我们就是十几杆枪对着十几个项目,有时间了把体会写下。不过我们不包括实施人员,如果加上实施人员应该由二十几杆枪了。现在又分出了开发组,质保组。产品中的功能模块化,以及版本控制很重要,不然会让升级的人心惊胆寒。
客户导向很重要,一个好的需求人员,进行引导客户,可以至少减少30%的需求。
0 请登录后投票
   发表时间:2010-07-21   最后修改:2010-07-21
anry513 写道
和我现在的情况比较像,我们就是十几杆枪对着十几个项目,有时间了把体会写下。不过我们不包括实施人员,如果加上实施人员应该由二十几杆枪了。现在又分出了开发组,质保组。产品中的功能模块化,以及版本控制很重要,不然会让升级的人心惊胆寒。
客户导向很重要,一个好的需求人员,进行引导客户,可以至少减少30%的需求。

  我这里所说的十几杆枪指的是纯研发人员,不包括测试(4位),实施人员(基本是每个项目一个)。有时间写下来,咱们一起讨论讨论,共同进步!
  的确善于控制和引导需求,能极大的节约项目成本,减少返工次数。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics