在2013初，笔者把过去两年开发app后端的经验总结成十多篇文章发表在博客上，那些笔记发表以后的反响出乎本人的意料，本人从网络上得到网友的支持和肯定，证明这些知识还是有价值。
2013年离开了当时的创业团队后思考今后的技术方向，当时笔者已经开发过两个社交app的后台，对开发app后端的流程比较熟悉，但是从技术发展的角度来看，笔者缺乏开发大流量大并发的技术经验，在今后的职业发展上必须填补这方面的空缺，因此就职时倾向于选择一些有大流量的公司。
当时笔者只投了两家企业，最后都拿到了offer，一个offer是现在工作的bmob后端云，每天访问量有上亿，另外一个offer 是一个用户量上亿的音乐app的基础技术部，每天的访问量更大。当时笔者考虑是那时bmob后端云我加入后也就3个后台工程师，在这种大平台小团队的环境中，想完整地掌握整个后台的架构不难，而且能得到应付每日亿级访问量的经验，有更多的负责全局的机会；而音乐app公司后台技术团队人员已经很多，笔者加入的话只能负责其中某些模块，很难完整掌握整个后台架构。因此笔者最后决定加入了bmob后端云。
笔者加入bmob接触到后台各个方面，技术水平和眼界也有了很大的提升，对以前写的一系列app后端开发文章也不太满意，当时和qq群上网友聊天时透露的这些想法也得到众多网友的支持，于是就打算重新写一系列关于“app后端架构”文章。
2015年时自媒体概念流行，微信公众号上的口号“再小的个体，也有自己的品牌”撩动了大众的神经，而笔者一向推崇“学习，实践和分享应该是3位一体”，正好借助重写一系列“app后端架构”文章的机会，实践和反思学习到的商业知识。
当时笔者的想法是试水自媒体，而产品就是一系列“app后端架构”文章，通过运作这个品牌和产品去实践学习过的商业知识。
后来笔者这系列“app后端架构”文章在博文视点的付编辑帮助下，能以书籍《App后台开发运维和架构实践》的方式展现在各位读者面前。
本文从下面几个方面展示了笔者在这个过程中的思考：
产品分析
目标用户
卖点
渠道
内容
内容的优化
思维的飞跃
产品分析
产品
产品就是一系列的“app后端架构”文章，而笔者自身的客观情况决定了能写出什么样的文章，因此产品分析其实是笔者自身情况的分析。
2015年时笔者分析自身的状况，优点如下：
1.两年半的外资企业工作经历，养成了良好的做事习惯和规范化的开发流程。
2.接近两年在创业团队中app后台开发经验，完整地经历了两个app后台“从0到1”的阶段，熟悉创业团队的整个工作流程和创业团队的开发模式。
3.两年在bmob后端云的工作经验，真正经历了亿级日访问量的技术洗礼，同时由于大平台小团队的原因，负责了大量的开发和运维工作，接触的技术范围非常广，对整个后台架构也非常熟悉。
4.一直以文艺青年（现在已进化为文艺中年人^-^）自居，享受写作的过程。
5.有长期写博客的习惯，文笔还行。
不足的地方如下：
1.没有一线互联网公司的工作经历，不了解大公司的工作流程和企业文化。
2.虽然通过网络了解过BAT等巨头的技术架构，但没有真正的实践经验，也没法和真正的业务结合起来，因此这些知识都是纸上谈兵，只能在吹牛时提高自身的逼格。
目标用户：
结合自身长期工作于创业团队的经历，对初创型团队的了解比较深入，而且技术上的技能是以app后台开发为主，这两者结合起来就是“创业团队中的app后台开发”。
什么人对“创业团队中的app后台开发”这个主题感兴趣？
一开始我以为只有和我类似经历的“app后台开发人员“是我的目标用户，后来在网络上发表的文章我留下了一个qq群号码，让感兴趣的同学加入到qq群中交流。在交流的过程中，我发现了目标用户比我想象中的更多，总结了下面3种用户画像（用户有多种，通过用户画像（例如职业，年龄，学历，地域等属性）给用户分类，通过分类更容易把握用户的需求）：
1.从传统软件开发行业转入app后台的开发人员。
2. 创业团队中的创始人，需要寻找技术合伙人。
3. 进入了创业团队，但还没有完整app后台开发经验的初级开发人员。
我估算了他们的比例：
app后台开发经验的初级开发人员：80%
从传统软件开发行业转入app后台的开发人员：10%
创业团队中的创始人：10%（2015年股灾后，这部分的用户基本消失了）
卖点：
有了上面的目标用户定位后，笔者就要确定“app后端”这个自媒体的卖点是什么？
这里的卖点，笔者所指的是由于app后台开发的内容非常广泛，“app后端”自媒体中的内容主要偏向于哪些方面？自媒体通过提供这些方面的知识来吸引目标用户。app后台开发的内容很广泛，有高深的架构知识、有运维知识、还有开发的管理方面，各个方面的内容都有各自的受众，需要结合自身的特点和市场来决定自身的卖点。
笔者分析卖点，是通过分析目标用户的需求来决定：
下面是笔者列举“创业团队中的app后台开发”的需求：
1.正式开发产品前，要招聘app后台工程师的需求，例如招聘使用哪种语言的工程师？
2.开发产品时，有下面的需求：
（1）分析业务流程，决定基本的技术架构的需求。
（2）完善产品开发效率的需求，例如面对创业团队中产品需求多变的特点，开发上应该怎样应对？
（3）技术的选型需求，例如用哪种数据库，用哪些推送服务，用哪种服务器？
（4）对于从未接触过app后台的开发人员，还要了解app后台不同于web的一些技术：例如推送，LBS。
3.产品上线后，有运维的需求：
（1）开发人员怎么合理选择服务器的具体配置，怎么快速部署服务器？
（2）面对线上出现的各种问题，怎么分析原因在哪？
（3）如何应对开发速度跟不上业务上的快速增长？
在本文的产品分析中提到，笔者的主要特点：
1.技术面广。
2.没有专研深入的技术领域。
3.比较喜欢写作。
因此结合上面的需求，笔者决定了下面的核心卖点：
使用通俗易懂的语言去讲述app后台各类技术，主要涉及某个技术的应用场景以及基本原理。
上面的核心卖点确定后，由于这个自媒体的卖点是使用通俗易懂的语言讲技术，对技术的基础要求不高，因此 “app后端”这个自媒体的目标读者范围可以扩大，增加了产品经理，android和ios程序员，因为他们都有了解app后台的需求。
渠道：
渠道是指：在哪里发表文章？
文章发表在哪里，这个问题的核心是：“app后端”的目标用户怎么才能接触到“app后端”这个自媒体的文章？
简单点来说，因为用户在网络中会通过各种网站和app接触到不同的信息，例如微博，微信，知乎，搜索引擎等等， “app后端”的目标用户主要集中在哪个网站或app？只有把“app后端”发表在正确的渠道，才能让目标用户了解和接触到“app后端”这个自媒体的内容。当然了，如果有足够的精力可以发布在所有你知道的渠道上，但本人精力有限，只能挑一至两个渠道发布。
下面是笔者对几个渠道的分析：
微信公众号
微博
知乎
搜索引擎
（1）微信公众号
现在想找到一个没有安装微信的手机很困难，微信公众号是移动互联网年代最大的中文信息入口，基于中国庞大人口带来的红利，无论多小众的领域都能在微信上找到对应的目标用户。
按照“app后端”目标用户“IT人员”的使用习惯，使用微信最主要的时间是在上下班的交通工具和家里，但这两个时间段都没有一个良好的学习驱动力，阅读微信上的信息主要以休闲娱乐为主。
而且微信公众号的设计是以时间线为主，这就意味着文章必须具备很强的热点效应，一篇文章发的几天不能吸引用户阅读，以后就更不会有用户阅读，对笔者这种讲解基本原理的文章很不利。
所以在微信渠道上笔者没投入多少时间，但是考虑到微信强大的沟通效果，和用户建立联系的便捷性，笔者把微信作为一个辅助的渠道。
（2）微博
娱乐八卦消息太多，不考虑。
（3）知乎
优质的渠道，上面聚集了大量的IT用户，但里面的内容不是以IT技术为主，但问答的方式不利于讲述各类技术，而且现在知乎的运营上有向八卦平台发展的方向。
读者可以想想，如果笔者想讲述某个具体的技术，必须要找一个对应的问题，很多技术不一定有相应的问题，这就只能自问自答了。
还有一个知乎专栏，虽然能解决上面提到没有相应问题的矛盾，但是专栏的流量是由答主通过回答问题，吸引用户关注导入，既然笔者不愿意回答问题，那也不会有啥流量。
最后考虑到笔者精力有限，放弃了知乎这个渠道。
（4）搜索引擎
在什么样的场景下，读者才会需要了解某个技术的适用范围和基本原理？
根据笔者自身的经验，是在自身遇到某个技术相关问题的时候。
而遇到某个技术相关问题时，最重要的解决方法是什么？是搜索。
“遇到技术问题，搜索相关答案”的场景，是技术类文章最重要的用户入口。所以笔者把搜索引擎作为“app后端”最主要的渠道。
内容：
完成渠道的选择后，就要根据渠道去制作相关的内容。
内容有下面3种形式：视频、音频、文字。
音频对于技术类的内容来说，可以放弃。
视频内容是不利于搜索（现在的技术还没法搜索视频的内容），不容易制作（一个视频不允许有重大失误，不然就只能重录），不利于修改（没法修改，只能选择重录），再加上笔者一口广东普通话，因此放弃了。
搜索渠道最适合的内容载体是文字，搜索引擎可以收录文字的全部内容。
既然最重要的是搜索渠道，那么就不得不提SEO。
笔者使用的主要SEO方法：
（1）权重
笔者长期在CSDN博客上发表文章，既然要打造“app后端”这个自媒体，那么需要建立一个独立博客吗？
考虑到CSDN这个专业的IT网站比独立博客有更高的权重，更容易被搜索引擎收录，排名更高，而且笔者目前的主要需求就是写文章而已，还不需要用到其他的功能，因此还是选择把文章发表在CSDN。
（2）关键词矩阵
用一级核心关键词+多个二级关键词作为文章标题，实现SEO霸屏术，确保文章能有足够多的机会能为用户搜索到。
一级关键词是最容器被搜索到的关键词， 当时考虑到的一级关键词有两个：“app后台”和“app后端”。比较后发现“app后台”在搜索引擎上被很多公司竞价排名了，如果笔者用这个词作为一级关键词，争不赢竞价的公司，所以最后选择了“app后端”一级核心关键词。
二级关键词是围绕着“app后端”相关的技术，例如开发语言，服务器，LBS等等，最后的文章标题是这样的：
app后端选择什么开发语言
app后端选择什么服务器
app后端如何实现LBS
（3）文章的互相索引
如果用户阅读了“app后端”系列的其中一篇文章，怎么引导用户阅读其它文章？
由于CSDN博客不支持文章签名功能，因此笔者选择的方法是在“app后端”系列每篇文章的结尾都指向了一篇相同的索引文章，在这篇索引文章中列出了所有发表的文章。
内容的优化：
接下来的问题是：如何用通俗易懂的语言写文章？这是不是有一定的方法或技巧的呢？
笔者参照《商业就是一场秀》这本书的内容，在“app后端”系列文章中使用了下面的写作框架：
（1）描述背景，建立认同感。
文章阅读犹如下阶梯，应该从第一句开始就吸引读者的注意，让读者读完第一句就想读第二句，再到第三句，直到结尾。
什么内容最容易吸引读者注意？和读者利益相关的内容，也就是这篇文章能给读者带来的好处，或者能给读者解决的痛苦，从而获得读者的认同，让读者有继续阅读的欲望。
另外在描述痛苦或好处中，同时建立了整篇文章的整体内容框架，让读者对文章的内容有个大概的认识，减轻读者的认知负担。
下面是《app是怎么炼成》这篇文章中开头的例子：
很多刚进入app后端的小伙伴，有的是之前没有接触过这个行业，有的是只在学校学习了基本的技术知识，不知道开发app的整个流程是怎么样的，因此心里会有一股恐惧。听着别人口中的一大串app相关的术语，也不知道怎么回事，更谈不上和别人交流。在本文中，根据本人在创业公司的经历，帮你解决以上的疑惑，助你迈入app开发的大门。
（2）讲故事，使内容不再抽象
大脑爱故事。
大脑天生不喜欢抽象的概念，喜欢具体形象的概念。通过拟人化的故事，使产品不再抽象。
但讲故事这个技巧，笔者在《app后端》中没用过，因为没学会^-^。而《商业就是一场秀》里面的故事，我觉得没什么吸引力，很无聊。
（3）类比，建立事物间的联系。
笔者一直认为，计算机是人类智慧的产品，因此，计算机中的大量概念能在生活中找到原型。把读者陌生的概念，和一个读者生活中熟悉的概念建立连接，可以让读者更容易理解。
通过类比的方法介绍某个概念，会在一定程度上丧失了概念的精确性，但为了使读者更容易理解某个概念，这种精确性的丧失对于科普类的文章来说，笔者认为是可以接受。
笔者在介绍Fastdfs这款分布式文件系统时，使用了下面的类比：
在生活中的仓库里，有很多货柜用来存放货物，怎么能保证无论增大了多少货柜，都能被合理使用的呢？
核心是每个仓库里都有一个仓库管理员，当增加了货柜，仓库管理员都收到。当工人需要向仓库里放货物，先问仓库管理员哪个货柜有足够的空间存放货物，仓库管理员会告知工人具体哪个货柜，然后工人走到对应的货柜中存放货物。
上面仓库中的仓库管理员和货柜，就是FastDFS在生活中的模型。
FastDFS就是仓库, FastDFS里有两大角色：跟踪器（tracker）和存储节点（storage）。跟踪器（tracker）就是仓库管理员，主要做调度工作，在访问上起负载均衡的作用。存储节点（storage）就是货柜。
（4）描述
使用讲故事和类比的方法让读者初步了解某个概念后，就需要用精确的语言去描述具体的内容，有两个需要注意的地方：
1.尽量用具体形象的方法，例如发现某个概念用抽象的语言很难理解，可以画图说明。一副图胜过前言万语。这点在网络上发表《app后端》系列文章时做得不好，后来在出版书籍《App后台开发运维和架构实践》弥补了这点，为《App后台开发运维和架构实践》配上了200张左右的图片。
2.避免“知识的诅咒”。如果目标读者是初学者的文章，一大堆的专业术语，他们看得懂吗？在写文章的时候，要注意初学者和行业资深人员知识上的差距，先从一些简单的概念出发，一步步引导初学者逐步掌握高深的概念。
思维的飞跃：
写博客的过程中，读者和我聊天时问我有没有想过出书，他可以给我介绍编辑，但我觉得自己悠然自得地写博客和公众号就好了，书籍出版这个渠道太折腾，也没啥用，于是婉拒了这位读者的好意。
个人身处移动互联网行业4年多了，经历了3个创业团队，两次的失败经历。在这个过程中，我都是负责技术方向的，考虑的都是后台架构方面的问题，怎么让后台更高效等。
后来慢慢开始在博客上，公众号上分享自己在创业团队中的经历，在qq上，在app后端qq群上和来自全国的创业者和后端开发聊天，眼界打开了。这个过程中，虽然也有对产品和技术的思考，但更多的也只是停留在表面上，没有进一步思考到这里面的商业化思维。
直到我看了老鹰发表的这篇文章《我靠微信公众号一天之内忽悠了十万元》做了深刻的反省，才发现自己是井底之蛙，一直都是“小农思想”，不懂得商业化思维。
后来“博文视点”的付编辑联系我，问我出书的意愿时，我考虑了一下就答应了。作为一名爱读书的文艺中年人，写书的过程要付出什么我很清楚，但当我用商业化的思维去思考这件事情，发现是利大于弊：
（1）“博文视点”作为国内著名的计算机图书品牌，拥有众多的合作渠道和良好的口碑，通过“博文视点”的渠道，我的作品能出现在大型的公众号平台（例如“运维帮”），京东，当当，亚马逊等国儿大型的购书网站，电子书平台，还有各大书店，这些渠道靠我目前个人的能力是无法接触。
（2）出书能提升自身的技术形象，“某某书作者”这个头衔在大众的观念中还是有一定的权威性。在某次去医院的时候，一开始医生还是脸无表情，听到我出版了一本书，立刻和我兴致勃勃地聊起了出书的事情。
（3）国内的确是缺乏《App后台开发运维和架构实践》这种专门针对App后台技术的书籍，现在都是移动互联网的时代，有这方面的强烈需求。通过出版书籍，能让更多的读者了解到这方面的知识。
（4）作为一名文艺中年人，没出过书始终是一大遗憾，虽然不能出版纯文艺书籍，但出版一本技术书伪装成技术文青还是挺好。这是一个文艺中年人炽热的心啊！
这个过程中的不足：
1. 写书的时候没有和用户的交流，所有业余时间都花费在写书上，这个过程是很危险，脱离了用户，走错一步就无法返回了 。同时写书后博客和公众号都没怎么更新了，热度有所下降，幸好SEO策略生效了，博客上的文章每天都带来固定的流量。
2. 缺乏写书的经验，有一些章节当初没想好就直接下笔了，导致交稿前3个星期，推倒重写了一个章节，时间非常紧迫。
3. 经历了第一本书的写作，这种闷头写书（中间曾经想过把书稿发给部分朋友看，咨询他们的意见，但没法控制书稿不被泄露，最后还是放弃了这个想法）的方式太危险了，整个写书过程没有任何反馈和迭代，一步错以后就全错了。这本书写得我胆颤心惊，我很怕内容把握错了，7个月的心血就全没。
《App后台开发运维和架构实践》一书上架各大网上书店的时候，发现了两个问题：
1.由于书名是《App后台开发运维和架构实践》，有部分网上书店的编辑人员把这本书归到“移动开发”这个分类，其实这本书应该是“架构”方面的分类，虽然后来做了些补救措施，但是有部分网站还是没法改分类。
2.我一直认为详细的目录是有利于读者检索和查找信息，因此这本书的目录占到了7页，结果网上的书店没有把本书的目录贴完整，大多数网站都只贴了一部分目录，这样极大不利于读者在浏览网页时了解本书的内容。
《App后台开发运维和架构实践》已经在京东，当当，亚马逊等网上书店上架了，在创业过程中相当于产品已经出来了，接下来就是大力推广（由于书籍的特殊性，没法迭代）。
第一次推广是在端午节前，在我经营了两年的qq群渠道（这个qq群的成员都是阅读过我发表的“app后端”系列文章的读者，和本书的目标用户高度重合）上用EDM邮件和@全体成员这两大利器推广，过了3天后就发现《App后台开发运维和架构实践》上了京东计算机分类新书榜的第10位（第10位是个很关键的位置，这个位置意味着京东的用户一打开“计算机”分类的网页就能看到书《App后台开发运维和架构实践》的链接，类似于app store的打榜），打算在端午后来第二波推广，结果发现了一个残酷的事实：
书没货了！
书没货了！
书没货了！
京东的书没货了，那在京东这个渠道上怎么推广都是白搭！这使我认识到纯粹的线上产品和实体产品的区别，我还不能控制京东什么能补上货。实体产品受库存的影响，还有供应链的影响，推广实体产品和纯粹的互联网产品是有区别。
接下来，我准备干什么？
一直都在关注踏浪100这个互联网营销学习网站，于是我买了它的VIP会员资格，现学现用互联网营销的知识，这篇文章也是学了它的课程后根据相应的知识点整理出来，接下来就是不断学习上面的营销知识，用所学的知识推广书籍《App后台开发运维和架构实践》。
在《认知写作学》的课程中，阳老师提醒过我们：
最后一个提醒就是，成年后，绝大多数事情都是自我决定，自我驱动，自我教育，自我输出。这种习惯的养成，容易受益终身。但是受制于小时候学习习惯的影响，我们依然每次学习，都会追逐完美，总想直接拿100分，而忘记了「最小」，这一点，相信不少同学会体味非常深刻。
你越追求完美，就容易拖延；你越追求「最小」，就越容易走到课程终点。成年后，像超级大牛西蒙所说的一样，给自己上一课，做「追求满意的人」而非「追求最优的人」。
这是成年后，终身学习与高中时应试学习最大的区别。永远学习；永远好奇；永远保持独立思考；永远与众不同。
不懂网络营销怎么办？学！
学了营销的最小知识：写文案，选择渠道，监测营销效果后，就立刻把知识投入到实践当中。
实践中发现问题怎么办？改！不怕做错，就怕不知道是做对还是做错。而且在这个过程中，试错的成本没有大家想象中那么高：就算犯错了，我会损失什么？
学而时习之，不亦说乎？