项目经理需要了解的开发经验

在 IT 公司中，管理层和“自命清高”的技术人员之间的沟通和协调永远是一个值得讨论的话题，先后从事过技术和管理工作的资深产品经理韩伟分析了技术人员的管理之道，包括何时以及如何评审、分层开发、尽快运行、追求代码质量等。

韩伟首先分析了管理层和技术人员之间的代沟：

在互联网项目当中，相信每一个项目经理或者制作人，最头疼的就是技术部的管理。因为技术工作看起来是那么的棘手，一般人难以理解，而且技术人员大多数都似乎情商不高。管理人员既不能轻易了解技术工作的内涵，技术人员也觉得很难和管理人员沟通。特别是技术工作，难以在不同人之间交接，很多技术人员都声称无法继续别人做过的项目……要管理好技术人员，就一定要懂技术。这是任何一种其他号称完美的管理方法都无法替代的。

开发文档的问题是一个老问题，韩伟根据文档的不同类型谈了自己的看法：

• 设计类文档：这类文档往往在项目、模块启动的时候，大家都会想到要去写，作为讨论和最后决议的成果，显然是很自然的。然而在项目进入开发之后，碰到实际问题时，往往就不能完全按照设计的初衷去做了，所以通常设计文档就在这个时候和代码脱离了联系。但有一点是绝对可以做的，就是在重构的时候，按照现有状况，重新增加重构前的系统状况说明，然后再添加上重构后的设计。这样就把重构的设计和文档的更新结合到一起了。
• API(应用编程接口) 文档：现代软件都希望能提高重用的程度，因此很多程序员都会自己构造自己的业务 API，以便在之后的开发中使用。而这种业务 API，也是很多分工合作的基础。这种代码的说明，会直接影响日常的开发，因此非常有必要保证和代码的高度一致性。
• 使用文档：一般来说，一个软件的使用文档必须包含以下几个：《产品版本说明》、《产品安装和部署文档》、《产品使用教程以及例程》、《产品 FAQ 文档》。这里面的《产品版本说明》应该在每次发版的时候，作为发布流程的一个固有环节来设计。《产品使用教程以及例程》是我认为所有文档中，最值得花大力气去写好的。《产品安装和部署文档》内容越少越好，应该让安装部署尽量智能化、自动化。

其次，韩伟认为，了解软件架构的范畴，才能有针对性地去把握软件开发中的风险，从而管理好软件开发的过程。根据软件需要应对的需求，软件架构一般包含以下几个部分：

• 逻辑架构：主要是为了明确“功能性需求”而做的设计，针对需求以及需求变化作为架构目标所做出的关于代码之间的划分、耦合、关联的决定。采用合理的逻辑架构，将会大大降低需求变更对开发的延迟作用。逻辑架构最直接指导代码中互相耦合的情况，仔细设计好耦合的规则，会让后续开发事半功倍。
• 运行时架构：运行时架构是为了满足运行期的质量需求，所做出的关于对象行文、进程结构、通信协议、数据结构等方面的决定。运行架构一旦确定，等于大部分的“实现”代码都确定了，设计有足够扩展性和可用性的运行架构，可以为后续工作节省时间，也降低了系统在运行期对开发工作的干扰。
• 开发架构：为了满足开发时的需求所做的决定，主要是软件根据分工开发、测试验证流程等需求划分的软件层次和区域以及各种接口设计，也包含使用的软件包、组件库、开发工具，以及编译构建的方法。一个好的开发架构，可以让沟通成本降低，开发速度提高。
• 部署架构：现代软件系统，基本上都包括了客户端和服务端程序，如何快速、高效、稳定地部署和发布这些程序，如网络机房的分布、服务器硬件的搭配、监控和维护工具软件的安装、开发测试网络和运营网络的设置。可以获得安全性的配置，良好的部署能力，能推动软件进行更频繁、更全面的测试，从而提高软件质量和开发效率。
• 数据架构：数据是软件项目的核心财富，关于数据的结构，数据的存放、备份、传输会直接影响到运行性能、业务功能、部署、安全等需求。在面向对象的开发模式下，数据到对象的 ORM 架构也是很重要的设计。一个完整的数据架构包括了数据流图、数据字典、ORM 结构 (如果需要的话)、数据索引和备份机制等几个方面。

相信大部分公司都有评审这个环节，评审可以包括方案评审、代码评审、项目专项议题的评审，比如对存留 Bug 的处理评审等。而这些评审，常常会变成一个挑毛病的会议。要解决评审给产品带来的负面影响，同时发挥这个活动的优点，韩伟指出，需要注意以下几个方面：

• 评审由谁发起：相对比较好的是，由负责此项目的“领导”来召集人员评审，并且一定要有负责开发的人员参加评审。参与评审的受邀请人员可能会与方案提交者就一些问题有分歧，但提交者有最终决定权。要把权力给有能力承担它的人。这样做可以让“防止风险”的一部分人和“注重效率”的开发人员形成平等的意见交换。
• 什么时候做评审：应该在每个迭代、每个较大的版本开工前，或者仅仅是某个认为比较重要的决定做出前，都来一次简短的评审。如果开始时只是做一个 DEMO，那么需要评审的东西也比较少，而随着不断的开发，评审也能遍历所有的开发。
• 做评审的方法：真正对项目有帮助的，是了解项目的需求，分析面临的难点，思考方案为何这样做，提出自己的解决方案，给项目开发者以建议和启发。多说“我建议这样解决这个问题”，而不要仅仅去说“这样做可能有问题，应该添补这样的功能”。以建设性的心态和思路去做评审，而不是以找问题的思路去做，这就是两种做法的最大区别。

除此之外，韩伟还讨论了分层开发、尽快运行、非功能需求决定成败、追求代码质量、搭好测试这个安全网、自己掌控开发方向、告别救火队员、绩效评估等问题，管理层在了解这些知识之后，可以更加得心应手地管理技术人员。