文/某鳥
起筆之前，我算了算距離寫上一篇文章的時間，大概已有半年左右。且這兩年寫的東西都是寫隨想云云，真正算上輸出的，可能要追溯到兩年之前。伴隨著職業生涯的高歌猛進，單單是為了讓一篇文章言之有物，敘之有理，就已經足以讓我難產了。
所以能在一篇文章中只描述自己的理解，而不深究其因果淵源，美其名曰『總結』，大抵是年終饋贈給我最好的借口了。
轉崗產品經理
如果回看這一整年，轉崗一定是繞不過去的坎。如果把畫第一張原型稿的時間看作正式轉崗的話，到今天為止，正好整整七個月。
記得去年向一個著名產品經理發求職信時，還只是怯懦的表述自己『有產品野心』。在那個階段，大概就已經把產品經理崗位標注為自己未來職業發展的一環，但更多的是想占個便宜，希望能『無產品經理之職，學產品經理之實』。究其原因，是因為每次對產品經理工作崗位的職責做推演，都覺得其艱辛復雜且枯燥。
而今年決定轉崗，則是判斷當時的時間節點，可能是自己在目所能及的未來里最容易轉崗的機會。慶幸自己身處創業公司，具體情節不再贅述。
我不知道自己算不算入了門
雖然對轉崗一事早有預謀，但直到現在，我都無法確切地描述出產品經理的定義。大部分的轉崗原因，反而是因為對研發工作的擔心。
擔心的東西并不是職業發展，而是視野受限。人的時間和精力總是有限的，在研發工作的大環境里，技術本身占有了很高的優先級，你就會覺得相對來說，其它的事并沒有那么重要。而這其實是一種被動的傲慢，它既體現在你分配閑暇時間的比重上，也體現在你獲取和理解信息的選擇上。
但其實，技術從來不是全部。
想起 DOTA 中的一個梗：『想要最快地熟悉 DOTA 中所有英雄的技能，只需要選擇「影魔」走中就可以了』。影魔本身是個很特別的英雄，如果操作得當，可以在游戲的中前期為隊伍贏來極大的優勢。但同樣由于該英雄名聲在外，但沒有任何逃生能力，所以在大部分情況下，會被當做重點針對對象。
當下里選擇產品經理作為新崗位，可能和依靠選擇『影魔』作為熟悉其它英雄技能的方式有著異曲同工之妙。如果當下里自己最想補齊的短板是視野，那么產品經理這個崗位可能是最佳選擇。
說到視野，我們來聊聊維度吧
維度這個詞可能意義太多，保險起見，我們先加個定義，這里的維度是指某個特定的抽象層級。
之所以提到這個詞，是因為接下來想總結自己對這幾年工作的一些心得，以拆分維度來進行分析是一個挺不錯的方式。
一般來說，當你選定一個維度的時候，就是選定了一類抽象的對象。通過對這個對象的不斷定義，你會得到很多該對象的特征，作為在當前維度解決問題的大前提。而接下來針對當前維度的所有決策，都是基于某個特征下的邏輯推演。不同的前置特征會呈現出多種關系，在互斥的時候，決策就會出現沖突，需要最優解；在有依賴的時候，決策就會出現時序；諸如此類。
抽象層級的產生是人在進行邏輯思考中的必然產物。你不會把蘋果和水果放在同一個層級比較，不會去討論水和火的哪個更重，也不會去討論橙子和維生素 C 哪個更有營養價值，如果你真的討論了，相信我，你想到的維生素 C 是『維 C 片』。
好了，對維度或者說抽象層級的解釋到此為止吧。其實我知道用一堆臆想的概念來解釋另一堆概念是不負責任的，但將所有的概念溯源到某本經典書目上，且我可能還沒讀過，在一篇總結里，我決定偷這個懶。
通過對一個維度進行理解，我們可以得到以下的收獲：
理清維度的內在邏輯鏈：邏輯鏈本身可以為我們帶來決策參考，比如前置條件會變為后續結論的局限。舉個例子吧，儲存形式受制于硬件。如果一份數據儲存在無法進行數據修改的光盤上，就無法進行刪除和修改的操作。如果想實現刪除和修改，就必須換一種儲存介質。
理清不同特征之間的關系：抽象對象的特征往往并非臆想，而是可以溯源到現實時間的固化現象。而這些特征在不經過特別設計的情況下，往往互有關聯。關聯的形式上文有聊過一些，不再贅述。實際上，針對某個維度的工作行為，實質上就是在利用這些固有特征解決問題。所以這些特征的關系往往會決定你實際的工作性質。如果特征是相互沖突的，那工作核心就是在調和沖突，如果特征具有復雜的依賴關系，那工作核心就是調和依賴關系。
理清不同維度之間的關系：相同的特征，在不同的聚合方式下，可以填充不同的維度。而這些特征，就是不同維度間的基本聯系。舉個例子，你想買電腦，這個時候我們要挑選硬件，顯卡可以被當做一個固化特征。在性能維度中，你期望盡可能的好，在外形維度中，你期望盡可能的小，而顯卡的性能和尺寸普遍是成正比的。簡單來說，對顯卡的決策需要同時考慮到兩個維度，求最優解。
上述例子其實也可以解釋為電腦的不同特征影響了決策，這就從維度關系簡化為了特征關系。因為維度是人為選擇的分析工具，所以如何去選擇維度本身并沒有對錯，可以用來分析問題就可以了。
比較復雜的維度關系一般是不同維度內在邏輯鏈的依賴性，比如緩存體系設計中，數據的讀取應當盡可能從緩存數據而非實際儲存數據，其邏輯基點是讀取性能的平衡。但這為寫入數據帶來了負擔，因為寫入一次變為了寫入兩次，只要寫入操作出現時間差，就會出現讀取數據的不一致。在兩條邏輯線中，核心沖突是數據一致性與性能平衡的沖突，簡單來說，想節省主儲存器的性能就要引入次儲存器，而引入次儲存器就會帶來數據不一致，反而引起數據讀取準確性出問題。
這個例子就是典型的不同維度的邏輯線互有依賴而導致的沖突，且無法被單純的解讀為特征依賴，因為特征本身是孤立的。
對于認真閱讀的朋友，我能理解到你的困惑和質疑，所以我額外解釋兩點：
維度是人為選擇用于分析和解決問題的工具，維度的邏輯基點是現實世界中的固化特征。固化特征本身只是信息，但特征間會產生邏輯關系，而邏輯關系可以被推演，從而形成邏輯線。當你找到一條可以用于分析當前問題的邏輯線時，就找到了一個穩定的抽象層級。之所以將它稱為維度，是因為它很類似于多維體系中的建模方式，孤立的點是無法確定一個平面的，但當它和其它的孤立點建立連線之后，線條就可以用來確定平面，乃至更高維度的確定范圍。
用維度作為分析問題的工具，其核心并不是拿到一個固定的維度模型來套用推演，而是根據實際特征，構建出一個符合當前情況的合理維度，而邏輯推演本身是在驗證當前邏輯線的可行性，所以不需要質疑我舉的例子中維度是否合理。
最后，無端地補一句話，實際上，寫代碼就是在表述邏輯。
我在產品經理工作中找到的維度
雖然產品經理和研發人員之間的矛盾是一個讓人津津樂道的話題，但在我來回走了一遭之后，能感覺到，其實產品經理和研發人員的工作在某些程度上具有很高的相似性，或者說，其實產品經理與研發人員的部分維度是共享的。
我試著總結了一些研發人員的經典維度。
數據維度
數據維度的核心抽象對象就是數據。這個維度下的主要前提有兩個：
- 現實世界中的信息只能以數據形式儲存在計算機世界中。
- 已儲存的數據以兩種形式來表示信息：數據本身，數據間的關系。
以儲存作為前提，可以推演出的是對數據的操作方式。
- 比如對已儲存數據的查看、刪除、修改。
- 比如產生新數據的添加、復制、運算。
以承載信息作為前提，可以推演出的則是對數據的應用方式。
- 比如最底層的儲存形式只是二進制數據，如果想讓二進制數據描述某類確切信息，需要一個翻譯機制，所以會有編碼/解碼器存在，從基本數據類型，到文本、圖片、視頻，都是如此。
- 如果想模擬現實中對一組特征加以聚合，來描述一個抽象對象，就會需要格式化的數據，由一個高層級的數據結構來聚合低層級的數據結構。
- 如果希望描述不同抽象對象之間的聯系，就需要利用兩個抽象對象之間的關聯特征，來描述關系化的數據。
系統維度
系統維度的核心抽象對象是模塊。基于模塊化系統設計，核心前提有兩個：
- 復雜的系統，可以被切分為小而獨立的功能模塊。
- 模塊與模塊間的通信方式構成了完整的系統。
其實系統設計是個浩瀚的大工程，類內函數/類/程序框架層級/獨立服務都可以視作獨立模塊。在這個維度下，核心復雜度實際上是設計模塊間通信方式。舉個不太被察覺的例子，我們如何體現系統結構的層級呢？其實是依靠設計好的通信方向與跨層級禁止通信規則。
工程維度
工程維度下的邏輯基點是將程序視作一個可持續化生產的工程，它的抽象對象并不是固化的事務，而是生產方式。一般來說，工程維度實際上是程序設計維度的一個補充，但其重要性與復雜度，已經足以單獨列出進行考慮了。
工程維度的核心目標是保證程序本身具備高效的可維護能力。這是一個典型的目標倒推型維度，它的特征是基于假定目標衍生出來，而非程序出現之初就已經固化的特征。諸如可監控、易調試、容錯策略、易回溯、可量產等等的衍生目標，會倒推出在程序設計之初，就需要額外考量的問題。
資源維度
資源維度其實也是系統設計中的一個補充維度。最常見的資源就是儲存空間與運行時間，除此之外，硬件性能、網絡帶寬、電池電量，也是程序設計中的典型資源。之所以單獨拎出來一個維度，是因為不同資源間往往呈現出競爭關系。比如導航程序在長期調用 GPS 定位硬件的時候，會加劇電量消耗，那么就需要就這兩者之間做平衡。
之所以將其定義為一個補充維度，是因為資源問題只有在觸頂臨界值時，才會出現需要解決的問題。比如同樣是 GPS 調用，一個外賣程序只需要在每次下單時確認你當前的位置，那么就不用在這里考慮電量問題，因為對電量資源的消耗可以忽略不計。
需求維度
雖然這里把產品需求也作為一個維度，但實際工作而言，產品需求本身就是一個決策結論，換句話說，它恰恰是在程序在解決問題過程中的主要邏輯基點之一。
所以在研發角度來聊需求維度，其實是在聊需求維度與其它研發維度的關系。由于需求會作為其它任何一個研發維度解決問題的前提之一，所以在這個維度的核心復雜度就是合理的設計需求與程序設計之間的關系。
所以很遺憾，如果我們把需求與程序設計之間的關系定義為抽象對象，這也是一個典型的目標倒推型維度。它的典型特征和工程化類似，是要自行推演基于需求的衍生特征，然后與其它邏輯線適配。
而這，通常也是產品經理與研發同事之間典型沖突的根源。
(至于產品經理拍腦門說這個功能明天要上線這種，研發柜子里還是放把刀比較方便...)
之所以先聊常見的研發工作維度，是因為實際上，這其中很大一部分也是產品工作的常見維度。不過產品工作與研發工作的工作側重點稍有不同，產品工作更多的是做決策，而研發工作更多的是做實現。所以研發工作的維度是不斷下移的，當程序復雜度上升，分析問題的維度就需要下沉，來解決更細致的問題。而產品工作的維度是上移的，當各個維度的復雜度提升，且無法進行決策的時候，就需要可以將各個維度視作典型特征，由此構成一個上升維度，用于做決策。
舉個簡單的例子，當產品經理給定某個需求的時候，研發需要將需求細化，下沉到各個維度來評估復雜度，然后反饋復雜度。而產品會把需求和實現復雜度同時作為決策依據，由此來決定是否進行實現。
不過也正是這個原因，維度概念對于產品經理來說，要比研發來得更為重要。因為在研發大環境中，是存在經典維度的。同時由于大量的人基于相同的維度來解決問題，所以會逐漸的產生一大批更為具體的問題與解決方案。
當然，以上只是針對應用層的研發工作。目前已知的抽象復雜度最高的研發工作是『編程語言設計』，無論是語言背后的數學與邏輯原理，還是解釋器自舉...總之，很復雜...
而對于產品經理(尤其是我這個新手產品經理)來說，想總結出一個經典維度并非易事。一方面，是因為出于決策目的，分析問題的維度從來是不嫌多的。
另一方面，則是因為在不同的場景下，不同維度的優先級并不相同，所以綜合各個維度產生的頂層決策模型也不得不隨之改變。
我之前有假設過一個思路，如果能夠把需求類型化，是不是也就可以將不同類型需求的對應維度固化。但隨后這個觀點被自己證偽了，因為存在不同的公司階段、人力情況、業務情況、用戶情況，在特定時間下的需求是具有唯一性的。如果強行類型化，一方面類型化需求的參數化特征多到令人發指；另一方面，在已知特定階段的情況下，還將影響類型化需求的特征全部復盤一遍，反而會降低產出。
接下來，我試著總結一些我目前總結到的產品經理常見維度吧。以下維度僅供自用，嗯 = =
研發維度
一般來說，研發維度是產品經理的底層維度，它的主要決策點是實現的可行性與復雜度，除此之外，在特定場景下，還需要考慮維護復雜度以及前向兼容/后向拓展的復雜度。
可行性的核心考量依據是數據和產品邏輯，其中尤其以數據為重。而數據之中，又以數據關系為重中之重。究其原因，是因為如果數據關系與產品邏輯如果無法做到高度契合，產品就會反向受制。比如今天在用一個軟件時，我在沒設置生日的情況下，它提醒我今天生日。我猜測，這是因為它將1月1日作為了生日的初始值。如果我現在作為產品想引導用戶填寫生日，就很難。因為我不知道這里的1月1日究竟是真實的用戶生日，還是默認值。
由于之前有三年的研發經驗，在這個維度上進行決策，對自己來說，確實是一件相對容易的事情，但后續的維度，就不再那么容易了。
業務維度
我在這里對業務維度定義，是指以程序與各個操作角色之間正常流轉作為目標的目標倒推型維度。如果只是程序與用戶之間的關系，那至少角色少，還不算復雜。但當運營同事、客服同事開始參與起來，復雜度也就變高了。尤其不同角色的操作開始出現時序與固化流程的時候，嗯，考驗的時候就來了。當然，還遠不止此，記得研發維度中的工程維度么？實際上，成型化的軟件工程本身還需要運維同事、測試同事與研發同事的介入。簡單來說，業務維度的復雜度實際上就是參與角色之間關系的復雜度。
用戶維度
產品經理是直面用戶的，毋庸置疑。但真正可以影響產品決策的，就很值得商榷了。迄今為止，我還沒有總結出自己覺得完全合理的邏輯線，只是從工作經驗慢慢區分出有些前提是可以證偽的。比如『用戶想要什么』，這個問題用戶其實回答不了，而產品經理也無法據此來得出直接結論。不同的用戶想要的東西可以不同，而用戶也未必真的知道自己想要什么。產品和用戶的關系，并不是在用戶維度來思考的，真正可以在用戶維度思考的問題，只是交互和體驗。也就是當我們已經決定了要如何服務于用戶時，怎樣降低使用門檻，簡化使用方式，諸如此類。
商業維度
產品與用戶的關系，其實是應該在商業維度決策的事情。都說『用戶是上帝』，『用戶要什么我們就給什么』，怎么想也覺得只有上帝才能做到要什么都給吧，矛盾的不行。
從商業維度來看待的產品與用戶關系，實質上就是供求與交易，所以產品需要同時滿足公司利益與用戶訴求。從來不存在產品層面上的偉大，偉大是屬于公司的，產品只是基于公司戰略下的產物而已。
可能是在互聯網行業里被洗腦的太久，其實是淺顯的道理，我卻花了很久才想通。
為什么商業維度對我如此重要。我舉個例子，用戶想要錢，產品可以給他錢么？如果損害公司利益，不可以。但如果以此作為交換，換取更大的利益，可以，比如補貼換取用戶粘性。再比如，我們公司賣好吃的，所有人都想買，但我們就倆廚師。所以核心問題就變成了解決產能問題，和在產能不足的情況下，如何保持用戶關注度的問題。
所以，在我目前的認知里，產品的頂層維度，應該是構建合理的商業模型。對于當下里的我來說，這也就是天花板了。
再聊幾句產品經理
在干工作時不能瞎聊夢想，但夢想還是有的。
在技術不斷發展的未來，一定會需要這樣一類人。他們一邊關注著不斷涌現的科技成果，一邊關注著當下社會中人們的訴求與困惑，然后將那些科技成果詮釋為可以滿足人們生活所需的產品，供人們改變生活。這些人未必是產品經理，不過，我有一點點想做這樣的人。
『站在科技和人文的交叉路口』，我大概是這么理解的。
草草的寫在最后
寫到現在，時間已經是 2018-01-01 23:51:43，我沒想到，這篇從昨晚開始寫起的總結，一寫，就是一天。
而到現在為止，也只是對這幾年的工作感悟，稍稍有個交待。但不敢再開話題了，明天還要上班。
其實我知道整篇行文倉促，文中細節也大多經不起推敲。雖然美其名曰『總結』，但實際上，只不過是把自己未經驗證的想法畫了個圈。
不過如果要問我這幾年工作最大的收獲是什么，那確實就是上面聊的這些東西。
究竟什么是解決問題的能力？不是寫代碼，也不是畫原型，而是如何在實際情況中，合理分析，得出結論，做出決策。
而如何提高解決問題的能力？一方面，是要拓寬自己的視野，能夠對更多的事實有所認知，從而優化決策。而另一方面，則是要總結出好的方法和工具，提高自己分析和解決問題的效率。
對于事實有所認知，僅僅知道定義是不夠的。必須要走進去，知道它的成因，它的發展脈絡，它所遵循的邏輯。當你服務一個人吃飯的時候，你只知道他會吃飯是不夠的，你要知道他什么時候餓，餓了想吃什么，不餓的時候會不會也想吃什么，更要知道這一切都是為什么。
記得在一部電視劇里看到過一句話：『現象并不代表真相，邏輯才是。可人們往往看到了現象，就覺得看到了全部』。
最后的最后
貌似還沒對 2018 做展望，對于一篇年終總結來說，不寫展望感覺就像拉完屎不提褲子一樣，總覺得少了點什么。
我本來想在結尾說，我想找一個看完這篇文章會對我產生興趣的異性進行求偶活動。但寫完之后，我覺得如果我真說了，如果不是我傻逼，那就是我和求偶對象都是傻逼 = =...不過，能看到這的應該都是真愛。是不是異性？再說吧。
聊點正經的，前幾天看《十三邀》中訪問林志玲的一期，其中有幾句話頗為認同，原句忘了，我翻譯下：
一定要保護好自己的感受力和好奇心
慶幸 2017 買了個相機，當你有了相機之后，你就會開始觀察和思考，什么景色是美好，什么值得記錄。借由此，你也真的會感受到美帶來的愉悅。
遺憾 2017 沒有什么額外的出行計劃，打算在 2018 補齊。我對風景不是很感冒，照完了照片總覺得像壁紙一樣。更喜歡在陌生的城市里走街串巷，看人們認真生活的模樣，看時間掠過之后，留下的痕跡和遺忘。
轉了產品經理之后，我借著慢慢學會的多維思考，第一次質疑了一個前提，人生的追求可能并不唯一，幸福也可能不是唯一訴求。
想到這點，起源于我為自己買了一本日歷。每一天都要撕一頁的操作，讓我第一次如此切實地感受到時間是個消耗品。對比之下，無論是多么先進的科技，多么好的屏幕，都無法對時間的流逝做出如此真實的隱喻。那么，如果只追逐效率的我們，是不是錯過了什么？
至少現在，與幸福無關，我不想錯過這種感受。所以我決定，今年的每天早起，我要撕一次日歷。為流逝的時間們，獻上一份祭品。
其它還有什么呢？祈禱漲工資，自我催眠學習進步，立個堅持不了幾天的戒煙或是早睡的 Flag？自己控制不了的事情，就不留在 2018 年底笑話自己了。
不過整個 2017 年，自己對游戲貢獻了太多時間，打了兩個賽季的暗黑，沒完沒了的爐石日常，是該放放了。打算找個代練，保證每個月能拿到爐石的新卡背，然后就刪游戲了。
我還是那個我，認命，但不信命。
對自己從不抱太大期待，但想做更好的自己。
姻緣靠天注定，性生活暫時靠自己。
做工作時要多逼自己，來了什么心情也不用壓抑。
附上一首批命詩：
天空未留痕跡，鳥兒卻已飛過。 —— 泰戈爾
晚安吧 (*^__^*)
某鳥 夜書于 2018年01月02日
