抛开个人的心智模式上的一些思维差异,软件行业从业者应该当具备的几个思维模型,相当重要,好软件好产品的理论指导也都无出其右。
用户思维
代码的抽象源自于现实世界,产品未来的受众必然是给人看的,与人交互的内容要面向用户,除了一些是面向业内人士,另外的产品要面向大众,不管是C端用户还是B端用户,想让用户看的懂,能用、易用、好用。比如一个交互页面上的必输项校验时抛出异常:“ID is required",这是ID必输提示语,普遍用户看到会完全摸不着头脑。正确的做法应该是稍做加工包装后再反馈给前端用户,比如”请输入身份证号“,简单明了,客户就能轻松发现问题所在。普通用户不具备软件专业使用能力,所以要尽可能站在他们的角度思考问题,否则开发出来的东西使用门槛很高,用户群体必然会很少。产品的迁移成本当下是很低的,因为一个色调的问题都有可能导致用户大批出走。
产品思维
写代码的如果看到只是代码,还处在一个比较低级的层次,只见树木不见森林。代码的集合是功能,功能的集合是系统,系统的集合是产品,产品的集合是生态。一定要看清代码背后的价值,这堆代码最终面向的用户是谁,能产生什么价值?或是个人价值,或是业务价值,或是社会价值。还有一个注意点:把产品当成一个完整的,可以交付给用户使用的是个很重要的理念,而不是一个独立的功能,独立功能再强大,产品不完整,同样不会有用户使用。举个栗子:很多产品场景中需要实名认证,并提供扫描身份证自动识别功能,识别率很高不代表不出错,当出现异常情况时,应该请允许用户手动调整信息,如果不提供入口,这一功能的不完整,导致后续一系列操作都无法完成。
工程思维
软件工程作为工程类中较为奇葩的一点在于,其生命周期有可能很短、返工率很高,不像路桥坝堤工程,规划完成后,需要结合大规模实施团队使用大量的工程机械进行严格施工,花费大量的时间成本、资金成本、人力成本,这些工程遵守现实的物理定律,力、电、热、能量等等,而软件工程除了硬件设施,其它基本由不可见的、不可量化的脑力思维活动组成,更多的是时间成本。构建之初,就要基于软件工程的思想指导实际工作,凡违背软件工程的基本规律的实施过程,规律必然会反作用于项目或产品,必须是先设计再编码,否则写到后期会发现很多不合理,必然导致返工。前期调研不到位,必然会做出来一堆没有市场的东西。质量、速度、成本是软件工程的不可能三角,只能平衡,不能打破。
题图 from unsplash
这是职业规律,抓住重点,就相当于摸清了脉络,从哪里来到哪里去,也就容易回答的多。规律可以指导实践,实践可以反哺经验,不断的拔高层次,来提升一个小小技术的格局。
以上三点,不难做到,稍做留意,稍加训练,后期即是习惯。