软件永远没有“完成”。但大多数公司却照那样定价、那样对待项目。本文讲如何避免把预算烧掉、同时把用户做到他们会自发告诉朋友。
你知道科技领域有软件架构师这个职位吗?软件开发者也常被称作建造者或工程师(更资深的开发者)。科技与真实的土木工程(盖建筑等)之间有这么多平行词,是有原因的。
那有哪些平行点,我们能从中学到什么?
在做软件产品?
挑战你的产品想想盖一栋建筑 🏗️,你需要:
我们开发软件方案的过程相当类似,这个过程不可避免地伴随同样的风险与挑战。
在插图中你看到的是典型的软件生命周期。每个功能、每个里程碑都要经历这一周期。它总是从“你要造什么”的计划开始,到维护当前功能集结束。
一旦用户提出新功能请求,或你的软件已老到无法在市场中竞争,周期就再次开始。
软件生命周期里的每一步都对成功至关重要。我们一步步看。
你会没有计划就开建一栋楼吗?大概不会。
这一阶段定义项目范围、目标、客户需求,并制定详细的项目计划。建软件产品有两种主要方法:瀑布方法和敏捷项目管理。
瀑布方法要求软件外包和客户在写下第一行代码之前,列出穷尽的功能清单并准备好完整计划。可以想见这非常有挑战,特别是需求会在过程中因新的市场反馈或其他外部因素而变化。
大多数软件项目使用敏捷方法来留在预算内并应对未预见的挑战。但关键来了:大多数公司把敏捷当作不规划的借口。我们看一下。
把敏捷当作“先开干”不做合适需求工程的借口,毫无疑问会害死你的项目。开发者很可能无法正确排序最紧迫的功能。最差情况下,软件甚至跑不起来;即使能跑也会显著延迟。如果你和外部软件供应商合作,请确保他们有连贯的流程和上报机制。
敏捷项目管理仍然需要计划。和瀑布的主要差别是我们有定期反馈循环、迭代,并每天、每周、双周重新对齐优先级。

"不规划就是规划失败。"
这一阶段,软件外包与所有利益相关方一起定义软件应包含的具体功能。跳过这一阶段,很可能导致想要的功能在计划预算内做不出来。
简而言之,客户不满意。详细需求帮助合理预算项目,并对齐预期,这对长期项目成功至关重要。
软件中的设计有两类。第一类是设计用户如何与你的应用交互,包括简单线框图、“情绪板”和模型图。最好用、最易用的界面都被精心设计过,让应用尽可能易用。
和任何职业一样,如果你想要一个出色的东西,请和出色的人合作。如果你可以接受平庸或预算紧张,那这或许是起步阶段可接受的取舍。
第二类是软件设计。从鸟瞰角度看所有软件组件叫软件架构。
它是什么?想想 Netflix,那家著名的流媒体平台。Netflix 的软件架构由成千上万个互相交互的软件服务组成,覆盖了你在 Netflix 上能做的一切,例如注册新账户、登录、看电影、订阅付费等。
这些服务每一个都被精心设计,能够承受用户请求量并在意外错误时恢复。下面是一个想象功能的示例软件设计。
正确地架构你的软件、设计其组件,可以决定你的软件会不会变得无法维护、非常难以扩展新功能。把合适的软件设计当作对项目未来的投资,能避免臭名昭著的技术债。
在做软件产品?
预约免费咨询这一阶段软件开发者实际写代码。作为敏捷项目方法的一部分,开发者应定期向客户上报并给客户留出早期反馈的机会。这能带来短期内的变更,否则可能要等到很晚才能修改。你可能会喜欢我们关于此话题的博文:《为什么人们觉得软件外包糟糕》。
测试阶段和软件生命周期中的其他阶段一样,需要时间和资源。但没有什么会比缺乏足够的程序化测试更快地把你的软件搞坏。
我们也有一篇关于软件测试的博文:《测试驱动开发》。
作为测试的一部分,也要确保你的软件与它依赖的外部软件被充分集成。一个 Web3 的具体例子是预言机,把链下数据带进你的智能合约。虽然这属于之前的阶段,但在真实主网区块链上的集成与测试也必须做。
我们刚说过软件有依赖,那些不是你软件外包写的、而是成千上万独立开发者写的。此外,你自己的软件也在演化,用户会提出新功能需求,会发现bug,依赖也需要更新。
你的软件外包前几个阶段做得越好,尤其是需求收集和软件设计,维护就越简单、越便宜。地球上没有不需要维护的软件,除非根本没人用,但我想那不是我们想要的。有些软件外包不喜欢做维护,请确认你的供应商愿意做。
另请参见:维护一款活生生的软件产品需要持续的工程领导力,而不是一锤子项目。如果你不想全职雇佣,可以看我们的 奥地利 Fractional CTO 服务。
请确保你合作的软件工程师或软件外包了解这些软件生命周期。最重要的是,他们愿意在整个过程中支持你。
你可以跳过或忽视某些阶段,但长期一定更贵,且会在后期拖慢新功能交付,前提是用一个有缺陷的流程还能完成最初的需求。