《产品研发过程实践》（8）技术分析

作者:asky 日期:2007-04-29

字体大小: 小中大

技术分析，是为了克服一些产品研发过程中，所必然会出现的一些明显的技术风险。一般来说，我们都会在产品研发前期启动一个Prestudy的过程（看具体产品或者项目大小，时间从1-2周到3个月不等）。我喜欢把这个阶段看成一个让大家充分犯错的过程。这个过程的目标是分析出来产品或者项目的重要技术风险，并根据这些技术风险进行预研。比如，我们常规的一般项目，是先做软件，在软件集成测试基本完成以后，然后展开性能测试和稳定性测试，但是如果这个项目是允许Delay的，这种做法问题并不大，大不了就是一个Delay而已。但是，如果这个产品这方面风险很大，那么就值得为此去做一些事情了。免得最后发现性能或者稳定性存在大量问题，不好处理，很难受的。

比如，我们曾经做过一个系统，主要的难度在于这个系统将会有至少2000万条主数据库容量（设计容量达到2个亿），这个系统访问量基本上预计为每年2-10亿次访问（也就是说并发访问量并不是特别恐怖，至少和硬件设备比起来，这种访问量还是没有让我过多的担心），但是我一直担心的是，这个系统我非常倾向于采用星形的数据库设计，我担心由于辅助的几个表出现大数据量的时候，查询速度将一下子全部下来，并且导致访问极其缓慢。而且这个系统主表数据不能定期导出，只能存放在其中（虽然数据增长量不大）。那么很明显的，如果我们系统到最后才发现性能根本不行，这个项目就基本全部失败了。在常规的功能性测试中，除了严格的性能和重载情况下的压力测试，其他的时候的数据量一直都不大。那么就有必要进行预研，使用测试数据，然后调节各个参数（比如索引的位置，数据库参数优化等等），并且模拟一个实际环境，来对每个版本进行一定测试，来保证某一个版本叠加上去以后，性能多少还能接受。

其实有时候，需要进行技术分析的，不仅仅是技术难点，还有一些其他的原因，比如做Workflow的人都知道WFMC，这是一个相对来说比较稳定的标准了，你基于这个标准进行研发，多少是让人放心的；但是，在有的领域，标准化上的一些工作并不完整，还是处于几个厂商的私有标准情况下，那么你是否敢于自己独立做一个，还是跟着一个厂商走，或者干脆认为这个市场太不稳定了，不值得现在就干（当然了，等标准出来了，你是否还有机会就很值得讨论了）。等等都是需要看的。

还有的情况是，由于要进行大型产品的研发，所以使用很长的时间，进行竞争对手产品技术框架和一些关键点技术分析，来猜测他们采用什么体系框架，采用什么样的数据格式等等，对于将来少走弯路还是很值得的。可以说，如果是这种情况下，你今天投入下去的1块钱，将在明天因为少犯一个错误而节省5块钱甚至更多。比如某一个大型中间件的研发初期，投入了10-20人，进行了为期3个多月的类似公司，效果还是比较明显的，至少那些哥们显得很专业。一个一个俨然是这个行业的大牛，恐怕将来这些哥们在这个领域，会吓唬住很多人的，呵呵。

实际上，在严格的立项过程中，以上这些因素都将是需要分析的，但是这种立项过程为时还是比较长的。但是，我赞成这一种做法：我们有时候，在最需要谨慎的地方太放松，而在与前者比不那么重要的地方上，又过于抓紧了。如果一个项目值得做，那么请说明他为什么值得做，值得公司投入几百万甚至上千万去做；如果不值得做，即使浪费2-3个人，3个月的时间，证明出来这个产品不值得投入，那么也还是值得的。至少他避免了我们将来更多的投入（想想有多少草率的决定，快速的动作，使得我们在后期包袱重重的？项目是需要尽快确认去做，但是不代表着，这个过程就可以省略）。让开发人员的工作至少变得更有价值一些吧！

我曾经对一年的主要工作进行了一次反思，有一年工作中，大家非常疲惫，加班非常多，但是过了这一年以后，我发现事实上，我们至少有30%左右的事情证明是没有价值的（或者价值不大）。我承认，必然有一些错误是难免的，但是如果情况如此，如果我们能够把这个数字降低到20%，我们的工程师就不用那么拼命加班了。所以，我一直认为，加班不是一个好的状态；最适合的软件行业工作强度是85%，剩下的15%由开发人员自由支配。这样对于团队成员的成长是相对比较有利的，同时，对于公司来说，也是一个利好的消息。我曾经看见过很多团队，很吃力地在做一些很复杂的底层开发，但是这些实际上并不需要自己开发，是有Open Source的软件可以使用，或者业界中已经有相对比较成熟的解决方案的。那15%的时间，就是让团队成员在这方面得到成长的。当然，团队学习气氛还是需要建立起来的，不然，这些时间很可能被浪费了。但是，即使是浪费，我也愿意支出这15%的时间，因为这将使得团队成员可以有一定时间去追求一下设计和代码的完美，很多事情，之所以在后面返工，是因为团队成员被压力压得过于厉害，所以在很长的时间中，不断地采用一种得过且过的解决方案，打补丁地解决问题。欲速则不达，这一点请记住！这方面，给我印象最为深刻的是：在一个同仁的季度考核表上，给自己的工作强度打上了85%，接着写了一句让我记到现在的话：“我最喜欢的工作强度就是现在的工作强度”。说到这一点，有一个现象让我非常感兴趣，在联想研究院，一直有一个做法是，20%的时间由具体人员自己分配，上级对此时间不加任何干涉，我亲眼看见一个毕业2-3年的工程师，从一个刚刚毕业的学生，成长成为一个具有良好设计经验的工程师（他的设计，即使让当时已经2倍于他工作时间的我都感觉很佩服）。这一点一直让我很惊讶，在一个良好的学习气氛的氛围中，一个工程师可以得到如此快速的成长。因为我也同样亲眼看见，一些具有7-8年工作经验的工程师，在设计理念和设计思路上极度混乱，知识结构严重老化；这对於公司来说，难道不是一场灾难吗？

曾国藩曾经讲过一句话，原文如何，我记不得了，大致意思是“世界上的大事情，失败的根源往往因为快；小事情失败的根源往往因为慢”。这句话还是很值得琢磨的。当然，什么是大事情，什么是小事情，还得大家自己判断啊。

同时，经过这样的技术分析，使得你的团队可以搭建出来一个简单的Demo，这个Demo将包含一些重要的，你希望了解的东西。这种尝试的做法，将使得团队可以尽早犯错，而不是到最后才发现错误已经很深地埋了下来。而且，这个Demo我赞成抛弃，我一直认同一点：你先期开发的东西，在你后期看来，一定存在很多问题；因为我们永远无法设计得如此完美，以至于我们可以完全依赖于这些设计；但是，在这种Demo过程，由于我们的投入是有限的，而且他是一种基于尝试的做法来做得，所以，如果可能，这种半成品性质的东西，就不必保留了。通过各种逐步的改动设计或者重构，付出的代价也许更大，毕竟这里暴露出来的问题，往往是结构性的或者架构性的。而且，你的团队重新构造到这个Demo高度的产品，速度将会很快，所以，就不必太留恋了。舍弃一些东西有时候是必须的。