从软件项目管理课引发的一些感想

引言

今天是软件项目管理课的第一节课。一节在看似普通的软件工程专业课，却给了我无限的思考空间。

我们的老师是一位经验丰富的老教授，在我们学校也算得上德高望重。老教授的课果然给了我想不到的惊喜。第一节课，老师就通过一个游戏，让我感受到了软件项目管理的意义。

游戏是这样的：我们班里所有的同学，轮流到黑板上写代码，每人只能写一句、修改一句或者删除一句，来完成一道简单的编程题。但是，规定人与人之间不能沟通交流，只能依靠自己的想法来完成自己的动作。

游戏的结果可想而知，无法沟通的我们在黑板上写一句改一句，写一句删一句，始终无法完成代码的编写。

当我正在思考为什么会发生这种情况时，我突然想到前不久读过的康威定律。

康威定律

康威定律是马尔文·康威1967年提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗地来讲：产品必然是其（人员）组织沟通结构的缩影。

当时我对这句话只是一知半解，不理解“沟通”为什么能够对设计系统的架构产生影响。因为对于完全没有参与过企业级项目开发的我来说，开发就是一两个人的事儿，有时候甚至一个人咬咬牙也能扛下来。

当我听到下课铃响的时候，我回过神来。我仿佛明白了什么：大型软件项目开发中，内部的沟通才是不可缺少的，而且是所有成本中占比最大的部分。

这不禁又让我想起了“人月神话”——软件项目的体量都是通过人*月的指标来衡量，很容易让人误以为人力资源和时间资源是可以相互弥补、相互转换的。这显然是错误的，其中很重要的一点就在于，当一个软件项目需要大量的人力资源时，内部沟通的成本会占据项目开发的很大部分。

题目的解法

于是，我有些领悟到了解答课上这个问题的要点：

1. 因为人与人之间无法沟通，因此需要尽量使用约定俗称的方式进行代码编写，弥补沟通成本大的缺陷，不能完全按照自己的想法编写代码。
2. 有了Scrum开发模式的经验，就知道一个能够运行的程序好过一个追求完美但是不能运行的程序。在完成题目的过程中，一开始要尽量多写一些代码，而不是频繁地修改代码。等到一个完整的程序诞生后，再开始修复那些隐秘的Bug。

一点小想法

也许一个人的成功与否也不仅仅能够靠他的智商和努力程度来衡量，关键在于他内在的性格驱动。不要以为有了努力和智商就能成为佼佼者，因为真正促使一个人成功的，只能是永远驱动着他向着成功迈进的性格。

像我的性格就过于“佛系”，总不想着争第一，结果就算再努力，事事也都落得个第二名，可谓“千年老二”。

如果真的想成功，就必须要改变自己的性格。虽然改变的过程必定是痛苦的，伴随着人生的阵痛，但是结果也许是美好的，而且好的性格会让人受益终生。