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

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

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

产品经理的缺失

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

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

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

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

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

关键文档的流失

在本书中，作者有写到他们当时用的产品界面设计是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的企业，相信这样的不规范的情况并不是少数。

从项目到产品的鸿沟

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

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

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

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

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

结语

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

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

一起加油，共勉！