我与项目管理

我的第一个项目

曾经一段时间，我一直认为，决定软件项目成败的关键因素是技术。那时，软件项目对于我来说，就是一个人的战场。

人生的第一个说得过去软件项目，应当是大一时数据结构课的课设。那时的情景还历历在目：只会C++在CMD中黑底白字输入输出的我，接到的题目是设计一个带GUI的电子字典程序。当时的我心里是很没底的，因为真的不会。但课设不得不做，我一头扎进代码中，整整两天的时间，我基本上没怎么合过眼，所有的心思都在这个项目上面。不断的在查资料、写代码两种状态之间切换。陷入了一种被心理学家称之为流（Flow）的状态。

在单一思考的工作时间里，理想情况下人们处于心理学家称为“流”（Flow）的状态中。在这种状态下，有一种普适幸福感存在，人们几乎不会意识到时间的流逝。

现在回过头来看，那两天应该是我大一学习生活中，代码能力提高最快的两天。从小到大，我们学习的方式都是老师教，学生学。这种教育模式让我一直无法理解，学来的东西到底有什么用。我听过对此最合理的解释是：是的，没用。但能够提高你的学习能力和思维能力； 这对我的学习热情是一个不小的打击————学习的回报来的太迟了。可是，当以完成一个软件任务为目标时，学习的回报是立竿见影的，这些回报带来的精神满足感也会激励我去学习，从而获得更多的精神满足感。这种循环让我坚持了两天的时间，这两天的时间，我都处于一种极度亢奋、专注的状态。这在高中时代，是不可想象的，我在课堂上会睡着好几次。

这个项目从完成课设的角度来看，是非常成功的。我在网上找了一本txt格式的四级词汇手册，把这些数据结构化，方便查找。并且用数据结构学到的知识，成功把查找的时间复杂度，降到了O(log2n)，最后用QT写界面，把查找算法封装。并且，我还增加了词语联想的功能，能够自动补全单词。最后，我用样式表修改掉了原来丑陋的UI。老师对我的结果很满意，给了我优，在我们班只有5个。

我用的是QT，因为我只会C++。MFC是时代的眼泪，我没有使用。事实证明，使用QT是非常明智的，上述自动补全这个功能看起来很复杂，实际只有几行代码就能实现（QCompleter）。感谢QT拥有强大的类库。

我记得那时做完软件的我意气风发的写了一篇博客，总结项目经验，大致观点有以下几条。当然，现在看来，这些观点有些错的很彻底。

• 项目成功与否取决于于技术的高低。
• 新的技术总归是好的，要尽量使用。
• 任务驱动型的学习效率比上课要高得多。

这大致就是我第一个项目的经历。我想，我对软件项目的热爱可能就是从这里开始的。

是什么决定项目的成败

也许……软件系统的主要问题不在于技术，而在于社会性因素。 -《人件》前言

当我第一次在《人件》中看到这句话时，我是崩溃的。他直接否定了我从第一个项目中学习到的经验——“项目成功与否取决于于技术的高低。”带着好奇，我很快的看完了这本软件项目管理的“神书”。这本书讲的很透彻，我也明白了我为什么会错，虽然知识理论层面上的。

因为我的第一个项目只由我一个人完成，我只需要自己查、自己写，项目概念的完整性只存在于我一个人的脑海中，不需要任何交流，大部分时间都在写代码。

而在真正的大型软件项目中，庞大的工作量需要大量的人合作编写。由此，大量的时间被用于交流。真正编写代码在整个项目中只占很小的一部分。如果交流不善，技术再高超，也会因为思路上的分歧使得项目流产。

所以，“是什么决定项目的成败？”这不是一个技术性的问题，而是一个管理性问题，需要用管理学的知识去解答。而管理的核心，就聚焦于项目经理这个独特的职位上。

我与管理

管理者的作用并不是让大家去工作，而是创造环境，让大家可以顺利开展工作。 ——《人件》

感谢《人件》这本书，为我打开了软件管理学的大门。从此之后，我开始尝试着去了解这方面的知识。我开始使用Git来进行团队协作，即使没有人与我合作，Git的版本控制也是极为好用的；我开始读《人月神话》，去了解一个软件项目团队应该使用哪种架构；我开始明白测试的重要性，开始为代码设置各种围栏，开始用单元测试验证代码的可靠性；开始主动的与他人交流，培养自己把思想传递给别人的能力；开始主动站出来担任一个小组的组长，安排组员进行工作。

我发现这些知识不仅仅能够用在软件项目管理上，也能用于其他的方面。比如，数学建模比赛，我们使用版本控制工具来实现团队合作和版本控制，效果非常好，大大加快了我们论文的写作进度。又如，在日常生活中，因为侯世达定律，我会使用甘特图来规划每天的学习生活。

做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。 ——侯世达定律

我认为不管是不是管理专业的学生，都应该学习一下管理学知识。因为它不仅可以锻炼我们成为项目经理的能力，还可以帮助我们学习和生活。

我与项目经理

在第一次上完软件项目管理公选课后，一位同学向我抱怨：这节课太无聊了。我和他分享了我的观点。

他告诉我，老老实实当程序员学技术就好，术业有专攻，让人家管理学的人来当项目经理岂不是更好。

我开始思考这个问题。软件项目经理究竟是由管理专业的人来当合适，还是技术出身的人当合适呢?

一次与薛老师的谈话让我明白：大多数项目经理都是技术出身。由于软件同其他工程不同，他是高度抽象的，是一群人思维的结晶，是最复杂的项目。如果项目经理不懂技术，他就不能把控整个项目。软件，只有当他运行的时候才能验证正确与否。他和造飞机不一样，造飞机你能够看到飞机一个零件一个零件的被制造出来，这是显而易见的。而软件，当完成一个功能模块开发时，他只有代码，几乎不可运行。如果项目经理不懂技术，他该如何判断这个模块是否完成了开发呢？

自此，我坚定了学习管理知识的决心。我意识到，除了程序员，我还有项目经理的路可以走。当然，要成为一名项目经理，首先要成为一名优秀的程序员，不然何以服众。

慎独

活泼、关怀、诚实、慎独 —— HFUT VCC实验室网站Banner

在学院VCC实验室的官网上，我看到了Banner上的一行标语，“慎独”这两个字让我心惊肉跳。

尽管我知道，团队合作能够迸发出惊人的能力，但我一直不敢尝试。

我不敢尝试，不是因为我不懂项目管理。正是因为懂一点，我才知道团队合作的甜与苦。

举个例子，我的另一门公选课，数字健康医疗导论。这门公选课中，我们分了组，需要完成一个“项目”：寻找一个与健康和计算思维有关的案例，做成ppt在课上分享。

拿到这个项目后，我站了出来领导整个项目。我打算“独”。从选题到制作ppt，再到演讲，几乎都是我一个人在做。其他的队员，只负责一些琐碎的工作，整个项目都是按照我想的来。我知道，这样对他们很不负责任，但我更想把这个“项目”做好。

我有私心在：我想靠着这个契机进入这门课任课老师的实验室。当然，最后也成功了，成功到甚至我还没开口，老师就直接问我愿不愿意进入他们实验室。

我选择“独”，因为我知道，这个项目我一个人有能力在预定时间内完成，并且我也相信自己的能力能够完成的十分出色。那么，就不要把时间花在交流上，为了保证概念的统一性，我宁愿牺牲团队合作。

概念的完整性非常重要。举一个反面例子。同样也是在这门公选课上。另一只队伍采用的分工合作的策略。但是，很显然，他们缺乏交流，导致概念的完整性破裂。最后的案例分享变得没有重点，一会讲这个案例，一会又讲另外一个案例。我反正听到云里雾里。

没错，团队合作是一把双刃剑。所以我一直很谨慎。

但是，我知道，“独”在小项目可能会很有用，但遇到真正大项目时，“独”只会使项目失败。“慎独”这两个字为我敲响了警钟，我缺少合作的经验。

还好，我还年轻。相信在进入实验室之后，我会逐渐吸取合作的养分。未来，有更多的项目等待着我去完成。

（ 全文完，总计3200余字。发布于我的博客：http://zouanning.me/pmp ）