一个项目的订单下来后，接下来的工作就是要考虑怎样来完成这个项目。

    技术架构

    技术架构决定开发线路。这个技术架构是成熟的还是不成熟的，对于项目进度的影响非常大。对于不成熟的技术架构，要两条腿走路，一个是谋求外部资源的支持，通过引进强力外援来将不成熟的技术架构变成成熟的技术架构，这是一条比较简洁的有效的方法，但是怎样找到这样的强援呢？另一个是内部的技术摸索，这个路子就比较艰苦了，不确定的因素也比较大，在不得已的情况也只能采取这种方式，更多的情况可能是二者相互结合。

    项目的规模

    需求决定项目的规模。在项目开始的时候，需求分析还没有做，项目的规模不能完全确定，所以需要估算，而且还需要根据技术架构结合起来考虑。考虑项目规模的目的是衡量项目的工作量，从而为下一步工作做准备。

    项目人选

    选择谁作项目经理，有哪些资源可以投入到项目中。项目经理确定后项目就可以正式启动了。

    以项目为核心的公司或者部门往往会遇到一个人力资源的问题，有时候项目多，有时候项目少，不容易保持正好。项目多的时候，人员就非常紧张，项目少的时候人就闲着，这两种情况都对公司带来麻烦。在项目多的时候，会想到两种办法，一个是公司招进大量的开发人员来充实到各个项目中，另一个是公司有多少项目能力就接多少项目，多余的项目不接。在项目少的时候，也有两种做法，一个是裁员，一个是养着。在项目多的时候，一般也是市场比较好的时候，公司都是具有逐利的本性，自然不能放过这个发展的大好时机，所以一般会选择扩张的路子，先把项目接下来，再招进开发人员进行开发。但这样会带来一些问题，一个是如果招进的人员太多，在一个项目中新手太多会影响项目的进度和质量，进而会影响到公司的声誉和与客户的关系；其次，一个新进来的开发人员要想很快融入的公司的开发体系是需要一个过程的，这个过程也是需要成本的；再次，在项目多的时候招进的人越多，在项目少的时候闲置的人员也越多，闲置人员过多会对公司造成很大压力。但是如果能接的单子不接却有可能错失大好的发展机会，这也是不可取的。在项目少、人员闲置多的情况下，如果将这些人员裁减掉，这固然可以降低公司的成本开支，但是公司在这些人身上的投入也付之东流，而且公司还要额外发放遣散费，还要平息这些人可能带来的麻烦。另外，如果一旦市场转暖，项目又多起来的时候，公司又得重新找人，这样造成的成本也很大。应该说频繁的人员裁减是不足取的。但是公司也不能白养着这么多人，否则公司会被拖垮的。

    产能

    公司实力的增长是其产能的增长，产能包括市场能力和项目开发能力。但就项目开发能力而言，开发人员的多少只是开发能力一个指标，但这个计算不是很准确，核心的指标应该是公司在单位时间内所能开发的标准规模的项目是多少，同时能支持多少个这样的项目正常进行。项目规模有大有小，对生产能力的消耗也不一样，为了可比性，需要将项目的规模折算成标准规模项目。比如我们定义标准规模项目为10人月（人月是一个平均值，是指平均一个人一个月所能完成的项目实体内容的数量），一个20人月的项目就可以折算为2个标准项目。在软件企业里，可以将增加开发人员的数量作为扩大生产能力的一个途径，但新手的工作效率与老手的工作效率是不一样的，新手的一个人月不等于老手的一个人月。在一个项目里一般可以容忍一定比例的新手加入到项目中而不会影响到项目的质量和进度。这比例一定要把握好，超过这个比例就可能出问题。由于老手的数量有限，可投入到扩张项目的资源就有限，所以自身的扩张一定是有限制的。换一种思路，培训是否可以改善新人的技术水平？应该说这是可以的，但是有限的，没有经过项目的磨练总要差很多。总之，公司扩张是必要的，但不能盲目扩张，招进新人是必须的，但不能盲目招人，新人的比例要有限制。

    外部资源

    在内部资源匮乏的情况下，可以考虑借用外部资源。一个是把项目推出去，把项目外包，这样做的好处是省心，缺点是不容易控制；另一个是把外部优秀的人员借进项目内使用，这样做的好处是项目控制有力，项目组成员可以学到一些好东西，而且可以不用长期养这些优秀的人（他们的成本往往很高），缺点是在本项目中对这些人员的支出会很高，公司会比较费心，如何建立与外部资源的信任关系也是一个问题。

    项目成本

    项目管理的另一个重要内容是成本管理，项目成本的主要构成是人力成本。控制项目成本的核心是控制项目对人力资源的占用。在项目管理中需要一种机制来限制项目经理对人力资源的无限占用。在项目中有两种相互矛盾的因素约束项目经理的作为，一个是项目的进度，另一个是项目的成本。项目进度约束使项目经理有对资源的无限需求，而项目成本控制则限制他对资源的贪求。两种约束都要足够强，任何一种约束的缺失都可能造成项目的困难。特别是成本控制约束的弱化是导致资源紧张的重要因素。在日常工作中我们更多的强调进度的约束而忽视成本的约束，反而最终导致进度的失控。要有一种机制，使得项目经理非常不愿意要人，除非不得已才把人员招进项目组，用完之后就赶紧把资源释放。释放的资源可以形成一个人力资源缓冲池，这样人力资源就可以更有效的利用起来。一种设想是项目经理的成本承包制，在保证项目进度的前提下，项目经理使用的成本越少，可供他提成的基数就越大。形式上的承包制其实并不重要，重要的是项目经理要与项目的成本挂钩，他花费的成本越少，他得到的奖励就越多。

    对于成熟环节，比如写JSP或者JavaBean可以采取记件的方式考核开发人员，并与其收入挂钩，这样可以保证真正干活的人的利益。

    项目监控

    项目管理的基础是项目的监控，就是要有量化的指标，没有量化的指标就只能是粗放的管理。由粗放到精细就是项目管理可以提升的空间。但为追求精细的管理而可能增加管理的负担，工作量的增加，在目前大部分项目进度压力巨大的情况下，可能会引起不好的结果。比如为能够准确把握每一个成员的进度情况而要求每一个成员要写日志（这在很多项目中存在），写日志成为每一个成员的额外工作，同时又为项目经理增加了大量的阅读日志的工作，项目经理还要通过日志去分析项目进度的真实情况，由于每个人写日志的风格都是不一样（既使是对日志的格式规定的很仔细，看两个人的日志仍然会感觉有很大的差别的），更增加了管理者分析的难度。对于写日志的人，如果他今天的工作没有任何进展，就比较难写，有可能写一些不真实的话在上面，目的在于表示我仍然在努力工作。对于项目经理来说，情况更糟，如果看日志，然后再从中分析数据，这个工作量是巨大的，如果不看日志吧，成员的日志就白写了，这种方法就没有起到其应有的作用，只是白白浪费大家的时间了。所以在谋求获取一种数据或信息时需要仔细考虑，是否增加的大量的工作量。对于写日志来说，不少管理者会说：“在下班前5分钟大家把日志写写”，这看起来是5分钟时间，好像是个小case，但这是每一个人的5分钟，如果再加上管理者对日志的阅读和分析，这个工作量会变得惊人。

    有没有一个比较好的方式来获取数据呢？有，而且只有一个原则，就是从项目的必要环节上要数据。什么是项目的必要环节？我们分析一下写日志，如果我们不写日志，项目是否也能够完成，回答是肯定的，所以写日志不是项目的必要环节。写设计文档是不是呢，没有设计文档，程序员就不知道下一步该做什么，项目就不能完成。所以写设计文档是项目的必要环节。以最抽象的形式来说，项目就是一个个过程和一个个（中间）结果组成，过程导致结果，结果是可以统计的。项目可以看作一个大过程，也可以看作一系列小的过程的集合，判断大过程的进度可以通过分析细小过程产生的结果的统计数据得到。顺着这个思路，我们首先分析项目的必要环节都有哪些，中间结果都是什么，然后选择一种好的表现中间结果的形式，以方便我们的统计。这需要我们在项目开始的时候就要对项目环节进行设计。针对不同的项目可能会有不同的设计结果，不可完全套用一种模式。

    对于完成的项目要善于整理和归类，提取有价值的东西保存下来，为以后的项目积攒经验