1 详尽的需求分析
2 当面临项目开始时的问题时，您需要正视并处理这些困难和有争议的问题而不应该 逃避
3 选择正确的技术
正确的技术能够使您有最大的机会在现有的人力条件下以最短时间按质量要求完成工作，选择一个抢眼的新技术并没有什么好处，尤其当您不能保证它是否有好处或者找
不到正确应用新技术的人的时候。
4 设计一个产品的结构，这个结构要有很好的模块化特性，并且简单易懂。要花时间
在设计功能模块和界面上，并且对这些模块和界面进行封装和组织
5 一旦您知道了您将需要做些什么，您就可以着手准备项目计划。
6 回顾和项目相关的标书，合同和其他高层文件。
如果您的计划表明合同得不到执行，那么为了避免以后的严重问题就必须进行重新 谈判
7 检查设计和代码
8 确定优先次序
a.)确保首先将精力放在最紧急的事情，其次是最重要的事情，如果还有余下的时间再去做不太重要的事情。重要的是从客户角度考察事情的优先次序。
b.) 确保问题得到充分的解决。
9 处理需求的变化
不管变化如何小，您都要进行必要的处理，将这种变化的结果反馈给客户或者市场
部门。项目发生延迟更确切的说是人们常常认为项目会发生延迟，不要期望在没有更多时间和资源的情况下做更多的事情。
10 让人们努力并机智地工作是问题的关键。
用时间和功能命名交付的产品要比仅仅使用数字命名更好。
您应该相信团对成员，相信他们明白需要做什么，并且会全力以赴做好它。
11 减少风险
a.)不要仅仅为了使用新的技术语言或者方法而使用它们。
b.)尽量避免不同的语言或技术混用。
C.)减少对其他项目和组织的依赖性
d.)在项目计划中要包含充分的权变措施。
项目延迟常常是由于一些主要的风险因素，例如新技术的失败或供应方延迟提交产品。
12 不做无用功。如果可以COPY一些有用的功能就不必重写。
13 采用稳固的编程方式
a.)在开发工具中应用最高级的警告功能。
b.)应用错误检查工具来发现内存泄露，通用代码错误和其他潜在缺陷。
c.)养成在写完程序之后立即测试的习惯。
d.)记下测试出的程序错误并编写报告。
e.)使用可靠的结构和算法。
14 减少“设计-编程-测试“循环的时间长度。
15 在测试方面不惜时间.
16 定期进行产品发布。
您得到的反馈越多您的客户最后拒绝您的产品的可能性就越小。
17 为了防止您的项目延迟，您必须承担领导的责任，进行切实的领导。
a.)担负起责任，不责备他人，不找借口，勇于承认错误并改进。
b.)不要任由他人责备，也不要寻找不具说话力的借口。
c.)为了整个项目团队能顺利工作，您必须做一些领导应该做的事情，即使这些事 情并不让人惬意。
d.)如果您知道问题所在就立刻着手解决这些问题而不要无视问题的存在。
e.)要做全局把握整个项目的人
18 为了节省时间一定要舍得花时间。
如果您有方法能够为整个项目节省时间，那么就采用这种方法,尽管它可能会使工 作暂时落后于预定计划。
相关评论
=====================================
Pasp(2003-11-5 13:09:38)
大话都会说
楼主漏掉了最重要,也是决定性的一条:人的管理
在中国,
如果项目经理的技术不是第一,则很难服众,我深有体会,项目组成员会和你发生无休止的技术辩论
如果项目经理没有得到上级的完全信任,比如,老总会开始时叫项目组员一起参与设计方案,而不是你独自负责完成;最后你就很难从全局把握.
如果项目期间,有人要求加薪,你没有最终许可权,上级否定后,该人可能就会离去,造成进度停滞
我发现最难的不是技术,是人的管理!!
GSDN(2003-11-4 15:57:48)
无量化标准且不可证伪。
此论调多出现于教科书，难以在现实中呈现。
很多话是对的，但缺少实际可参考的价值。
jamesfay(2003-11-4 12:14:27)
必要的时候要出一些花里胡哨的东西去给客户看看，尤其在项目一开始搭建底层结构的时候，客户显得十分没有耐心，对team的信任度也很低。这个时候一定要适时地拿些东西出来骗骗他们。哪怕是很傻的不是很相干的东西。这个时候pm就必须有很好的交际能力，替团队档掉来自外部的压力。
而且和你谈判的人应该是懂一些的，不是很难说话，怕就怕他的老板——一个知道出钱，然后什么都不懂的人，所以适时地出些东西交给客户，也好较少客户在他老板面前的压力。
logicfeeling(2003-11-4 12:10:02)
打造一个团队首先需要持续的项目改进，一个好的项目经理永远知道现在该做什么，并为将来作打算（如果你想跳槽，那就不需要往下看了，去看招聘信息吧）。在恶劣的环境下生存，gsuner遇到的问题我们好像都遇到过，关键是你的团队必须选择前进还是在原地等待被消灭。如果你除了抱怨还想做些什么，而且不想离开这样的团队的话（天下乌鸦一般黑），应该认真考虑一下上面的军规该何时怎样运用到你的团队中。
Polarislee(2003-11-4 10:46:16)
这些都是做不到地
建议作者去看看《Agile Software Development》
gsuner(2003-11-4 10:30:11)
全做到这些的条件：
1 项目计划时间：18年，最少38个月
2 项目负责人的年薪：最少180万
3 项目组成员:最少180个人
4 项目资金：1.8个亿，最少1千8百万（美元)
可是我们往往面临的条件：
1 用户热情消失的时间：0.8月（您必须在这个时间内拿出个象样的原形）
2 用户这个项目的负责人更换的时间：0.8年（您必须在这个时间内拿到大部分项目资金。剩下的当做扔了)
3 项目资金：0.8Million人民币（靠，够活2.8年了),一般0.18M
4 项目组成员：8.8人(包括老板娘,网络管理员，文员，扫地员，看门员，每月0.8K的初级程序员，每月1.8K的中极程序员，每月2.8K的高级程序员)
aawolf(2003-11-4 10:09:20)
记住那句话：“没有银弹”。
项目延迟的因素往往在团队外部，我没有看到防范需求变更的“军规”，而外部的变更要比内部变动来的更致命。
lzfbird(2003-11-4 8:45:28)
不过大部分还是应该严格遵守得
mili_0816(2003-11-3 22:52:13)
这些东西说起来容易，可真正做起来，嘿嘿，由项目经验的都知道！难啊，连微软出产品都经常跳票！
|
