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

原贴转载：http://www.iteye.com/topic/714269 

 

 

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

 

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

 

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

 

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

 

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

 

架构上的设计：

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

 

 

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

 

下面是有好的回贴

写道

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

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

 

 

写道

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

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

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

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

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

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

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

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

 

 

写道

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。：）