一、前言
做为一名程序员，你是否为自己或是为公司做过项目前期的工作量评估？接手项目后应该怎样应对？此篇文章不是ibm和华为的方法论，没有严格的、标准的流程和输入、输出，只不过是些经验总结，其中某些步骤视项目大小而定。
此文意在与大家分享，同时也希望广大的博友提出宝贵的改进意见。
二、目录
1.项目前期输入
2.第一步---了解项目背景
3.第二步---需求细化
4.第三步---根据需求做初步总体架构及技术架构
5.第四步---WBS分解
6.第五步---人员组织架构分析
7.项目前期输出
1.项目前期输入
该文章以一个简单的办公系统为例，由于办公系统的业务各不相同，我随便在网上找了一个做为示例(共3个模块)
原始需求(原文档，一点没修改过)如下：
1)个人工具箱
站内信、消息提醒、个人文件、短信系统
2)考勤系统
上班签到，值班签到：排值班表，按值班表在值班中每个时段签到(17:00-18:00、18:00-19:00、19:00-20:00 三个时段分别签订一次，满三次 给予积分，少于两次扣分)；签到结果 领导查询统计， 员工查询个人记录；评年度全勤；
3)工作日志
每人每天 逐项填写当天工作记录 和 明日工作计划 ；填写后提交所属领导，所属领导根据 计划 和 完成情况 予以打分；
2.第一步---了解项目背景
估计有不少朋友在接到需求都会直接细化需求吧？不过我在这里提醒，请不要忽略这一步，客户才是最终给你钱的人
几年前博主曾经接到过两个项目，一个是国企下面的下属企业公司的企业型网站。另一个是一家小公司的含有业务的运营系统。企业网站大家都知道，是最基础文章发布系统，几张数据表、十来个栏目、十几个页面搞定。而含有业务的网站系统就不同了，如：活动啦，流程啦什么的。含有业务的系统工作量必然会比企业网站大很多。但最后两个网站的报价几乎差不多。虽然都是赚点小钱，但两个项目的利润相差很大。为什么？项目的背景不同而以。如果当时还是按程序员的标准思维去老实的评估工作量，那么那个企业型的网站利润会大打折扣。所以这一步对于下面的多个步骤都是一个重要的前置分析条件。对于不同的背景的公司会做出不同的需求分析含水量是不同的。
3.第二步---需求细化
客户给出的需求是多么的凌乱和无理头？我们需要把需求细化一下，并把思路搞清些
1)个人工具箱
站内信：员工间可以相互发送的，可以即时查看的文字或图片的信息。
消息提醒：是发送消息的时候浏览器右下角弹出提示吗？弹出时像msn一样弹出几秒就消失？还是一直持续？这里因为和客户具体的业务需求不一样，所以在此我们只假设和msn的一样，收到消息的时候弹出对话框并在3秒后消失。
个人文件：个人文件是什么意思？这里也无法确定，此时我们假设他是站内信的一个部分，即：站内信发送的同时可以带有附件。
短信系统：短信的业务也是根据需求而定，这里只是假设：根据站内信的重要级别，在收到站内信的时候，重要级别非常高的站内信向收到信息的用户发送短信给予手机短信的提醒功能。
2)考勤系统
上班签到，值班签到：签到？公司一般都会有考勤机或是指纹机，但对于我们的即将要开发的办公系统来说，他只是一个对外开放的接口，工作量基本是一致的。
签到时段 (17:00-18:00、18:00-19:00、19:00-20:00 三个时段分别签订一次)：签到的要有时段的限制，上面开放了三个时段。
满三次 给予积分，少于两次扣分：（这里又引入了积分子系统和积分子系统的业务规则）只有每天都满三次的签到才给积分，否则不给积分或扣分。
签到结果 领导查询统计， 员工查询个人记录：领导可以根据每员工的个人考勤情况查看公司整体的考勤报表（这里又引入了报表子系统）员工可以查看个人的考勤详细记录。
评年度全勤：系统要支持可以查看到年度全勤的员工。
3)工作日志
每人每天 逐项填写当天工作记录 和 明日工作计划：系统需要支持员工在每天下班前要填写当天的工作记录和对第二天的工作计划。
填写后提交所属领导，所属领导根据 计划 和 完成情况 予以打分；这里又引出了审批流程子系统和组织机构子系统，领导可以查看他所管理的员工的工作情况和计划，而且还可以给该员工打分。
4.第三步---根据需求做初步总体架构及技术架构
把需求转换成子系统或模块、必要的技术拆分
1)总体架构：把需求描述成业务子系统
网站访问系统
我一般习惯把公众访问子系统独立出来，因为在当前的技术发展程度下，一般的系统都会要求有“手机访问子系统(安桌、Iphone、WinPhone)”、“网站访问子系统(基于浏览器)”、“其他硬件机器访问子系统(如：银行的取款机，查询机等)”。该系统主要负责与接收用户数据，一般不处理业务(手机App除外)。
办公管理子系统
办公管理：主要处理业务数据，如：日志填写、考勤记录的查询、工作日志的填写与查看、审批工作等
运维管理：描述积分的查看和报表的形成等
系统管理：每个系统都会有这么一个模块，用户、权限、角色、流程定义等
外部系统
针对有关联的系统做数据或业务交互
2）技术架构：把需求描述到技术层面，把技术分析清楚，不管业务多么复杂一般这里只分析到3层就可以了。致于详细的架构和设计可能是项确定合作意向以后要做的事。
5.第四步---WBS分解
把业务模块和技术分析转换成具体的工作量
Wbs分解一般会借助于外部应用软件，个人比较喜欢Micorsoft的Project，当然在项目管理的集合中大部份人都会使用Project，功能强大模型多。此处只列出了必要的几列。
由于只是举例，这里做的有些粗糙，但意图已表述明确。系统调研视企业背景而定，一般政府的项目都要有大量的人力物力投入在调研阶段。
大的项目在其中每个阶段都会再次细分，这里不在冗述。
6.第五步---人员组织架构分析
按工作量确定人力资源信息
根据技术架构和WBS容易得出我们需要什么的样团队去实施该项目，一般会用抽象程度很高的组织架构图来表示
人员组成：
领导组：项目经理1名
需求组：需求分析师人员1名
开发组：开发工程师2名。人员要求，2名.net 2年以上的开发人员开发基础信息、至少其中一名会使用mvc和wcf
测试组：测试工程师1名
7.项目前期输出
是时候汇总了，人力资源、成本即是我们在项目前期需要内容
编号 | 小组 | 人数 | 工时 | 人月单价 | 成本 | 是否全职 |
1 | 领导组 | 1 | 5人天 | 1.2万/月 | 0.3万 | 否 |
2 | 需求组 | 1 | 5人天 | 0.6万/月 | 0.15万 | 是 |
3 | 开发组 | 2 | 43人天 | 0.8万/月 | 1.6万 | 是 |
4 | 测试组 | 1 | 10人天 | 0.6万/月 | 0.3万 | 是 |
5 | 合计 | 2.35万 | ||||
该项目的成本，粗略估算为：2.35万人民币。人力成本是有地域性的，人月单价不同成本合算差异比较大。在实际过程中不同的单位会有不同的成本合算表格里面含有各种公式，这里就不列举了。
三、后继说明
这个例子只是写项目初期的成本合算，随着需求的细化各方面变动会非常大，但很多工作都是确定合作意见后的工作。具体情况具体确定吧，总之，但完成了这些步骤后，哪些地方可以压缩，哪些地方可以细化，哪些工作水深，心里应该有底了。