產品經理不可不知的7種技術思維

產品老司機手把手教寫文檔,10天線上課程,零基礎掌握產品經理必備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. 如果確定是共性問題,還是盡快丟給開發吧。

結語

本篇粗略講述了開發人員見到需求或者遇到問題的時候,大致都有哪些『技術思維』,這些思維出于嚴謹,卻又難免有吹毛求疵,鉆牛角尖之嫌。

技術說到底,都是冷冰冰的代碼邏輯,沒有什么感情用事和臨時的殺伐決斷。只有把所有細節和可能出現的狀況盡量考慮清楚,才能開發出健壯穩定的系統。

同樣,作為產品經理,你的產品能健壯穩定地給用戶提供服務,也是產品成功的表現。

既然如此,這方方面面的技術問題,則不可不察。所以說,優秀的產品經理,就是要對各個角色的分工了如指掌,熟悉每個角色的性格脾氣和思維方式,才能撮合各個角色無障礙地分工協作,從而產出出色的互聯網產品。了解技術人員的思維方式,或許是個良好的開端。

 

作者:姬小光,微信公眾號“姬小光(ID:hi-laser)”

本文由 @姬小光 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 不是很喜歡這種文風,作者的知識背景有限

    回復
    1. 通篇下來,感覺這是一個剛入行的女產品才會需要知道的東西 :roll:

      回復
  2. 學到了

    回復
  3. 產品經理的統籌思維法,非常有見地??

    回復
  4. 輕輕走過

    回復
  5. 《如何洞悉隱性需求》在哪里看?

    回復
  6. 碼農路過(?????)

    回復
  7. 不懂技術的小白路過留名

    回復
  8. lzfrosyvpuc在親情中/danfcfutr開著
    kxgk去發展發展快

    回復
彩票开奖接口怎么接