如果你是非技术人员，我想说：
请不要对技术人员说“这个需求很容易实现”
当一个不懂技术的人试图对软件开发时间进行评估时，有一个很基本的直观指标在辅助他们：以体积或者数量为指标的复杂度。
要么是根据代码的行数，要么是根据参与的人数。
之前听朋友讲到一个真实的段子：公司老板让项目经理，统计每位开发工程师的代码行数，根据代码行数确定每个人的绩效。
另外一个常见的例子就是，产品经理问你需要几天完成这个需求，你说需要1周，那么一般接下来的对话就是，“给你加2个人，我要2天做完。”
不幸的是，开发的复杂度，唯一有效的推测方法是技术人员根据过去的经验。而且还不是每次都管用。作为一名十几年的技术人员，我知道，根据我之前开发过或者领导的相似项目，我可以估计出现在的这些功能特征各自要多少开发时间。然而，事实情况中，每个项目在开发过程中都遇到意想不到的事情。比如block issue，人员的突发情况，沟通障碍等等。这些问题，有时在项目开始前，根本不会有所预见。
除此之外，非技术人员会将“最快做完功能”来判别技术人员或者技术团队的能力，因为背后的“可维护性”或者“可扩展性”不是一眼看出来的。
如果你是技术人员，我想说：
请不要对非技术人员说“这个需求技术上无法实现”
参见多年前小马哥说的，在鹅厂，没有什么需求技术上是无法实现的。
很多时候，需求的真正限制，只取决于时间或者资源。
何况，需求并没有限制我们使用某一种技术去实现。
从15年前的Google, 到StackOverFlow，GitHub和各类垂直技术社区，可以说，任何技术问题都能找到直接答案乃至源码。
比我们当年在寝室啃MSDN英文文档找一个解决方案，幸福无数倍了。
所以，我们只是觉得现在想到的方案过于复杂，而且会带来高额的维护成本或者会带来一系列的副作用，才不愿意去解决。
正确的做法，绝不是急于否定需求。而是站在全局的角度：
分析需求的核心是什么？将非核心的干扰先排除掉。
将需求进行有效的拆分，尝试为每一部分找到一个最优解。
根据优先级，分步骤完成需求，降低副作用。
打开好奇心，切勿畏惧技术探索的困难
还是一句老话，无论是技术还是非技术人员，解决沟通问题的关键，在于看待问题的方式。
相关阅读
扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes
欢迎转载，带上以下二维码即可
1347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
