| Francis's profileFrancis & EvaPhotosBlogLists | Help |
|
Francis & Eva美丽小公主哥哥的小公主实在是太漂亮太可爱了!欢迎大家光临小公主的博客噢~http://guoyutong2007.blog.sohu.com/
踩踩~明天大车和丽姐结婚一周年~祝福下~有情人终成眷属并天长地久噢~呵呵~
大勇找到新工作!加油啊!
萌萌,啥也不说了,也要加油啊!
俺们俩~~嘻嘻~~更得加油呀! 还有一个月就整七年了 昨天没有更新上~不抱怨了!
喜欢~
Eva 大事件 2007年7月30日 阴历6.17 Francis & Eva 大事件 记!
Francis Because you loved mefor all those times you stood by me for all the truth that you made me see for all the joy you brought to my life for all the wrong that you made right for every dream you made beome true for an the love i found in you i'll be forever thankful baby you're the one who held me up never let me fall you're the one who saw me throught through it all you were my strength when i was weak you were my vioce when i couldn't speak you were my eyes when i couldn't see you saw the best there was in me lifed me up when i couldn't reach you gave me faith cez you believed i'm everything i am because you loved me N年更新~嗯?竟然登录上来了!还很快呢!呵呵~
每次面对异形的登录画面总是毫不留恋的关掉!可每次又忍不住的一次一次试着登录! 软件项目失败因素分析软件开发是一项复杂的系统工程,牵涉到各方面的因素,实际工作中,经常会出现各种各样的问题,甚至面临失败。如何总结、分析失败的原因,得出有益的教训,对一个公司来说,是在今后的项目中取得成功的关键。 需求内容不明确,把握不充分 这是我们经常遇到的问题。一方面,由于客户(需求方)IT知识缺乏,一开始自己也不知道要开发什么样的系统,或者懒于系统地整理出来,经常是走一步算一步,不断地提出和更改需求,使得实现方叫苦连天。另一方面,实现方由于行业知识的缺乏和设计人员水平的低下,不能完全理解客户的需求说明,而又没有加以严格的确认,经常是以想当然的方法进行系统设计,结果是推倒重来。因此,需求分析必须注重双方理解和认识的一致,逐项逐条地进行确认。 工数估算过少 软件开发的工数估算是一项很重要的工作,必须综合开发的阶段、人员的生产率、工作的复杂程度、历史经验等因素,将一些定性的内容定量化。对工数的重要性认识不足,经常用拍脑袋的方式草算,是最常见的问题。还有,软件开发经常会出现一些平时不可见的工作量,如人员的培训时间、各个开发阶段的评审时间等,经验不足的项目经理经常会遗漏。同时,还有如下一些原因也是很典型的: (1)出于客户和公司上层的压力在工数估算上予以妥协。例如,客户威胁要用工数更少的开发商,公司因经营困难必须削减费用、缩短工期,最后只能妥协,寄希望于员工加班。 (2)设计者过于自信或出于自尊心问题,对一些技术问题不够重视,或者担心估算多被嘲笑。 (3)过分凭经验。由于有过去的成功经验,没有具体分析就认为这次项目估计也差不多,而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多,而且是一个新的行业。 项目组织过小 每个公司都希望以最少的成本完成项目,人手不足是大多数项目都会面临的问题。还有一种情况是项目组成员的技术水平达不到项目的要求,公司只能提供这些分配好的技术人员,或者由于项目经理的失误,在项目工数估算时没有明确要求技术水平,寄希望于员工自己努力。还有一些项目经理认为,在项目启动时不需要高水平的技术人员。 开发计划不充分 没有良好的开发计划和开发目标,项目的成功就无从谈起。开发计划太粗略主要反映在以下几个方面: (1)工作分担(责任范围)不明确,工作分割结构(WBS)与项目组织结构不明确或者不相对应,各成员之间的接口不明确,导致有一些工作根本无人负责。 (2)每个开发阶段的提交结果定义不明确,中间结果是否已经完成,完成了多少模糊不清,结果是到了项目后期堆积了大量工作。 (3)开发计划没有指定里程碑或检查点,也没有规定设计评审期。 (4)开发计划没有规定进度管理方法和职责,导致无法正常进行进度管理。 不能添加在评论里,一定要隆重一下!Because of Francis
妸滴神哪!
感动~
妸滴神啊!
鼓掌~
妸滴神呀!
Eva
自我总结(一) 项目的发展终于有了眉目,曙光再次偷偷露出了头,成功吧,只有成功才会冲淡曾经的辛累与苦闷。
从2006年9月到现在已经半年多的时间,我的生活一直处在紧张,忙碌,奔波,劳累中,在昨天给客户培训结束后,回头想想曾经的努力都是那么的值得。
没有放弃,没有逃避,剩下的是乐观和坚持,也正是这一点点的乐观和坚持,才能支持着我们这个团队在无数次的百米冲刺后 还能犹有余力。
项目管理的经验谈:
一、明确的需求
只有在明确的需求的指引下,才能保证少走弯路,少作无用功,节省人力。即使在项目后期的需求变更中,也要学会如何控制需求,怎样围绕先有的成果,在不扩大,不影响的情况下,变通的完成客户的需要。
二、积极的沟通
积极 灵活 及时的沟通,能够保障在项目开发的过程中,将一些可能或未知的问题控制在一个范围内,很多问题其实就是沟通不良引起的,因为太多的文字内容会使不同的人有不同的理解,而往往有些理解的偏差是致命的,这就需要我们不能不懂装懂,而是要根据文字和自己的理解,和客户有个直接的确认。
三、Call High
这是一种项目管理的理念,就是和客户的高层确认,尤其是国内项目,大多数国内项目最终的成败不是由客户中的基层群体决定的,而是由几个甚至一个高层领导决定的,这就需要尽可能的满足客户群体中有决定权的几个人的绝大部分要求。
四、合理的拒绝
如何控制项目收尾阶段的需求变更,不能全部无条件的接受,而是要在适当的条件下懂得如何拒绝,但是这种拒绝需要几种前提,明确地合同内容,良好的客户关系,准确的系统分析和变更评估等,我的领导曾教过我一句话,现在想想很有道理,复杂的事情简单化,简单的事情复杂化。 这句话在不同的情况下,可以有多种理解,如果客户提出的变更太大,会对目前稳定的系统产生不稳定的变化,而这个变更又是合情合理的和需要做的,那么这时候,就需要仔细的分析现有系统,如何能够从现有系统中挖掘出这个变更,而不是首先想的就是要去动手做。简单化刚好相反。拒绝也是种技巧,需要反复的琢磨。
五、我不是客户
国内项目的需求调研,往往是很耗人力和时间的事情,因为部分客户会对自己想做出的系统没有个准确、明确的框框,一切都还是在概念中,所以在需求调研的最初阶段,一切都会很模糊,这时候我们需要做得一件事情就是挖掘需求,在了解该行业 企业的基础上,在客户提到的边边角角处去帮助客户整理需求,让它清晰化,但是这时候,切忌不要把自己真正的摆到了客户的位置,一定要时刻记住,我们不是客户,我们只是开发商,帮助客户挖掘需求没有问题,但是所挖掘并提给客户的这些需求必须是自己的开发团队能够实现的,否则可能你的一个自认为很好的提议,客户也很满意的需求,到最后无法实现,很难收场。
六、良好的心态
在项目进展不顺利,加班不停的情况下,如何保持团队的成员们还能有信心,有激情的投入到开发中,是件很难的事情,这时候作为Project Leader就需要想办法调节团队中的气氛,适当的放松,吃顿饭,唱次歌,平常的嬉闹等,都是调节心态的方法,这个会因人而异,不同的人会有不同做法,但总之就是尽量将大家的负面情绪打散,不能集中爆发。
上面说到的,也只是我个人的几点感受,不能笼统地套在所有的项目上,其实还有满重要的一点就是 “计划没有变化快”,项目计划是保证项目开发进度的重要标准和依据,但是我一直认为 计划是死的 人是活的,而一个项目的成功还是取决于 人——包括客户,开发商,监理等会影响到项目成败的各种角色, 所以如何灵活的掌控计划和进度也很关键。
好久没有写东西了,就胡说八道一番吧 ,算是给自己一个交待。
Francis |
|
|||
|
|