软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣，所以程序员们才会乐此不疲，前仆后继。
首先，这种快乐源于一种创造事物的快乐； 其次，这种快乐来自于一种开发出对别人有用的东西时所带来的满足感；
第三，快乐源自开发过程中，亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力；
第四，快乐源自开发过程中持续学习的快乐；
最后，快乐源自开发过程中，我们能象诗人一样，仅凭自己的想像，来建造自己的城堡时带来的快乐。
编程的快乐在于它不仅满足了我们内心深处进行创建的渴望，而且还唤醒了每个人内心的情感。不幸的是，同样作为游戏它也有苦恼的一面：
首先，苦恼来自追求完美主义；
其次，苦恼来自总是由他人来设定目标、供给资源、提供信息；
第三，苦恼来自于寻找琐碎的bug却是一项枯燥的、重复性的活动；
第四，人们通常希望在项目接近结束时，能收敛得快一些，然而，情况却是越接近完成，收敛得越慢；
最后，苦恼来自当投入大量的辛苦劳动后，产品发布时却面临着陈旧过时的危险。作为软件开发者，我们别无选择，只有适应它们，就这样痛并快乐着地面对每一天。
来自领导的信息只有25%被下级知道并正确理解，从下到上的反馈信息不超过10%，平等交流的信息则可达到90%以上。平等造就信任，信任增进交流。有效地进行适当的意见交流，对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流，才是蠃得市场的关键。
——引自《管理智典》
管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是“遭受损失的可能性”，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：
一、风险识别
从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。
二、风险分析
对风险出现的可能性和潜在的危害性进行量化分析。
三、应急计划
如果识别出的风险真的出现，你将采取的应急措施。
四、风险缓解
为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。
五、持续的监控
跟踪需要管理的风险，寻找风险出现的迹象。
项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效地管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：
一、缺乏合理的进度安排
这是导致项目滞后的最主要的原因。
首先，它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现bug。
其次，它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担，另外，还有任务重新分配所造成工作中断带来的负担，正如alistair cockburn所说：“最有效的交流方式是面对面的交流”。当3、5个人的时候很容易做到这种交流方式，随着人数的增长，很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。
第三，源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。
第四，如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不仅应该将“可能需要做”的事情所需工作时间加上，还要将某些“可能不需要做”的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。
最后，项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外，也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外，需要指出的是现代敏捷方法论对此进行了有效改进，如xp(极限编程)中，就利用用户素材与crc卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个crc卡的功能点，得到总功能点来推导出比较准确的进度安排。
二、需求的变化
从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如xp(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。
三、人员的变更
在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。
另外，还有一种现象在中国软件事业中普遍存在。当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目地认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。
同样，现代敏捷方法论非常注重人的能力，如xp中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。
