标签：需求 问题 技术 原因 注意 架构设计 升级 架构 设计
在《构建之法》中，提到了一个案例，大意是程序员小飞在实现功能模块的过程中，发现原来的设计中的“弱点”，如果调整，将会影响交期；如果不调整，小飞可以按时交付，但会影响该模块被集成的效率，影响后续及整个工程效率。该怎么办？
这是个非常典型的案例，仅今年下半年类似问题在我们团队里处理了至少2次，一次与硬件相关，一次与软件服务相关。这2次我们的处理方式均是一样：按时交付、随后立即优化。必须明确的是，我们这样做，不代表这样是对的、是普适性的，而是这2次我们所面临的客观原因，使得我们必须这样去做。
我个人理解这个问题，是一个产品交付问题。产品交付，都有一个计划时间及一个deadline。若计划时间提前于deadline，例子里的小飞大概率是要作调整的；若计划时间大于deadline，不调整，增加的是产品成本，调整，市场里可能没有这个产品什么事儿（我们今年就是在某区域市场里，临时被通知必须在截止时间前完成交付，否则下次再来该区域就是一年后了）。以上，基本是职场人员的共识。
更进一步，为什么在实际产品实现过程中，会遇到需要在中途作较大调整的情况。就我遇到的主要有2点：1、对同一需求，理解不到位+沟通不到位；2、对细节的忽视。
理解不到位，包括PM对客户原始需求理解不到位，也包括技术负责人对需求规格理解的不到位。需要做较大调整的，很多时候是对整个业务逻辑的理解存在偏差。导致一开始从架构设计到流程设计都走偏了。所以，针对这种情况，后来我在做初期的市场调研时，至少会带技术负责人一起跑一次，让他对市场的原始需求有一定程度的了解，这样在后期对大量的需求进行讨论时，有一个基本的背景认知。事实证明，后来我在与其他程序员在沟通同样的业务需求时，往往需要花费更多的时间去让他们理解业务场景。
对“细节”的忽视，这里我将细节打了一个引号。确实，对于一般的细节，会让我们多加加班，不至于说引起较大的调整。但就怕是一个你没注意到的大问题，被误以为是个细节问题。我们产品终端在一次升级过程中，除了功能的变动外，还将键鼠操作改为键鼠+触屏。当时大家都把精力放在功能的实现上了，忽视了触屏操作的优化，都误认为键鼠都用了这么多版本了，这次只是换了个带触屏的PC机。结果投入到市场，客户对触屏操作的兴趣远大于键鼠（这里面也有我们键鼠操作），但毫不例外的反馈触屏操作的优化是个必须解决问题。后来我们针对触屏操作的习惯，对整个界面及交互进行重新设计。最后证明，我们自己都回不到键鼠操作的版本了。
先就我所见、所感写到这里，继续埋坑~
标签：需求 问题 技术 原因 注意 架构设计 升级 架构 设计
原文地址：https://www.cnblogs.com/music-heaven/p/10146896.html
