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

  团队就十几个人，开发一个产品，该产品引出了几十个项目，然后就导致了人全扑向项目，经常加班，产品半年没有进展。然后大家需要思索一条出路：那就是产品化，一个产品版本对应多个项目。

 

以下是我多年来的积累，如有异议大家可以讨论，探索出一条可行的出路。本文作为抛砖引玉之用。

 

项目中的问题：

• 项目需求太多，没有人力开发产品。
• 产品很难用，要出项目效果，实施非常耗时。
• 项目催得很紧，明天就要功能上线。
• 各个项目都需要支持，研发成了客服。
• 客户领导要看，下周就要演示。
• BUG太多，项目经理埋怨研发，研发埋怨测试。
• 项目定制化需求过多，一般有报表定制,首页内容定制,界面优化定制,登录界面和客户LOGO定制,工单流程定制。

 

那么需要解决这些问题需要做一些改进：

 

管理上的改进：

• 开发产品，而不是开发项目。这需要项目经理和产品经理顶住项目的压力。
• 优先保证质量，而不是开发新功能，不然项目中问题最多的就是BUG了。最重要的就是程序员需要从源头抑制BUG的出现，减少测试的成本。如果发布产品版本后，反复测试，又反复发版本，这样对时间和信心的消耗非常大。
• 产品功能不易过多，产品主要是解决用户的需求，而不是在功能点的累加。
• 增加易用性，产品使用简单快捷，产品出厂的时候内置标准数据和通用流程，减少实施成本和客服成本。
• 增强用户体验，减少用户的反馈意见，详见“操守俱佳之女子为何隐于市”。
• 统一接口人，由他统一支持各个项目，该接口人需要对产品非常熟悉。
• 削弱项目定制需求，以减少人力都投入到项目，需要定期整理各个项目中的需求，分析出产品功能和项目定制功能，产品功能优先开发。
• 定期发布产品版本，最快1个月项目做一次更新。
• 减少沟通成本，能决定的就不要讨论，需要讨论只涉及相关人。
• 做好需求处理，详见“企业应用中需求处理”
• 团队成员要精，不宜过多，以降低沟通成本，管理成本和培训成本。
• 少用没经过仔细研究的新技术，以减少后期维护的成本。

 

架构上的设计：

• 统一门户: 门户的内容可以定制，解决各种层次的用户关注的角度不一样的问题。
  
• 功能开关: 产品功能可能有的项目中用不到，开着却又影响使用和产品性能，那就建议增加产品功能开关，默认打开，不需要关闭。
  
• 项目功能开关：对于项目中完全定制化需求，需要增加项目功能开关，在产品中配置一个项目ID，产品判断当前项目有此功能，才将功能打开（如每个项目都有客户的LOGO）
  
• 界面换肤：其实界面美观真是仁者见仁智者见智的事情，客户的审美观差异非常大，而且提不出修改意见的客户也会说界面要改改，那就支持产品内部换肤吧。
  
• 菜单定制: 假如项目是按照模块来卖的，而且项目中经常想改变菜单的名称及位置，那就建议增加菜单定制功能，模块和一二级菜单可以随意定制和挂载。
• 程序安装一键化，配置界面化,建议实施的时候配置项尽量少，出场尽量配置好。

 

评论

24 楼 fantasy 2010-10-23  

zhangyz215 写道

说说我们现在的情况，公司一开始是一套C/S结构的产品，客户的二次开发需求很少。前几年花大力气开发了一套B/S下的产品，现在基本成型，但经不住客户的现场使用，每个客户那里都会有这样那样的问题，于是一个产品衍生出N个项目，基本上是一个客户对应一个。客户发现一个bug，在客户版本中更改的同时需要对产品进行更改；客户有些功能性的需求感觉比较通用的，也会加到产品中。于是版本控制开始混乱起来，常常是改了这个版本忘了那个版本。现在是5个人维护四五个项目还有一个产品。
有专门的实施部门，研发这边的需求都是由实施部门反馈过来的。两个部门之间的摩擦也不小。
现在最大的问题就是版本控制非常混乱，每次客户更新都是手工整理更新包。常常会出现客户那边出错，一路排查下来，原来是更新包中少了一条数据库脚本

尽量让一个产品版本对应多个项目版本。对于通用的功能需求，可以使用开关功能或者功能插件的方式来屏蔽项目的差异性。对于项目完全定制的需求，可以采用单独的分支（但尽量少），不然打补丁很痛苦。
脚本问题，我们也遇到过，我们是使用一个单独文件来记录每个版本的升级SQL语句（每个数据库一份），如从某个版本升级到另外一个版本XX表需要增加一个非空字段的SQL脚本。

23 楼 zhangyz215 2010-08-10  

说说我们现在的情况，公司一开始是一套C/S结构的产品，客户的二次开发需求很少。前几年花大力气开发了一套B/S下的产品，现在基本成型，但经不住客户的现场使用，每个客户那里都会有这样那样的问题，于是一个产品衍生出N个项目，基本上是一个客户对应一个。客户发现一个bug，在客户版本中更改的同时需要对产品进行更改；客户有些功能性的需求感觉比较通用的，也会加到产品中。于是版本控制开始混乱起来，常常是改了这个版本忘了那个版本。现在是5个人维护四五个项目还有一个产品。
有专门的实施部门，研发这边的需求都是由实施部门反馈过来的。两个部门之间的摩擦也不小。
现在最大的问题就是版本控制非常混乱，每次客户更新都是手工整理更新包。常常会出现客户那边出错，一路排查下来，原来是更新包中少了一条数据库脚本

22 楼 fantasy 2010-07-23  

其实做好产品化也只是其中一个方面，我觉得团队管理更加重要。
毕竟8人左右的团队能靠感情感化，几十人的团队就必须得靠制度。
团队管理必须制定出良好的制度和流程，才能达到团队经验的积累和团队的效率提高。
整个团队必须统一编码规范，统一技术，统一质量标准和统一管理。

21 楼 anry513 2010-07-21  

fantasy 写道

anry513 写道

和我现在的情况比较像，我们就是十几杆枪对着十几个项目，有时间了把体会写下。不过我们不包括实施人员，如果加上实施人员应该由二十几杆枪了。现在又分出了开发组，质保组。产品中的功能模块化，以及版本控制很重要，不然会让升级的人心惊胆寒。
客户导向很重要，一个好的需求人员，进行引导客户，可以至少减少30%的需求。

  我这里所说的十几杆枪指的是纯研发人员，不包括测试（4位），实施人员（基本是每个项目一个）。有时间写下来，咱们一起讨论讨论，共同进步！
  的确善于控制和引导需求，能极大的节约项目成本，减少返工次数。

那我们的人数和你的差不多啊，我刚刚数了下项目，发觉现在有18个了，不过我们的项目不是十几个一起上，项目都是从07年才陆陆续续上的。现在感觉稳定些了，对有些小项目，部署上去就完了，基本上没有什么需求了。

20 楼 zhhang920 2010-07-21  

好像说的就是AMS啊；

19 楼 fantasy 2010-07-21  

anry513 写道

和我现在的情况比较像，我们就是十几杆枪对着十几个项目，有时间了把体会写下。不过我们不包括实施人员，如果加上实施人员应该由二十几杆枪了。现在又分出了开发组，质保组。产品中的功能模块化，以及版本控制很重要，不然会让升级的人心惊胆寒。
客户导向很重要，一个好的需求人员，进行引导客户，可以至少减少30%的需求。

  我这里所说的十几杆枪指的是纯研发人员，不包括测试（4位），实施人员（基本是每个项目一个）。有时间写下来，咱们一起讨论讨论，共同进步！
  的确善于控制和引导需求，能极大的节约项目成本，减少返工次数。

18 楼 anry513 2010-07-20  

和我现在的情况比较像，我们就是十几杆枪对着十几个项目，有时间了把体会写下。不过我们不包括实施人员，如果加上实施人员应该由二十几杆枪了。现在又分出了开发组，质保组。产品中的功能模块化，以及版本控制很重要，不然会让升级的人心惊胆寒。
客户导向很重要，一个好的需求人员，进行引导客户，可以至少减少30%的需求。

17 楼 fantasy 2010-07-20  

yimlin 写道

做产品很不容易，从组织结构上看将产品研发团队同项目实施团队分开是比较合理的作法，这是因为：产品需要的功能要求和技术投入，同项目开发的优先级本身是存在冲突的。对于高层领导当然是多、快、好、省，但是你认真观察下，实践中从目标考核上看，项目讲的是快、省，而产品讲的是多、好。

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

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

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

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

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

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

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

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

   至于您提到的第二点，这个建议非常好，客户的需求通常就那么几种，产品有很好的扩展性和定制能力，就容易满足大多数项目的需求了，所以产品化也需要在这方面多下工夫。

16 楼 yimlin 2010-07-20  

jiangduxi 写道

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

道理是很明白，但就是难以实践，不同部门面临的考核压力不同，工作时的目标就不尽相同，一旦出问题开始清算责任更是要撇清自己，保护自己部门/组的兄弟们。

15 楼 yimlin 2010-07-20  

做产品很不容易，从组织结构上看将产品研发团队同项目实施团队分开是比较合理的作法，这是因为：产品需要的功能要求和技术投入，同项目开发的优先级本身是存在冲突的。对于高层领导当然是多、快、好、省，但是你认真观察下，实践中从目标考核上看，项目讲的是快、省，而产品讲的是多、好。

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

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

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

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

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

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

14 楼 fantasy 2010-07-20  

jiangduxi 写道

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

您说到的团队的力量这点也很重要，如何将团队形成斯巴达克方阵，这必须好好研究如何带队伍。
1：如何形成优秀的团队。
    这需要很健全的员工培养计划（就像斯巴达人的教育，从婴儿抓起，团队也必须从面试抓起，一粒老鼠屎打坏一窝粥，我们是有惨痛经历的）
2：如何形成团队的文化，
    如知识和经验的共享，具体表现形式为结对编程，培训和师傅带徒弟。乐于沟通，如吃饭会议，队长中午请大家吃饭，顺便聊聊工作，生活和感情（说实话大家都会被这些问题困扰）。激励队员，如当面表扬，邮件表扬，奖励图书，让其演讲工作所得等。
3：如何形成强大的团队战斗力，使得团队力量最大化的向一点发出。
    这需要角色分工明确，每个角色都有自己的服务目录，专业人干专业事，使工作流程化制度化。如：之前我们的团队总是会搞不清一个文档该是由谁负责编写，而且写完之后质量也不怎么样。
4：如何形成良好的团队环境。
    这取决于队长及每一位员工的修养，每个人的个性和天性不一样，大家必须得摒除自己的特性，以适应团队环境，不能融入团队的人必须得被剔除掉。

13 楼 jiangduxi 2010-07-19  

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

12 楼 fantasy 2010-07-19  

seeckt 写道

要搞产品，最重要的是有产品经理，我自己的体会来说，用项目经理当产品经理是相当的杯具

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

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

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

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


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


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

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

的确如您所说，目前做产品永远是愿景大于实际，项目支持的优先级永远是最高。
目前公司是有产品的，也是在逐渐的基于产品做项目的过程中，进展还不错，因为目前这个阶段项目比较少，有产品经理支援项目并汇总各个项目的需求，研发能静下心来在公司统一将这些需求开发到产品中。
的确需要产品经理这样的职位来统一协调各部门，所以我从研发组长的位置转职到产品经理的职位上。这个职位最大的优点就是没有权利，只能靠能力和权威去协调各个部门，这中间遇到的困难非常多，目前没有把主要精力花在客户研究方面，而是在做做各个项目的支持工作。
也的确需要组织结构是产品开发模式，这样才能自上而下的进行制度变革。

11 楼 seeckt 2010-07-19  

要搞产品，最重要的是有产品经理，我自己的体会来说，用项目经理当产品经理是相当的杯具

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

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

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

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


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


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

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

10 楼 fantasy 2010-07-19  

zgsheng 写道

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

非常感谢您的建议，辛苦了！

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

9 楼 rocwon 2010-07-19  

第一，版本方面，通用的/可产品化的和定制的分开维护
第二，将开发和实施分开

8 楼 poson 2010-07-18  

感觉主要不是技术上面的问题，而是管理上的问题。
需求太多，做不过来。
开发成了客服。

这说明还没有把项目需求的优先级排出来。每次只能主攻几个项目，不能做太多。不然只有失败的份了。
建议每次发布一个可用的版本。同时不断的迭代。

7 楼 xyz20003 2010-07-18  

fantasy 写道

  写了这么多，辛苦了，您说的正是我的心声，项目是由销售和售前带来的，和产品关系不是很大，说实话产品并不是做的很成熟，拉出去单干不现实。其实我觉得单靠加人是不能解决问题的，而应该靠管理来优化内部流程。
  这样的状况持续了几个月，用户一般都是下半年发现自己有有点闲钱，就想做点项目来冲业绩，所以都要求年末完成，可想而知在这种状况下，我们没有人力投向产品的研发。对产品研发人员的造成的影响非常大，本来按照计划开发产品的，现在却要支援项目，修改BUG和经常加班和为项目开发功能（因为我们原则上不提倡加班，所以加班的时间是承受范围之内的，但是有的组也有因加班太狠流失大量的组员），待到花开之时，我们才开始有时间将做到项目里的功能，尽量产品化到产品版本中，但是有时因为项目太紧，在项目中做的功能非常的不健全，这导致patch到产品版本的时候，需要重新设计和开发，浪费了人力。的确这样是很影响组员的士气，修改一个BUG需要Patch到好几个分支，反复解决重复的问题，杂事多很难静下心来按照计划做事。
  写了这么多也是希望我们遇到的问题和一些解决思路供大家借鉴，希望大家不要重蹈覆辙，或者是有更好的办法来解决这些问题。

看来我之前有一个很严重的误解。所以在继续讨论之前还是先澄清一下这个问题“项目和产品关系不大。”有两种理解方式：
1.项目是由销售市场拉来的，靠的是关系，不是靠产品的竞争力。但是项目和产品之间的功能很类似，或者有重叠。所以不至于每个项目都是重头开发。
2.项目和产品没有一点儿关系，比如我做的产品是个oa办公自动化，结果销售找来的产品都是网站。

从后面的描述来看，因为项目的feature可以merge到trunk里，修改的bug又可以patch多个branches，所以项目和产品在功能上还是有重叠的，至少有功能可以共用。（如果是第二种情况就太可怕了。阿弥陀佛。）

即便如此，从你的说话口气，还是能听出来有点儿“垂头丧气”的意味，你自己都感觉项目卖钱不是因为产品做的好，而是客户钱多了烧的，然后销售有关系才拉到的。这样发展下去形势不太好，要想办法扭转局势。

下面进入正题，我以上面提到的第一种情况作为基础，如果你们遇到的情况是第二种，建议直接放弃产品，老老实实做项目吧。

第一问：为啥要做产品？这个想法是谁提出来的？提出这个想法的依据是什么？
我觉得这个问题最重要，搞清楚上意很重要。到底上面说：“做产品”是确有其事，还是心血来潮。如果是玩真的，那就简单多了，虽然半路会遇到很多问题，但至少大方向不会变，我们永远都是在曲折前进，总有一天有机会到达终点，你上面提到的这些出路也有可能落实。
不过，一般正常的老板都很滑，没有做技术的这么死硬，他们可以游走在各个客户之间，面对各种情况，所以自然要求属下拥有类似的素质。这样就会麻烦一点儿，你只要见机行事，尽力周旋了。
要是公司里的结构复杂一点儿，产品的想法是某总提出来的，这样就稍微简单一点儿，可是也要建立在某总的周旋能力够强，否则你就是抱错了大腿。这种情况其实比较适合技术人员，老老实实干活，多出业绩，尽快提高本派系的实力，有啥需要的，都可以提上去，让头目去为你们争取。

第二问：产品的盈利周期有多久？产品的盈利模型是啥？
3 milestone, 1 alpha, 1 beta, 1 rc, 1 release。对于1.0说，这种进度已经算是很快的了。3 milestone做技术和需求调研，1 alpha功能评审，1 beta测试，1 rc验收，1 release发布。最后1.0玩具版正式发布。：）请注意，这个版本时用不了的，只能作为业务人员去给客户做演示，用户实际用一下就会露馅。
下一步，1.0能发展到多稳定，多完善，就要看实际实际业务的历练了。从这时候开始也算是产品的高速发展期，因为客户一旦用起来就会需求不断。一边解决客户，一边完善产品架构。用几年时间把产品升级几个版本，然后就会越来越轻松，遇到的问题开始不断重复，没有新意，旧有架构上变得没那么灵活轻巧，然后剩下的人就开始研究怎么进行大版本升级，甚至重新搞一套好玩的。
反观这个过程，1.0之前完全是投入，没有盈利。1.0发布后，所有人都迫不及待的把产品投入使用，结果发现效果没有预想的那么好，开始进行修改，扩充，进一步提高产品的稳定性和灵活性。这一阶段是个难关，挺过去以后钱就进来了，然后想办法保持上升势头，随着产品的日趋完善，收益却是受着真实市场所作为，可能在一段时间内可以达到一个最大值。再以后就是如何挖掘新市场，在原有基础上进行增值了。俺没有经验，没法继续说下一去了。

写完以后，发现上面这些纯属自己在做梦，低头看看自己，估计还处于第一个milestone之前，同时接两个项目都有困难，更别提几十个项目了。不过没吃过猪肉也见过猪跑，对于你们现在遇到的这些问题，我如果可以坚持下去，以后也肯定会遇到，到时候我可能会这样解决：
1.能力不足的时候，就少接点儿项目。（无可奈何）
2.产品一开始不好用很正常，为了生存和发展，前几个客户说什么，我们就听什么，熬过黑夜就是黎明。（这点对打工的人来说不管用）
3.项目催得很紧的时候，就通过商务削减功能，或者延后交付。（你和客户接触多了，就会发现他们不会把乙方往死里逼，大多都是乙方老板自己把自己人往死里逼。）
4.各个项目都需要支持的时候，首先要想支持是否可以收费，如果不能收费，就要整理用户手册，视频教程，部署阶段的培训，整理公用的FAQ，尽量不要把研发的电话直接留给客户。考虑实习生这类成本低的支持方式。
5.“客户领导要看，下周就要演示。”这个也是问题吗？平常注意积累ppt就ok了。
6.bug多，各部门互相埋怨。很多公司就留着不管，让内部自己斗争去，非要管管的话，可以开誓师大会，各自立下军令状，最后其实还是保证生命不止，内斗不息。
7.定制化是收益的来源，只是搞研发的被抓去做定制多了肯定会心里不爽，有钱以后赶快招人专门做这部分工作吧。

说着说着就变成逐点分析了，可以肯定的这些解决方法不可能全部有效，你列举的问题也不是产品化公司才会遇到的。做产品看重的还是长期效益，只要选择的方向不是错的厉害，坚持几年就可能看到曙光。中间遇到的这些问题总可以解决。最后祝Good Luck。：）

6 楼 王者之剑 2010-07-18  

赚一把就死，搞产品的没有股东？

我觉得可以将产品部门和实施部门分开。

实施部门可以分成几个组，每个组负责几个项目。

5 楼 fantasy 2010-07-18  

xyz20003 写道

这个事情要分成几个方面讲。

首先，十几个人同时支撑几十个项目，这个状态是不太正常的，尤其是在同时对几十个项目进行开发，而不是维护的时候（如果我没有理解错的话）

其次，在产品不成熟的情况下，如果不通过实际项目，那么做出的产品可能就是个中看不中用的玩具，而且还只能开发者自己玩。无论是先做项目，渐渐抽离相似的部分形成产品，还是从以产品的方向开始从头设计，都要经历一段实际项目检验，不断根据实际情况对产品进行调整的过程。

这个过程，个人认为，当然项目越大对产品的益处越大，但是不应该在产品未成形前就急于求成。因为我觉得，既然是做产品，那么我们的最大盈利目标应该定在产品成熟后，而不是在产品刚成雏形时，就突然加大项目压力，这种做法会给人一种杀鸡取卵的感觉。

但是，说起来也很矛盾，我又是支持产品线的同志直接加入项目的，因为通过自己的亲身经验，我相信只有让做产品的人直接面对客户，感受客户的现实需求，才能将客户最想要的功能以最快速度添加到产品的功能列表里。如果让这些家伙一直做产品，很容易出现闭门造车，做的东西越来越理论性，最终叫好不叫座的窘境。从这点来说，项目组的同志交换穿插到产品组也能起到项目与产品互通的效果。结果这些操作是否能够起到预期效果，完全要看领导的魅力，是否能让合适的人在合适的时间去做合适的事情，维持产品线和项目组生机勃勃，蒸蒸日上。

十几个人支持几十个项目，从老板来看，真赚钱。从底下人来说，心里有底，东西还没做完，就可以卖出去，市场大大的。首先恭喜你们一下，争得了一个开门红。只是以后怎么继续发展就变成了一个更大的问题，公司会想办法榨取最大的价值，如果最上层不是以追求产品的完美做为自己的人生目标，那就总会有一定的危险：“上层可能会疏于产品研发，而转为将更多精力投入项目。”作为一个非“业务市场人员”，怎么才能在技术层面说服上层继续在研发产品上继续投入呢？如果能解决这个问题，以后技术人员的日子就会越来越好过了。

最后，想请教一下，你们这种十几个人支持几十个项目的情况持续多久了，预期还可能持续多久，对原本的产品研发计划造成了多大影响（其实我的意思是做项目造成产品的发布延期了多少），对产品研发人员是否造成了影响（比如加班是否严重，是否因为做项目的项目太多影响了人员的士气）。如果不方便公开讲，也希望可以通过站内短信，或者email回答一下（我的email是[e-mail]），这对我以后的规划会是一个很好的借鉴。多谢。

突然看到主贴中多了一些东西“项目经常加班，产品半年没有进展”。恐怕老板已经吃到了甜头，不打算做冤大头继续往产品里投入，现在项目这么多，只要让人不断加班就可以赚钱了。这种情况下，技术人员翻身的机会有点儿小，就算你想到更多途径，上层不支持你也是白费力气。如果负责产品的老大骨头够硬，就把产品拉出去自己干吧，但是风险很高哟。：）

  写了这么多，辛苦了，您说的正是我的心声，项目是由销售和售前带来的，和产品关系不是很大，说实话产品并不是做的很成熟，拉出去单干不现实。其实我觉得单靠加人是不能解决问题的，而应该靠管理来优化内部流程。
  这样的状况持续了几个月，用户一般都是下半年发现自己有有点闲钱，就想做点项目来冲业绩，所以都要求年末完成，可想而知在这种状况下，我们没有人力投向产品的研发。对产品研发人员的造成的影响非常大，本来按照计划开发产品的，现在却要支援项目，修改BUG和经常加班和为项目开发功能（因为我们原则上不提倡加班，所以加班的时间是承受范围之内的，但是有的组也有因加班太狠流失大量的组员），待到花开之时，我们才开始有时间将做到项目里的功能，尽量产品化到产品版本中，但是有时因为项目太紧，在项目中做的功能非常的不健全，这导致patch到产品版本的时候，需要重新设计和开发，浪费了人力。的确这样是很影响组员的士气，修改一个BUG需要Patch到好几个分支，反复解决重复的问题，杂事多很难静下心来按照计划做事。
  写了这么多也是希望我们遇到的问题和一些解决思路供大家借鉴，希望大家不要重蹈覆辙，或者是有更好的办法来解决这些问题。