前松后紧和前紧后松——想起PM的点滴

简单谈谈开发流程和管理中几个一般性的原则。

 

1.  前松后紧原则
    做事情有时候真的要看好方向。方向错了，会严重影响项目进度和投入产出比，你努力工作的成果也许几乎无用，这也是很多项目失败的根本原因之一。所以，负责任的PM们总是小心翼翼地反复评审着需求文档和设计文档，因为这是项目或产品成型的前提，是开发的最原始驱动力。从项目时间分配的角度来讲，这就存在一个前松后紧原则。多预留点时间在此处要害，总比做完了又推翻来得有余地。不愿意花功夫在这上面，早晚必自食恶果。
    由此也衍生出来一个架构设计的行当，它完成系统和平台选型、总体方案设计、关键业务逻辑分析和风险点评估等重方向的工作。然而架构设计不是凭空而来的，它需要长期产品优化和改进积累起来的宝贵经验，需要迅速搭建模型验证方案关键技术的实施能力。所以一般来讲，优秀的架构师首先是优秀的产品优化人员。没有做过系统的性能优化，你都不好意思说你是架构师。

 

2.  分离原则
    谈到性能调优，首先要重视程序结构和业务逻辑，其次才是程序细节。如果程序的架构都有问题，优化不知从何谈起。
    Daemon进程是一种比较普遍的设计，但是也会带来一些隐患，比如内存泄露的话就会一直泄露，直到系统内存耗尽。解决的办法之一是分解daemon程序，只将监听和接收部分留下，繁杂的具体业务处理另由其它程序处理，只在需要时才调用它，用完了马上销毁。这是通常说的分离原则应用场景之一。
    还有一个结构性的问题也应重视，那就是主机的应用种类。应用不同，决定了性能调整的方向不同；而对于不同的调整方向，调优使用的方法和工具也可能大不相同。比较常见的有两种典型应用，服务器（server）型和终端（terminal）型。不要迷惑于某些优秀的工具为什么你一直用不上，也许你的环境和资源本就不允许。
    回到研发流程管理方面来说，一般的IT研发过程是：需求分析-系统设计-详细设计-编程实现-单元测试-集成测试-交付使用-产品服务，再加上编程设计与测试的反复迭代。很显然，研发流程的按步就班本身就是分离原则的一种体现。对某些关键步骤的再分解，细化一些业务和分工，跳开传统PM的一个人一条龙到底的观念，做出有针对性的部署和处理，会大大地提高研发效率和团队的创新视野。

    分离原则在很多地方在默默地应用着，各有说法。但相信所有的分离，都是为了更好的整合。 

 

3.  前紧后松原则
    如果设计与编程是程序员的主要工作的话，那么接下来的Debug调试（Test测试则重点不同，由Integration Test专业人员完成），也许是产品化过程之中交付成果之前，程序员的临门一脚了。此步看似简单，实则暗流涌动。对于一个真正的项目来讲，没有哪份代码可以直接通过，而是必须经历一段不轻松的Debug历程。而且即使交付给Test人员后，反馈回来的必将是一堆问题，仍然要继续De-bug。有经验的PM一般将调试与编程的任务时间比例定得很高（2~5），这叫做前紧后松原则。
    当然在中国，特殊的发展阶段和丰富廉价的人才使得Boss们将Debug时间定得很紧，至于Test反馈问题后的Debug时间一般不在项目规划内，码农们只能通过无穷无尽的免费加班来完成。这是闲话，还是少说为妙。

  

    最后简单说，如果想一个项目成功，请PM们重视需求和调试，而不仅仅是完成编码，不然害人害己。当然，说说总是容易，而且没有一成不变的原则，有些具体事务的处理总是相对的。比如模块和业务分离，在资源相对紧张的情况下，过度的分离也许会拖慢程序的启动速度。