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

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

 

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

 

项目中的问题：

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

 

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

 

管理上的改进：

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

 

架构上的设计：

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

 

评论

4 楼 xyz20003 2010-07-18  

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

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

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

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

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

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

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

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

3 楼 fantasy 2010-07-17  

李逍遥 写道

产品为head，项目为branch，branch的bug要在head上测试，patch要merge。
branch结束后，其新增功能是否纳入head是架构师(产品经理)的事，但没人管的话，head 就乱了，head乱了，以后的衍生branch无标准可依，更混乱
head 开发设置里程碑，有版本，阶段性release，但branch 是要daily build都通过的。branch衍生自head，有基准版本功能可参考。
时间安排是pm的问题，不可能的时间带来不可靠的交付，这个谁也怪不了谁
研发和实施分开，否则谁也做不好，可以招senior 做support，历练后可转为研发或市场
如果几十个衍生项目都要订制开发，那么是否产品的功能，比如订制功能不足

做产品要积累，光想着赚钱同时开几十个项目，不过是急功近利

您说的很有道理，我们之前基本也是这么做的只是贯彻的不够彻底。branch是要daily build都通过这个我们没做过，公司也在逐渐引入持续集成，但是大家都没有自动化测试的意识。

光想着赚钱同时开几十个项目，这个是因为售前和销售掌控的市场，研发和测试也经常支持他们去做市场开辟支持，而且优先级也很高。不过公司主抓市场这样也很对，产品不经过项目的历练很难得到提高，特别是该产品在整个中国市场都不成熟的环境下。

2 楼 李逍遥 2010-07-17  

产品为head，项目为branch，branch的bug要在head上测试，patch要merge。
branch结束后，其新增功能是否纳入head是架构师(产品经理)的事，但没人管的话，head 就乱了，head乱了，以后的衍生branch无标准可依，更混乱
head 开发设置里程碑，有版本，阶段性release，但branch 是要daily build都通过的。branch衍生自head，有基准版本功能可参考。
时间安排是pm的问题，不可能的时间带来不可靠的交付，这个谁也怪不了谁
研发和实施分开，否则谁也做不好，可以招senior 做support，历练后可转为研发或市场
如果几十个衍生项目都要订制开发，那么是否产品的功能，比如订制功能不足

做产品要积累，光想着赚钱同时开几十个项目，不过是急功近利

1 楼 fantasy 2010-07-16  

还有一个方案是，产品研发和项目研发团队分开，项目研发团队专门负责项目需求研发，为每一个项目建立一个项目版本，而产品研发团队负责产品开发，定期推出一个版本，最为项目版本的基础版本，这样虽然投入的人力大，但是分工明确，需要考虑的事情也会变少。但是会遇到以下问题：
1：这些项目要升级到新版本怎么办？
2：这些项目里的需求如何做到产品里？
3：这些项目同时出现BUG，需要修改N份代码。