论文部分内容阅读
随着我国数字出版产业的快速发展，数字出版产品逐步由同质化向着差异化发展。出版社对于数字出版产品的布局也越来越细化，无论是研发环节还是运维环节，出版社的参与度越来越高。
热词：数字出版 产品研发 产品运维
北京交通大学出版社的数字出版产品研发完全采用自主研发，实践证明：自主研发的成本并不比外包研发高。在笔者看来，数字出版产品研发本就不应该有所谓的外包开发，因为没有出版经验渗透其中的技术开发是毁灭性的。下面笔者就关于产品在研发过程中比较关注的几点做一下阐述。
关注点一：研发模式
如今，认识到应该自主研发产品的出版社还不多，但是坚持一定外包研发的出版社越来越少。在数字出版转型初期，几乎所有的出版机构都认为应该走合作研发的路线，论调是：“出版社应该把精力放在内容上”“合作研发节约成本”等明显的“+互联网”思维，而不是“互联网+”思维。当初所谓合作研发其实就是外包研发，因为出版社能做的仅仅是提出需求，这些需求仅仅是结果层面的，而不是过程层面的，这样的需求可能成为整个产品的瓶颈甚至“毒瘤”，摧毁整个项目。同时，如果采用外包开发模式，必然也要采用外包运维。因为，广义的产品研发并不仅仅是一款App的开发环节，还包括更重要的运维与推广环节，开发环节只能占整个环节的10%。
一般来说，一款产品的研发包括需求分析、需求评估、规划与架构、程序开发、测试、上线、运维等几个主要环节。从人员参与来看，出版人能勉强参与的环节仅仅是需求分析、测试和运维，还都是基于内容上的参与，99%的事情都是技术公司完成的，那这样一款产品到底是谁的？不要小看理解上的偏差，当使用语言描述一个功能或者一个概念时，每个人的理解都是千差万别的，即使是做出产品原型，在架构上的偏差也会在产品正式运行后出现差之毫厘谬以千里的可能。
所有经历过产品开发的团队都知道，目前出版相关的产品大多不会使用瀑布式（对于小体量开发代价太过高昂）和螺旋式（相对来说不太在乎风险）开发方式，基本都会使用迭代式或敏捷式开发方式，这两种开发方式首要强调的就是高度协作，迭代开发方式的特点就是忽略一些明知不完美甚至有问题的地方，按照“先主再辅最后补”的方式进行开发，即使产品上线后，每天都会有需要更改的地方，也就是说开发永不停歇。外包开发既做不到高度协作，又做不到持续开发，而敏捷开发比迭代开发的每一轮周期更短，并且是强调适应性而非预见性，这一条从根本上否定了外包开发。
关注点二：驱动力
数字出版转型初期，我多次强调技术的关键作用，往往被很多老前辈“打”成技术驱动派，认为出版社根本没有能力掌握技术，应该坚持“内容为王”，也就是内容驱动。他们大概是觉得我不认为内容重要，或者觉得我想让出版社与BAT（百度、阿里、腾讯）拼技术。作为晚辈，不太适合当场辩驳，其实在数字出版时代，内容驱动是错觉，内容强大是传统出版的优势在数字出版时代的继承而非决定因素，或者说“内容为王”是一个出版社存在的基础而非数字出版转型的核心，通过不同的包装或者展现形式，将原本优质的内容重新以数字出版形式发行，其关键在于技术的运用而非内容上的创造。举个例子，内容的管理者是作者和编辑（包括策划编辑和内容编辑），如果这两个角色均不了解技术，如何在已有内容上进行数字出版形式的改造，更别提从零开始专门为数字出版形式进行内容创作了，我相信处在各出版社数字部门的同仁，一定经常被传统编辑询问某个产品如何改造，某个想法如何实现。至少，内容管理者想得到就可以进行讨论研究，如果内容管理者根本想不到，创造或者改造就无从谈起。知识决定思想的范围，如果不了解AR（增强现实）中图像识别技术的基本常识，编辑就不会考虑书中每张图片的差异量如何控制，如何选定识别率高的图片，这样的例子太多了。
数字技术人员，虽然欠缺文字编辑功底，创作或改造的作品在文字、标点、格式方面都会有问题，但并不会影响作品的创意和内容，并且在传统编辑加工环节会将这些瑕疵修正。
那么如何才算技术驱动？我认为，只有以专业背景为基础，全面了解各项数字媒体技术，能主动运用于创作活动中才算技术驱动。单项技术只能算工具，谈不上驱动。所以，技术驱动的门槛很高，也就是我们团队常常自诩的“会技术、懂出版、晓传媒”，虽然我们还远未达到，但这一定是数字出版人才需要具备的，这也是為什么国家现在开始注重数字编辑人才培养了，就是要打破壁垒。
关注点三：身份与人才
数字出版人需要放下传统出版时代“文化人”的姿态，放低身价，虚心听取那些与先前经验里相对立的部分。在数字出版转型初期，有决策权的数字出版业务负责人中，有多少在没有市场调研的情况下认为电子书会冲击纸书？有多少不懂服务器技术却斩钉截铁地认为数据放在云服务器上比放在私有服务器上安全？有多少在仅仅具备出版行业经验的情况下，认为自己应该是团队里那个做顶层架构设计的人？
为了避免类似上面提到的种种外行领导内行的情况存在，我们的产品研发团队里全部是80后，大半是90后，并且90后在产品设计上有绝对的话语权，这是一个互联网公司开发团队的常态，在我们出版业界却常常被别人称为“体制灵活”或者“有魄力”。分享一个故事，我们的产品在Demo版本时期（2013年），我曾经带着产品找过多家投资公司（后面会解释原因），有趣的是，分别有一家国内投资公司和国际投资公司的投资顾问对我说过类似的话：“80后做互联网？互联网项目我们现在只投90后了。”虽然这个说法有一定的片面性，但折射出了投资公司对互联网初创项目的态度，他们认为互联网项目的爆发点在于C端的年轻人，了解年轻人的必然是年轻人本身，我们这样的80后“老人”，目光往往难以精准分析年轻人的需求，不信你来分析一下，00后喜欢玩什么？为什么微信始终代替不了QQ？
无论是产品的研发还是产品的运维，人才都是最重要的因素，无论多大规模的出版社，我都听过相关负责人关于人才难寻的抱怨，愿意来的看不上，看上的不愿意来。前者没什么好说的，后者不愿意来出版社工作的原因无外乎薪资和发展两个问题，薪资的制约在于体制，在于不同级别的负责人对人才的重视问题。第二个问题是应面试者主观意识问题，既然选择来面试，就证明他并没有将出版社与BAT等互联网公司做绝对的划分，如果没有薪酬问题，一定是出版社不符合其自身的职业规划或自身现有定位。面试后主动放弃职位的人员中，两类情况最普遍，一是感觉自己在出版社里太小众，不是企业的主流，没有发展空间。一是在同一个工种上只有一人，担心自己在日后的工作中容易进入定式思维，进步缓慢。对于第一种情况，我们面试过程中不再让领导参加，而是部门人员都参与，基本上会以“聊闲天”的方式讨论着技术问题完成面试，并且尽可能多的解释数字部在出版社中的身份如何特殊，完全可以看做是一个小型的互联网公司，每个人都有足够大的发挥空间，有想法有能力任凭发挥，而不是仅仅负责流水线上的某一个模块的开发。同时，我们会进行网络视频面试，让面试者更容易感受到传统文化企业并不是那么古板。对于第二个问题，基于控制成本考虑，无法在相同的工种上安排超过1个人，对此，我们也只能以其他条件进行弥补。 吸引人才加入后，留住人才尤为重要，毕竟每个程序员的开发习惯不同，即使撰写详细的开发文档，在更替开发人员时仍然会存在很多问题。对于技术人员，工作时间、工作环境、工作设备等与传统出版社有很大的不同，比如工作时间上，我们单独制定了7+1小时弹性工作制度，即上午到岗不晚于10点，下午离岗不早于6点，中午休息1-2小时，保证不少于7小时工作时间，如有做不完的事情需要处理控制在1小时内，超出1小时视为加班。程序员在处理个别问题的时候，往往会持续工作至很晚，第二天也无需按照规定时间到岗。有时遇到动画制作任务比较多时，动画师也会申请在家连续工作3-4天，不但不会被其他事情打断从而大大提高制作效率，每天还能节省3-4小时的通勤时间。同理，工作环境和工作设备在条件允许的情况下，给予最大的支持往往会带来效率的提高。
关注点四：过程
前面说过我们的产品开发模式为迭代式和敏捷式，在第一个正式版本时期便开始进入运维期，用户数（拉新）、留存率（粘性）、转化率（盈利）等问题如果在产品设计时期没有进行透彻的思考，此时就要好好进行推敲了。比如，先集中精力拉新再做粘性，还是先做好粘性再拉新，拉新是做线下推广还是线上推广，是做口碑营销还是做事件营销，等等。
在申请国家财政支持前，按照互联网项目的进展程序，我们专门做了商业计划书找投资，虽然碍于体制问题，很多投资公司未必愿意涉足国企项目，同时又遭遇资本寒冬前期，找投资的成功率极低，我们依然找了不同规格不同体制的不下二十家投资公司，也许有人觉得是在浪费时间，其实这样会迫使团队和负责人做很多非常重要又常常被忽略的事情。比如商业计划书对于整理商业思维和产品定位极为重要和有效，在互联网企业里，这一步必须由CEO亲自撰写，除了能让路演更为顺畅，也为让负责人能够通过商业计划书的撰写，反复思考产品的定位。同时，通过接触不同的投资公司，与不同的投资顾问进行探讨，可以对市场定位有一个更为精确的修正，了解当下市场看中的是什么，未来的爆发点在哪里，手中项目盘子的大小判断正误等等。
关注点五：痛点
痛点，是互联网项目的创业点，也就是市场需求，或者说某个现有运转的体系中最弱的环节。解决一个完整的痛点固然有可能成为一个行业的领跑者，但付出的成本和承担的风险也往往较大，如果没有绝对领先的资源，很容易被大企业复制并超越。所以，能解决现有运转体系中的痛点更容易被接纳。这始终是我们做产品的指导思想，也是在我们找投资公司时首先被认可的，甚至是敲门砖。
我们的产品出发点是满足学生自主学习的需求，同时满足一线教师课上课下的教学问题。所有这些痛点都是来自学生和一线教师描述以及我们实地参与调研得到的。但要解决一个完整的痛点，对于我们这样的小团隊是过于沉重的，即使现在有了国家财政支持也难以长时间仅以社会效益作为目标。所以，为了有一定的经济效益支持项目持续发展，必须结合现有目标，在数字出版乃至传统出版中寻找痛点发力，以项目养项目。我们本身也是传统出版出身，自己的痛点多多少少也是整个行业的痛点。在当时，“书配盘”的出版模式迅速萎缩，一方面光盘介质在大众存储领域即将退出历史舞台，各种设备已经难以见到光盘驱动器。另一方面，公共网盘等网络介质的不安全、不稳定因素与广告泛滥等问题还无法取代光盘的地位。如果纸质图书使用我们的App能代替光盘或者网盘，并且还能加密、随身阅读、读者交互、编辑和作者随时增加新资源等等，而每册书仅增加1元成本，远低于光盘的成本，还能降低运输过程中的损毁，同时降低读者的阅读成本。这笔账很清楚，所以解决这个痛点也很容易成为项目的切入点。依照这个思路，我们先后又增加了“一册一码”“3D引擎”“离线阅读”“Flash动画移动解决方案”“直播”“电商接入”等功能。所有这些功能在我们与同行交流时，都会得到共鸣。同时，能做到随时增加新模块解决痛点的前提就是，必须自建团队进行迭代式和敏捷式开发。
数字出版产品不像传统出版物有一个特定的线性周期，而应该是循环发展的周期性产品，从出版属性来看，数字出版物的生命周期可无限延长，作者和编辑可以定期更新内容，读者的参与和二次创作也可以让产品内容更加丰富，甚至衍生出新的产品。从互联网产品属性来看，网络产品具备永恒的生命，这与网络的基本属性有关，网络上的内容是永远不会被消除的，即使产品失去活力，不再运维，也将在互联网的某个角落存在。所以，数字出版产品在研发和运维时要注重产品自身的发展与转型，这也是下一个重要的议题，没有永远时髦的产品，只有永远受欢迎的改变。
热词：数字出版 产品研发 产品运维
北京交通大学出版社的数字出版产品研发完全采用自主研发，实践证明：自主研发的成本并不比外包研发高。在笔者看来，数字出版产品研发本就不应该有所谓的外包开发，因为没有出版经验渗透其中的技术开发是毁灭性的。下面笔者就关于产品在研发过程中比较关注的几点做一下阐述。
关注点一：研发模式
如今，认识到应该自主研发产品的出版社还不多，但是坚持一定外包研发的出版社越来越少。在数字出版转型初期，几乎所有的出版机构都认为应该走合作研发的路线，论调是：“出版社应该把精力放在内容上”“合作研发节约成本”等明显的“+互联网”思维，而不是“互联网+”思维。当初所谓合作研发其实就是外包研发，因为出版社能做的仅仅是提出需求，这些需求仅仅是结果层面的，而不是过程层面的，这样的需求可能成为整个产品的瓶颈甚至“毒瘤”，摧毁整个项目。同时，如果采用外包开发模式，必然也要采用外包运维。因为，广义的产品研发并不仅仅是一款App的开发环节，还包括更重要的运维与推广环节，开发环节只能占整个环节的10%。
一般来说，一款产品的研发包括需求分析、需求评估、规划与架构、程序开发、测试、上线、运维等几个主要环节。从人员参与来看，出版人能勉强参与的环节仅仅是需求分析、测试和运维，还都是基于内容上的参与，99%的事情都是技术公司完成的，那这样一款产品到底是谁的？不要小看理解上的偏差，当使用语言描述一个功能或者一个概念时，每个人的理解都是千差万别的，即使是做出产品原型，在架构上的偏差也会在产品正式运行后出现差之毫厘谬以千里的可能。
所有经历过产品开发的团队都知道，目前出版相关的产品大多不会使用瀑布式（对于小体量开发代价太过高昂）和螺旋式（相对来说不太在乎风险）开发方式，基本都会使用迭代式或敏捷式开发方式，这两种开发方式首要强调的就是高度协作，迭代开发方式的特点就是忽略一些明知不完美甚至有问题的地方，按照“先主再辅最后补”的方式进行开发，即使产品上线后，每天都会有需要更改的地方，也就是说开发永不停歇。外包开发既做不到高度协作，又做不到持续开发，而敏捷开发比迭代开发的每一轮周期更短，并且是强调适应性而非预见性，这一条从根本上否定了外包开发。
关注点二：驱动力
数字出版转型初期，我多次强调技术的关键作用，往往被很多老前辈“打”成技术驱动派，认为出版社根本没有能力掌握技术，应该坚持“内容为王”，也就是内容驱动。他们大概是觉得我不认为内容重要，或者觉得我想让出版社与BAT（百度、阿里、腾讯）拼技术。作为晚辈，不太适合当场辩驳，其实在数字出版时代，内容驱动是错觉，内容强大是传统出版的优势在数字出版时代的继承而非决定因素，或者说“内容为王”是一个出版社存在的基础而非数字出版转型的核心，通过不同的包装或者展现形式，将原本优质的内容重新以数字出版形式发行，其关键在于技术的运用而非内容上的创造。举个例子，内容的管理者是作者和编辑（包括策划编辑和内容编辑），如果这两个角色均不了解技术，如何在已有内容上进行数字出版形式的改造，更别提从零开始专门为数字出版形式进行内容创作了，我相信处在各出版社数字部门的同仁，一定经常被传统编辑询问某个产品如何改造，某个想法如何实现。至少，内容管理者想得到就可以进行讨论研究，如果内容管理者根本想不到，创造或者改造就无从谈起。知识决定思想的范围，如果不了解AR（增强现实）中图像识别技术的基本常识，编辑就不会考虑书中每张图片的差异量如何控制，如何选定识别率高的图片，这样的例子太多了。
数字技术人员，虽然欠缺文字编辑功底，创作或改造的作品在文字、标点、格式方面都会有问题，但并不会影响作品的创意和内容，并且在传统编辑加工环节会将这些瑕疵修正。
那么如何才算技术驱动？我认为，只有以专业背景为基础，全面了解各项数字媒体技术，能主动运用于创作活动中才算技术驱动。单项技术只能算工具，谈不上驱动。所以，技术驱动的门槛很高，也就是我们团队常常自诩的“会技术、懂出版、晓传媒”，虽然我们还远未达到，但这一定是数字出版人才需要具备的，这也是為什么国家现在开始注重数字编辑人才培养了，就是要打破壁垒。
关注点三：身份与人才
数字出版人需要放下传统出版时代“文化人”的姿态，放低身价，虚心听取那些与先前经验里相对立的部分。在数字出版转型初期，有决策权的数字出版业务负责人中，有多少在没有市场调研的情况下认为电子书会冲击纸书？有多少不懂服务器技术却斩钉截铁地认为数据放在云服务器上比放在私有服务器上安全？有多少在仅仅具备出版行业经验的情况下，认为自己应该是团队里那个做顶层架构设计的人？
为了避免类似上面提到的种种外行领导内行的情况存在，我们的产品研发团队里全部是80后，大半是90后，并且90后在产品设计上有绝对的话语权，这是一个互联网公司开发团队的常态，在我们出版业界却常常被别人称为“体制灵活”或者“有魄力”。分享一个故事，我们的产品在Demo版本时期（2013年），我曾经带着产品找过多家投资公司（后面会解释原因），有趣的是，分别有一家国内投资公司和国际投资公司的投资顾问对我说过类似的话：“80后做互联网？互联网项目我们现在只投90后了。”虽然这个说法有一定的片面性，但折射出了投资公司对互联网初创项目的态度，他们认为互联网项目的爆发点在于C端的年轻人，了解年轻人的必然是年轻人本身，我们这样的80后“老人”，目光往往难以精准分析年轻人的需求，不信你来分析一下，00后喜欢玩什么？为什么微信始终代替不了QQ？
无论是产品的研发还是产品的运维，人才都是最重要的因素，无论多大规模的出版社，我都听过相关负责人关于人才难寻的抱怨，愿意来的看不上，看上的不愿意来。前者没什么好说的，后者不愿意来出版社工作的原因无外乎薪资和发展两个问题，薪资的制约在于体制，在于不同级别的负责人对人才的重视问题。第二个问题是应面试者主观意识问题，既然选择来面试，就证明他并没有将出版社与BAT等互联网公司做绝对的划分，如果没有薪酬问题，一定是出版社不符合其自身的职业规划或自身现有定位。面试后主动放弃职位的人员中，两类情况最普遍，一是感觉自己在出版社里太小众，不是企业的主流，没有发展空间。一是在同一个工种上只有一人，担心自己在日后的工作中容易进入定式思维，进步缓慢。对于第一种情况，我们面试过程中不再让领导参加，而是部门人员都参与，基本上会以“聊闲天”的方式讨论着技术问题完成面试，并且尽可能多的解释数字部在出版社中的身份如何特殊，完全可以看做是一个小型的互联网公司，每个人都有足够大的发挥空间，有想法有能力任凭发挥，而不是仅仅负责流水线上的某一个模块的开发。同时，我们会进行网络视频面试，让面试者更容易感受到传统文化企业并不是那么古板。对于第二个问题，基于控制成本考虑，无法在相同的工种上安排超过1个人，对此，我们也只能以其他条件进行弥补。 吸引人才加入后，留住人才尤为重要，毕竟每个程序员的开发习惯不同，即使撰写详细的开发文档，在更替开发人员时仍然会存在很多问题。对于技术人员，工作时间、工作环境、工作设备等与传统出版社有很大的不同，比如工作时间上，我们单独制定了7+1小时弹性工作制度，即上午到岗不晚于10点，下午离岗不早于6点，中午休息1-2小时，保证不少于7小时工作时间，如有做不完的事情需要处理控制在1小时内，超出1小时视为加班。程序员在处理个别问题的时候，往往会持续工作至很晚，第二天也无需按照规定时间到岗。有时遇到动画制作任务比较多时，动画师也会申请在家连续工作3-4天，不但不会被其他事情打断从而大大提高制作效率，每天还能节省3-4小时的通勤时间。同理，工作环境和工作设备在条件允许的情况下，给予最大的支持往往会带来效率的提高。
关注点四：过程
前面说过我们的产品开发模式为迭代式和敏捷式，在第一个正式版本时期便开始进入运维期，用户数（拉新）、留存率（粘性）、转化率（盈利）等问题如果在产品设计时期没有进行透彻的思考，此时就要好好进行推敲了。比如，先集中精力拉新再做粘性，还是先做好粘性再拉新，拉新是做线下推广还是线上推广，是做口碑营销还是做事件营销，等等。
在申请国家财政支持前，按照互联网项目的进展程序，我们专门做了商业计划书找投资，虽然碍于体制问题，很多投资公司未必愿意涉足国企项目，同时又遭遇资本寒冬前期，找投资的成功率极低，我们依然找了不同规格不同体制的不下二十家投资公司，也许有人觉得是在浪费时间，其实这样会迫使团队和负责人做很多非常重要又常常被忽略的事情。比如商业计划书对于整理商业思维和产品定位极为重要和有效，在互联网企业里，这一步必须由CEO亲自撰写，除了能让路演更为顺畅，也为让负责人能够通过商业计划书的撰写，反复思考产品的定位。同时，通过接触不同的投资公司，与不同的投资顾问进行探讨，可以对市场定位有一个更为精确的修正，了解当下市场看中的是什么，未来的爆发点在哪里，手中项目盘子的大小判断正误等等。
关注点五：痛点
痛点，是互联网项目的创业点，也就是市场需求，或者说某个现有运转的体系中最弱的环节。解决一个完整的痛点固然有可能成为一个行业的领跑者，但付出的成本和承担的风险也往往较大，如果没有绝对领先的资源，很容易被大企业复制并超越。所以，能解决现有运转体系中的痛点更容易被接纳。这始终是我们做产品的指导思想，也是在我们找投资公司时首先被认可的，甚至是敲门砖。
我们的产品出发点是满足学生自主学习的需求，同时满足一线教师课上课下的教学问题。所有这些痛点都是来自学生和一线教师描述以及我们实地参与调研得到的。但要解决一个完整的痛点，对于我们这样的小团隊是过于沉重的，即使现在有了国家财政支持也难以长时间仅以社会效益作为目标。所以，为了有一定的经济效益支持项目持续发展，必须结合现有目标，在数字出版乃至传统出版中寻找痛点发力，以项目养项目。我们本身也是传统出版出身，自己的痛点多多少少也是整个行业的痛点。在当时，“书配盘”的出版模式迅速萎缩，一方面光盘介质在大众存储领域即将退出历史舞台，各种设备已经难以见到光盘驱动器。另一方面，公共网盘等网络介质的不安全、不稳定因素与广告泛滥等问题还无法取代光盘的地位。如果纸质图书使用我们的App能代替光盘或者网盘，并且还能加密、随身阅读、读者交互、编辑和作者随时增加新资源等等，而每册书仅增加1元成本，远低于光盘的成本，还能降低运输过程中的损毁，同时降低读者的阅读成本。这笔账很清楚，所以解决这个痛点也很容易成为项目的切入点。依照这个思路，我们先后又增加了“一册一码”“3D引擎”“离线阅读”“Flash动画移动解决方案”“直播”“电商接入”等功能。所有这些功能在我们与同行交流时，都会得到共鸣。同时，能做到随时增加新模块解决痛点的前提就是，必须自建团队进行迭代式和敏捷式开发。
数字出版产品不像传统出版物有一个特定的线性周期，而应该是循环发展的周期性产品，从出版属性来看，数字出版物的生命周期可无限延长，作者和编辑可以定期更新内容，读者的参与和二次创作也可以让产品内容更加丰富，甚至衍生出新的产品。从互联网产品属性来看，网络产品具备永恒的生命，这与网络的基本属性有关，网络上的内容是永远不会被消除的，即使产品失去活力，不再运维，也将在互联网的某个角落存在。所以，数字出版产品在研发和运维时要注重产品自身的发展与转型，这也是下一个重要的议题，没有永远时髦的产品，只有永远受欢迎的改变。