该贴有很大参考价值,论坛的综合管理区有该贴,也转到这儿来分享。。。。 原文: 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 为了节省时间一定要舍得花时间。 如果您有方法能够为整个项目节省时间,那么就采用这种方法,尽管它可能会使工 作暂时落后于预定计划。 -------------------------------------------------------------------------------- [回复] 非常感谢这些心血总结出来的经验总结,我仿佛看到了好多的项目在不断的尝试,不断的失败,觉醒者终于从教训中。。。给后来者指明一些方向。再次感谢! 在软件开发中,我对以上18条军规有以下体会,请同行拍砖: 1、需求的详尽程度是个问题,以什么作为100%完整的标准,我一直闹不明白,虽然有一些checklist,但是还是感觉隔靴搔痒,最后我会找内行们(当然要明白某些需求细节抽样)过来,通过评估,认为需求细读已经达到80%了,我就下断言,可以进入下一个阶段了(这里应用了一个2/8法则)。。 2、在项目任何时候面临问题时,都直面和解决,不应该回避,否则它反咬一口,你可能死的很惨。。。当然在项目开始和结束的时间点上尤其重要! 3、技术这个东东,在真正做项目的时候,不一定能摆正它的位置,我是一个懒人,总想用最省事的方法做事,如果作项目,我一般不自己添加技术风险因素,而且尽量回避,用最没有风险的成熟技术。但是有时候要说服技术牛人并不是件容易的事 4、系统架构,两个字:重要!!,老billGates还是首席技术架构师呢。 5、做计划什么时候都不嫌早,有一点苗头就开始想规划的事了,这应该是PM的一种本能,还有一点,也是一牛人说的:计划永远不够详细。。。赞同! 6、标书,合同和其他高层文件是项目存在的根本理由,闹得越清楚越给你省事,闹不清楚的一定要刨根问底,别嫌烦 7、。。做评审和质量保证的角色? 8、从客户角度考察事情的优先次序。。。太对了,可是团队成员往往不这么认为。。。[技术情节~~] 9、范围/需求蔓延/变更的风险一定要尽早识别,而且必须要明确负责人。。弄不好这对项目周期有致命影响 10、激励每一个成员机智地、能动的工作,别让规矩限制了团队的手脚,放手的让他们干! 11、项目管理就是一个持续不断的风险控制过程,软件项目风险尤其高,所以高度警惕你的风险列表,化解风险于无形~ 12、重用,重用,还是重用,懒人就喜欢这样想问题,懒人往往能想出一些怪招来巧妙的解决问题,这方面的杰出青年就是当年草船借箭的诸葛孔明 13、提高开发人员的代码自检能力,我们推荐XP方法的先写测试,后写代码,并且配对编程,严格的编码规范。。。。这里控制好了,真的可以省掉不少无法想象的返工。。。。。但是测试的成本也很高哦~~,对于工期为第一目标的项目,质量上可能要做些让步。。鱼和熊掌不可兼得。。哎~ 14、我提倡小版本,短周期,迭代式推进 15、测试当然重要,不过,参见13。。 16、见14 17、团队成员都应该有责任心,但是作为PM,应该清晰的理解自己责任的重大,或许别人有办法推卸责任,你要推就困难很多。 18、有方法能够为整个项目节省时间,如果你确信,当然没有问题~,不过也要有风险意识。。 个人看法~~~
|