翻译 : 蔡雪丹
欢迎访问网易云社区 https://sq.163yun.com/blog?tag=M_tg_888_65 , 了解更多网易技术产品运营经验.
有许多因素可以成为糟糕的软件形成的催化剂: 从正在使的具, 到团队沟通, 到开发员在推动 其成功上可获得的个利益, 再到测试法.
我认为在这其中有个主要问题, 个乎可以作为所有软件变成糟糕软件推动的根源: 幻想出来的 问题.
多数复杂或坏掉的软件并不是设计得过于复杂或功能失调, 它只是被设计做了很多超出预期的的 事情.
假设你是个播客主持, 你想要定制个站可以销售你的告产品, 在没有第三介的情况下 赚钱, 最重要的是, 可以向你的观众提供播客, 视频和博客.
你的 web 应的需求可能如下所示:
在北美络下有较短的加载时间, 可以实时播放和下载博客流.
99.99% 的户少在头 15 分钟内不会崩溃或卡住, 最好始终不会崩溃或卡住.
如果有时间的话, 最好可以与歌告以及其他些第三告提供商较好地集成.
动态链接到 Zazzle 商店的最新产品, 如果可能的话, 可以根据户消费的内容向他们提供建 议.
与 Facebook 实时播放器集成. 如果可以有个不需要 Facebook 流媒体的替代解决案就更好 了.
你把这些需求给了个承包商团队, 然后你与他们聊了会, 似乎每个都明的你意思. 然, 两个后, 当他们带着最可运产品 (MVP) 回来时, 你的脸变红了. 你发现你只是在块垃圾上 浪费了 15000 美元, 你想要回你的钱.
因为第次打开应程序时, 屏幕会卡住. 你问他们如何选择允许在站上运的告类型, 他们指 出个丑陋, 难以让理解的定义( UI ). 半数 Zazzle 商品链接是断开的或丢失的图, Facebook 直播流的也有延时!
但是开发者团队对你的愤感到很困惑 - 从他们的度来看, 这些都是理所当然的 -- 因为他们已经经 历过地狱式地开发之后回来找你了.
他们全全意创建了这个应, 它拥有些惊的功能:
最先进的推荐系统
实时成所有流副本的算法
屏加载时间在全世界络内都可以低于 200ms
流媒体协议和客户端乎都是重头构建的, 因为不想依赖 Facebook 直播
这项服务可以让你轻松整合 20 多个告交易
这个问题在于你想你的核产品拥有堆额外的功能, 如果它们易于实现的话. 但是开发团队听到的 是不样的东, 他们听到了些对他们来说可以攻克的挑战... 以及系列聊, 基础, 他们根本不 想去测试或者关的功能.
更糟糕的是, 你没有直接与这些开发者进沟通 - 你就像在玩电话传声游戏样进沟通. 你和个 销售员谈过, 他和个中层管理员开了会, 这个管理员写了些业务规范交给了 PM,PM 写了 技术规范交给了团队负责或程师, 最后, 这个和他的团队开始设计这个产品, 每个在设计的 过程中或多或少也都加了些的曲解.
更糟糕的是, 你没有直接与这些开发者进沟通 - 你就像在玩电话传声游戏样进沟通. 你和个 销售员谈过, 他和个中层管理员开了会, 这个管理员写了些业务规范交给了 PM,PM 写了 技术规范交给了团队负责或程师, 最后, 这个和他的团队开始设计这个产品, 每个在设计的 过程中或多或少也都加了些的曲解.
多数程序员希望得到报酬, 同时享受乐趣. 当然,"乐趣" 的定义对每个来说都不样, 但对许多 程师来说, 它归结为解决可解决范围内的有趣且富有挑战性的问题.
给个有点聪明的太多法动化的聊任务, 你最终会让他发疯. 然, 经过数亿年的进化, 类的脑在保持理智常有天赋. 就像童年困苦或虐待的受害者可以在幻想书中找到逃避, 企 业中或者进由 Web 开发的受害者可以在解决想象中的问题时获得解脱. 个软件程师可以想象出来问题的数量取决于他们的想象, 也取决于他们应该解决的真实问题难度.
应该注意的是, 这个问题并不是开发者独有的, 管理部, 销售部, 部分, 后勤持, 法务, 甚会计部都有他们独有的式来创建想象中的问题. 当他们没有被要求或者形式性地参加某会 议时, 会试图让更多地参与决策. 他们过分强调某个与他们相关的问题, 或者招募更的 团队来说明他们的重要性.
当问题变得愚蠢时, 聪明的总能找到解决的办法.
但是很多想象中的问题并不仅是聊的开发者造成的, 它们也有可能是沟通链产的结果.
当我第次开始接触由职业客户时, 不可谓不过分周到. 我们电邮件的交谈链已经持续了 100 多 次, 仅仅讨论关于内部 MVP 的些关紧要的细节. 我让在周内改动了项的每项要求, 我问 了户些问题, 如 "这是 ICO 吗? 或者" 我们能在这添加些智能元素吗?"诚然, 多数客户都这更精明, 但即使如此, 他们经常缺乏表达或构建些需求所需的知识. 这很 好, 作为我" 计算机员 " 职业的部分, 我的作就是帮助们根据他们的例指出他们想做什么和 不需要什么. 但是当你和客户之间隔了好层进沟通时, 确定需要什么就变得更加困难了.
需求变更是因为有误解了个意图, 或者是因为有试图应付上述聊的需求
多数公司喜欢由个销售员对潜在客户进推销, 协商价格, 并概述可能的功能. 他们也专有 个与客户讨论更深的需求和细节, 这通常是另个销售员, 但职别略有不同. 然后是技术团 队内部的指挥链, 各种级别的管理, 可能还有些其它层级结构.
当份客户需求列表流转很多时, 即使这些拥有最好的想法, 些东也不可避免地会在层层翻 译中丢失. 有时, 这种变化是因为最初的需求没有意义, 或者有时需要重新定义需求. 销售员可能 会告诉客户,"只需额外付 39,999 英镑, 我们就可以在区块链做这件事. 但这让所有遇到需求的 都想知道" 在区块链上做 "的定义是什么."
很多时候, 需求会改变是因为有误解了个意图, 或者因为有试图应付上述聊的需求, 试图让 他的作或者他团队的作更有趣, 更令印象深刻.
因此经历所有这些, 最初的需求 - 真正的问题在这过程中已经被溶解了 - 丢失了. 它们被想象中的问 题和空洞所取代, 并且你会发现很多已经准备好他们想象中的问题来填补这些空洞, 因为他们真 正需要解决的问题很聊, 填补这些空洞给了他们种法来应对这种聊.
过度复杂化和然选择
想象中的问题的存在往往有更阴暗的原因: 问题可以帮助团队或公司成, 甚可以成为其功能不可分 割的部分.
那些通过被培养, 挑选和补偿来寻找复杂解决案的往往没有动去实施简化的解决案. -- Nassim Nicholas Taleb
你听过那三位 Web 程师吗? 他们发现安全的上银其实是个很容易解决的问题, 他们从零开始 开发了些完美的银软件, 使功能设计法论和内存安全语, 然后开始将主要银迁移到他们 惊的基础设施中.
也许你没有听过过他们, 因为他们不存在. 然, 有许多由成千上万的开发员组成的团队, 他们 法掌握像 "回滚" 这样的简单概念, 从不断创造银软件.
数字的存储和传输并不是个特别困难的问题, 检索整个互联内容并在短时间内为然语查询提 供相关结果是个难题, 但也个聪明设法去解决这个问题.
但是上银业存在的问题是, 银身的态系统已经分善于维持的赚钱等级, 它的领导者 是腐败的蛭, 他们掠夺社会 -- 但组织中的领导者只是其成员的个症状.
我不认为多数银下属员是邪恶或怀有恶意的, 与此相反, 他们通常是些友好的伙, 为家 庭提供物, 住所和教育, 但是他们的主要动机并不是修复银软件, 是保住作. 对些来 说, 这今天的经济形势下失去作不是开玩笑的事; 在银业, 嘴巴或太过主动表现很容易在纪律 委员会前暴露.
因此, 银系统仍然保持原样 -- 不是因为这些系统是效的, 是因为惯性. 这种惰性的表现形式是 为了解决想象中的问题, 以避免解决真正的问题.- 真正的问题旦被指出, 就会威胁到其他的 作. 聚焦于这些真正的问题可能会导致被解雇, 甚, 在些特别恶劣的 "机构", 如盛, 让个 毁灭活的棕信封送到联邦调查局那会引发奇怪的杀.
当个的薪取决于他对某件事的不了解时, 要让他了解某件事是很困难的!- - Upton Sinclair
层管理员忽略了这样个事实, 即他们的上层管理员的 90 % 的时间都花在 "客户会议" 上, 这些会 议涉及热带岛屿和数百万美元的 "其它费" 预算. 作为回报, 这些上层管理员对他们上级的腐败视 不.
上层管理员忽略了那些购买古怪办公室并给雇三名秘书和名实习的中层管理员, 因 为中层管理员励他们活在华尔街的幻想中.
中层管理员也忽略了这样个事实, 即产线管理层把时间都花在了关于 "改进我们的敏捷法" 的 PPT 演示上, 削减成本, 因为产线管理层并不抱怨他们的独裁权幻想.
产线管理层则忽略了团队负责和架构师谈论的 "我们使 JRPC 的系统和使 Hibernate 和 Spring 的 微服务之间的下代接", 所以当他们应该不到天的时间来处理那些该死的 MySQL 查询. 因为 团队负责似乎没有注意到他们的上级甚不能正确使 Excel, 并且仅仅只是隔周来次办公室.
团队负责并没有抱怨他们的开发员, 是查看了前提到的缓慢查询的解释, 并在那年第次使 新的 JavaScript 框架重新设计 UI. 因为开发员似乎没有注意到他们的领导除了 DOT 图之外没有真 正编写过任何代码.
这是个解决想象问题的恶性循环, 从没有意识到再偷 3000 万也不会让他的亲爱上他的 CEO, 到没 有意识到使 Angular-Material-Bootstrap 19.13.5 重新设计 "提交" 按钮并不会让他们以明形式存储 密码 (并将其作为授权 cookie 的部分) 的事实消失的 UE 实习.
但是每个都需要继续解决想象中的问题, 因为如果他们停制造和解决这些问题, 如果他们开始关 注真正的问题, 他们可能会意识到整个系统已经崩溃. 他们可能意识到 Debra 已经坐在那个落, 盯着内部服务器集群的正常运时间图看了 10 年, 尽管该公司五年前搬到了 AWS. 他们可能意识到他 们 99 % 的作是让别的作永垂不朽. 这是个难以接受的事实 -- 我敢说, 对多数来说是不 可能的. 因此, 多数找到了种应对的法.
来源: https://www.cnblogs.com/163yun/p/10069209.html