说实话，这是一个很敏感的话题。
“设计”这个词比较害人，基本涵盖了软件从需求到最终交付前的所有阶段：需求分析、系统功能设计、架构设计、模块设计、代码设计、代码实现、测试设计……
最害怕的就是一种说法：某某 能力是设计出来的（这个某某可以代表任意功能或者质量属性）。
这句话说的不无道理，但要看怎么解读，但是很多管理者将此当做借口，软件出现任何问题就是设计的问题。从而主动丧失了对于软件产品的控制力。
不少团队中，有专职的“设计人员”，在“设计”这个概念没有明确确定时，“设计人员”和“开发人员”经常会产生矛盾，即设计得是否充分了。这是矛盾的根源。
从我的理解来看，“设计”决策，涵盖范围很广，不能用一个专职的“设计人员”或者独立的“设计阶段”解决所有“设计问题”。
从经验来看，软件产品的60%~70%的技术决策应该提前完成，剩下的30%~40%只能通过“开发人员”和“设计人员”在后期的探索和分析才能妥善解决。
矛盾的解决根本不在于- 硬生生的在“设计”和“开发”之间划出一条线，分辨出哪些是你的，哪些是我的。这是有灰度的，需要人来沟通协调。
解决的源头是， 大家确定基本原则，对于交界处的设计工作可以统一处理，协同作战。只有默契协作，才是解决问题的根本。
我的处理经验是：
- 在设计阶段，带领开发骨干一同完成“设计”工作。
- 让开发骨干将设计思路、设计理念、设计要点带入到开发过程中，这样通过他们的传播，有利于让开发团队更好的把握设计目标，抓住需求要点。而通过传统的文档传递，效果还是有限的，毕竟信息存在丢失，开发团队也不容易记住。
- 对于开发过程中遇到的“设计问题”，开发骨干、开发团队、设计人员要一起讨论解决，不要一遇到问题就相互扯皮。
- 将开发过程中的“设计决策”权利，适当的交给开发人员，至少绝大多数的设计提案应该有开发人员提出，不要搞“设计垄断”，开发团队的能力要充分发掘出来，要帮助开发团队培养技术决策的能力，否则累死设计人员，也无法做完所有的设计决策。
- 问题解决后，在阶段点需要带领设计人员、开发骨干、开发团队一起进行总结和反思，看看前期设计阶段如何改进，提前识别后期风险。
当我看到开发人员和设计人员相互抱怨和指责的时候，我都比较痛心，软件开发没有多少时间，更为主要的还是尽快解决问题，平时相互促进、共同提高。
软件开发不是盖楼，编码也不是搬砖砌墙，设计也很难完成所有规格参数的制定。（日本的软件设计除外，这是他们的追求，在这里就不做评价了）。
如果“开发”和“设计”被划分成两个不同的阶级，将是一种灾难。