互聯網的產品人員，可能整個職業生涯都要與技術人員打交道。有些產品是技術出身，對于某個領域的技術有一定了解，但是涉及到具體需求可能并沒有開發人員了解深入，問題提不好反而弄巧成拙。而大多數的產品人員，可能都是在工作中慢慢積累，逐漸接觸到一些零散的技術知識，雖不成體系，但遇到類似的問題，尚且可以舉一反三弄懂其原理。但在遇到新的項目或未知的領域時，仍然不知從何下手。

因此，本文的目的是希望從特定的一些方面闡述基本的技術思維，即拿到一個需求或見到某款互聯網產品時，技術人員關注更多的點可能是什么。以此，來讓產品人員一窺開發者的腦回路到底是怎樣設定的，增進日后的相互理解。

所謂技術思維，并不是讓你真的用技術人員的思考方式看待問題。這里所說的技術思維，只是讓你從某種程度上更加縝密地思考與技術相關的問題，如此既可以在技術相關的知識面上有一定積累，也可以在一定程度降低與技術人員的溝通成本。

技術思維之可行性

策劃產品的初期，原則上是不應該受可行性的干擾，先想到好點子，剩下的交給技術解決。但是到了具體的產品需求文檔形成之前，可行性就成為最后一道門檻。是時候找開發哥哥聊聊，到底能不能做。這時候，產品同學最怕的就是開發哥甩過來一句：實現不了。那么到底能做還是不能做，是不是只有開發說了算？當然不是，至少還有老板。

然而，作為一個小產品，總把老板搬出來也不是個事兒，況且，不是每個需求都有老板關注和授權的。那么，在日常無窮無盡的小需求中，如何防止被開發「忽悠」就是最核心的技能了。如果不想被「忽悠」，首先自己要做足功課。自己負責的產品、相關的平臺已有功能、基礎能力等，都要了如指掌，否則如果對于自己的產品細節都不夠了解，怎么去提新需求？

思維提示

• 新開發的系統，盡量熟悉平臺已有的基礎能力，再來看新特性；
• 使用外部開放平臺的，一般都有現成的文檔，雖然未必全懂，但至少大概知道平臺能力；
• 別人已經做好的效果，總不能說實現不了吧？如有差異，至少要給我講清楚；
• 關注不同端的巨大差異，很多實現不了的，其實是終端差異的局限；
• 理解從芯片、硬件廠商、操作系統不同、手機廠商不同、機型不同、瀏覽器不同、語言不同等造成的種種差異。

技術思維之角色分工

評審需求的時候，很多產品最頭疼的，可能就是區分「前端需求」還是「后端需求」了。前端開發和后臺開發有什么區別？到底哪里是前哪里是后？這些改動到底要拉前端還是拉后臺？

這里首先我們要明確一下「前」和「后」是相對于什么來區分的。假設用戶打開瀏覽器，看到了一個網頁，那么用戶第一眼看到的這些，就是所謂的「前端」，即與用戶面對面的前。再說說「后」，這個「后」就是背后你看不到的一切，可以是遠到地球另一側的某臺服務器上運行的代碼，也可以是隱藏在你桌上電腦中的邏輯。

至于中間的地帶，就有點曖昧了。不同的公司對于前后端的定義不盡相同，對于所謂「前后端分離」架構的產品，那么至少頁面層級一定是前端的工作了。而對于某些「服務端渲染」架構的產品，即使是頁面，也可能是后臺同學的工作。

因此，對于自己負責的產品，要先弄清楚基本的架構，才好確定一個大概的界限。目前在互聯網行業，整體的趨勢都是趨于「全?！?，即前端也能做后臺，后臺也能搞前端，那么區分角色分工，就難上加難了。

思維提示

• 熟悉自己負責的產品的基礎架構；
• 頁面結構及樣式相關，往往需要前端參與，最好拉上前端；
• 頁面無法訪問，或者直接輸出錯誤信息，往往要拉上后端或運維同學；
• 實在分不清，只能一起約了。

技術思維之極限情況

產品思維，需要考慮產品的形態、受眾群體、交互流程等等，這些已經很傷腦筋了?？墒堑搅碎_發這里，卻總是各種鉆牛角尖，輸入框輸入 1000 個字怎么辦？同時 10000 個人訪問怎么辦？ 500 個賬號薅羊毛怎么辦？

嚴格意義上來說，這些確實不是產品人員需要考慮的，到了「測試用例評審」這一步，自然會有專業的測試人員提出這些問題。但是假如這些類似的問題你之前都沒有思考過，那么也可能被測試人員批評。想要表現得專業，需要你對研發流程的各個環節都成竹在胸，不至于一問三不知，或者一看就根本沒有深入思考過。

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

思維提示

• 開發哥的鉆牛角尖思維，暴力一點會怎樣；
• 開發哥的薅羊毛思維，量上來會怎樣；
• 并發思維，全都一起來了會怎樣；
• 即使是測試或 QA 的工作，發現問題還是要產品拍板修改，跑不掉的。

技術思維之安全性

每隔幾年，就會出現一次較大的用戶隱私信息泄露問題，最近一次的事件大家都知道，就是 Facebook 的隱私泄露事件，以及國內的 WIFI 萬能鑰匙。還有「開房信息泄露」，是由于被黑客攻擊。

關于黑客攻擊的問題，作為產品人員甚至普通的開發人員，都是沒有辦法應對的，要有極其專業的安全團隊才可能應對。我們這里說的，只是一點安全意識的問題。不要說產品人員，很多工作一兩年的開發人員都非常缺乏安全意識。甚至有些是不經意的人為信息泄露，壓根算不上技術問題。

比如，我們在互聯網產品里標識用戶要有某個特定的維度，可能是用戶的手機號、第三方開放平臺提供的 openid、淘寶登錄名、微信昵稱等等。那么，當我們以這個維度標識用戶，并向他們展示隱私信息的時候，能否確認看到信息的一定是本人呢？有沒有可能我們的維度沒變，但是用戶換了呢？

嚴格來說，除了生物認證和實時的真人認證，我們幾乎無法確定網絡另一端到底是什么人，甚至連是不是人都很難知曉。所以現在的很多互聯網產品，才會有那么多煩人的認證。這個問題盡管無解，并且還要跟真實的用戶體驗之間做權衡，但終歸是不能不考慮的問題。

思維提示

• 弄清楚所負責產品的用戶體系，以及「用戶」的定義；
• 考慮你展示給用戶的信息，有多大可能被別人看到，站在身后看也算；
• 用戶如有多個小號，能否達到 1+1=3 的效果；
• 你的系統有沒有可能被機器人或外掛直接使用，而無法分辨。

技術思維之性能

很多東西，看上去都是技術人員的事情，比如報錯、性能，身為一個產品真的需要考慮這些嗎？這個問題就要靠你自己了，你希望你的產品做到什么程度，是能用就行，還是在任何情況下都能對用戶友好。如果程序上報錯，信息一定是有助于問題定位的方法名、代碼位置等等。那么用戶需要看到這些嗎？用戶看到之后是怎樣的體驗呢？

所以，互聯網產品如果想做到盡量完善，就要考慮到各種情況。當然，你不考慮也可以，那么接下來就是在開發、測試、運維同學不斷地提問和質疑中慢慢填坑。

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

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

思維提示

• 產品的工作沒有界限，多了解點什么知識都沒壞處；
• 互聯網產品都會在某個環節或階段有性能瓶頸，由此可能產生意外的需求特性；
• 從腦子里的一個點子，到最后用戶使用的口碑，產品經理都有責任關注；
• 在很多客觀條件的限制下，沒有所謂的絕對公平，一定是通過某種技術手段來「維持秩序」。

技術思維之隱性消耗

所謂隱性消耗，當然是不那么明顯的消耗。那么對于產品人員來講，哪些消耗不容易察覺呢？最常見的，就是硬件資源和帶寬的消耗，例如某些帶有視頻的活動，如果出現爆發式增長，就可能快速燒掉云服務賬戶里的余額。如果公司有資深的運維人員，那么可以在類似的產品上線之前，找運維同學預估流量和費用，以免不小心超出預算。

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

還有一種情況，作為自己有開發團隊的公司，遇到任何需求第一反應就是自己的開發能不能做，如果不是特別復雜的需求，一般都會得到「能做」的答案。但是有些時候，同樣的能滿足需求的東西，如果采用外包的形式交給外部團隊，成本可能會降低很多。

這是為什么呢？如果說一個需求全是從零開始的話，那么可以說很多公司的開發無論在速度和質量上，都是值得信賴的。但是，當這些需求外部已經有成熟的方案，或者活動模板，甚至是不怎么需要修改的現成代碼的時候，這個成本就完全不一樣了。畢竟術業有專攻，專門做活動的積累了很多活動，專門做游戲的積累了很多小游戲，這些東西對許多外包公司來說甚至是零成本復制。

當然，外部采購也有麻煩的地方，比如公司資質門檻，財務流程等等，肯定是沒有直接給開發哥提需求方便。但如果整個項目的成本和 KPI 都比較明確了，并且考察過有類似的外部團隊可以滿足需求的話，不妨對比一下成本和效率。

思維提示

• 重點項目要考慮技術側可能花錢的地方；
• 開發說「能做」只是說明可行性，效率和時間還要再評估；
• 外部采購成熟方案有時效率更高。

技術思維之關聯改動

我們在規劃新的產品特性的時候，往往會涉及到對原有系統的改動，由于原有系統可能不是自己負責的產品，即使與對應的產品溝通過，也可能考慮不周，而這些，還只是表面的功能改動，更大的坑還在后面。

無論從設計到產品，還是從前端到后臺，都希望有很多所謂「模塊化」的東西，最好像 PS 一樣貼過來就能用。對于完全相同或差異不大的功能，模塊化固然很好。但是在需求迭代的歷史長河中，總會產生同一模塊的大大小小的變種，以及與各個使用模塊的系統之間千絲萬縷的聯系。

此時，如果你的需求動到了這些所謂的「公共模塊」，麻煩就來了。其他使用模塊的系統是否需要一起改動，是否需要同步更新，還是保持原樣？保持原樣的模塊是另一份拷貝還是在原有模塊基礎上兼容？

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

思維提示

• 只要你的需求修改到的地方，在技術側就有可能牽一發而動全身；
• 模塊化未必是好事，只有在保證這些產品模塊功能相對一致時才有用；
• 技術人員也一直在糾結優化與過度優化之間的界線，這個界線完全取決于產品的走向。

技術思維之問題定位

什么？問題定位也要產品參與？那要開發有何用？話雖這樣說，但還是那句話，這是體現產品經理素養的地方。如果你完全不懂，沒人會怪你，但是如果你表現出一些技術上的專業性，大家就會對你刮目相看。

舉個簡單的例子，以前經常會遇到某個同事捉急地截圖過來，說頁面亂了。而我看過之后，往往會直接回復「ctrl+0」。那么，為什么當事人自己看不出問題？甚至中間轉發的幾個人也看不出來呢？

這里有兩個技術點：第一，chrome 瀏覽器 ctrl+滾輪，會縮放頁面，而且放大比例會對當前頁面保存設置，再次打開頁面還是上次放大的比例；第二，不管你截圖的顯示器上看上去是大是小，轉發給我之后實際的像素應該跟我打開的頁面是一樣的，如果頁面沒有被放大的話，你的截圖部分，和我的瀏覽器里對應的部分看起來應該是一樣的。如果大小不一致，說明一定有縮放存在。那么這種簡單的問題定位，就根本不需要去問開發人員。

再結合前面所說的角色分工問題，目前主流公司大都采用前后端分離的架構，所以頁面上出現問題，往往可以先找前端。那么，除了這種粗淺的區分找前端還是后臺，還能不能做點別的呢？當然能。最簡單的，就是先橫向確認一下，你這里有問題，其他人是不是也都有問題。WIFI 有問題的，是不是網線的也有問題。以此類推。

這些基本的判斷也是開發人員的定位思路，先大概確定問題的范圍，你會發現，很多時候問題往往出現在自己這里。開發人員也會犯類似的錯誤，甚至定位了好久才發現，原來是如此低級的一個錯誤。所以，當你能嘗試自己發現低級錯誤的時候，你就擁有了開發人員的腦回路了。

思維提示

• 初步判斷以及精準的問題描述非常有助于定位問題；
• 橫向對比，再看遇到問題之前做了哪些「不尋常的事」；
• 如果確定是共性問題，還是盡快丟給開發吧。

結語

本篇粗略講述了開發人員見到需求或者遇到問題的時候，大致都有哪些「技術思維」，這些思維出于嚴謹，卻又難免有吹毛求疵，鉆牛角尖之嫌。技術說到底，都是冷冰冰的代碼邏輯，沒有什么感情用事和臨時的殺伐決斷。只有把所有細節和可能出現的狀況盡量考慮清楚，才能開發出健壯穩定的系統。

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

歡迎關注作者的微信公眾號：「姬小光」