最近和朋友聊天,发现大家普遍遇到比较多下面一些情况。 『这个功能不是已经实现「差不多」了吗,再加个功能很快吧』; 『以前做过「类似的」功能,这次项目可以复用以前的模块咯』; 『怎么要这么长时间,这个功能以前不是做过的吗』; 『都快 deadline 了还没做完啊。再加个人,一定要按时发布』; 『我们团队已经这么多人了,怎么还完不成这么简单的功能』; …… 遇到上述情况之一,不仅管理者无奈,作为工程师其实也很无奈的。有些事情真的不容易解释清楚,比如:动态需求和动态需求管理。 如果定义我们看到的产品需求是*静态需求*,那么从一个静态需求向另外一个静态需求迁移的过程,就会产生对应的*动态需求*。过去工程师们一般会将这种需求称为*需求变更*,不过这种说法容易导致产品经理的抵触,因为一个产品实际中总是充满各种变化的,不能很好执行*需求变更*的技术团队不是好的技术团队。为了避免这种误解,我们称呼其为*动态需求*更好一些。 解释一下为什么通常*动态需求*会让工程师抓狂,这事儿就好理解了。 一般来讲,完整的项目需求给到工程师,架构师会首先根据项目的需求进行系统架构设计,一方面尽量实现项目的需求,以满足各相关方的利益表达,另外一方面还需要结合项目的发展规划、团队实际情况、现有技术架构等情况,尽可能多地实现非功能性的目标,包括可维护、可扩展、安全性、稳定性、易用性、质量控制、灾备方案,甚至团队构成、成本核算。有句话叫『没有最好的解决方案,只有最适合的』。针对每个具体的场景和需求,一定会有一个相对合适的方案,而这个方案也就是具体到这个场景和需求的,如果简单地把方案挪用到其它场合,就配不上『最优』这个形容词了。 所以,当一个适合某场景的方案产出了成果,我们要直接复用它,拿它为另外一个场景服务,这就是一次从『最优』到『次优』甚至『不优』的迁移。也许这两个场景中一些需求是存在一定程度的重复,因为各个因素的关联性,为了保证迁移之后的方案能相对『较优』,一定是需要额外付出劳动的,而且往往,这种付出对应的工作量还不小,很多迁移本身就是一次大工程。 这也解释了为什么很多工程师往往愿意选择自己重新造轮子,也不愿意使用别人的代码,因为使用别人的代码需要读代码、抠细节、做迁移,当然也包括承担和消化前人遗留下来的谬误。 对于很多创业公司来说,忽视动态需求的危害已经到了能够影响公司自身发展的地步,却很少有人能意识到。最近几年大家对*非功能性需求*普遍比较重视,因为有人通过*技术债*的概念将它抽象出来。可惜需求到需求的迁移产生的代价,还在水面之下,不为众人所见。 后面有时间再讲关于如何处理动态需求带来的问题,以及动态需求的管理。……

阅读全文