在2013初，筆者把過去兩年開發app後端的經驗總結成十多篇文章發表在博客上，那些筆記發表之後的反響出乎本人的意料，本人從網絡上獲得網友的支持和確定，證實這些知識仍是有價值。android
2013年離開了當時的創業團隊後思考從此的技術方向，當時筆者已經開發過兩個社交app的後臺，對開發app後端的流程比較熟悉，可是從技術發展的角度來看，筆者缺少開發大流量大併發的技術經驗，在從此的職業發展上必須填補這方面的空缺，所以就任時傾向於選擇一些有大流量的公司。ios
當時筆者只投了兩家企業，最後都拿到了offer，一個offer是如今工做的bmob後端雲，天天訪問量有上億，另一個offer 是一個用戶量上億的音樂app的基礎技術部，天天的訪問量更大。當時筆者考慮是那時bmob後端雲我加入後也就3個後臺工程師，在這種大平臺小團隊的環境中，想完整地掌握整個後臺的架構不難，並且能獲得應付每日億級訪問量的經驗，有更多的負責全局的機會；而音樂app公司後臺技術團隊人員已經不少，筆者加入的話只能負責其中某些模塊，很難完整掌握整個後臺架構。所以筆者最後決定加入了bmob後端雲。程序員
筆者加入bmob接觸到後臺各個方面，技術水平和眼界也有了很大的提高，對之前寫的一系列app後端開發文章也不太滿意，當時和qq羣上網友聊天時透露的這些想法也獲得衆多網友的支持，因而就打算從新寫一系列關於「app後端架構」文章。web
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（http://www.talang100.com/）這個互聯網營銷學習網站，因而我買了它的VIP會員資格，現學現用互聯網營銷的知識，這篇文章也是學了它的課程後根據相應的知識點整理出來，接下來就是不斷學習上面的營銷知識，用所學的知識推廣書籍《App後臺開發運維和架構實踐》。
在《認知寫做學》的課程中，陽老師提醒過咱們：
最後一個提醒就是，成年後，絕大多數事情都是自我決定，自我驅動，自我教育，自我輸出。這種習慣的養成，容易受益終身。可是受制於小時候學習習慣的影響，咱們依然每次學習，都會追逐完美，總想直接拿100分，而忘記了「最小」，這一點，相信很多同窗會體味很是深入。
你越追求完美，就容易拖延；你越追求「最小」，就越容易走到課程終點。成年後，像超級大牛西蒙所說的同樣，給本身上一課，作「追求滿意的人」而非「追求最優的人」。
這是成年後，終身學習與高中時應試學習最大的區別。永遠學習；永遠好奇；永遠保持獨立思考；永遠不同凡響。
不懂網絡營銷怎麼辦？學！
學了營銷的最小知識：寫文案，選擇渠道，監測營銷效果後，就馬上把知識投入到實踐當中。
實踐中發現問題怎麼辦？改！不怕作錯，就怕不知道是作對仍是作錯。並且在這個過程當中，試錯的成本沒有你們想象中那麼高：就算犯錯了，我會損失什麼？
學而時習之，不亦說乎？
這個過程的最終成果，點擊「閱讀原文」就去瞧瞧^-^