从60 个方案交付聊聊软体开发经验

Sam Huang
·
(修改过)
·
IPFS
·
应用软体的开发在于撷取事物运行逻辑,真正需要在意的是可控性
软体系统开发顾问: https://consult.revtel.tech/

回顾忻旅科技自2016 年创办以来,产出了超过60 个软体方案。

回顾过往曾接触过合作内容

  • 规模自海外独角兽到本土新创
  • 内容从专案、产品到商业题目都有
  • 技术涵括Web、APP、IoT 和系统
  • 遍及电商、物流、医疗、金融、展览、印刷等多个领域
  • 分工自纯咨询、部分协力、完整开发到后续维运都有
  • 除开发及咨询之外,也协助团队组建

仔细看看也还蛮多面向的,未来好像可以就这些部分做些分享交流。但总会想到一件事,到底这些开发里头我们到底都在做些什么?

应用软体的开发在于撷取事物运行逻辑

出社会后经历过大公司、新创公司到自己创业,总不免在思考过往训练给了我什么,这几年才模模糊糊的感觉到软体工程的训练给了我一把拆解现实逻辑的手术刀。

软体系统是在电脑那头、虚拟世界中重新模拟现实世界发生的流程并满足现实需求。比如饭店住房查询的系统可以想像成在那一端有个虚拟助手替你查表,而先前的开发过程,则是在帮那位助手打造属于他的工具(如记录簿等)。

有趣的点也在于,既然是在虚拟世界重新建构流程,是以能在一定程度上消减来自现实世界的种种限制。以刚刚的住房虚拟助手为例,可控范围内能让馆内人员直接跟客户做互动来增进效率,但这在现实生活中却会因为政治、组织架构或各种风险考量而无法实作。

考量到「系统= 人+ 软体」,使得这会是一个不断反覆抽离、拉近的思考过程,考验在于如何适当把握抽象层次及实作深度。并且几乎永远只有当前最佳解而未必存在全局最佳

强弩之末,势不能穿鲁缟

身为设计师是否常常觉得某些著名产品的体验不好?比如该对齐没对齐或重要功能拜放在很难找到的地方。

身为工程师是否常常觉得某些知名服务有bug 或者顺畅度不足?比如前景背景的推播顺畅度或奇怪的死当状态。

换个场景思考,是否常常觉得许多政治人物的言论或大公司的决策很荒诞而脱离现实?但要这么理解,如果某些事物的跟我们想的不一样,除非能完全确认我们胜过那些团队的集体智能,不然最有可能的其实是我们并没有看到问题的真正本质及该处境的客观限制

强弩之末,势不能穿鲁缟。力所难及之处才是真正要挑战的地方,重点应该在于如何把握每个时段的关键问题。当然,如何去看穿真实限制也会是个永恒课题。

试着理解自己的局限性

对惯于大量吸收资讯的现代人来说,自多管道接触资讯并不是什么太困难的事情(反而筛选成了一个议题!)。想像一下上一辈人如何看待我们在同一时间自多渠道(如Line、Facebook)吸收资讯,就可以约略感受资讯管理方式存在某种时代性的天花板。

要很小心的去觉察自己认知的隐性极限,方方面面的框架不只形塑了你的世界观同时也成为了往前的制动器。

这种隐性天花板往往不只是盲点,更可能是一整个维度的丢失。

真正需要在意的是可控性

所以要如何看待真实世界的软体系统设计?

回想下这些年很常在吵的课纲议题。过往我们的学习经验,是由主管机关每隔一段时间修订课纲,再让各大出版商根据课纲填充内容。基于这种框架,我们就能相对明确的去讨论是大方向不正确或是具体实作有问题。

软体开发亦然。

自上而下的框架能很大程度作为总覆盖面的方向指引(这里会有很多方法论,暂且不谈),藉由锁住商务需求及商务时程两个维度,能有效避免走错方向。

可毕竟软体开发是一个动态的双向过程,所以也不要忘记自下而上的反馈。藉由这个反馈锁住实作校正这个维度,能有效避免虽然方向对了,但却挑错路走的窘境。

追求的都是可控性。倘若开发时程的进行都能在巨观及微观尺度上被把握住,那风险自然就被降低了。

不要停止前进

说到底要告诉自己的也在于不要停止前进的这句老掉牙的话。知道的总是太少、可能性总是太多。

通篇荒唐言,多少也来自一些辛酸泪。假如您有不同看法,也欢迎跟我交流:)

CC BY-NC-ND 2.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!

Sam Huang[ https://www.sam-huang.info/ ] 一扁帽,一壺酒,一溪雲,佔得人間一味愚,此心安處是吾鄉
  • 来自作者
  • 相关推荐

平淡但輕鬆的年假

工作所思所想

陽台種植物