非常张

今天去公司参加PDCA的培训, 收获很多, 但是印象最深刻的是一个tip: 时刻注意关键路径.

第一次听说这个词还是在大四的时候, 当时开了一门dsp设计的课, 为了凑学分大家都得去, 因为当时已经开始实习, 这门课我一共也就听了不到十分钟, 只记住了一个概念, 就是关键路径(Critical Path).

虽然记住了这个词, 但是理解并不深刻, 似乎就是在一个系统中从输入到输出存在很多条路径同时工作, 那么数据流的传输时间就取决于消耗时间最长的那条路径, 即关键路径. 换句话说, 关键路径优化的好, 整个系统的效率就高, 关键路径没有优化好, 其他的路径再怎么改进也没戏.

今天的课程里讲的是:我们在日常的工作和生活中, 经常会有很多条线索同时进行, 会有很多资源可以调度, 也会有很多冲突, 那么从一个相对较大的时间跨度上来说, 最终目标能否达成就取决于你对关键路径的控制.

虽然是很浅显的道理, 但对我这样乱七八糟的想法比较多, 导致经常自己搞出很多活的人来说, 还是很醍醐灌顶的.

比如每周对自己的工作进度进行控制, 与主管之间保持一致, 实际上是应该把握住彼此的关键路径, 而不是在一些分支上花费太多时间.

通常的情况是, 我会被一些并不重要但是很有趣的事情, 或者一些不紧急但是非常重要的事情拖住脚步, 比如一些很有用的小工具, 或者从头review整个模块的设计和历次较大的改动, 这都是让人情不自禁去做的事情, 但是很容易使人迷失, 导致关键路径上的事情没有进展, 而在分支上花的时间反而超过了关键路径.

其实对于这些事情, 我的经验是, 对一些确实有用的小工具, 需要你自己来承担风险, 也就是说你很难事先就从主管那里要到资源和时间去做, 因为这些东西是better而非must的. 所以往往需要自己额外找时间去做, 等做到主体功能都ok了, 完全可以work时, 才能show出来, 进而去争取更多的资源.

而对那些重要而不紧急的事情, 需要你有足够的实力来说服主管和同事, 让他们相信花时间来听你的分析是值得的, 因为类似模块设计级别的东西往往很抽象, 在这个级别的一次高强度的讨论是很消耗体力和脑力的. 所以这之前可能需要你自己多消耗很多体力和脑力….

例如有一个模块先后进行了几十次改动, 但是一直都有新的问题冒出来, 那么往往就是走错路了, 一定在早期存在某些简单而草率的改动, 使得后来产生了很多问题, 进而陷入了更困难的境地. 这个时候就需要做很多的推演, 去统计很多场景, 找出这些改动的缺陷所在.

最后还有一点比较深的感悟, 就是SMART原则, 大意就是要有具体的,可衡量的, 能达到的, 有关系的, 有时限的目标.

虽然我对口号一类的东西比较反感, 但是对一个软件模块的设计和维护来说, 有一个明确的可以衡量的目标是至关重要的.

如果我们有心去观察某个模块的改动记录和改动理由的话, 会发现很多时候它的目标都是互相冲突的, 这次是为了效率更高, 下次可能就变成了维护的方便性, 而过一段时间又会基于兼容性做一些改动, 等到项目transfer给另一个人, 又会发生更大的改动, 大概就是类似布朗运动的那么一个轨迹.

以一个display driver为例, 我们说要考虑效率, 那就应该对应于每次application请求update时得到响应的时间, 这个时间的期望和方差应该都是比较小的.

再比如说我们希望减少带宽的占用, 那应该定义出每秒钟update的数据总量, 然后给出每种设计方案下每秒钟update的数据总量的近似值.

另外还有对multi-thread情况下的效率和安全性, 硬件加速的性能, 内存的占用量, 等等等等.

这些指标应该有一个总的表格, 当我们需要在几种设计方案之间做出选择的时候, 可以讲每种方案的利弊都列出来, 然后选择那些真正优秀的方案, 而如果仅凭口头的讨论, 人们的思维往往只局限在两到三个局部因素的比较上面, 几乎无法做出从全局角度来看更优秀的选择.

zhangxuecheng 随笔