在进行项目管理的过程中，特别是软件行业的项目管理的过程中，我们要切记一点：你首先管理的是人，而不是过程，更不是文档，企图使用管理文档的方式来管理、监控整个项目，就象仅仅站在1000公里以外，指挥进攻华沙的图哈切夫斯基一样，遭到指挥生涯中，最严重的失败。从理论上来说，你的确可以如此做，但是实际上，你将面临严重的危机。

另外，我们企图用传统的工程学（类似机械、土木工程）的方式，来定义整个软件过程，这一点，至少从现在我的观点来看，是有点过于乐观了。我们在从这些传统工程学行业中吸取经验和教训的同时，最好也能够看见他们之间的不同，不然，也许我们将一步从成功走向失败。

至少在现在，还不是流程决定着软件开发的结果，而是开发软件的人，至少从我在项目中看见的绝大多数错误，来自于我们的愚蠢的设计，比愚蠢的管理更致命（当然不是说，良好的管理就不需要，但是，的确，就我个人的观点来看，愚蠢的设计给项目带来的损失远远超过愚蠢的管理）。我们要记住一点，流程为什么而存在？流程本身并不是目的，流程仅仅是更好地达到目的的一个手段，流程可以使得良好的经验迅速固化，并且在推广展开；而且流程的操作性很强，相对于很多模糊的概念来说，他们至少更容易进行管理。但是，无论采用什么流程，我们的目的是客户所满意的结果。请随时记住这一点。不要让流程成为你迈向成功的绊脚石。

对于项目管理来说，人是最重要的，至少有三层意思：

1. 不管你开发什么软件，不管你用什么流程（不管是至少我看来多少有点胡扯味道的软件工厂也好，还是很谦虚同时也很自豪地宣称自己是软件作坊的也好），实际在为客户提供价值的是研发人员所提供的产品，这些首先是人所作出来的；

2. 你的软件，是为人来服务的，如果你不把主要注意力放在“客户...

查看更多...

OK，需求已经出现了，当然我们需要面临就是，构造这个软件了。

在这里，恐怕开发人员更熟悉以下的一些过程，比如版本控制、比如设计过程、编码过程等等，这个阶段也往往是一个研发周期中，最繁忙的一段时间，可能频繁地发生加班。但是，同时，这也是抱怨最多的一个阶段，我们抱怨流程不够清晰，我们抱怨配合出现问题，我们抱怨设计出现纰漏，我们抱怨测试不够完善，我们抱怨……，总之，士气似乎在不断下降过程中，我们一直绷紧着神经。

但是，这个阶段，也是很有成就感的一个时间，看着系统在被一天一天地构建出来，这多少是让人非常有成就感的感觉，虽然那不是最有成就感的时候。

在这个将会占据很多内容的章节中，我希望首先介绍一下我的思路，我的思路是：

首先，我们将关注人，分析在一个项目组构成中，各个角色承担的责任；我们将希望在这样一个团队中，我们都能互相往前，或者往后走半步，原因仅仅是我们都不够优秀，向前或者向后走半步，将使得我们可以尽早发现一些问题，尽早发现一些各自职责之间的灰色地带。从而使得我们可以少犯一些错误。

其次，我们将简述一下整个流程，当然，这在绝大多数情况下，都是大同小异的，说大同，是因为几乎每一个公司都是如此要求的，说小异，是因为大家具体的操作方法上，可能还是存在一些至关重要的不同，往往正是因为这些不同，导致了结果完全不同；

再次，我们将把我们的注意力，集中在几个我们很关注的过程中，在这些过程中，我们将略微详细讨论一下，我曾经如何做过，效果是什么？

最后，我们会就几个很多人很关心，而且非常非常多次问起的一些问题，针对这些问题，我希望能够给出一个我的观点。

当然，正如我很多次所说过的，项目经理是一个概念十分庞大的名词，三峡工程也可以称之为项目...

查看更多...

在这里，之所以把这章单独拉出来，是因为需求文档，一直是我们的一个大问题。过于详细的，而且缺乏分层和索引的文档，引起的是更新不及时，而且耗费大量成本。成本一点我们多少还能够接受，但是千万不要低估他的成本，认为这些文档可以随手就改过来，正式自己操作的人，就会明白，这远远不是随手改过来的问题，当然，一个文档如果结构相对合理，能够组成立体的层面，那么修改还相对简单一些，如果一锤子到底，全部是扁平的User Case的模式，那么很不幸，如果某一个地方发生一点全局性的变动（比如增加了一个在我们系统中，用户必须首先登录，不然不能使用），那么分配到每个User Case中，这将是非常庞大的工作量。对此千万要小心，文档不仅仅是写出来就完事的，将来还是要维护和更新的。另外一个极限是，几乎没有需求文档，几乎所有的需求都是简简单单一句话，比如“用户的数据需要定期备份”这一点，就存在大量的分支，是系统自动备份？还是定期提示用户自己备份？最近一个备份会覆盖前面一个备份结果吗？这些备份数据，会自动清理吗？备份的数据，用户能够进行什么操作？等等，如果这些问题都是一无所知，就直接进行开发，无异于把自己的命运完全寄托在幸运上（而且是非凡的幸运），因为这意味着，所有这些疑问，如果被提出来，还算好；不然，这些将完全依赖于大家自己的设想，而要保证大家的设想是完整的的概念集中一部分，那么这多少可以称之为奢望了。

针对上面这两种情况，都不是我们想要的，在其中，我们希望有个平衡点。

在这里，我首先要说的一点，是我对于文档的看法；无论过程多么重要，但是过程的保证是为了目标的保证，如果一件事情对于客户的直接价值不大，我们就需要极其小心地对待这件事情，因为我们要记住的是目标。那么做为重要的沟通方式和知识固化的一种做法的文档，我们应该如何看待呢？

首先需要明确的一点是：...

查看更多...

曾经参加过MS的一次笔试（哈哈，一个做得很烂的笔试，居然为我赢得了1个机会，呵呵，看来天下比我笨的人还比较多哦。哈哈，说一个比较自豪的哦，显摆一把，曾经参加过一个公司的IQ测试，结果发现是他们历史上参加这个测试的人员中，得分非常高的一个，于是我突然有一种高兴的感觉，呵呵，看来人都是有点虚荣啊。包括在这里写这件事，好像也挺孩子气的），题目是：“如果给你叁个月，你将如何设计一个资源管理器的Shell”。看到这个题目，的确让我很挠头，看来我们就如同穷困惯的孩子，在一下子得到了一大笔财产的时候，几乎不知所措了。

不说别人如何做的了，对于我们来说，一般的做法是这样的。下面的东西也许太简单了，但是我们实际就是如此做，也只能理解到这里了。

首先，我们会企图先花一些时间，先列出几个典型用户场景出来；比如举一个例子说：当用户手机地址本和服务器的地址本进行了无线同步以后，如果同步成功，将自动给用户的地址本做一个镜象，使得将来用户能够从这个镜象中取得自己某一个时间段的完整的地址本。OK，我们想像一下，我们是客户（当然，如果有现成的客户在眼前，而且这是他以前日常的一个工作，就不要想像了，问问别人就是了，胡思乱想没有什么好处），我们会如何使用这个功能。“我掏出手机(这一点一定要写，不要只是写系统的行为)à进行同步à同步成功à收到一条短信，告诉我同步成功，并且地址本已经保存”。很简单，不是吗？

OK，这时候，我们会拿起准备的一些基本的原则（比如你的系统中有多少概念？比如对于Word来说，保存就是一个概念），看看用户在这个操作过程中，是否和原来的概念有冲突？如果存在冲突概念，请想出合乎逻辑的处理方式。比如，在这里例子中，由于在网站上，我们也提供了用户手工备份地址本镜象的操作，那么这个自动操作，是否会覆盖用户手工的地址本镜象呢？如果是一个镜象区，...

查看更多...

一般在立项的过程中，我们会提交一分需求的文档，简略地说明这个软件会干什么，具备什么功能，但是这时候，还是比较粗略的。事实上，你也不可能做得如此详尽，因为那时候，你也没有这个精力，也没有那个必要。

正如事情需要一件一件来做一样，这时候，一些设计角色，框架角色，以及一些测试主管，应该快要进入团队了。你总不希望仅仅是几页需求列表，来迎接他们吧？OK，我们要干一些实实在在的事情了。

首先，对于产品经理来说，你一定已经比较过相关的产品的优势和劣势了吧（如果到这个时候，你对于竞争对手的产品或者类似产品还是模模糊糊的，那你就有点失职了），下面你就该动用你的脑子，考虑清楚，我们产品具体该是什么样子的了。

但是要防止两个错误：

首先，不要只以为是，不要认为你那么强大，可以在一朝一夕赶上竞争对手，你要明白一些现实世界中的基本准则；

其次，你是在替客户设计一种软件，而不是为你自己设计一种软件，所以不要告诉我觉得这个功能多么多么酷，多么多么实用，我们需要知道的是：谁用？如何用？对于我们价值何在？为什么不能没有它？在这一点上，我很赞同Yahoo的产品需求规划过程，当然，他们整个产品功能规划过程比我看见过的绝大多数公司都做得好得多，他们会说出这些功能到底谁来使用，为什么我们需要添加这个功能（这一点尤其重要，谁提出谁举证，如果不能举证，就不应该做；而不是由其他人说这个功能无用。因为相对来说，说某个功能无用是很困难的，即使再没有用的东西，我们总是能够找出他的一点点用处。），这个功能会为我们带来什么（再有用的功能，用户不买单，还是没有用）。对于产品来说，一个基本的想法就是能够不做的，千万不要做（顺便插一句，犯上“任务饥渴症”的人员，基本上都是以累死自己，累死别人而收场的），一个小而强壮的产品给客户带来的价值远...

查看更多...

以上，我们花了不少篇幅，说了如何判断一个产品是否应该做，并且在立项之前，应该考虑清楚的几个事情，其实简单地来说，无非就是：谁是你的客户？我们是否值得并且有能力去做这件事情？我们是否可能成功？我们的产品是什么样子的？仅此而已。

做到这些都很简单，不是吗？但是以下一些情况使得我们在实际中做到这些并不容易：

1. 我是负责项目或者产品的人员，不是市场分析或者预算控制者；记住，如果你这么想，那么你还不是一个合格的产品经理，还不是一个合格的项目经理；去尝试着这样做！

2. 我们的时间太紧了，我们需要尽快开始，不然我们就死定了；很诱人的理由，不是吗？但是记住一点：你现在还没有开始，在这个阶段，我们需要讨论的是是否做的问题，而不是解决如何做的问题；就象你没有把握之前，是不会投资某一个领域的，因为你知道风险太大了，这简直在浪费钱；同样的，如果我们不清楚我们的状态，就直接进入，同样也会埋下失败的种子。

3. 从结论反推起因：我这里不谈论政治，如果你仅仅是为了证明某一件事情值得一做，那么你可以放心，我们总是能够找到证据的；商界上的例子太多了，就象历史中的各种例子，只要你想，你总是能够找到证明你的观点的论点；排除或者隐瞒掉掉最大的风险点。我们就事论事来说，不要考虑你是否必须做这件事情，而是把自己看成一个评估者，你如何评估这个产品？当然，这一点，无论对于高层管理者还是底层管理者，都是一个难以抵御的诱惑。所以，我就是这么学究地一说，你就也是那么恍恍惚惚地一听就是了。但是，如果你处于这种状态，任何方法都是没有用的。

另外，我需要指出的一点是：如果你已经有了相当的经验，请相信你的直觉。直觉这种东西很奇怪，我们会直觉地感受到某些事情存在部分问题，或者存在...

查看更多...

所谓产品形态，内涵很多。但是我一向很简单地理解成为一句话；你可以在没有看见集成起来的软件的时候，清楚地知道这个产品是谁来使用（是最终使用这个系统的人，还是第三方开发者？）？他将如何使用（他是否可以打开这个程序？这个产品是否允许第三方系统通过某些接口的访问，来实现某些特殊的功能）？将在那些方面为客户提供价值。你的脑海中最好能构成一幅一幅的图画，模拟这个用户的操作过程。并且设想出来他们使用你这个产品过程中，所会碰到的一些典型场景。

“我们要做一个进销存系统”，然后脑子里面一团混乱，就带领团队开始动工，这简直是一种扯淡的做法。是一种严重不负责任的做法。

记住这一点，虽然做为开发人员来说，我们能够容忍失误，但是我们无法忍受一次又一次的愚蠢！不要让自己犯愚蠢的错误！请各位项目经理和产品经理把这一点牢牢记在脑海中，碰到问题的时候，第一时间需要考虑的是：是否我又做了什么愚蠢的决定，而不是第一反应是别人执行错误了。这是一个管理者的度量，也是你做为一个管理者将来还能向上发展的一个限度。不改变这一点，你就已经做到了你能力所允许的最高的岗位了。

构思清楚你的产品形态，并且把他传达到整个团队中，是一个好的项目经理和产品经理所必须要做的。

这一点虽然看起来很容易做，但是如果碰到严格的立项审批者，这个问题极其难以回答，当时我们很多人立项的时候，最害怕碰到的两个问题，就是产品形态和3年现金流分析，往往被攻击地很厉害。至于其他分析，就显得很写意了。呵呵，认真对待这一点。

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

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

其实有时候，需要进行技术分析的，不仅仅是技术难点，还有一些其他的原因，比如做Workflow的人都知道W...

查看更多...

在比较严格的立项中，是需要附有相关的3年现金流分析的。首先，需要说明的是，这一个在其他领域使用得很多的立项必备条件，在软件行业中，并不是很多（当然，在融资的时候，这可就是一个大学问了，会有专门的人来做这一块的）。这让人感觉，我们就象一个傻孩子，什么都不看就扑上去做了起来。直到最后，才一拍脑袋：“啊～”。

这一点，在财务分析中，方法比较清晰，无非是各次追加投资，以及现金流回，折算到期末的现金。来衡量项目是否值得做。相似的，更简单的做法是投资回报期的分析（投资将在几年内得到回收）等等。就不详细说了。

具体做法不说了，但是值得说一说的是，倒是，这种分析方法，对于预测人的商业知识要求很高，否则，你能够把现金流估算在一个数量级内，就算不错的了。但是，即使如此，这个方法还是值得去作一下的，因为他将促使你去考虑，你的产品将如何盈利，你的各个层次的投入情况是什么。而且，这对于初级的项目经理（或者产品经理）来说，也可以增加成本概念，让你仔细规划成本投入和产出情况。而且，这些情况将由于此过程，深深印入你脑子里。当这些先决条件发生变化的时候，你能够敏锐地发现，而不至于一味埋在产品里，让一个产品把公司全部拖垮。每过一段时间，你需要做的就是Review一下你的现金流和Mailstone，看看和你原来的现金流估算是否存在很大的偏差，如果存在很大的偏差，务必及时提出来（当然，你执意要拿这个项目来练手，就不要提出来了，一般来说，如果你们公司的老板保持足够的理性的话，这种项目很可能被取消的）。

当然这种做法，会引起一些政治问题，比如初期故意降低成本估算，过高估算现金回流；而在产品过程中，不断提出一点一点的资金和人员需求；使得公司这个项目拥有越来越多的沉没成本；虽然在正常的决策过程中，沉没成本是不应该进行项目是否值得往后做的决策依据的，但是事到临头，...

查看更多...

下一个也是一个非常经典的战略管理模型；通过分析你的竞争对手，上游提供商，下游的分销商，客户等竞争环境来分析你的竞争优势所在。

上面提到的每一点都有将近10多条值得讨论的问题，比如你的上游提供商是否具有可信的向后一体化的能力，这将削弱你的竞争力量；比如你的竞争对手的强度和报复可能性和报复欲望是否足够强烈等等，也是影响你进入一个行业，或者开发一个产品所要考虑的。这些东西，在战略管理中，都有更详细的说明，这里就不一一列举了。如果你照着这个思路走下来的话，你会感觉到一些不同的。

做这种分析，是为了让自己清醒一些，知道你在这个行业中，或者具体化到这个产品上，你是否具备足够的实力来参与竞争。

一般的来说，具有比较高的入门门槛（无论是资金门槛，还是政策门槛），进入障碍比较高，退出障碍比较小，竞争对手比较弱或者市场处于一个快速膨胀的市场之中等等，这是一个典型的好的领域。如果都是相反的，那么要么你能够利用快速进入，通过扩张，在别人没有反应过来以前，取得了市场或者用户的认可，或者短期干一票，拿完就走，否则就算了。这种行业都是比较吃力的。

举两个例子来说明这个问题，为什么出租车行业的利润很高（至少北京市场如此），而从业人员的工资很低，而且工作强度很大？原因很简单，就是进入门槛低，而且退出门槛高。只要有3年驾龄的司机都可以做出租车司机，而很多大型国企的不景气，使得这些人更多了；而退出门槛体现在他们交的保证金上，如果违约，保证金将不得退还。于是大家还在这个领域中搏杀。做为一个额外的话题，如果需要提高出租司机的工资，而且不引起很大的社会不公，至少我们可以从哪些领域着手呢？也许经济强人对这个话题会感到兴趣吧。这里就不谈论了。

第二个例子是和我们更贴近的例子，大家都知道税务行业是政府行业中的一个大户，理由很...

查看更多...

这是任何一本《战略管理》中都会提到的一个分析方式。事实上，我在进行研究生课程班的学习的时候，真正让我感到受益匪浅的，只有这一门课程（至于高级管理学之类，可能是因为我们老师除了读书以外，什么都没有干，所以使得我感觉恶心不已吧，而且整本书对于我真正有用的也就是几页纸而已，其他的属于完全正确的废话）。

SWOT分析，主要是根据目前出现的机会和挑战，结合自己的优势和劣势，来分析这个机会或挑战，意味着什么？举一个现实的例子来说，2003年，做公安行业的时候，主要做公安行业的人口系统；当时正面临着2代证的换证工作。这是一个机会，也是一个挑战；说他是机会，因为公安行业是一个具备比较高入门门槛的行业（需要通过部委的认证，才能向地市一级推进），所以对于处于绝对优势位置的企业来说，对他们发起挑战，机会并不多。但是乘着2代证而引起的全面的人口系统更新上，这将是一个机会。说他是挑战，是因为我们并不是一无所有，在2-3个省的市场占有率达到了90%，那么至少应该保住自己的地位吧。

我们的优势在于，做为一个大型的IT企业，至少在口碑和市场推动力方面的能力，还是比较强大的；弱点是，在这个行业中，对于客户的细节方面的理解远远低于竞争对手。那么在这个环境下，你到底应该如何做呢？

同样的，我们举一个最近的例子，做为运营商的DM系统，使得我们有机会进入DM领域，我们的优势在于在中国落地得比较深（相对于绝大多数参与竞争的国外厂商），但是在DM这一块的积累比较薄弱。从这两点分析来看，直接竞争显然不是一个好的选择（我们不能期待自己聪明到这种程度，用6个月的时间超越别人3-4年的努力吧？但是，很奇怪的一点是：很多人相信。呵呵，这一点有点像我们都喜欢看淝水之战，喜欢看见中国历史上最庞大的军队被几万北府兵打得土崩瓦解，但是忘记了另外一点是，几十倍于这个案例的是：几万...

查看更多...

客户定位：并不是所有的客户都是你需要服务的客户。我的理解是，对于绝大多数公司来说，找到一个足够细分的市场，成功的希望才足够大。当然，你要是细分出来一个“北京市朝阳区麦子店片区18岁以下年龄组75KG以上太极拳高手的帅哥”，我估计也不成呢。那么之所以这么说是因为，我们目前的问题不是细分市场过度，而是细分市场不够，绝大多数产品属于打到哪里算哪里，四面突围，也许闯出去了呢？这种做法的结果就是让研发承担了产品和公司战略上的困境。因为在这种困境下，研发不得不在极大的时间压力下应付很大的改动需求。（这一点，请各位公司老总慎重，有时候，你批评下属的原因也许仅仅是因为你是他的领导而已，错误根源在你！）。

找到合适的使用人群，比如商务用户初期对于功能要求并不多，根源在于稳定、持久的服务（我之所以使用Word做为文档工具，是因为我估计这份文档，在10年以后应该还能打开；再比如我从来不使用不能导出的日记软件，因为如果突然有一天他不能使用了，我将损失我投资在上面的所有时间和心血）；对于年轻一代的“酷”一族来说，重要的是“Woo……”的感觉。这两点是完全不同的。比如我只要能够打电话，绝对不使用Short Message；但是学生一族，一天能够发出60条短信，这一点实在难以让我理解；因为那么多字的输入，发送将浪费我多少时间哪。

OK，用户首先需要会使用你这个系统，并且为此付钱。找到你的合适用户是很困难的，至少比我们想像中难很多。所以，有必要做到一点，当你确定你的用户群以后，请在后面的每个决策或者设计的时候，都记得你的用户群（而不是你！），不要仅仅把他当做是PPT上的一个幌子而已。这一点是无穷多的公司付出了血的代价而得来的，道理大家都知道，但是实际操作的时候，又有多少人能够记住呢？

并且，要记住一点，改换用户群所做的相应改动，成本是很高的，至少...

查看更多...

首先我会做业务环分析，举一个例子来说，我需要做一个小的Brew平台上的手机游戏产品，那么这个业务环是什么呢？手机用户登录到联通的“百宝箱”上，然后找到我们开发的游戏，选择下载到手机上；然后，每个月（或者一次性）的通过联通进行交费；联通收到这笔费用以后，和我们进行分帐处理。于是我们可以看见，其中涉及的角色有三个：手机的游戏玩家；运营商和我们。

OK，我们就可以划一个圆圈，来模拟在现实环境下的现金流向：手机游戏玩家à运营商à我们公司；在这三个点上，各方的态度是什么呢？手机游戏玩家其实对我们的游戏无所谓推动或者不推动，他们完全是被动的，当这个游戏很有名气，或者很对他的胃口，那么他就会选择下载。仅此而已。运营商呢？联通在企图将“百宝箱”做得和移动一样出彩，那么他们对于我们这个游戏，至少是欢迎的，虽然到不了推动的局面，那么如果需要运营商有推动的态度呢？如果这款游戏是一款在线的，商务的，出发点令他们非常感兴趣的（比如能够把短信Push到网络上保存，当然Brew平台没有短信接口，所以至少在目前也就不用费心了），那么他们就会推动这件事前进。至于我们自己，那么不用说了。当然是推动的性质了。于是，我们看见上面这个业务环，基本上是可做的。没有什么太多问题。因为其中没有抵制的人，基本上是合作和推动。而且这个业务环很短，不会出现复杂的关系，比如你原来设想的客户突然之间改变了态度（原因是他们企图在其中上自己的系统等等……）。当然，在实际工作中，我们对以上这个案例是不会费心进行分析的，因为这个业务环很短，而且其中角色的关系不复杂，所以也就不用费心折腾了。

下面举一个例子，是中国移动的DM系统。DM系统是个全网业务，基本完成的功能可以看成这些：能够动态地给各款手机下载各种软件，在用户手机呼叫或者使用WAP、SMS功能的时候，能够清楚地知道用户手机型号，用户手机中所使...

查看更多...

首先先明确一个概念：什么是产品？我想这个问题令很多人很挠头，在我们（特别是高层主管们）需要融资的时候，任何项目都是产品，但是我们故意地忘记了不同客户之间所存在的惊人的需求不同性；在我们（特别是开发人员）需要放弃一个产品的时候，我们故意地不去想想该如何走下一步而只是看见他的不足；至于项目经理和产品经理，口中所说的，和心中所想的，很大可能上存在着不同，而且这一点随着他看了几本新书或者听到几个新观点，都在随时随地地发生着改变，这不是由于项目经理和产品经理具有的惊人的不真诚，而是首先因为他认为这个产品（或者项目）是他的孩子，他对他非常珍惜，其次在现实中，项目或者产品表现出来的越来越多令人烦恼的事情，不断冲击着项目经理的自信心。对此，我不想说太多太多的纯学术性的话（说实在话，这些话多少让我感觉有点隔靴搔痒，感觉什么都对，但是操作性不强）。我记得在2003年的年初，很多同事在一个京郊的度假村里就这个问题讨论了至少2个小时，结论是：是由A团队开发，但是可以由B团队独立实施部署的软件。这个定义当然是不完全的。但是这句话给我的印象非常深刻，他第一次比较可操作地指出了项目和产品的不同。也许有更好的定义。但是我在这两年中，一般都用这个来衡量自己所做的是项目，还是产品。

OK，说明白了产品，在我们进入正题之前，先讲一个小故事。

有一个故事，一个人想要砍树，于是他想到我需要一把斧子，于是开始兴致勃勃地开始制作斧子；然后发现需要铁，然后发现需要炼铁，需要一小块木头做为斧头的柄，同时为了告诉别人，这个斧头是自己的，于是开始在斧头上雕琢一些花纹，开始在木头上刻上自己的名字……最后，当这个哥们干着和砍树八杆子打不到的工作的时候，别人问他，你干什么呢？他回答说：“……”。如果你看见这个人，你会如何想，一定认为他思路涣散，这样的工作一事无成吧。但是我们自己呢？这种错误还少...

查看更多...

序言

这是一本介绍我在8年研发过程中，所积累下来的点点滴滴感触；中国的研发，对于各个层面上的人来说：包括我们最重要的客户、包括高层管理者、包括项目经理、包括项目组中的每一个人、甚至还包括我们的家人、朋友们；都是一种噩梦。特别是在产品研发中，自己辛辛苦苦研发出来的产品，突然发现根本没有人使用。这就象生下了一个怪胎一样令人恶心。

相信每一个踏入软件行业的人，都是充满了幻想，认为这里将是一个高技术的领域，这是一个高薪的行业，这是一个年轻人张扬性格的地方；以上这些从某种层面上来说都是对的；但是我们往往没有看见其他方面：这是一个快速发展的领域，这意味你如同在飞速转动的漩涡中飞奔，如果慢了哪怕一点点，就将成为失败者，同时，你在快速旋转中，还要保持良好的方向感，不然总有一天，你也将因为迷失而出局，这对于一个刚刚进入行业的年轻人来说，是充满了危机的领域；

这是一个大家自认为聪明，但是绝大多数人很幼稚的领域：也许由于发展得太快，我们认为自己很聪明，但是实际上，如同军事上一样，如果我们揭开伤疤的话，将看见很多令人难以置信的愚蠢；当然，愚蠢不仅仅属于军事领域和IT领域；同样也存在在管理领域，当IT和管理合并的时候，这种愚蠢将翻倍（看看现在市面上鼓吹针对高新技术领域的管理书籍还少吗？从类似文化大革命年代口号般《都是你的错》，到吃力不讨好的《基业长青》或《追求卓越》等等，看着这些书中吹捧着一个一个昨日黄花的企业，我简直不知道应该如何看待这些似是而非的观点，这多少有点类似广告学中的那句名言，我们改过来，可以写成：我们知道有一些理论错了，但是问题是我们不知道哪一半错了；到大量的胡扯类型的书，大话，水煮等等都是）；

这是一个所谓高利润的领域，但是实际上，我们的绝大多数公司的利润率甚至比卖大白菜的小贩还低，很多成功者是建立在绝大多...

查看更多...