先说一个故事，A公司承接了客户K的一个项目，要做一个财务软件，先开发WinForm端，然后在web端参考Winform实现类似的功能。为了保持产品的概念完整性和一致性，并且让最终用户（Users）不需要去改变使用习惯，客户要求web端要跟Winform端做成一样。
系统中有一个需求是创建一个向导，A公司的Web端开发人员在页面完成后，发现有些Bug怎么调试也调不通，而且整个页面的速度特别慢。后来寻求A公司高级开发人员的帮助，调查发现这个页面承载了太多相互嵌套的控件，而且业务逻辑过多，结果就是页面很复杂，这导致相关代码有N千行，彼此牵扯特难维护，所以出现了很多牵一发而动全身的莫名Bug，同时整个页面的性能也变得特别慢。
A公司只好建议客户K把该页面拆分，但是客户K要为此付出很多额外的时间和费用，这些都是在K客户最初的预计之外的，最后导致客户K的很多不愉快和接下来的很多谈判。
从这个故事中我们能学到什么？是哪里出了问题？
1 – 把一个需求搞得太复杂、太庞大是应该极力避免的事情，一方面增加了实现和维护的开销，另一方面也会提高最终用户的理解和学习成本；所以把需求简化对于一个成功的产品来说是至关重要的，这也是产品经理的价值所在。在这个案例中，显然缺乏一个良好的产品规划，如果团队中由于各种原因没有一个明确的产品经理来负责产品的构思和设计，那么这个工作一般都会无形地分摊到每个开发人员身上，因为他们在实现的时候，必须决定页面的布局是什么样子，以及如何与最终用户交互。由于一般情况下开发人员都缺乏产品设计的经验，所以这种分散带来的结果通常都是 - 产品缺乏一致性，关联功能的交互复杂而混乱。所以第一个教训是一定要有个统一的对产品进行良好规划和设计的过程(无论是产品经理来负责还是几个人一起讨论都可以)，而且一定要简化产品功能，避免复杂性。
2 – 在现有的技术条件下，想在Web端达到跟Winform一样的效果，还是很困难的；这个想法虽然可以理解，但是实际在做的时候，需要进行很多折中以及功能层面的简化；“照着Winform端去实现Web端”的想法看起来简单易行，实际上却风险重重，类似这种案例，Web端最好能独立于Winform端去并行考虑和设计，同时要进行必要的精简。当然独立规划Web端的时候，与Winform的概念一致性是重要的考虑之一。
3– 按照客户的要求做没错，但是一定要加上自己的思考和判断。如果在实现之初，承担任务的开发人员就充分评估页面复杂性将带来的风险，并且把这个风险与客户充分沟通清楚，那么很可能会避免这种情况，至少充分沟通过后，客户不会完全不买单，这规避掉后期很多不必要的纠纷。
这是我实际遇到的一个案例，分享给大家共同学习。身边自己亲历、看到、听到、跟朋友讨论到的软件项目开发案例还有很多，以后会慢慢跟大家交流，也希望朋友们能不吝分享你的故事给我们参考。