大软件的概念一定是总括公司所有业务的核心概念,也是所有探索和尝试最后要汇总回归的地方。一个公司的发展,要能够提纲挈领的抓住要点。这个要点就是产品。这是偏用户的视角。其背后其实就是作为整体的软件。
只有这样一个整体的思路,我们才知道如何从宏观上去把握公司整体的发展,能够始终把力气放在当前最需要的地方,有不断的试错而非重复的反复折腾,有经验的持续积累, 有产品的持续完善而不是摇摆不定,有各部门的经验和操作的整合而不是割裂和对立。
抱着大软件的观点,就很容易把公司整体的管理给牢牢抓住,而不是陷入各个细节里去,反而造成整体的失调。
本文试图提出大软件部门和软件师的概念,以及互联网公司可以采取的大软件战略。
这里所讲的概念,单独提出来讲,也许大家都明白。但在实践中,却是大相径庭,甚至背道而驰。
互联网公司,至少大多数情况来讲,首先是个软件公司,是在用互联网来重新定义或者颠覆自己的行业。其实更准确的说法是,用互联网软件来真正实现本行业的核心价值。
那么这必然涉及到对行业的理解,包括对现有的行业的了解,是如何运行的;对行业的本质的理解,什么是核心的价值;互联网能给行业带来什么,如何用互联网实现行业的核心价值。
软件是知识和思想的表达,上述的理解应该凝结到软件中去,形成公众使用的产品。而这个软件的开发过程是迭代的,从吸引最初用户,到对用户的需求的进一步理解和满足,到产品的升级和丰富等等,其核心都是在不断的增加对这个软件的认识,不断的改进和完善这个软件。所以大软件的概念一定是总括公司所有业务的核心概念,也是所有探索和尝试最后要汇总回归的地方。一个公司的发展,要能够提纲挈领的抓住要点。这个要点就是产品。这是偏用户的视角。其背后其实就是作为整体的软件。
只有这样一个整体的思路,我们才知道如何从宏观上去把握公司整体的发展,能够始终把力气放在当前最需要的地方,有不断的试错而非重复的反复折腾,有经验的持续积累, 有产品的持续完善而不是摇摆不定,有各部门的经验和操作的整合而不是割裂和对立。
抱着大软件的观点,就很容易把公司整体的管理给牢牢抓住,而不是陷入各个细节里去,反而造成整体的失调。
稍微具体的说,各个部门的第一线的经验,比如商务部门,支持部门等,其经验应该汇总上来,形成对软件这个产品的反馈,并将新的理解和改进融入到软件的开发中去。这里就要求软件人员主动的去了解公司各个部门的情况和积累的经验。
大软件策略,包括对公司软件的整体把控。
这里首先是公司软件/产品能否有一个清晰的简单的概念模型。这里面要求有一定的抽象的思维能力。一个清晰简单的概念模型可以大大简化软件的开发,让软件的架构更加清晰化,也可以让用户更快速的明白公司产品的功用,更好的交互。
其次,是对软件复杂度的判断。公司的产品,应该容纳多大的复杂度。这和当前用户对公司产品的接受阶段有关。早期产品主要在给用户一个从无到有的惊喜感,满足他们以前无法满足的一个强需求,不用做的太复杂。用户已经接受了,更多的用户也加入进来了,要求产品在更多的细节上满足他们的需求时,产品的复杂度也在升级。对这些复杂度的级别的掌握,需要有一个整体的概念和把控。尤其是这也会涉及到公司当前软件开发的规模和能力。这是互联网公司至关重要的部分,相信是诸多互联网公司发展的瓶颈,或者更正确的说法是,互联网公司本来最大的成本就是在软件开发上,其核心就是软件/产品的开发。所以没有大软件的整体把握,如何能让公司做到有序的发展?
互联网公司整体的发展,其实就是其软件发展的过程。这里主要需要把控的是从软件整体的角度,对轻重缓急的把握,对突破口的认识。新产品,新功能的开发,代码的重构,结构的调整,功能的完善,用户体验的提高等等,都是一个整体,必须在一个整体上去考虑。而这其中,必须去了解各个部门对软件使用的情况,获得充分的反馈。对于软件的迭代开发,首先我认为软件一定是在不断更新的。其次,我对软件的更改又一般持一种保守的态度,不会轻易的去改已有的软件功能。已经反馈上来的需求,我会让其等一等,从整体的角度考虑,有相当大的把握度(80%或90%的把握)确实是需要改,我才会改。因为软件的开发是一直都有必需做的事情的。如果你把精力放在了不是必需要做的事情上,那么那些必需的事情一定就是耽误下来了。
互联网是个创新的领域,是用互联网去改变现有的行业。这里面就会有很多的预设(assumption)。需要很快的意识到哪些是自己的预设,如何快速的验证这些预设的正确与否,这里面取决于技术能力,都会有很大的差异。在这个环节,我感觉没有技术基础的人很难有好的把握。
因为大家包括软件从业者对软件的误解,很多公司的软件战略无法实施出来。在很多公司里,是单纯的技术(IT)部门,仿佛是公司的一个支持部门,其功能是支持其他部门的工作。技术部门的员工是被动消极的接受其他部门指派的任务。这样的公司,在互联网领域是很缺乏效率的。
软件是个整体,包括技术,也包括商业和该行业的知识。所以单纯的只懂技术,或者只懂商业或行业知识,都无法对软件这个整体有好的把握。
在我过去的接触中,我碰到过不少非技术出生,但是对互联网很感兴趣的人,他们一直在积累自己对互联网的理解,这些人虽然不懂技术,但因为互联网门槛不高的特质,他们对互联网的理解能够达到一个比较高的水平。当然他们中的很多人也自己承认的,如果懂技术的话,很多东西会理解的更深。
而现在互联网上兴起的社交化编程学习,其实也是在进一步降低技术学习的门槛。很多人开始越来越意识到,编程能力不是一个专业的能力,而是一个通识的能力,或者如Python作者Guido所说的,未来衡量是否文盲的标准。
所以我很鼓励其他领域的优秀的非技术人员,可以来更多的了解软件,不用畏难,软件如果有难以学习的地方,本来也就是软件人员应该努力改进的(我以前就常说,一个软件工程师的理想应该是让所有的人都能够编程)。
对于我所接触到的那些单纯的技术人员,我也明白,要让他们明白整体的软件,恐怕并不见得比让非技术人员明白整体的软件更容易。对商业和行业的了解,同样是需要付出很多时间去积累的东西。就我个人而言,我总认为那些其实是比技术更容易学到的,门槛更低的。但我们知道现在教育体制人文教育的极度缺失,对于这些纯技术人员来说,太单纯了,学习商业和行业知识又是需要很多很广领域的知识需要去慢慢弥补的。
我想正是因为从业的软件人员的能力其实和“软件”差距太远,才催生出了PM这个职业。我在学习软件工程的时候,一直很重视project management,并且视其为软件工程最重要的一部分,是优秀的软件工程师应该掌握的。但是没想到进入行业后,发现大量公司的PM其实是非软件人员,而所谓的从业的软件人员又沟通表述能力奇差。软件行业的问题,其实是教育的问题。
可以改进的地方,除了上面说的对非技术人员加强对软件的认识(即使不到软件编程的层次,起码是对互联网的理解吧),对于技术人员的要求,可以尝试的是,技术人员必须有一定的时间去了解公司的业务,比如周五下午不给他们安排技术的活。让他们上公司的网站,去使用公司的产品,整体上把握公司的产品。当然,你可以选择做一个传统意义的技术员,只解决技术难题,不和人打交道。但就互联网软件来说,其一定是和人交互的,和社会交互的。
造成现状的原因,除了上述的现代教育里人文教育的极度缺乏外,一个比较直接的原因,恐怕就是“计算机科学”这个命名了。正象Dijkstra所说的,这个命名已经对这个行业造成了无可挽回的损害。我不自量力的希望通过我的工作,能够尽量的挽回一些损害。而这个努力的开始,即提出大软件策略,恢复其本来应有的地位。拥有能够实施大软件策略的人才的公司,必然能够在互联网行业健康快速的发展。其实我们看精益创业/实践的书,无不是围绕软件本身来的。而软件师这个带有工匠意味的头衔,更能反映软件的本质和我们的要求。软件师不是单纯的从事技术支持的人,而是热爱软件,懂得软件的整体,能够从整体上观察把握公司的软件,能够实施公司大软件策略的人。
一个实施大软件策略的互联网公司应该起码有一个或几个软件师的角色。老板本人最好就是一个大软件师。软件师除了领导软件部门的工作,也参与统摄公司整体的运营,承担的职责涵盖原有PM等的职能。
后记:这篇文章算是暂时写完了。其实自提笔起,就感觉写的很不带劲。这些都应该是和尚头上的苍蝇,明摆的事情,之所以要写,完全是因为行业里各种荒谬的做法。当然这根本的原因还是由于现代教育为了适应过去的社会化大生产的需求,对知识做了偏狭的分类和理解,导致人文教育的极度缺失和把软件错解成了计算机科学,使得我们极度缺乏真正的软件人才,也才有了我们今天的困境。
回复 徐继哲 2013年08月21日 星期三 00:36