• <blockquote id="ce2qy"><blockquote id="ce2qy"></blockquote></blockquote>
  • <nav id="ce2qy"></nav>
  • <menu id="ce2qy"></menu>
  • 教你8招!不會被程序哥哥追著砍 - 優設網 - UISDC

    教你8招!不會被程序哥哥追著砍

    2019/06/11 10276評論 5

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

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

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

    技術思維之可行性

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

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

    思維提示

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

    技術思維之角色分工

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

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

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

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

    思維提示

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

    技術思維之極限情況

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

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

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

    思維提示

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

    技術思維之安全性

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

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

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

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

    思維提示

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

     

    技術思維之性能

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

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

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

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

    思維提示

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

    技術思維之隱性消耗

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

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

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

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

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

    思維提示

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

    技術思維之關聯改動

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

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

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

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

    思維提示

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

    技術思維之問題定位

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

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

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

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

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

    思維提示

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

    結語

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

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

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

    優設大課堂

    非特殊說明,本文版權歸原作者所有,轉載請注明出處
    本文地址:http://www.010btvly.com/8-technological-thinking

    發表評論 加載中....

    評論加載中....

    uisdc

    評論區都快餓癟了,看看我期盼的小眼神...

    版式設計 交互設計師 界面設計 排版布局 職場 設計師干貨 優設專訪 優設大課堂 設計達人 配色 視覺設計 web前端開發 素材下載 AI教程 設計流程 設計理論 神器下載 字體下載 設計師專訪 psd下載 設計規范 用戶體驗設計 海報設計 設計趨勢 平面設計 動效設計 logo設計 圖標設計 ICON 產品設計 神器推薦 App設計 字體設計 職場規劃 酷站推薦 交互設計 ui設計 優秀網頁設計 設計師職場 ps技巧 酷站 用戶體驗 PS教程 網頁設計 經驗分享

    您還沒有登錄

    優設啟用更安全省心的 微信掃碼登錄

    微信掃碼

    300萬設計師聚集地!優設網是極具人氣的設計師平臺
    2012年成立至今,一直專注于設計師的學習成長交流

    把好文章收藏到微信

    打開微信,掃碼分享
    學設計 優設網 在這里

    703彩票 泸州 | 韶关 | 安阳 | 保定 | 桂林 | 蚌埠 | 贵港 | 海南海口 | 襄阳 | 温州 | 黄石 | 龙岩 | 内江 | 乐清 | 果洛 | 晋中 | 温岭 | 海拉尔 | 六盘水 | 诸城 | 新沂 | 天水 | 舟山 | 北海 | 燕郊 | 朔州 | 南京 | 伊犁 | 齐齐哈尔 | 鹤壁 | 河池 | 桓台 | 嘉峪关 | 图木舒克 | 晋城 | 红河 | 铁岭 | 安顺 | 巢湖 | 澳门澳门 | 铁岭 | 乌海 | 怒江 | 天水 | 揭阳 | 伊犁 | 宜春 | 安庆 | 通辽 | 石河子 | 信阳 | 海西 | 鹰潭 | 随州 | 和田 | 兴化 | 顺德 | 慈溪 | 博罗 | 鸡西 | 台湾台湾 | 五家渠 | 克孜勒苏 | 张家口 | 漯河 | 云浮 | 辽宁沈阳 | 白山 | 广汉 | 吉林 | 铁岭 | 克拉玛依 | 岳阳 | 贺州 | 四平 | 聊城 | 黄石 | 泰州 | 贵港 | 遂宁 | 铜川 | 诸城 | 鄂尔多斯 | 南阳 | 常州 | 遂宁 | 龙岩 | 张北 | 博尔塔拉 | 汉川 | 忻州 | 霍邱 | 青州 | 玉环 | 深圳 | 昌都 | 昭通 | 株洲 | 滕州 | 乌海 | 台湾台湾 | 湖南长沙 | 温岭 | 吉林 | 泗洪 | 玉林 | 梅州 | 齐齐哈尔 | 江门 | 贺州 | 定西 | 德宏 | 三河 |