做为一个测试人员，首先你需要明确自己的责任何在？我很愿意把测试人员看成是球场上的守门员，虽然我们不是依靠测试人员来取得胜利，但是如果一个差劲的测试团队，将使得项目离开胜利越来越远。你是团队的最后一道防线了。请站好自己的位置！

我一直说，如果我的精力仅仅允许我在项目中做一件事情，那么我做需求工作，如果允许我做2件事情，我做需求和测试，如果允许我做三件事情，我做需求、测试、和框架设计；这是测试在我心目中的地位！

中国明显缺乏优秀的测试人员。我从事软件行业8年以来，接触的测试人员，测试团队换了一波又一波，但是真正让我觉得很放心的测试人员，只有一个，我很高兴，在去年的时间中，为得实找到了一个良好的高级测试工程师，这是我去年中令我最高兴的3件事情之一（一件是我找到了唐明浩和李兆松，唐明浩在测试领域中的优秀素养让我倍加放心，只要她进行的测试的项目，总是令我很放心，以至于评审她的测试点和测试大纲，是一件让我非常愉快的事情；李兆松是一个非常具有前途的工程师，虽然到目前为止，我还没有看见李兆松完全地发挥出来，但是我相信自己的眼光，具有非常清晰思路，做事明了，具有想法的人员，将来必定能够让我眼界大开的，期待中……，一件是我不顾团队中成员的反对，起用刘海琳，正是刘海琳的宽阔思路和严谨的工作作风，使得Syncin能够很顺利地向前推进，而且几乎没有占据我多少精力，刘海琳的将来也是值得期待的啊……一件是通过我们的努力，我们战胜了不少竞争对手，看着自己的产品逐渐发展起来，多少是让人有自豪感的。）但是就是在这样的环境下，我们还是认为测试是项目中最不重要的一环，测试团队的工资普遍低于开发团队，一个人员如果在开发中并不出色，往往会往测试团队中一塞，仿佛那里是流放地。但是正是这种若有若无的测试，正在摧毁着我们工作热情，折磨着我们的客户，我们的团队。

那...

查看更多...

OK，产品开始构造了，这段时间中，一般都是团队士气比较高涨的时期，看着产品逐渐地被构造出来，而且没有很多烦人的事情，这一切都很愉快不是吗？我想绝大多数开发人员都有这样的感触，疯狂地写代码，然后看见程序逐渐地出现，这是一件多少令人愉快，且具有成就感的事情啊。

那么首先，做为一个开发人员，从项目经理的角度出发，希望什么样子的开发工程师，会认为是一个好的开发工程师呢？

首先，我们希望他的思路清晰，这是一句类似于废话的表达，我们希望所有的人思路都很清晰，但是这的确很重要；

其次，我们希望他思维慎密，我们代码的一个大问题是，只考虑正常路径，对于异常路径考虑不足，这在小型应用中，一旦出现问题，很容易进行判别，但是对于大型应用来说，一旦逻辑由于异常而飞掉，那么想要判断出来问题何在就很麻烦了。异常路径的考虑绝不仅仅是Try，然后Catch一把这么简单。记住这一点，在你写程序的时候，多考虑一下，如果这样会发生什么？如果那样会发生什么？如果用户不按照你的设计的流程来做，那么结果是什么（即使你说，程序会出错，也没有问题，但是必须是我们知道他会出错，而不是不清楚结果是什么）？如果I/O出现问题，那么会发生什么情况？等等。

再次，我们希望不管你面对的压力如何，请动动脑子，不要写一些采用一些非常近视，将来必然会发生问题的做法。原则上来说，这些问题应该设计来解决，但是正如我们所知道的，设计一般来说，真的很难做到那么Detail，那么还是有很多问题，会留在开发阶段来解决。我在2001年看过一个程序，这是一个贺卡发送程序，用户点击了贺卡发送后，会生成一个页面，然后把URL发送给接受贺卡的人员邮箱中，开发人员把所有的贺卡生成的页面都放在一个文件夹中，结果时间略微长一些，在那个文件夹下，就生成了上百万的文件，以至于系统维护人员几乎认...

查看更多...

对于一个15-20人左右的开发团队来说，设计人员在项目中，主要完成项目的总体框架设计工作和设计工作，一般的来说，由于他们会承担一些Code Review，以及一些系统级的工作（比如集成发布等等），并且承担一些核心模块的开发工作。在这个环节，我们主要把精力放在设计环节上。

首先做一个定义，我同样不清楚书上是如何说的，说设计是什么。在实际操作环节中，总体设计的产出的标志，一般是package能够确立，并且package之间的协议（如果有的话），协议确立一个0.1版本，设计的一个中间阶段的产出是（常说的概要设计，但是我现在倾向于这两者不做那么严格的分离，实际上，也很难做什么太多的分离）文件目录确立，比如对于WEB开发来说，一般采用Frame结构，以及Frame结构内的页面名称基本上已经确立，并且很清楚，在每个页面中所需要完成的工作是什么，更严格一些的要求，需要把Class也确立出来，接口函数定义等等基本产出，空Project基本上确立起来就可以了。当然这个目标是比较难以达到的，但是如果能够做到，能够为后面的工作，减少很多随意性。

OK，定义说完了，接下去，我们先讨论一个问题，如何看待设计和编码之间的结合，一般来说，15-20人的团队，其中只有一个设计人员可以不延续到编码阶段，因为在研发过程中的种种调整工作，会消耗他的很多精力，对于更小的团队来说，独立设置设计人员，强制分离设计人员和编码人员，实在是意义不大的，理由很简单，你的沟通成本太高了，在过程中，可能产生的误解也太多了（当然，这通过统一设计语境平台等等，可以减少这些误解的机会，但是没有一种方法，可以避免这一点，而且就现在来看，这种方式也是执行成本比较高昂的方式）。

请大家明了一个事实，不要被误导了，很细的分工会使得工作整体提高效率的一个前提是这个工作相互之间的交流不多...

查看更多...

SQA人员，是一个对项目流程进行监控的人员。他是一个监控者的角色。我们可以想像一点，SQA使用各种方式，从项目中获取信息，并且站在第三方的角度上，来衡量项目的进程，估算项目的进展。并且通过各种通报手段进行预警等工作。

但是，恐怕绝大多数公司SQA部门似乎变成了一个文档管理部门，他们仅仅监控了项目的关键几份文档的入库，认为通过监控这些文档，就可以监控整个过程了。这是一个笑话。负责一些的SQA人员，会通过长时间的工作，感到一些不对劲，为什么我总是无法发现项目问题呢？于是私下的频繁沟通，换位思考等更有效的方法开始衍生出来，这是一个进步，比那种“文档保管员”有用得多。他们至少开始意识到自己和项目组团队不是警察和小偷之间的关系，是一种合作关系（这不是公司的大道理，那种大道理我连听都不想听）；但是，他们还是发现，自己对于流程的监控并不是那么有效，经常是外部而不是他们发现项目组问题，这似乎成了一个事后追查部门，而不是过程监控的部门。

在我和SQA人员进行配合的过程，我对以下几种SQA人员抱有好感，他们一般具备以下的特制：

1. 他们多少是参与过项目，并且很多人在进行SQA管理之前，具有非常丰富的项目管理经验，我曾经碰到过一个SQA Leader，具备6年以上项目管理经验；和他进行合作的时候，我感到至少我们能够就某些问题的操作性进行一些讨论，并且他也能理解我在项目中碰到的具体问题，并为我提出建议，如何进行流程裁减，并且执行某几个关键流程来解决目前的问题；

2. 他们是良好的沟通者和良好的协调者，他们很会换位思考能力。让一个团队或者一个个人喜欢一个“监工”，是一句笑话，但是在公司各个部门合作过程中，如果仅仅是这种关系，将是一个双败的结局，当然，SQA可以通过通报的方式，来使得项...

查看更多...

需求人员，是一个项目成功还是失败的，最重要的一环（我不想讲，是最重要的几环中的一环，事实上，任何人员，都决定着项目的生死，我们说他是最重要的一环，是因为我们绝大多数项目，失败的首要原因是项目需求模糊，混乱）。

做为一个需求人员，你需要分析客户的需求列表，进行需求获取，需求分析的工作，并且为团队整体工作，打下一个良好的基础。同时，在项目过程中，我希望他能够有相当的精力，来维护整个需求文档，因为这是我们开发软件的唯一的一份准则。

目前，需求获取和需求分析方面，有一些很不错的资料，在Xprogrammer和ITURL网站中，都有很大的篇幅去说明在和客户沟通过程中的一些注意事项，以及使用各种工具，来分析，挖掘需求的技巧。而且，不管你使用什么工具，不管你使用何种分析方式，我们还是需要认识到，需求分析，还是需要很大程度上依靠着需求人员的经验。这些经验往往是最难获取的，也是最决定成败的一件事情。

其他的不多说了，事实上，在绝大多数小型项目中（7-8人的项目组，半年以下的研发时间），我强烈建议不设置专门的需求人员（也许有些人说这是小作坊，小作坊也没有什么不好的，我们最关心的是产生出来的东西是什么，而不是到底如何产生出来的，流程是为目的服务的，而不是以流程本身做为目的的。），由PM（我希望他必须具有良好的沟通能力和一些些商业知识以及谈判技巧），技术设计人员（他首先应该具备清晰的思路，能够在需求阶段从技术角度提出一些解决方案，以供客户选择，并且我希望他能够把在需求过程中，所吸收到的东西，能够贯穿到项目全部过程中），测试主管（我首先需要他具备良好的整体思维能力，能够敏锐地发现需求的不完善或者不完整的地方，他需要从可测试性的角度来看待需求）；一起来进行需求的获取和分析。

在需求获取和分析阶段，有几个问题，是绝对不能犯的...

查看更多...

做为一个产品经理，首先需要的是你的创意和思路，你必须去规划产品所应该具备的功能，这将使用各种分析方法和手段，比如从竞争对手的产品中进行正向和反向的思维；你需要为自己的产品构造一个好的环境，研发虽然是产品中重要的一环，但是绝对不是唯一的一环，你需要有良好的构思，来形成产品在整个业务环中的定位，需要找到各种合作伙伴来和我们一起推进整个产品在市场上的成熟，你需要根据产品在使用过程中的反馈，来考虑不断的改善（有时候，也是通过一些数据分析手段和数据分析方法，这一点，我一直认为Yahoo做得不错，他们的改进都是有系统监控数据支撑的，而不时拍脑袋出来的），并且分析用户行为，来修整自己的产品；同时，也需要为整个研发部门指明一条前进的方向，说明我们的产品在各个阶段将是什么样子的；并且你还将牵头进行产品的推广的一些工作，比如产品的关键字，产品的宣传语，产品的基本色调等等，这些都是你必须去做的。同时，象对待孩子一样看待这个产品，你必须对这个产品的过程具有一个很清晰的思路，你必须十分明白你的产品目前处于什么阶段，并且清醒地指出下一个阶段的发展方向。

在去年一年中，Yahoo的产品给我留下最深刻的印象是，他们的产品具备了良好的监控能力，我们可以很简单地加入某些代码，来监控用户在站点上的操作访问，并且能够很轻松地定义出各种综合条件的监控，这样，我们才有各种依据来说，某一项工作是否有价值，某一项工作需要改进等等。在产品设计之初，我们就必须考虑这些要素，虽然绝大多数公司未必具有这样一个灵活的监控系统，但是即使是生磕代码，我们也需要加入这些探针，为我们将来的工作来留下一些监控的余地。

以上是产品经理应该做到的一些事情。后面，我仅仅谈一些对我印象最为深刻的产品的思路，当然，这些点不足以构成整个理论体系，但是，只是这些内容在我印象中太深刻了，以至于不吐不快。
<...

查看更多...

首先，我认为，一个项目经理，最重要的职责，就是对结果负责。也就是说，当一个项目成功的时候，你不用脸红，说你什么也没有做（如果你真的什么也没有做，就能使得项目如此成功，那么你要么运气很好，有一个杰出的助手，并且你有足够的明智、信任和恰如其分的懒惰，来让他负责具体的工作。那么你的管理才能让你可以轻松地胜任这一职务，你前途无量啊，小伙子。呵呵，不过还真的有一些管理者，恶意地偷懒，给团队带来很多不好的风气，也有类似的一种现象出现――什么也没有干，问题是看如何分辨了，最简单的一种方式就是看看结果如何？并且问问他身边的上级、下级，看看大家到底如何看待这件事情了），你就是一个胜利的Team的Leader；如果一个项目失败了，首先要做的，就是责备自己，不要责备手下人，不要说：我的团队不够优秀，我的设计人员设计出现了大问题，我的开发人员代码编写存在很大问题，我的测试人员不够优秀；归根结蒂一点，是你的错，就承担下来，如果按照这样的项目经理的逻辑，没有任何错误是管理者的错误(随便插一句，为什么我认为《都是你的错》，这本书是一本胡扯居多的书，就是因为如此，实际上，在公司层面上，很多的问题并不是执行层面上的问题，而根本是战略层面上的问题，我可以承担我层面上的错误，但是我觉得再多承担，就是有点自虐了。如果客观条件都如此好，一切都按照你的想法完成了，比如一个人在一天内，完成了整个万里长城的建设；那么也许一切都很完美了。但是，真的能够如此吗？)。一个管理者要从自身去找问题，这样他才能进一步成长，如果全部从手下人身上找责任，我觉得至少这不是一个大气的管理者，不是一个让我敬佩的管理者。举一个例子，当你是项目经理，你的项目存在了很大的问题，你的态度是什么？你正常的态度应该是很惭愧和内疚，着急想法子去解决这些问题；如果你的态度是很生气，对不起，我只能说，你没有资格生气！你还没有足够的度量和责任心来承担更多的责任。...

查看更多...

在进行项目管理的过程中，特别是软件行业的项目管理的过程中，我们要切记一点：你首先管理的是人，而不是过程，更不是文档，企图使用管理文档的方式来管理、监控整个项目，就象仅仅站在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...

查看更多...