软件设计中“说不”的力量:拒绝坏想法的艺术

本文探讨了软件设计中拒绝不良功能实现的重要性,阐述了如何识别坏想法、避免技术债务积累,以及如何在团队中有效沟通拒绝决策,同时保持开发进度和团队和谐。文章基于实际开发经验提出了具体判断标准和实践建议。

软件设计中“说不”的力量

作者:Max Kanat-Alexander
发布日期:2011年1月20日

你是否经常遇到充满复杂功能、奇怪决策和难用界面的软件?是否曾因为电脑无法正常工作或无法理解操作方式而想对它破口大骂?又多少次想过“程序员怎么会觉得这种设计合理?”

如果你有过这些经历,接下来可能会想“这破电脑”或“那个做出这种设计的愚蠢程序员”。确实,程序员和硬件设计师在一定程度上应该为系统的疯狂行为负责。但多年深入参与软件设计后,我对实现不佳的功能有了另一种反应:不再对实现系统的程序员生气,而是问自己“是谁批准了这个功能?”谁在有权力阻止时却默许了它的发生?

当然,有时根本没有软件设计师,这种情况下系统几乎注定会出问题。但当存在软件设计师时,他们最终要对系统的构建方式负责。这项工作很大程度上涉及在功能进入系统前设计其结构,但还有另一部分——阻止坏想法被实现。多年软件行业经验告诉我:软件设计师词汇中最重要的词是“不”。

问题在于,如果给一群人完全自由去实现任何随机想法,他们几乎每次都会实现坏想法。这不是对开发者的批评,而是现实。我对个体开发者的智慧和能力充满信心,钦佩他们在软件开发中的奋斗和成就。但不幸的是,没有中心指导时,群体中的人往往会演化出无法充分帮助用户的复杂系统。

个体设计师通常能为用户和开发者创造一致且愉快的体验。但如果当其他开发者开始以错误方式做事时,设计师不站出来说“不”,系统就会自我崩溃,变成混乱的坏想法集合。因此,拥有有权说“不”的设计师至关重要,而设计师在适当时机实际使用这种权力同样重要。

只需对真正值得拒绝的想法说“不”,就能显著改善产品,这令人惊叹。

识别坏想法

在应用这一原则前,需要知道如何识别坏想法。幸运的是,有许多软件设计原则可以帮助你识别坏想法,并在真正需要时引导你说“不”。例如:

  • 如果功能实现违反软件设计法则(如过于复杂、无法维护、不易更改等),那就是坏想法
  • 如果功能对用户没有帮助,是坏想法
  • 如果提议明显愚蠢,是坏想法
  • 如果某些更改没有解决已证实的问题,是坏想法
  • 如果不确定是好想法,就是坏想法

随着时间的推移,人们往往会学会识别好坏想法,特别是当以上述内容为指南并理解软件设计法则时。

没有更好想法时的处理

有时设计师能识别坏想法,但仍因暂时想不出更好主意而实施它。这是错误的。如果只能想出一个明显愚蠢的解决方案,仍然需要拒绝它。

这似乎违反直觉——问题不需要解决吗?我们不应该尽力解决问题吗?问题在于:如果实施“坏想法”,你的“解决方案”会迅速变得比原始问题更灾难。当实现糟糕的东西时,它“有效”,但用户抱怨、其他程序员叹息、系统损坏,软件受欢迎度开始下降。最终,“解决方案”本身变成需要其他坏“解决方案”来“修复”的问题。这些“修复”又成为巨大问题。沿着这条路走下去,最终会得到一个臃肿、混乱且难以维护的系统,就像当今许多现有软件系统一样。

如果经常发现自己被迫接受坏想法,很可能已处于事件链的末端——即基于系统过去一系列预先存在的坏想法进行构建。这种情况下,解决方案不是继续“修补”坏想法,而是找到系统最根本的底层坏想法,并随时间重新设计它们。

理想情况下,拒绝坏想法时应提供替代的好想法——这样既具有建设性又能推动项目前进,而不是被视作开发道路上的障碍。但即使暂时想不出更好主意,对坏想法说“不”仍然重要。好想法最终会出现。可能需要一些研究,或者某天淋浴时突然想到。不知道想法从何而来或是什么,但不必过分担心。相信总有解决每个问题的好方法,持续寻找直到找到。不要放弃并接受坏想法。

澄清:接受与礼貌

所以说“不”很重要,但需要澄清几点。我并不是说每个建议都是错的。实际上,开发者通常非常聪明,有时确实能提出好建议。许多开发者提出完美建议并实现优秀方案。即使最差的解决方案也可能有好的部分,尽管整体不佳。因此,很多时候,实际说的不是“不”,而是“这个想法有一部分很好,但其余部分不太行。我们应该提取最佳部分,通过更多工作构建成出色的东西。”但仍需对想法中的坏部分说“不”。想法的一部分好并不代表整个想法好。提取智能部分,精炼它,围绕它构建好想法,直到设计的解决方案真正出色。

此外,与团队其他成员良好沟通仍然至关重要——有说“不”的责任并不意味着有权粗鲁或不体贴。如果持续毫无善意地说“不”,会分裂团队、引起不满,最终在与不满者的争论中浪费大量时间。因此,当必须说“不”时,最好找到礼貌的沟通方式——表达对输入感谢、提出改进建议、轻松让对方接受的方式。理解放慢速度解释事情(甚至对第一次不理解的人重复解释)可能令人沮丧,但如果有助于建立有效开发团队同时拒绝不良功能,就必须这样做。


评论部分

KurtB 2011年2月25日上午8:39
+1
这与高中辅导员办公室墙上的海报一致:“机智是提出观点而不树敌的艺术。”
我认为编码人员可以从学习如何引导思路这一社交技能中受益。根据经验,从防御立场说“不”或试图通过强制手段获得想要的东西很少奏效。
是的,我在辅导员办公室花了太多时间——或者可能不够。
-kb

Max Kanat-Alexander 2011年2月25日下午9:39
嘿Kurt。完全同意!有技巧地说“不”的能力确实需要更广泛培养。
-Max

Vladimir Dzhuvinov 2011年3月26日上午5:20
软件业务尽管主题“逻辑”,却常受未解决的情绪、固执和意识形态支配。我知道这一点,因为偶尔在自己行为中注意到这些。
在必须时说“不”并不容易,尤其当压力来自上级(老板)、客户或投资者时。或者来自女友。
我还观察到,有时选择不说“不”(或说“不”但显得不机智)不是因为不想,而是因为当时精神懒惰,不想构建好论证。

Mike W. 2017年7月21日下午6:22
今天刚用了这个,并给了这篇文章链接。
“如果不确定是好想法,就是坏想法。”
金玉良言。感谢在此实例中说“不”时给我确定性!

Max Kanat-Alexander 2017年7月26日下午9:35
太好了,很高兴能帮助!
-Max


comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计