1. 首页
  2. 运营资讯
  3. 新媒体运营

看得见的to B互联网,走不出的软件作坊

最近在看一本十年前出版的《走出软件作坊》,这本书让我越看越有感触,因为十年前作者提到的这些问题,至今依然存在

最近在看一本十年前出版的《走出软件作坊》,这本书让我越看越有感触,因为十年前作者提到的这些问题,至今依然存在,至少是在我当前处的环境中感受到的。

互联网企业相较于传统软件公司属于一个新兴现代化的组织,而且产品大多也以C端为主,而如今各大势头转入B端的时候,很多公司遇到和面临的问题,其实和这本书中提到的相差无几。说明这些历史问题至今都没有解决。

 

看得见的to B互联网,走不出的软件作坊

产品经理的缺失

在十年前,软件公司是没有产品经理这一岗位的,我看了作者大篇幅的介绍,其实很多问题和流程的症结,都在于缺少一个如今的核心角色,也就是我们现在产品经理这个岗位所从事的事情。

在那里,有程序员、有测试、有项目经理、有文案人员等等,单单就没有产品经理,这也不足为奇,毕竟是国外兴起的岗位。我努力对标到作者介绍的那些职责,发现他所提到的业务开发组组长、文案人员、以及项目经理三个角色所做的工作都和如今的产品经理有交集。

比如需求调研、产品设计、需求文档、产品宣传介绍资料、与客户介绍产品、过程管理等,其实这些都是如今产品经理岗位所从事的工作。这些在互联网公司作为核心的岗位,在很多软件公司其实都是缺失的,是的,至今都是。

在我进入这个公司前,公司内部是没有PM角色的,以前所有的混乱和书中描述的一样,客户说改什么,程序员随手就该,没有任何规范可言,而且招聘的产品经理,之前做什么的都有,到了这个公司不管个人角色是不是PM,统一都称谓是产品经理。


所以你会发现同样的岗位,每个PM所做的事情和承担的责任大不相同,这也就导致原本该规范标准的产品经理工作,实际过程中会因为个人角色不同而有所缺失,而解决的核心是不管有没有专职PM岗位,这个岗位对应的这些事都是要具体落实的,就像书中作者当年并没有设这个岗位,可该做的工作却并没少。

 

看得见的to B互联网,走不出的软件作坊

关键文档的流失

在本书中,作者有写到他们当时用的产品界面设计是PPT+WORD+脑图+Excel的描述方法。而对于产品的demo演示,他们自己也摸出了规律。每次给客户展示产品效果时,如果是C/S结构的项目,客户对PPT的原型就挺接受,而若是B/S结构的项目,则更倾向于HTML那种界面模拟。

对于功能详细设计说明书,也就是类似于我们如今产品中的PRD文档,他们当时采用的是Excel来描述,Excel第一个sheet中放的是版本信息,每次修改都有变更记录,第二个sheet是页面布局,放的是PPT或者开发工具建立的一个界面草图贴上去,第三个sheet是页面上每个字段的说明,第四个sheet,如果有必要,就用Visio画出业务流程图,第五个sheet是运行要求,如易用性、安全性、性能、数据量、并发性等不同等级要求。

在看到这的时候,我觉得作者当年采用的方式和我们如今是何其相似,只不过那时候没有Axure原型工具,没有与功能详细设计说明书所对应的PRD文档专有名词,而他们通过当时可以做到的极致把这一环节做了补充。

十年前,作者通过这些方式解决了一直存在的难题,让自己的团队和公司走上了规范。可遗憾的是,即使十年过后的现在,文档的齐全与齐备在很多to B公司依然缺失,我所在的环境就是如此。

在之前项目开发过程中,没有产品经理角色,所有的开发内容没有文档记录和留存,这就导致一方面在开发进程中无据可依,客户说一个就改一个,最后说不清道不明,另一方面即使开发完成后,没有一个整体对所做东西的介绍与描述,对于后期这些成果的有形化宣传都是一种损失。

而技术人员在写介绍文档方面并不擅长,之前就总听到同事说,技术开发的这些骨干都把东西做出来了,但让写相关文档,就是一句写不出来,想找点资料拿出去宣传都无据可依。所以,在to B尤其是项目to B的企业,相信这样的不规范的情况并不是少数。

 

看得见的to B互联网,走不出的软件作坊

从项目到产品的鸿沟

文中作者提到,项目开发是国内大部分软件作坊在做的事情,一般就是几个个程序员往客户那里一驻扎,客户说要啥就做啥,做完之后客户觉得行就验收,不行就再改,这是典型传统做项目的方式。

而做产品和做项目是相对而言的,产品是标准的,不修改,就这个东西,客户看着好就买,看着哪点不舒服也没办法,我们不修改,客户如果觉得不修改就不买那也没办法,如果买了,就继续给客户安装、配置、初始化数据、培训等等。

最难的就是说产品不是产品,说项目不是项目,这也是当今我们在做B端时常常面临的标准化+定制化。如果是代码的复用,那么一个客户有需求变动,那么也会影响另一个客户的使用,所以理想的情况是别掺和,一个客户一套代码。但这种方式也仅适用于客户数量不大的情况。

通常一套独立的代码中有60%-70%的代码是相同的,给各个客户定制的也就是30%-40%不同而已,一旦这个相通部分的代码出现了bug,要改代码就难了,有多少个客户就有多少套独立的代码,就要改多少遍,而且每套代码还有30%-40%的差异。

如今,项目化和产品化已经不单单是改代码的问题,它还事关一个公司的选择和发展方向,目标客户以及未来走向。从项目到产品的鸿沟,是这十年来作者一直在探索的,也是如今的to B前行者时刻在考虑的,不能说哪种方式更好,生存的前提下,活下去最重要。

 

看得见的to B互联网,走不出的软件作坊

结语

看这本书有一种熟悉的年代感,同时也是一种启迪和警示。很多问题并没有随着时间的流逝得到很好地解决,所以作者提到的那些点,那些流程的构建,那些重要性的经验,直到今天仍有很多借鉴意义。

这是一本好书,走出软件作坊,对于缺少互联网基因的传统to B公司还有很长的路要走。

一起加油,共勉!


原创文章,作者:挽人_于心,如若转载,请注明出处:https://www.guyarts.com/487.html

发表评论

登录后才能评论

联系我们

19912629517

在线咨询:点击这里给我发消息

邮件:1125146170@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息