程序员的思考 - 人件

“人件”是国外一本著名的讲述软件工程的书的书名。所谓人件，即是软件项目开发过程中和人相关的一些事情，现代说法即“软件工程”。

事实上，软件开发的关键是“人”。软件开发过程中用到的硬件－PC、服务器、网线、路由器；用到的软件－操作系统、开发软件、数据库管理系统等等这些都可以花钱直接买到，成本大小清晰可见。另外，软件项目中涉及到的技术，开发语言、框架、协议、算法等等，只要不是非常尖端的技术，理论上都可以加以研究、利用，无非是花费的时间精力不同，适不适合项目的问题。唯独是人－是一个变数非常大的方面。因为所有的事情需要人来完成，硬件需要人来搭建才能利用，技术需要人来研究才能利用，软件开发的核心是人，最大的成本也是人。所以在软件行业诞生了一门专门的技术－“软件工程”，研究的就是如何组织人员来高效完成软件项目。

1. 人员构成

一个软件项目，是由一群人来完成的，这批人担任的角色是不同的，因此所具备的能力也是不同的。全部是高精尖的程序员可能反而完不成项目。最基本的人员构成，三类：经理、程序员、文档和测试。经理即是用来组织人的人，他来带领团队从项目开始走向项目完成，他需要很理解业务需求，并很了解团队中的人，他需要制定项目计划，定义各个人员的职责，组织各类项目会议等，他不需要很精通技术，但他必须很了解每个人，他做的所有事是管人；程序员，即担任软件设计、开发的人，这部分人是需要精通软件开发技术的，包括各个方面，开发语言、数据库、协议、版本控制等等，他们负责实现项目需求的各个模块。程序员中需要一个主程序员，技术全面的，明白整个项目需求并制定项目技术框架的，这个人将和经理一起，一个负责管理、一个负责技术来共同带领团队向前，他可以称为“技术经理”。文档和测试，即文档编写人员和测试人员。文档编写并非全部由他来编写，程序员也需要写文档，只不过由他来组织整理。测试人员很好理解，他模拟客户来使用软件，找出软件的BUG，敦促程序员来修正。

这是最简单的人员构成，不能再省了，适合初创公司。项目大了，公司大了，就需要再从每类细分更多职责人员。如经理可能有需求经理、技术经理、架构师；程序员可能有数据库管理员、编码人员、版本控制人员；测试人员可能有单元测试、集成测试等等。这些角色需要你根据项目大小、进度来灵活设定。

2. 人员沟通

项目开发中，人之间的互动是非常频繁的。协作是建立沟通之上的。但沟通必须高效，不然会浪费大量时间。很多程序员都会抱怨会议太多，编码时间太短，这就是沟通出了问题。团队坐在一起开发是最好的，是最高效的，沟通可以当面完成，团体中个人的技术能力不一样，在一起可以相互交流提高，这是很理想的状况。但现在也有很多软件开发团队是分散在各地的，如大公司下的各个分部不在同一个地方而协作开发的，开源项目中的项目成员甚至不在一个国家，可能连面也没见过。这样，团队沟通就需要通过别的方式，如邮件、即时通讯、视频会议等等。项目开发每到一定程度，项目经理必须组织团队层面的沟通，让所有成员全面了解项目的情况。

项目经理必须避免的一个问题是：不同步，或称阻塞。即一个模块需要等待另外一个模块完成才能继续开发。这种情况会浪费人力和时间。这样必须协调让这个阻塞的模块继续下去，或者让开发这个模块的人做别的事。总之，不能有人员等待的情况。这样才能达到高效。另外，不能有项目成员敌视的情况。这是严重影响项目协作的地方。项目经理需要果断处理，首先出面协调，协调不了则成员调离。

项目的协作与沟通是项目经理的重要职责，这是项目的润滑剂，这是项目能否走向成功的关键因素之一。

3. 人员选拨

作为项目经理，在项目初期需要选择或招聘合适人员进入项目组，这是非常重要的一项工作。项目的成功与失败就在于这批人。什么样的人是合适的？这是个仁者见仁，智者见智的问题。有时候，很大部分取决于经理看不看得顺眼，或者说和经理合不合拍，则也是一个合理的因素。但客观来讲，我认为，态度决定一切。即首先得看这个人是否敬业尽职，肯干肯学，即他的态度是端正的，积极的；其次才看他是否具备某项适合于项目的技术或经验。即总的原则是品格大于技能。只要品格好，技能是可以后期学习加以掌握的；而品格不好，就可能拖累整个项目。

人员选拨需要有一个列表，项目中需要用到的各方面的人才，开发语言、数据库、图形图像等等。找到相关的熟悉该项技术的人当然是最好的，这样能加快项目进度。当然有时候可能短时间内无法找到合适的，就需要找人快速上手学习。技术经验都是从项目开发中积累起来的，程序员应该很明白这一点。

人员选拨应当避免找到偏激的人，或者说性格走极端的人，例如自信心膨胀，飞扬跋扈，趾高气扬；或者过度自闭，交流困难，或者品格低下，动不动就奚落人，人身攻击等，这类人的技能再好，但难以融入团队，无法和团队很好协作，也就不堪大用。项目团队必须步调一致，同心协力，成员之间互相尊重，才能做好项目。

项目成员之间的关系必须保持融洽，这也是项目经理的重要职责。

4. 开发方式

开发方式或者开发模型，是指整个项目向目标推进的过程，这是软件工程研究的重点。这是指导和组织人员参与开发活动总的准则。

目前大家比较熟悉的模型有瀑布模型、快速原型、迭代型、螺旋型，还有近几年兴起的敏捷方法，这些模型各有特点，相关资料也讲得比较详细，不再赘述。

采用哪种开发模型，现在已经不存在一个定式了，很可能是一种混合模型。在项目开发中，灵活地调整开发方式以适合项目需要是非常必要的，也是经常发生的。

总的来讲，现代的软件项目，由于IT技术日新月异，业务需求的变化也是非常快的。所以，希望需求一旦确定就不变简直就是梦想，因此，开发方式必须适应多变的需求。所以，传统的瀑布模型肯定是过时的，不能用的。快速原型法是一种比较好的方式，快速建立一个简单的模型，再在该模型上迭代开发，好处是能够很快触摸到实际的东西，用户也可以根据原型提出更加具体的需求，加快开发时间，减少需求变化带来的不确定性。但缺点是对原型的要求较高，设计不好就可能迭代过程中完全颠覆前面的设计。这里可能就需要引进风险管理，这又是螺旋模型的范畴。

另外，软件的重构是不可避免的。软件的设计不能一开始就完美无缺，后期总会因为结构、性能、易维护等原因产生重构。所以，过度设计是不可取的。最初关键的一点是满足需求，完成应有的功能，然后在应用过程中发现新的需求、架构方面的问题再加以重构。有一句话很适合软件开发－“在行进中开火”。即软件越早投入使用越好，这样能把现场中尽快暴露出来，软件才能快速改进，这也是现在的互联网企业中流行的产品开发方式。软件捂在开发人员手里越长越不好。

重构是一件非常重要的工作，在功能、性能、易维护之间寻求平衡。这是维持软件生命力的长期任务。人无完人，软件无完美，追求软件尽善尽美是程序员的终极目标。