摘要：互聯網的產品人員，可能整個職業生涯都要與技術人員打交道。還有開房信息泄露那次，是由于被黑客攻擊。關于黑客攻擊的問題，作為產品人員甚至普通的開發人員，都是沒有辦法的事情，要有極其專業的安全團隊才可能應付。

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

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

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

因此，本文的目的即是希望從特定的一些方面闡述基本的技術思維，即拿到一個需求或見到某款互聯網產品時，技術人員關注得更多的點可能是什么。以此，來讓產品人員一窺開發者的腦回路到底是怎樣設定的，增進日后的相互理解。此前我寫過一篇《如何洞悉隱性需求》，算是從開發的角度提示一些可能會被產品同學漏掉的需求細節，在需求溝通方面，可以作為本篇的補充。

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

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

新開發的系統，盡量熟悉平臺已有的基礎能力，再來看新特性；

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

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

關注不同端的巨大差異，很多實現不了的，其實是終端差異的局限；

理解從芯片、硬件廠商、操作系統不同、手機廠商不同、機型不同、瀏覽器不同、語言不同等造成的種種差異~

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

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

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

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

熟悉自己負責的產品的基礎架構；

頁面結構及樣式相關，往往需要前端參與，最好拉上前端；

頁面無法訪問，或者直接輸出錯誤信息，往往要拉上后端或運維同學；

實在分不清，只能一起約了~

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

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

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

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

開發哥的鉆牛角尖思維，暴力一點會怎樣；

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

并發思維，全都一起來了會怎樣；

即使是測試或QA的工作，發現問題還是要產品拍板修改，跑不掉的~

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

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

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

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

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

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

用戶如有多個小號，能否達到 1+1=3 的效果；

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

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

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

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

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

產品的工作沒有界限，多了解點什么知識都沒壞處；

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

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

在很多客觀條件的限制下，沒有所謂的絕對公平，一定是通過某種技術手段來『維持秩序』~

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

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

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

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

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

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

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

外部采購成熟方案有時效率更高~

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

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

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

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

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

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

技術人員也一直在糾結優化與過度優化之間的界線，這個界線完全取決于產品的走向~

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

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

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

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

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

初步判斷以及精準的問題描述非常有助于定位問題；

橫向對比，再看遇到問題之前做了哪些『不尋常的事』；

如果確定是共性問題，還是盡快丟給開發吧~

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

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

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