《产品研发过程实践》（31）谈谈团队管理者和下属的关系
作者:asky 日期:2007-04-29
这一点，每个管理者的做法都不同了。有的人很严肃，有的人很没有架子。倒没有什么证据说明，一定严肃的管理者，团队的绩效高呢，还是随和的管理者的团队绩效高。
一般我习惯的是一种更加默契一些的团队关系，也就是说，我希望我们不仅仅是工作上的同事关系，也希望是私下比较谈得来的人。但是，我不刻意追求这一点，如果能够成为朋友，那么就是朋友；如果合不来，就算了。我没有意愿把工作中所有的人都变成私交的朋友。而且，一般来说，我也不会刻意给私交好的人员更高的评价，但是这一点是难以避免的，因为我们私下里价值观比较类似，所以相互观点也比较容易接受而已。但是这是一个鸡生蛋，蛋生鸡的问题，不想过多说。
我知道，很多管理者都希望看见团队内部很默契。但是一般来说，我们首要的目标还是绩效。没有业绩的团队本身对公司来说，就没有太多必要存在。而且，管理学上也没有明显的证据说明，内部关系很好的团队，就是一个高业绩的团队。只有证据说明，一般来说，一个非常高绩效的团队，基本上内部关系也不太差而已（我们最好不要从结果反过来推原因）。
我相对喜欢的一些Team Leader和属下的关系，是那种Team Leader作为一个环境维持者，他会替员工着想，同时，依靠员工完成自己部门的目标。在完成的过程中，他会团队成员提供各种建议。
总之，也许，我是一个相对来说比较平和的人，所以我一般来说，喜欢在团队中维持一种比较平和的气氛。希望我们工作得更快乐一些。仅此而已。
没有必要一定要同仁们把你看成什么什么人。你是什么就是什么。你在某一些地方上，也要能够容忍自己不如别人。简单得看待一些事情，总是让自己放松的事情。至于一些管理者，非得大家围着他转，才满意，这又何苦来着，你的生活又不是仅仅工作这一块。放松一些哦！不然会很累的。
查看更多...
一般我习惯的是一种更加默契一些的团队关系，也就是说，我希望我们不仅仅是工作上的同事关系，也希望是私下比较谈得来的人。但是，我不刻意追求这一点，如果能够成为朋友，那么就是朋友；如果合不来，就算了。我没有意愿把工作中所有的人都变成私交的朋友。而且，一般来说，我也不会刻意给私交好的人员更高的评价，但是这一点是难以避免的，因为我们私下里价值观比较类似，所以相互观点也比较容易接受而已。但是这是一个鸡生蛋，蛋生鸡的问题，不想过多说。
我知道，很多管理者都希望看见团队内部很默契。但是一般来说，我们首要的目标还是绩效。没有业绩的团队本身对公司来说，就没有太多必要存在。而且，管理学上也没有明显的证据说明，内部关系很好的团队，就是一个高业绩的团队。只有证据说明，一般来说，一个非常高绩效的团队，基本上内部关系也不太差而已（我们最好不要从结果反过来推原因）。
我相对喜欢的一些Team Leader和属下的关系，是那种Team Leader作为一个环境维持者，他会替员工着想，同时，依靠员工完成自己部门的目标。在完成的过程中，他会团队成员提供各种建议。
总之，也许，我是一个相对来说比较平和的人，所以我一般来说，喜欢在团队中维持一种比较平和的气氛。希望我们工作得更快乐一些。仅此而已。
没有必要一定要同仁们把你看成什么什么人。你是什么就是什么。你在某一些地方上，也要能够容忍自己不如别人。简单得看待一些事情，总是让自己放松的事情。至于一些管理者，非得大家围着他转，才满意，这又何苦来着，你的生活又不是仅仅工作这一块。放松一些哦！不然会很累的。
查看更多...
《产品研发过程实践》（30） 谈谈绩效考核
作者:asky 日期:2007-04-29
绩效考核，是每一个管理者，每隔一个时间，都需要花很长时间来做的一件事情。而且是管理中很重要的一件事情，他绝对值得你花很多的时间去做。而且它的影响对于团队来说，将非常非常重要。
绩效考核可能仅仅是针对职责的考核，或者是针对目标的考核，我们先分析一下这两者之间的优缺点。
针对职责的考核，在每个季度（或者某个周期时间段，比如半年等等）末的时候，反馈上一个季度你所做的工作，比如我参加了2个项目，在第一个项目中承担设计工作，在第2个项目中承担开发的工作等等，然后针对这些业绩进行考核。一般我们推荐5分制的方式进行（100分的制度太细节了，而且不好处理，谁知道85和86之间的区别是什么啊？）。这是业绩的考核，然后，再进行行为能力的考核，比如执行能力啊，比如对公司的认同感啊，比如组织规划能力啊等等都是如此。最后做一个总评，就是你的绩效考核分数了。这种方式的优点是非常便于操作（上个季度做什么总是很明确的，而且针对任务的考核相对比较容易有说服力），缺点是，我们会仅仅关注一些自己的任务完成情况，团队的目标往往会被忽略掉。这种考核，直接的部门经理，会在每个员工身上花费大约2-3个小时（包括评价，包括面谈等等）。
针对目标的考核，则相对比较复杂很多了。在季度之初，部门会得到分解以后的部门目标，然后将这些目标分解到个人身上。并且和每个成员商量，这些目标是否能够达到等等。总之，是综合部门和个人意愿，达成一份双方认可的责任书。在过程中，基本上每隔一段时间要进行反馈一次，看看目标是否发生了变化；如果目标发生变化，则需要进行改变。然后在周期末对这些目标的达成情况来进行考核。这种方式的好处是容易把大家的注意力集中在公司的目标身上，目标不容易发生偏差；但是问题是操作难度太大，比如目标的分解是需要具备良好的能力的；而且对于一般的公司来说，稳定这些目标，在现...
绩效考核可能仅仅是针对职责的考核，或者是针对目标的考核，我们先分析一下这两者之间的优缺点。
针对职责的考核，在每个季度（或者某个周期时间段，比如半年等等）末的时候，反馈上一个季度你所做的工作，比如我参加了2个项目，在第一个项目中承担设计工作，在第2个项目中承担开发的工作等等，然后针对这些业绩进行考核。一般我们推荐5分制的方式进行（100分的制度太细节了，而且不好处理，谁知道85和86之间的区别是什么啊？）。这是业绩的考核，然后，再进行行为能力的考核，比如执行能力啊，比如对公司的认同感啊，比如组织规划能力啊等等都是如此。最后做一个总评，就是你的绩效考核分数了。这种方式的优点是非常便于操作（上个季度做什么总是很明确的，而且针对任务的考核相对比较容易有说服力），缺点是，我们会仅仅关注一些自己的任务完成情况，团队的目标往往会被忽略掉。这种考核，直接的部门经理，会在每个员工身上花费大约2-3个小时（包括评价，包括面谈等等）。
针对目标的考核，则相对比较复杂很多了。在季度之初，部门会得到分解以后的部门目标，然后将这些目标分解到个人身上。并且和每个成员商量，这些目标是否能够达到等等。总之，是综合部门和个人意愿，达成一份双方认可的责任书。在过程中，基本上每隔一段时间要进行反馈一次，看看目标是否发生了变化；如果目标发生变化，则需要进行改变。然后在周期末对这些目标的达成情况来进行考核。这种方式的好处是容易把大家的注意力集中在公司的目标身上，目标不容易发生偏差；但是问题是操作难度太大，比如目标的分解是需要具备良好的能力的；而且对于一般的公司来说，稳定这些目标，在现...
《产品研发过程实践》（29） 谈谈授权
作者:asky 日期:2007-04-29
一个管理者如果做不好授权这一块，那么对于团队和个人来说，都是一场灾难。一般来说，一个普通的管理者的直接下属的人数在7-8个之间。当然，随着工作的程序化的加强，相互之间工作差异性的减小等等，会增加你的直接控制幅度，但是这种控制幅度增加也不会很大，一般来说，直接控制12个人，几乎是一个极限了。到了这个极限以外，就需要来做分层的处理了。
这里就涉及一个授权。所谓授权，简单得说，就是把你的一部分权力，在某个情况，某个时间下，授予别人，这一方面使得你可以集中精力去做你最需要作的事情，另外一方面，使得属下承担责任，他们的主观能动性能够被最大地调度起来，从而更好地完成工作。这看起来很容易做，但是实际上，这是一个管理者最难做好的几件事情之一。因为有以下一些客观和主观因素，使得你的授权更加难以进行：
某些高管，要求你能够对手下人的事情了如指掌，那么你的授权就会发生一些限制。因为无论你如何授权，对Detail的控制程度都是超不过直接控制，所以，多次碰到一些询问细节的事情以后，将使得你不得不越来越插手各种细节的事情。这是一个占比例很高的因素。当然了，谈到这个问题的时候，我插一句，这并不是让你做甩手掌柜，什么都不管。我认同的一种管理者，是这样的管理者：他执行管理职能，并且在最影响部门业绩的领域中（比如如果你们的研发很成问题，你就需要花比较多的精力，投入这块的工作中），投入自己的精力，亲自做一些事情。现在纯粹的管理者，已经很少看见了。因为很简单，我们现在越来越看重实际的东西，而不仅仅是一些虚的东西了。呵呵，事实上，这样的要求也是部分的有理由的，因为管理者的一个责任是决策，比如你的项目已经严重Delay，你需要砍掉某些功能，那么砍掉哪些功能呢？这需要你对于客户的理解，对于项目研发进度的估算，对于各个Feature的成本估算才能做出这样的决定；当然，你可以说，这些...
这里就涉及一个授权。所谓授权，简单得说，就是把你的一部分权力，在某个情况，某个时间下，授予别人，这一方面使得你可以集中精力去做你最需要作的事情，另外一方面，使得属下承担责任，他们的主观能动性能够被最大地调度起来，从而更好地完成工作。这看起来很容易做，但是实际上，这是一个管理者最难做好的几件事情之一。因为有以下一些客观和主观因素，使得你的授权更加难以进行：
某些高管，要求你能够对手下人的事情了如指掌，那么你的授权就会发生一些限制。因为无论你如何授权，对Detail的控制程度都是超不过直接控制，所以，多次碰到一些询问细节的事情以后，将使得你不得不越来越插手各种细节的事情。这是一个占比例很高的因素。当然了，谈到这个问题的时候，我插一句，这并不是让你做甩手掌柜，什么都不管。我认同的一种管理者，是这样的管理者：他执行管理职能，并且在最影响部门业绩的领域中（比如如果你们的研发很成问题，你就需要花比较多的精力，投入这块的工作中），投入自己的精力，亲自做一些事情。现在纯粹的管理者，已经很少看见了。因为很简单，我们现在越来越看重实际的东西，而不仅仅是一些虚的东西了。呵呵，事实上，这样的要求也是部分的有理由的，因为管理者的一个责任是决策，比如你的项目已经严重Delay，你需要砍掉某些功能，那么砍掉哪些功能呢？这需要你对于客户的理解，对于项目研发进度的估算，对于各个Feature的成本估算才能做出这样的决定；当然，你可以说，这些...
《产品研发过程实践》 28 团队组建的几个要点
作者:asky 日期:2007-04-29
OK，团队组建起来了。团队管理的东西太多了，多得几乎每一点都值得去写。但是最根本的，我认为无非3点：
1. 团队目标；
2. 团队规则；
3. 团队的文化；
下面展开，结合一些实例来说明吧。
OK，任何团队都需要一个目标，一个没有目标的团队，就象乡村俱乐部，仅仅是一堆人的聚会而已。没有太多的价值。目标能够使得我们在判断各种问题的时候，有判断的依据。如果缺乏一个目标，我们如何做都是对的，那如何还有战斗力啊？举一个例子来说，我们的目标是开发一个中间件产品，那么在作判断的时候，就相对比较简单了。比如，有个开发工程师过来告诉我，我们漏了一项东西，就是第三方接口的验证程序，如果缺少这个程序，等到我们的中间件和对方对接以后，出现大量问题的时候，排错成本很高。如果这是一个严格的中间件产品，而且我们的产品将要推出，那么没有什么可说的，即使开发难度大，成本高，也是必须去作的。但是，如果这个中间件目标是给我们的系统使用，那么这种验证程序，暂时是没有太多必要开发的。如果缺乏目标，这种问题会纠缠我们很多时候，公说公有理，婆说婆有理，实际上，问题的根源不是谁对，而是我们的目标是不明确的。顺便说一句，我在2000年的时候，非常惊讶于一些资深的管理人士能够迅速做出一些我认为很难处理的问题的决策。但是我现在至少明白，他们的心目中拥有一个非常明确的目标，并且有一条价值底限。用目标来衡量这件事是否要做，用价值底限来防止自己做出出格的决定，这样他们的决定也许不是最好的，但是大致也是不会错得太离谱的。这一点是如此的重要，以至于我决定在下面独立写得更详细一些，这里先放下，继续我们的话题。
团队的目标必须是清晰明了的，可能达到的而且有一定挑战性的...
1. 团队目标；
2. 团队规则；
3. 团队的文化；
下面展开，结合一些实例来说明吧。
OK，任何团队都需要一个目标，一个没有目标的团队，就象乡村俱乐部，仅仅是一堆人的聚会而已。没有太多的价值。目标能够使得我们在判断各种问题的时候，有判断的依据。如果缺乏一个目标，我们如何做都是对的，那如何还有战斗力啊？举一个例子来说，我们的目标是开发一个中间件产品，那么在作判断的时候，就相对比较简单了。比如，有个开发工程师过来告诉我，我们漏了一项东西，就是第三方接口的验证程序，如果缺少这个程序，等到我们的中间件和对方对接以后，出现大量问题的时候，排错成本很高。如果这是一个严格的中间件产品，而且我们的产品将要推出，那么没有什么可说的，即使开发难度大，成本高，也是必须去作的。但是，如果这个中间件目标是给我们的系统使用，那么这种验证程序，暂时是没有太多必要开发的。如果缺乏目标，这种问题会纠缠我们很多时候，公说公有理，婆说婆有理，实际上，问题的根源不是谁对，而是我们的目标是不明确的。顺便说一句，我在2000年的时候，非常惊讶于一些资深的管理人士能够迅速做出一些我认为很难处理的问题的决策。但是我现在至少明白，他们的心目中拥有一个非常明确的目标，并且有一条价值底限。用目标来衡量这件事是否要做，用价值底限来防止自己做出出格的决定，这样他们的决定也许不是最好的，但是大致也是不会错得太离谱的。这一点是如此的重要，以至于我决定在下面独立写得更详细一些，这里先放下，继续我们的话题。
团队的目标必须是清晰明了的，可能达到的而且有一定挑战性的...
新方法学
作者:asky 日期:2007-04-29
Chief Scientist,Thoughtworks 2004.3 从无、到繁重、再到敏捷
多数软件开发仍然是一个显得混乱的活动，典型的“边写边改”（code and fix）。设计过程充斥着短期的、即时的决定，而没有完整的规划。这种模式对于小系统开发其实很管用，但是当系统变得越来越大，越来越复杂的时候，要想加入新的功能越来越困难，同时，错误故障越来越多，越来越难排除，一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期的感觉，从而对项目的完成产生了眼中的影响。
而“正规方法”（methodology），对软件过程有着严格而详尽的规定，以期使软件开发更有可预见性并提高效率，这种思路借鉴了其他工程领域的实践－因此我们称之为工程方法。工程方法存在了很长的实践，但是没有取得令人瞩目的成功，甚至没有引起人们注意。对这种方法最常见的批评就是他们的官僚繁琐，要是按照它的要求来，那有太多的事情要做，从而延缓整个软件开发过程。
敏捷型和工程型方法有一些显著的区别，其中一个显而易见的不同反映在文档上，敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档，从很多方面来看，它们更像是“面向源码”。事实上，它们认为最根本的文档就是源码。更深层的两个特点是：
1. 敏捷方法是“适应性”而非“预见性”的。工程方法试图对一个软件开发项目在很长时间跨度内做出详细的计划，然后依据计划进行开发。这类方法在一般情况下工作良好，但是当环境、需求有变化的时候，就不太灵了。因此它们的本质上是拒绝变化的，而敏捷方法是欢迎变化的。
2. 敏捷方法是“面向人”的而非“面向过程”的。工程型方法的目标是定义一个过程，不管是谁用都工作，而敏捷方法则认为没有任...
多数软件开发仍然是一个显得混乱的活动，典型的“边写边改”（code and fix）。设计过程充斥着短期的、即时的决定，而没有完整的规划。这种模式对于小系统开发其实很管用，但是当系统变得越来越大，越来越复杂的时候，要想加入新的功能越来越困难，同时，错误故障越来越多，越来越难排除，一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期的感觉，从而对项目的完成产生了眼中的影响。
而“正规方法”（methodology），对软件过程有着严格而详尽的规定，以期使软件开发更有可预见性并提高效率，这种思路借鉴了其他工程领域的实践－因此我们称之为工程方法。工程方法存在了很长的实践，但是没有取得令人瞩目的成功，甚至没有引起人们注意。对这种方法最常见的批评就是他们的官僚繁琐，要是按照它的要求来，那有太多的事情要做，从而延缓整个软件开发过程。
敏捷型和工程型方法有一些显著的区别，其中一个显而易见的不同反映在文档上，敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档，从很多方面来看，它们更像是“面向源码”。事实上，它们认为最根本的文档就是源码。更深层的两个特点是：
1. 敏捷方法是“适应性”而非“预见性”的。工程方法试图对一个软件开发项目在很长时间跨度内做出详细的计划，然后依据计划进行开发。这类方法在一般情况下工作良好，但是当环境、需求有变化的时候，就不太灵了。因此它们的本质上是拒绝变化的，而敏捷方法是欢迎变化的。
2. 敏捷方法是“面向人”的而非“面向过程”的。工程型方法的目标是定义一个过程，不管是谁用都工作，而敏捷方法则认为没有任...
《产品研发过程实践》（27） 团队沟通
作者:asky 日期:2007-04-29
在团队这一章中，我首先提到的是团队沟通，因为这是最对于团队来说是最为重要的。特别对于一个软件项目项目组来说。我们在前面已经很多次地说到了这一点，软件行业的项目组将依赖于大家的沟通。在项目中，如何强调沟通都是不过分的。而事实上，绝大多数问题的出现，我们基本上都可以在沟通上找到一些问题的根源。举一个例子来说，我们很多人在工作中，都有一点感觉，我们之间的工作挂接不那么严丝合缝，似乎总是有一些灰色地带的存在，而正是这些模糊的地方，导致我们工作出现一些不和谐音。可以明确的说一点：这一点将在你的工作中，不断出现；而且随着你岗位的提升，责任的提升，这一点将变得越来越多。原因是，至少在现在我看来，任何组织结构都无法定义得如此明晰（因为我们面对着是变化越来越快的市场的这一个现实），所以，需要我们加强沟通，依靠沟通能力来弥补一些问题。
首先，团队沟通的成本上很高的，而且随着以下因素，沟通的成本会越来越高：人数的增加，工作地点的分离，缺乏共同的语境平台，不相同的价值观或者判断准则等等。
人数的增加，使得相互之间的沟通线越来越多，而且，信息的增加，不见得就一定能够把你导向成功，你将不得不判断各种不同的信息，从而使得成本越来越高。根据这点，我们在管理上，推荐进行单头领导（而不是多头领导）就是这个原因，我们赞成使用少量的高素质人员替代大量无经验的人员，也是基于这一点的判断。
工作地点的分离，也将导致沟通成本急剧上升。我不知道大家如何看待在这样的一个团队：我们的需求团队在北京，设计团队在上海，开发团队在武汉，测试团队在大连。如果是我看见这样的团队，将使得我很挠头。而且，但凡有可能，我极其不愿意使用这样一种团队，因为地点的分离，使得沟通和交流的数量和质量大大低于直接的面对面的交流。对于一般的开发团队来说，我希望他们不仅仅是在一个办公室里，而且更希...
首先，团队沟通的成本上很高的，而且随着以下因素，沟通的成本会越来越高：人数的增加，工作地点的分离，缺乏共同的语境平台，不相同的价值观或者判断准则等等。
人数的增加，使得相互之间的沟通线越来越多，而且，信息的增加，不见得就一定能够把你导向成功，你将不得不判断各种不同的信息，从而使得成本越来越高。根据这点，我们在管理上，推荐进行单头领导（而不是多头领导）就是这个原因，我们赞成使用少量的高素质人员替代大量无经验的人员，也是基于这一点的判断。
工作地点的分离，也将导致沟通成本急剧上升。我不知道大家如何看待在这样的一个团队：我们的需求团队在北京，设计团队在上海，开发团队在武汉，测试团队在大连。如果是我看见这样的团队，将使得我很挠头。而且，但凡有可能，我极其不愿意使用这样一种团队，因为地点的分离，使得沟通和交流的数量和质量大大低于直接的面对面的交流。对于一般的开发团队来说，我希望他们不仅仅是在一个办公室里，而且更希...
《产品研发过程实践》（26）团队的概述
作者:asky 日期:2007-04-29
下面我们要开始花很多篇章说管理了哦。如果对这块不感兴趣，请自行跳过，直接看后面的项目管理部分，但是我认为如果项目管理缺少人力管理这部分，就变得太不完整了。而且，我在项目管理过程中，一般对人员关注很多，所以，这里也就花比较多的篇幅了。
团队是如此的重要，以至于现在任何的岗位，都需要你首先是一个“Team Player”。那么团队是什么呢？首先不是一堆人在一起就是一个团队了，他只是一堆人的集合而已。我们想想，我们打牌的时候，和对家就是一个小的Team。这个Team具备了团队的基本一些特征：共同的目标（你们都想联合起来打败对手），你们有一些共同的工作规则（你们之间的默契，你们必须按照牌理出牌），团队的成功依赖于你们的共同努力（我最不喜欢和合作的牌友，就是一有好牌，就疯狂出打牌，根本不考虑如何利用双方的牌进行配合，然后抱怨你一手烂牌）。
同样，项目组也是如此，我们具有共同的目标（希望一个项目成功）；我们具有相同的一些工作规则（我们在一个规范下，进行研发），目标的达成，依赖于我们每个人的努力（缺少任何一个岗位的团队，都是残缺不全的，和离开成功希望越来越远的）。也就是说，我们是为了达成目标而集中起来的，我们的努力目标就是达成团队目标（以及在此过程中，达成自己的目标）。
这对我来说，就是团队！
说明白了团队，我们下面按照这样的思路展开吧：
首先说说团队沟通，因为他是基石，缺乏沟通的管理，根本做不好管理；
其次，由于团队管理方面涉及的内容太多，我取其中我认为最为重要的3点去说，然后展开一系列的话题，每个话题解决一个问题，当然这都是我的观点，看得不顺眼的就跳过不看好了。管理无所谓对或者错，只是个人的一种风格。
以此看来，用这种方法表述，对于个人来说，真的...
团队是如此的重要，以至于现在任何的岗位，都需要你首先是一个“Team Player”。那么团队是什么呢？首先不是一堆人在一起就是一个团队了，他只是一堆人的集合而已。我们想想，我们打牌的时候，和对家就是一个小的Team。这个Team具备了团队的基本一些特征：共同的目标（你们都想联合起来打败对手），你们有一些共同的工作规则（你们之间的默契，你们必须按照牌理出牌），团队的成功依赖于你们的共同努力（我最不喜欢和合作的牌友，就是一有好牌，就疯狂出打牌，根本不考虑如何利用双方的牌进行配合，然后抱怨你一手烂牌）。
同样，项目组也是如此，我们具有共同的目标（希望一个项目成功）；我们具有相同的一些工作规则（我们在一个规范下，进行研发），目标的达成，依赖于我们每个人的努力（缺少任何一个岗位的团队，都是残缺不全的，和离开成功希望越来越远的）。也就是说，我们是为了达成目标而集中起来的，我们的努力目标就是达成团队目标（以及在此过程中，达成自己的目标）。
这对我来说，就是团队！
说明白了团队，我们下面按照这样的思路展开吧：
首先说说团队沟通，因为他是基石，缺乏沟通的管理，根本做不好管理；
其次，由于团队管理方面涉及的内容太多，我取其中我认为最为重要的3点去说，然后展开一系列的话题，每个话题解决一个问题，当然这都是我的观点，看得不顺眼的就跳过不看好了。管理无所谓对或者错，只是个人的一种风格。
以此看来，用这种方法表述，对于个人来说，真的...
《产品研发过程实践》（25） 软件角色总结
作者:asky 日期:2007-04-29
在上面，我们花了不少篇幅去写从一个项目经理眼中的各个角色。当然，还有很多角色被漏掉了，比如公司内部其他部门的人员，比如工程人员，比如售后人员等等，都没有很好地去表述他。这并不代表他们不重要。相反的他们很重要。但是，我也不想一一地说太多了。
软件是由那么多角色，人员配合才能顺利产生出来。其中必要的沟通和相互的谅解是必然的。无论做为一个客户也好，做为一个高层管理者也好，做为一个项目组中一员也好，只有大家都认识到这一点，我们才能构造出适用的软件。
其中，最为项目成功的最大的要素，不是其他的，是沟通！
贯穿于项目中点点滴滴的沟通，我们所做的各种额外的工作，绝大多数是为了沟通。在项目中，再如何强调沟通都是不过分的。
让我们为一个美妙的软件而合作，而沟通。
其实，对于很多软件人员来说，能够参与一个成功的软件的研发过程，都是一个美妙的过程。这是一个拥有无穷成就感的工作。让沟通，让理解把我们从一个一个软件噩梦中拯救出来！
祝福软件行业中的每一员，我相信，随着时代的进步，我们会做得越来越好。
软件是由那么多角色，人员配合才能顺利产生出来。其中必要的沟通和相互的谅解是必然的。无论做为一个客户也好，做为一个高层管理者也好，做为一个项目组中一员也好，只有大家都认识到这一点，我们才能构造出适用的软件。
其中，最为项目成功的最大的要素，不是其他的，是沟通！
贯穿于项目中点点滴滴的沟通，我们所做的各种额外的工作，绝大多数是为了沟通。在项目中，再如何强调沟通都是不过分的。
让我们为一个美妙的软件而合作，而沟通。
其实，对于很多软件人员来说，能够参与一个成功的软件的研发过程，都是一个美妙的过程。这是一个拥有无穷成就感的工作。让沟通，让理解把我们从一个一个软件噩梦中拯救出来！
祝福软件行业中的每一员，我相信，随着时代的进步，我们会做得越来越好。
《产品研发过程实践》（24） 客户
作者:asky 日期:2007-04-29
之所以把客户列在其中，是因为客户也是项目组中的一部分，而且是很重要的一部分。
在这里，我主要想说的就是一点，如何和客户沟通。其他的部分，都不重要，但是这一点做不好，累死你也没有好下场啊。再往后，我们会讨论几个我们老是会碰到的问题。
首先，和客户沟通应该抱着一个什么态度？首先必须肯定的一点是：你不是什么救世主，客户不需要你来拯救世界；你也不要把自己看成帮助客户来改善他们的工作的专家，一般来说，这种态度往往得不到别人的认可，他们之前的工作已经做得很好了，不需要你来改善工作，你所做的仅仅是帮助他们更轻松地完成他们本来已经做得很好的工作而已。记住这一点！这很重要。这是一个沟通的站位问题。
其次，和客户沟通的技巧。技巧原则上其实很简单，这里我不准备详细说“服务客户技能”，这方面的内容，值得我为它另外写一篇东西。我这里就是简单说一说。你需要换位思考，首先考虑考虑你的客户的个人利益，企业利益，然后再考虑考虑你的个人利益和企业利益，如果都能符合了，那么恐怕就是一个好的提议了。比如要你的客户为你买单什么东西之类的东西，就不用说了，说了也是白说。一般的来说，对于客户方面的工程师来说，你首先最好知道他的背景，比如他是一个研发背景，希望将来在技术领域走得很深的人，那么你最好在适当的机会，提供各种设计分析等等内容，并且结合你的项目，提供一些结论性的东西，他会很自然去使用这些东西的；如果希望走项目管理路线的，记得组间协同和项目文档必须做得好，让他在汇报的时候，可以很轻松引用你的东西，那么将在他的老板心目中，给他造就一个人才的印象，这对你来说是很有利的；对于客户方面的中层管理者来说，一般来说，他们都希望事情能够安全做完，并且得到老板认同，那么不要用太多激进的东西会比较稳妥一些，而且他们喜欢看见数字性的东西，说明问题的时候，最好使用数字来说话，不...
在这里，我主要想说的就是一点，如何和客户沟通。其他的部分，都不重要，但是这一点做不好，累死你也没有好下场啊。再往后，我们会讨论几个我们老是会碰到的问题。
首先，和客户沟通应该抱着一个什么态度？首先必须肯定的一点是：你不是什么救世主，客户不需要你来拯救世界；你也不要把自己看成帮助客户来改善他们的工作的专家，一般来说，这种态度往往得不到别人的认可，他们之前的工作已经做得很好了，不需要你来改善工作，你所做的仅仅是帮助他们更轻松地完成他们本来已经做得很好的工作而已。记住这一点！这很重要。这是一个沟通的站位问题。
其次，和客户沟通的技巧。技巧原则上其实很简单，这里我不准备详细说“服务客户技能”，这方面的内容，值得我为它另外写一篇东西。我这里就是简单说一说。你需要换位思考，首先考虑考虑你的客户的个人利益，企业利益，然后再考虑考虑你的个人利益和企业利益，如果都能符合了，那么恐怕就是一个好的提议了。比如要你的客户为你买单什么东西之类的东西，就不用说了，说了也是白说。一般的来说，对于客户方面的工程师来说，你首先最好知道他的背景，比如他是一个研发背景，希望将来在技术领域走得很深的人，那么你最好在适当的机会，提供各种设计分析等等内容，并且结合你的项目，提供一些结论性的东西，他会很自然去使用这些东西的；如果希望走项目管理路线的，记得组间协同和项目文档必须做得好，让他在汇报的时候，可以很轻松引用你的东西，那么将在他的老板心目中，给他造就一个人才的印象，这对你来说是很有利的；对于客户方面的中层管理者来说，一般来说，他们都希望事情能够安全做完，并且得到老板认同，那么不要用太多激进的东西会比较稳妥一些，而且他们喜欢看见数字性的东西，说明问题的时候，最好使用数字来说话，不...
《产品研发过程实践》（23） 高层管理者
作者:asky 日期:2007-04-29
高层管理者，这里之所以要提起，是因为，事实上，使得项目成功，在很大程度上也需要取决于高层管理者对于项目的一些做法和态度。那么做为一个项目经理的角度出发，我们期待于高层管理者如何呢？
首先，我们希望能够保证资源的供给，保证时间、人力和资金的保证。当然每个人都希望从投入中得到足够多的反馈，但是我希望高管们能够理解项目、工程的一般性原则，有时候，我们的确无法答应一些时间条件，不要和我过多地谈起我给你1倍的人，你是否可以少用一半的时间完成这种怪问题，我真的很难回答（当然，现在这种什么都不懂的高层管理者不多了，倒是看见不少底层管理者敢于对上面这个问题，回答“是！”）。如果我真的如此答应你，那么对于你来说，恐怕也是一场灾难。因为，我可能仅仅是因为希望扩大一些沉没成本而已，来使得这个项目更难以取消。
其次，我希望高管们，在一定时间中，维持一个相对来说比较稳定的环境，而不是变化多端的环境给研发团队，人的想法变化很快，但是一个项目目标老是改变，就很难受了。不是吗？至少有一定的定力来维持一个至少短期的一个稳定。我们能够拥抱变化，但是不是说，去拥抱无节制的变化。比如，原先一个产品是为了解决项目中的实际问题而做的引擎，后期变成了为了演示而开发的引擎等等；这就多少让我惊讶万分了。
再次，做好你的事情，其他的事情，让兄弟们干好了。我不喜欢伸手得太长的高管。比如在有的合作中，做为产品和市场方面的高管，每天和我一起讨论技术问题和一些界面安排问题。我觉得多少有点离谱，对于一个新开始做的行业来说，在这段非常重要的时间中，我希望你能够提供更多的市场信心，找到合作者，找到我们产品的试用者，找到我们的合作伙伴，而不是一天又一天得和我讨论，项目何时开始编码比较合适。直到某一天，我的一个同仁对对方说：“某某，还是让周海峰负责研发方面的决定就可以了，毕竟他好歹也...
首先，我们希望能够保证资源的供给，保证时间、人力和资金的保证。当然每个人都希望从投入中得到足够多的反馈，但是我希望高管们能够理解项目、工程的一般性原则，有时候，我们的确无法答应一些时间条件，不要和我过多地谈起我给你1倍的人，你是否可以少用一半的时间完成这种怪问题，我真的很难回答（当然，现在这种什么都不懂的高层管理者不多了，倒是看见不少底层管理者敢于对上面这个问题，回答“是！”）。如果我真的如此答应你，那么对于你来说，恐怕也是一场灾难。因为，我可能仅仅是因为希望扩大一些沉没成本而已，来使得这个项目更难以取消。
其次，我希望高管们，在一定时间中，维持一个相对来说比较稳定的环境，而不是变化多端的环境给研发团队，人的想法变化很快，但是一个项目目标老是改变，就很难受了。不是吗？至少有一定的定力来维持一个至少短期的一个稳定。我们能够拥抱变化，但是不是说，去拥抱无节制的变化。比如，原先一个产品是为了解决项目中的实际问题而做的引擎，后期变成了为了演示而开发的引擎等等；这就多少让我惊讶万分了。
再次，做好你的事情，其他的事情，让兄弟们干好了。我不喜欢伸手得太长的高管。比如在有的合作中，做为产品和市场方面的高管，每天和我一起讨论技术问题和一些界面安排问题。我觉得多少有点离谱，对于一个新开始做的行业来说，在这段非常重要的时间中，我希望你能够提供更多的市场信心，找到合作者，找到我们产品的试用者，找到我们的合作伙伴，而不是一天又一天得和我讨论，项目何时开始编码比较合适。直到某一天，我的一个同仁对对方说：“某某，还是让周海峰负责研发方面的决定就可以了，毕竟他好歹也...
《产品研发过程实践》（22） 测试人员
作者:asky 日期:2007-04-29
做为一个测试人员，首先你需要明确自己的责任何在？我很愿意把测试人员看成是球场上的守门员，虽然我们不是依靠测试人员来取得胜利，但是如果一个差劲的测试团队，将使得项目离开胜利越来越远。你是团队的最后一道防线了。请站好自己的位置！
我一直说，如果我的精力仅仅允许我在项目中做一件事情，那么我做需求工作，如果允许我做2件事情，我做需求和测试，如果允许我做三件事情，我做需求、测试、和框架设计；这是测试在我心目中的地位！
中国明显缺乏优秀的测试人员。我从事软件行业8年以来，接触的测试人员，测试团队换了一波又一波，但是真正让我觉得很放心的测试人员，只有一个，我很高兴，在去年的时间中，为得实找到了一个良好的高级测试工程师，这是我去年中令我最高兴的3件事情之一（一件是我找到了唐明浩和李兆松，唐明浩在测试领域中的优秀素养让我倍加放心，只要她进行的测试的项目，总是令我很放心，以至于评审她的测试点和测试大纲，是一件让我非常愉快的事情；李兆松是一个非常具有前途的工程师，虽然到目前为止，我还没有看见李兆松完全地发挥出来，但是我相信自己的眼光，具有非常清晰思路，做事明了，具有想法的人员，将来必定能够让我眼界大开的，期待中……，一件是我不顾团队中成员的反对，起用刘海琳，正是刘海琳的宽阔思路和严谨的工作作风，使得Syncin能够很顺利地向前推进，而且几乎没有占据我多少精力，刘海琳的将来也是值得期待的啊……一件是通过我们的努力，我们战胜了不少竞争对手，看着自己的产品逐渐发展起来，多少是让人有自豪感的。）但是就是在这样的环境下，我们还是认为测试是项目中最不重要的一环，测试团队的工资普遍低于开发团队，一个人员如果在开发中并不出色，往往会往测试团队中一塞，仿佛那里是流放地。但是正是这种若有若无的测试，正在摧毁着我们工作热情，折磨着我们的客户，我们的团队。
那...
我一直说，如果我的精力仅仅允许我在项目中做一件事情，那么我做需求工作，如果允许我做2件事情，我做需求和测试，如果允许我做三件事情，我做需求、测试、和框架设计；这是测试在我心目中的地位！
中国明显缺乏优秀的测试人员。我从事软件行业8年以来，接触的测试人员，测试团队换了一波又一波，但是真正让我觉得很放心的测试人员，只有一个，我很高兴，在去年的时间中，为得实找到了一个良好的高级测试工程师，这是我去年中令我最高兴的3件事情之一（一件是我找到了唐明浩和李兆松，唐明浩在测试领域中的优秀素养让我倍加放心，只要她进行的测试的项目，总是令我很放心，以至于评审她的测试点和测试大纲，是一件让我非常愉快的事情；李兆松是一个非常具有前途的工程师，虽然到目前为止，我还没有看见李兆松完全地发挥出来，但是我相信自己的眼光，具有非常清晰思路，做事明了，具有想法的人员，将来必定能够让我眼界大开的，期待中……，一件是我不顾团队中成员的反对，起用刘海琳，正是刘海琳的宽阔思路和严谨的工作作风，使得Syncin能够很顺利地向前推进，而且几乎没有占据我多少精力，刘海琳的将来也是值得期待的啊……一件是通过我们的努力，我们战胜了不少竞争对手，看着自己的产品逐渐发展起来，多少是让人有自豪感的。）但是就是在这样的环境下，我们还是认为测试是项目中最不重要的一环，测试团队的工资普遍低于开发团队，一个人员如果在开发中并不出色，往往会往测试团队中一塞，仿佛那里是流放地。但是正是这种若有若无的测试，正在摧毁着我们工作热情，折磨着我们的客户，我们的团队。
那...
《产品研发过程实践》（21）开发人员
作者:asky 日期:2007-04-29
OK，产品开始构造了，这段时间中，一般都是团队士气比较高涨的时期，看着产品逐渐地被构造出来，而且没有很多烦人的事情，这一切都很愉快不是吗？我想绝大多数开发人员都有这样的感触，疯狂地写代码，然后看见程序逐渐地出现，这是一件多少令人愉快，且具有成就感的事情啊。
那么首先，做为一个开发人员，从项目经理的角度出发，希望什么样子的开发工程师，会认为是一个好的开发工程师呢？
首先，我们希望他的思路清晰，这是一句类似于废话的表达，我们希望所有的人思路都很清晰，但是这的确很重要；
其次，我们希望他思维慎密，我们代码的一个大问题是，只考虑正常路径，对于异常路径考虑不足，这在小型应用中，一旦出现问题，很容易进行判别，但是对于大型应用来说，一旦逻辑由于异常而飞掉，那么想要判断出来问题何在就很麻烦了。异常路径的考虑绝不仅仅是Try，然后Catch一把这么简单。记住这一点，在你写程序的时候，多考虑一下，如果这样会发生什么？如果那样会发生什么？如果用户不按照你的设计的流程来做，那么结果是什么（即使你说，程序会出错，也没有问题，但是必须是我们知道他会出错，而不是不清楚结果是什么）？如果I/O出现问题，那么会发生什么情况？等等。
再次，我们希望不管你面对的压力如何，请动动脑子，不要写一些采用一些非常近视，将来必然会发生问题的做法。原则上来说，这些问题应该设计来解决，但是正如我们所知道的，设计一般来说，真的很难做到那么Detail，那么还是有很多问题，会留在开发阶段来解决。我在2001年看过一个程序，这是一个贺卡发送程序，用户点击了贺卡发送后，会生成一个页面，然后把URL发送给接受贺卡的人员邮箱中，开发人员把所有的贺卡生成的页面都放在一个文件夹中，结果时间略微长一些，在那个文件夹下，就生成了上百万的文件，以至于系统维护人员几乎认...
那么首先，做为一个开发人员，从项目经理的角度出发，希望什么样子的开发工程师，会认为是一个好的开发工程师呢？
首先，我们希望他的思路清晰，这是一句类似于废话的表达，我们希望所有的人思路都很清晰，但是这的确很重要；
其次，我们希望他思维慎密，我们代码的一个大问题是，只考虑正常路径，对于异常路径考虑不足，这在小型应用中，一旦出现问题，很容易进行判别，但是对于大型应用来说，一旦逻辑由于异常而飞掉，那么想要判断出来问题何在就很麻烦了。异常路径的考虑绝不仅仅是Try，然后Catch一把这么简单。记住这一点，在你写程序的时候，多考虑一下，如果这样会发生什么？如果那样会发生什么？如果用户不按照你的设计的流程来做，那么结果是什么（即使你说，程序会出错，也没有问题，但是必须是我们知道他会出错，而不是不清楚结果是什么）？如果I/O出现问题，那么会发生什么情况？等等。
再次，我们希望不管你面对的压力如何，请动动脑子，不要写一些采用一些非常近视，将来必然会发生问题的做法。原则上来说，这些问题应该设计来解决，但是正如我们所知道的，设计一般来说，真的很难做到那么Detail，那么还是有很多问题，会留在开发阶段来解决。我在2001年看过一个程序，这是一个贺卡发送程序，用户点击了贺卡发送后，会生成一个页面，然后把URL发送给接受贺卡的人员邮箱中，开发人员把所有的贺卡生成的页面都放在一个文件夹中，结果时间略微长一些，在那个文件夹下，就生成了上百万的文件，以至于系统维护人员几乎认...
《产品研发过程时间》（20）设计人员
作者:asky 日期:2007-04-29
对于一个15-20人左右的开发团队来说，设计人员在项目中，主要完成项目的总体框架设计工作和设计工作，一般的来说，由于他们会承担一些Code Review，以及一些系统级的工作（比如集成发布等等），并且承担一些核心模块的开发工作。在这个环节，我们主要把精力放在设计环节上。
首先做一个定义，我同样不清楚书上是如何说的，说设计是什么。在实际操作环节中，总体设计的产出的标志，一般是package能够确立，并且package之间的协议（如果有的话），协议确立一个0.1版本，设计的一个中间阶段的产出是（常说的概要设计，但是我现在倾向于这两者不做那么严格的分离，实际上，也很难做什么太多的分离）文件目录确立，比如对于WEB开发来说，一般采用Frame结构，以及Frame结构内的页面名称基本上已经确立，并且很清楚，在每个页面中所需要完成的工作是什么，更严格一些的要求，需要把Class也确立出来，接口函数定义等等基本产出，空Project基本上确立起来就可以了。当然这个目标是比较难以达到的，但是如果能够做到，能够为后面的工作，减少很多随意性。
OK，定义说完了，接下去，我们先讨论一个问题，如何看待设计和编码之间的结合，一般来说，15-20人的团队，其中只有一个设计人员可以不延续到编码阶段，因为在研发过程中的种种调整工作，会消耗他的很多精力，对于更小的团队来说，独立设置设计人员，强制分离设计人员和编码人员，实在是意义不大的，理由很简单，你的沟通成本太高了，在过程中，可能产生的误解也太多了（当然，这通过统一设计语境平台等等，可以减少这些误解的机会，但是没有一种方法，可以避免这一点，而且就现在来看，这种方式也是执行成本比较高昂的方式）。
请大家明了一个事实，不要被误导了，很细的分工会使得工作整体提高效率的一个前提是这个工作相互之间的交流不多...
首先做一个定义，我同样不清楚书上是如何说的，说设计是什么。在实际操作环节中，总体设计的产出的标志，一般是package能够确立，并且package之间的协议（如果有的话），协议确立一个0.1版本，设计的一个中间阶段的产出是（常说的概要设计，但是我现在倾向于这两者不做那么严格的分离，实际上，也很难做什么太多的分离）文件目录确立，比如对于WEB开发来说，一般采用Frame结构，以及Frame结构内的页面名称基本上已经确立，并且很清楚，在每个页面中所需要完成的工作是什么，更严格一些的要求，需要把Class也确立出来，接口函数定义等等基本产出，空Project基本上确立起来就可以了。当然这个目标是比较难以达到的，但是如果能够做到，能够为后面的工作，减少很多随意性。
OK，定义说完了，接下去，我们先讨论一个问题，如何看待设计和编码之间的结合，一般来说，15-20人的团队，其中只有一个设计人员可以不延续到编码阶段，因为在研发过程中的种种调整工作，会消耗他的很多精力，对于更小的团队来说，独立设置设计人员，强制分离设计人员和编码人员，实在是意义不大的，理由很简单，你的沟通成本太高了，在过程中，可能产生的误解也太多了（当然，这通过统一设计语境平台等等，可以减少这些误解的机会，但是没有一种方法，可以避免这一点，而且就现在来看，这种方式也是执行成本比较高昂的方式）。
请大家明了一个事实，不要被误导了，很细的分工会使得工作整体提高效率的一个前提是这个工作相互之间的交流不多...
《产品研发过程实践》（19） SQA
作者:asky 日期:2007-04-29
SQA人员，是一个对项目流程进行监控的人员。他是一个监控者的角色。我们可以想像一点，SQA使用各种方式，从项目中获取信息，并且站在第三方的角度上，来衡量项目的进程，估算项目的进展。并且通过各种通报手段进行预警等工作。
但是，恐怕绝大多数公司SQA部门似乎变成了一个文档管理部门，他们仅仅监控了项目的关键几份文档的入库，认为通过监控这些文档，就可以监控整个过程了。这是一个笑话。负责一些的SQA人员，会通过长时间的工作，感到一些不对劲，为什么我总是无法发现项目问题呢？于是私下的频繁沟通，换位思考等更有效的方法开始衍生出来，这是一个进步，比那种“文档保管员”有用得多。他们至少开始意识到自己和项目组团队不是警察和小偷之间的关系，是一种合作关系（这不是公司的大道理，那种大道理我连听都不想听）；但是，他们还是发现，自己对于流程的监控并不是那么有效，经常是外部而不是他们发现项目组问题，这似乎成了一个事后追查部门，而不是过程监控的部门。
在我和SQA人员进行配合的过程，我对以下几种SQA人员抱有好感，他们一般具备以下的特制：
1. 他们多少是参与过项目，并且很多人在进行SQA管理之前，具有非常丰富的项目管理经验，我曾经碰到过一个SQA Leader，具备6年以上项目管理经验；和他进行合作的时候，我感到至少我们能够就某些问题的操作性进行一些讨论，并且他也能理解我在项目中碰到的具体问题，并为我提出建议，如何进行流程裁减，并且执行某几个关键流程来解决目前的问题；
2. 他们是良好的沟通者和良好的协调者，他们很会换位思考能力。让一个团队或者一个个人喜欢一个“监工”，是一句笑话，但是在公司各个部门合作过程中，如果仅仅是这种关系，将是一个双败的结局，当然，SQA可以通过通报的方式，来使得项...
但是，恐怕绝大多数公司SQA部门似乎变成了一个文档管理部门，他们仅仅监控了项目的关键几份文档的入库，认为通过监控这些文档，就可以监控整个过程了。这是一个笑话。负责一些的SQA人员，会通过长时间的工作，感到一些不对劲，为什么我总是无法发现项目问题呢？于是私下的频繁沟通，换位思考等更有效的方法开始衍生出来，这是一个进步，比那种“文档保管员”有用得多。他们至少开始意识到自己和项目组团队不是警察和小偷之间的关系，是一种合作关系（这不是公司的大道理，那种大道理我连听都不想听）；但是，他们还是发现，自己对于流程的监控并不是那么有效，经常是外部而不是他们发现项目组问题，这似乎成了一个事后追查部门，而不是过程监控的部门。
在我和SQA人员进行配合的过程，我对以下几种SQA人员抱有好感，他们一般具备以下的特制：
1. 他们多少是参与过项目，并且很多人在进行SQA管理之前，具有非常丰富的项目管理经验，我曾经碰到过一个SQA Leader，具备6年以上项目管理经验；和他进行合作的时候，我感到至少我们能够就某些问题的操作性进行一些讨论，并且他也能理解我在项目中碰到的具体问题，并为我提出建议，如何进行流程裁减，并且执行某几个关键流程来解决目前的问题；
2. 他们是良好的沟通者和良好的协调者，他们很会换位思考能力。让一个团队或者一个个人喜欢一个“监工”，是一句笑话，但是在公司各个部门合作过程中，如果仅仅是这种关系，将是一个双败的结局，当然，SQA可以通过通报的方式，来使得项...
《产品研发过程实践》（18） 需求人员
作者:asky 日期:2007-04-29
需求人员，是一个项目成功还是失败的，最重要的一环（我不想讲，是最重要的几环中的一环，事实上，任何人员，都决定着项目的生死，我们说他是最重要的一环，是因为我们绝大多数项目，失败的首要原因是项目需求模糊，混乱）。
做为一个需求人员，你需要分析客户的需求列表，进行需求获取，需求分析的工作，并且为团队整体工作，打下一个良好的基础。同时，在项目过程中，我希望他能够有相当的精力，来维护整个需求文档，因为这是我们开发软件的唯一的一份准则。
目前，需求获取和需求分析方面，有一些很不错的资料，在Xprogrammer和ITURL网站中，都有很大的篇幅去说明在和客户沟通过程中的一些注意事项，以及使用各种工具，来分析，挖掘需求的技巧。而且，不管你使用什么工具，不管你使用何种分析方式，我们还是需要认识到，需求分析，还是需要很大程度上依靠着需求人员的经验。这些经验往往是最难获取的，也是最决定成败的一件事情。
其他的不多说了，事实上，在绝大多数小型项目中（7-8人的项目组，半年以下的研发时间），我强烈建议不设置专门的需求人员（也许有些人说这是小作坊，小作坊也没有什么不好的，我们最关心的是产生出来的东西是什么，而不是到底如何产生出来的，流程是为目的服务的，而不是以流程本身做为目的的。），由PM（我希望他必须具有良好的沟通能力和一些些商业知识以及谈判技巧），技术设计人员（他首先应该具备清晰的思路，能够在需求阶段从技术角度提出一些解决方案，以供客户选择，并且我希望他能够把在需求过程中，所吸收到的东西，能够贯穿到项目全部过程中），测试主管（我首先需要他具备良好的整体思维能力，能够敏锐地发现需求的不完善或者不完整的地方，他需要从可测试性的角度来看待需求）；一起来进行需求的获取和分析。
在需求获取和分析阶段，有几个问题，是绝对不能犯的...
做为一个需求人员，你需要分析客户的需求列表，进行需求获取，需求分析的工作，并且为团队整体工作，打下一个良好的基础。同时，在项目过程中，我希望他能够有相当的精力，来维护整个需求文档，因为这是我们开发软件的唯一的一份准则。
目前，需求获取和需求分析方面，有一些很不错的资料，在Xprogrammer和ITURL网站中，都有很大的篇幅去说明在和客户沟通过程中的一些注意事项，以及使用各种工具，来分析，挖掘需求的技巧。而且，不管你使用什么工具，不管你使用何种分析方式，我们还是需要认识到，需求分析，还是需要很大程度上依靠着需求人员的经验。这些经验往往是最难获取的，也是最决定成败的一件事情。
其他的不多说了，事实上，在绝大多数小型项目中（7-8人的项目组，半年以下的研发时间），我强烈建议不设置专门的需求人员（也许有些人说这是小作坊，小作坊也没有什么不好的，我们最关心的是产生出来的东西是什么，而不是到底如何产生出来的，流程是为目的服务的，而不是以流程本身做为目的的。），由PM（我希望他必须具有良好的沟通能力和一些些商业知识以及谈判技巧），技术设计人员（他首先应该具备清晰的思路，能够在需求阶段从技术角度提出一些解决方案，以供客户选择，并且我希望他能够把在需求过程中，所吸收到的东西，能够贯穿到项目全部过程中），测试主管（我首先需要他具备良好的整体思维能力，能够敏锐地发现需求的不完善或者不完整的地方，他需要从可测试性的角度来看待需求）；一起来进行需求的获取和分析。
在需求获取和分析阶段，有几个问题，是绝对不能犯的...
