收藏 | 產品經理不可不知的 7 種技術思惟

咱們常說，做爲技術人員要有產品思惟，從產品和運營的角度去思考技術方案。是的，咱們也這樣作了。然而，從我多年的需求溝通及項目協調的經驗來看，產品人員其實也能夠有一點技術思惟。

所謂技術思惟，並非讓你真的用技術人員的思考方式看待問題，那樣確定作不出好產品，兩種思惟方式是不可調和的。這裏所說的技術思惟，只是讓你從某種程度上更加縝密地思考與技術相關的問題，如此既能夠在技術相關的知識面上有必定積累，也可在必定程度上下降與技術人員的溝通成本。

互聯網的產品人員，可能整個職業生涯都要與技術人員打交道。有些產品是技術出身，對於某個領域的技術有必定了解，可是涉及到具體需求可能並無開發人員瞭解深刻，問題提很差反而弄巧成拙。而對於大多數的產品人員，可能都是在職業生涯的慢慢積累中，逐漸接觸到一些零散的技術知識，雖不成體系，但遇到相似的問題，或可觸類旁通弄懂其原理。但在遇到新的項目或未知的領域時，仍然不知從何下手，徒增的只是盲目的自信而已。

所以，本文的目的便是但願從特定的一些方面闡述基本的技術思惟，即拿到一個需求或見到某款互聯網產品時，技術人員關注得更多的點多是什麼。以此，來讓產品人員一窺開發者的腦回路究竟是怎樣設定的，增進往後的相互理解。此前我寫過一篇《如何洞悉隱性需求》，算是從開發的角度提示一些可能會被產品同窗漏掉的需求細節，在需求溝通方面，能夠做爲本篇的補充。

技術思惟之可行性

策劃產品的初期，原則上是不該該受可行性的干擾，先想到好點子，剩下的交給技術解決。可是到了具體的產品需求文檔造成以前，可行性就成爲最後一道門檻了。是時候找開發哥聊聊，到底能不能作了！這時候，產品同窗最怕的就是開發哥甩過來一句：實現不了… 那麼到底能作仍是不能作，是否是就只有開發說了算呢？固然不是！至少還有老闆~

然而，做爲一個小產品，總把老闆搬出來也不是個事兒，何況，不是每一個需求都有老闆關注和受權，狐假虎威確定是要出事情的。那麼，在平常無窮無盡的小需求中，如何防止被開發『忽悠』就是最核心的技能了。若是不想被『忽悠』，首先本身要作足功課。本身負責的產品、相關的平臺已有功能、基礎能力等，都要了如指掌，不然若是對於本身的產品細節都不夠了解，怎麼去提新需求？

思惟提示

1. 新開發的系統，儘可能熟悉平臺已有的基礎能力，再來看新特性；

2. 使用外部開放平臺的，通常都有現成的文檔，雖然未必全懂，但至少大概知道平臺能力；

3. 別人家已經作好的效果，總不能說實現不了吧？若有差別，至少要給我講清楚；

4. 關注不一樣端的巨大差別，不少實現不了的，實際上是終端差別的侷限；

5. 理解從芯片、硬件廠商、操做系統不一樣、手機廠商不一樣、機型不一樣、瀏覽器不一樣、語言不一樣等形成的種種差別~

技術思惟之角色分工

評審需求的時候，不少產品最頭疼的，可能就是區分『前端需求』仍是『後端需求』了。前端開發和後臺開發有什麼區別？到底哪裏是前哪裏是後？這些改動到底要拉前端仍是拉後臺？

這裏首先咱們要明確一下『前』和『後』是相對於什麼的。假設用戶打開瀏覽器，看到了一個網頁，那麼用戶第一眼看到的這些，就是所謂的『前端』，即與用戶面對面的前。再說說『後』，這個『後』就是背後你看不到的一切的一切，能夠遠到地球另外一側的某臺服務器上運行的代碼，也能夠是隱藏在你桌上電腦中的邏輯。

至於中間的地帶，就有點曖昧了。不一樣的公司對於先後端的定義不盡相同，對於所謂『先後端分離』架構的產品，那麼至少頁面層級必定是前端的工做了。而對於某些『服務端渲染』架構的產品，即便是頁面，也多是後臺同窗的鍋。

所以，對於本身負責的產品，要先弄清楚基本的架構，纔好肯定一個大概的界限。目前在互聯網行業，總體的趨勢都是趨於『全棧』，即前端也能作後臺，後臺也能搞前端，那麼區分角色分工，就難上加難了。

思惟提示

1. 熟悉本身負責的產品的基礎架構；

2. 頁面結構及樣式相關，每每須要前端參與，最好拉上前端；

3. 頁面沒法訪問，或者直接輸出錯誤信息，每每要拉上後端或運維同窗；

4. 實在分不清，只能一塊兒約了~

技術思惟之極限狀況

產品思惟，須要考慮產品的形態、受衆羣體、交互流程等等，這些已經很傷腦筋了。但是到了開發這裏，卻老是各類鑽牛角尖，什麼小破輸入框輸入 1000 個字怎麼辦？什麼同時 10000 我的訪問怎麼辦？什麼 500 個帳號薅羊毛怎麼辦？

嚴格意義上來講，這些確實不是產品人員須要考慮的，到了『測試用例評審』這一步，天然會有專業的測試人員提出這些問題。可是假如這些相似的問題你以前都沒有思考過，那麼也可能被測試人員懟得很慘。要想表現爲專業的產品經理，須要你對研發流程的各個環節都胸有成竹，不至於一問三不知，或者一看就根本沒有深刻思考過。

這些極限狀況也能夠稱之爲『異常流』，有些異常流可能用戶感知不明顯，而有些異常流則會對用戶形成很大的影響。所以，當出現這些異常的時候，如何給用戶更好的提示和引導，或者引領用戶去找客服尋求幫助等，就顯得尤其重要了。

本文來自公衆號【姬小光】，已受權轉載。

思惟提示

1. 開發哥的鑽牛角尖思惟，暴力一點會怎樣；

2. 開發哥的薅羊毛思惟，量上來會怎樣；

3. 併發思惟，全都一塊兒來了會怎樣；

4. 即便是測試或QA的工做，發現問題仍是要產品拍板修改，跑不掉的~

技術思惟之安全性

每隔幾年，就會出現一次較大的用戶隱私信息泄露問題，最近的一次你們都知道，就是 Facebook 的隱私泄露事件，以及國內的 WIFI 萬能鑰匙。至於以前的門系列，雖然也是用戶隱私，可是跟互聯網關係不大，主要是修電腦的鍋。還有『開房信息泄露』那次，是因爲被黑客攻擊。

關於黑客攻擊的問題，做爲產品人員甚至普通的開發人員，都是沒有辦法的事情，要有極其專業的安全團隊纔可能應付。咱們這裏說的，只是一點安全意識的問題。不要說產品人員，不少工做一兩年的開發人員都很是缺少安全意識。甚至有些是不經意的人爲信息泄露，壓根算不上技術問題。

好比，咱們在互聯網產品裏標識用戶要有某個特定的維度，多是用戶的手機號、第三方開放平臺提供的 openid、淘寶登陸名、微信暱稱等等。那麼，當咱們以這個維度標識用戶，並向他們展現隱私信息的時候，可否確認看到信息的必定是本人呢？有沒有可能咱們的維度沒變，可是用戶換了呢？

嚴格來講，除了生物認證和實時的真人認證，咱們幾乎沒法肯定網絡另外一端究竟是什麼人，甚至連是否是人都很難知曉。因此如今的不少互聯網產品，纔會有那麼多煩人的認證。這個問題儘管無解，而且還要跟真實的用戶體驗之間作權衡，但總歸是不能不考慮的方面。

思惟提示

1. 弄清楚所負責產品的用戶體系，以及『用戶』的定義；

2. 考慮你展現給用戶的信息，有多大可能被別人看到，站在身後看也算；

3. 用戶若有多個小號，可否達到 1+1=3 的效果；

4. 你的系統有沒有可能被機器人或外掛直接使用，而沒法分辨~

技術思惟之性能

不少東西，看上去都是技術人員的事情，好比報錯、好比性能，身爲一個產品真的須要考慮這些嗎？這個問題就要靠你本身了，你但願你的產品作到什麼程度，是能用就行，仍是在任何狀況下都能對用戶友好。若是程序上報錯，信息必定是有助於問題定位的方法名、代碼位置等等。那麼用戶須要看到這些嗎？用戶看到以後是怎樣的體驗呢？

因此，互聯網產品若是想作到儘可能完善，就要考慮到各類狀況。固然，你不考慮也能夠，那麼接下來就是在開發、測試、運維同窗不斷的提問和質疑中慢慢填坑。

以電商的搶購活動爲例，最理想的狀況下，是系統有無限的承受能力，你們隨便搶，系統也不會掛。但現實的狀況是，硬件資源、網絡帶寬等都是有限的，即便我能夠預估真實用戶的量，也沒法預估羊毛黨的量。某個活動一旦有利可圖，被轉發到幾個羊毛羣，那基本上分分鐘就要被掏空了。

那麼在這樣的現實下，如何能保證對大多數用戶來講儘可能公平，系統又不至於很快掛掉呢？這就是產品和技術要一塊兒解決的問題了。譬如不少搶購活動引入的排隊機制，或者提早發放的資格碼等。這些需求某種程度上都是因爲客觀條件的限制，才引入的產品特性，從而倒逼產品人員修改流程和界面交互等。那麼在你負責的產品中，有沒有由於性能或其它的限制而產生的『特性』呢？

思惟提示

1. 產品的工做沒有界限，多瞭解點什麼知識都沒壞處；

2. 互聯網產品都會在某個環節或階段有性能瓶頸，由此可能產生意外的需求特性；

3. 從腦子裏的一個點子，到最後用戶使用的口碑，產品經理都有責任關注；

4. 在不少客觀條件的限制下，沒有所謂的絕對公平，必定是經過某種技術手段來『維持秩序』~

技術思惟之隱性消耗

所謂隱性消耗，固然是不那麼明顯的消耗。那麼對於產品人員來說，哪些消耗不容易察覺呢？最多見的，就是硬件資源和帶寬的消耗，例如某些帶有視頻的活動，若是出現爆發式增加，就可能快速燒掉雲服務帳戶裏的餘額。若是公司有資深的運維人員，那麼能夠在相似的產品上線以前，找運維同窗預估流量和費用，以避免不當心超出預算。

一樣，有些公司購買的帶寬是峯值計費的，那麼就很容易出現意外。服務器臨時扛不住，緊急加機器也是能夠的，最壞的狀況就是有短暫的時間沒法給用戶提供服務。其實通常狀況下，產品人員是不太須要考慮這些的，有技術和 IT 人員搞定就能夠了。只是特殊的一些產品和活動，才須要把這些預算考慮在內。

還有一種狀況，做爲本身有開發團隊的公司，遇到任何需求第一反應就是本身的開發能不能作，若是不是特別複雜的需求，通常都會獲得『能作』的答案。可是有些時候，一樣的能知足需求的東西，若是採用外包的形式交給外部團隊，成本卻可能下降不少。

這是爲何呢？難道咱們的開發就這麼挫嗎？固然不是！若是說一個需求全是從零開始的話，那麼能夠說不少公司的開發不管在速度和質量上，都是值得信賴的。可是，當這些需求外部已經有成熟的方案，或者活動模板，甚至是不怎麼須要修改的現成代碼的時候，這個成本就徹底不同了。畢竟術業有專攻，專門作活動的積累了不少活動；專門作遊戲的積累了不少小遊戲；這些東西對許多外包公司來講甚至是零成本複製，就看他想賺你多少錢了~

固然，外部採購也有麻煩的地方，好比公司資質門檻，財務流程等等，確定是沒有直接給開發哥提需求方便。但若是整個項目的成本和 KPI 都比較明確了，而且考察過有相似的外部團隊能夠知足需求的話，不妨對比一下成本和效率，開發哥的工資也很貴的~

思惟提示

1. 重點項目要考慮技術側可能花錢的地方；

2. 開發說『能作』只是說明可行性，效率和時間還要再評估；

3. 外部採購成熟方案有時效率更高~

技術思惟之關聯改動

咱們在規劃新的產品特性的時候，每每會涉及到對原有系統的改動，因爲原有系統可能不是本身負責的產品，即便與對應的產品溝經過，也可能考慮不周，而這些，還只是表面的功能改動，更大的坑還在後面。

不管從設計到產品，仍是從前端到後臺，都但願有不少所謂『模塊化』的東西，最好像 PS 同樣貼過來就能用。對於徹底相同或差別不大的功能，模塊化當然很好。可是在需求迭代的歷史長河中，總會產生同一模塊的大大小小的變種，以及與各個使用模塊的系統之間千絲萬縷的聯繫。

此時，若是你的需求動到了這些所謂的『公共模塊』，麻煩就來了。其餘使用模塊的系統是否須要一塊兒改動，是否須要同步更新，仍是保持原樣？保持原樣的模塊是另外一份拷貝仍是在原有模塊基礎上兼容？

在技術的架構上，咱們很難既知足想要一塊兒改的時候就徹底一塊兒變化，而不想要一塊兒修改的時候，又能夠隨便想改哪一個改哪一個。這兩個點之間只能是不斷地權衡和妥協，沒有完美的解決方案。所以，在咱們尋求公共邏輯和修改迭代的便利性的同時，也須要考慮到將來分道揚鑣時千絲萬縷的糾纏。

思惟提示

1. 只要你的需求修改到的地方，在技術側就有可能牽一髮而動全身；

2. 模塊化未必是好事，只有在保證這些產品模塊功能相對一致時纔有用；

3. 技術人員也一直在糾結優化與過分優化之間的界線，這個界線徹底取決於產品的走向~

技術思惟之問題定位

什麼？問題定位也要產品參與？那要開發有何用？！話雖這樣說，但仍是那句話，這是體現產品經理素養的地方。若是你徹底不懂，沒人會怪你，可是若是你表現出一些技術上的專業性，你們就會對你另眼相看。

舉個簡單的例子，之前常常會遇到某個同事捉急地截圖過來，說頁面亂了。而我看過以後，每每會直接回復『ctrl+0』。那麼，爲何當事人本身看不出問題？甚至中間轉發的幾我的也看不出來呢？

這裏有兩個技術點：第一，chrome 瀏覽器 ctrl+滾輪 會縮放頁面，並且放大比例會對當前頁面保存設置，再次打開頁面仍是上次放大的比例；第二，無論你的截圖你的顯示器上看上去是大是小，轉發給我以後實際的像素應該跟我打開的頁面是同樣的，若是頁面沒有被放大的話，你的截圖部分，和個人瀏覽器裏對應的部分看起來應該是同樣的。若是大小不一致，說明必定有縮放存在。那麼這種簡單的問題定位，就根本不須要去問開發人員，可是你能夠問：爲毛縮放了就會亂掉呢？

再結合前面所說的角色分工問題，目前主流公司大都採用先後端分離的架構，因此頁面上出現問題，每每能夠先找前端。那麼，除了這種粗淺的區分找前端仍是後臺，還能不能作點別的呢？固然能。最簡單的，就是先橫向確認一下，你這裏有問題，其餘人是否是也都有問題。WIFI 有問題的，是否是網線的也有問題。以此類推。

這些基本的判斷也是開發人員的定位思路，先大概肯定問題的範圍，你會發現，不少時候問題每每出如今本身這裏。開發人員也會犯相似的錯誤，甚至定位了很久才發現，原來是如此低級的一個錯誤。因此，當你能嘗試本身發現低級錯誤的時候，你就進入了開發人員的腦回路了。

思惟提示

1. 初步判斷以及精準的問題描述很是有助於定位問題；

2. 橫向對比，再看遇到問題以前作了哪些『不尋常的事』；

3. 若是肯定是共性問題，仍是儘快丟給開發吧~

結 語

本篇粗略講述了開發人員見到需求或者遇到問題的時候，大體都有哪些『技術思惟』，這些思惟出於嚴謹，卻又不免有吹毛求疵，鑽牛角尖之嫌。技術說到底，都是冷冰冰的代碼邏輯，沒有什麼感情用事和臨時的殺伐決斷。只有把全部細節和可能出現的情況儘可能考慮清楚，才能開發出健壯穩定的系統。

一樣，做爲產品經理，你的產品能健壯穩定地給用戶提供服務，也是產品成功的表現。既然如此，這方方面面的技術問題，則不可不察。因此說，優秀的產品經理，就是要對各個角色的分工瞭如指掌，熟悉每一個角色的性格脾氣和思惟方式，才能撮合各個角色無障礙地分工協做，從而產出出色的互聯網產品。瞭解技術人員的思惟方式，或許是個良好的開端。

本文來自公衆號【姬小光】，已受權轉載。