教育改變生活 嶽麓成就夢想

全國報名咨詢電話:0731-85572692
來自産品經理的技術建議

2018-09-20

 
 
1. 不要試圖去教程序員如何寫程序就像産品不可能願意接受技術教他一個産品該如何設計一樣,程序員也(更)不願意别人批評他程序寫的不對,甚至自己的同行說這個話都得撩開了鍵盤敲一仗。至于實習生或剛加入的新人,那有技術經理罩着,還輪不到産品出馬。如果發生這樣的事,這不是在把一個項目往好的方向帶,隻會更糟糕,到不可調和的境地。這種情況有沒有,從我的經曆來看還是很多的。大約兩年前我接手過一個項目的管理工作,整個團隊一盤散沙,5個技術杠着3個産品;技術經理也是半路接手,對外壓力重重對内無法服衆。我記得當時首當其沖的一個需求是對已經存在的數據做一個搜索過濾的功能,操作上類似 LinkedIn,長得就像這樣:上面是搜索框,左側是更細緻的分類篩選。當時已經上了一個關鍵詞搜索引擎了,但是左側的篩選功能産品始終不滿意,特别是一個細節在用到了各種什麼異步請求、分塊查詢,最終實現還是不太好,不是左側卡頓、丢項、合計不一緻就是左右數量不一緻。從第一個圖到第二個圖,勾選了英國後,地區的所有統計量都沒變,而除地區外的條件切換了;如果我再勾選目前就職,則就職闆塊所有選項和數量(包括沒勾選的)都不會變,而地區除已勾選的外根據條件改變……産品特地寫了一個很長的文檔來描述這個動作應當如何變化如何查詢,沒錯,他真的寫了一個不太嚴謹的僞代碼,顯然他是懂一些程序判斷邏輯和 SQL 的。大緻上是:按關鍵詞查詢到結果選擇 A 分類的選項後篩選結果,A 分類不再根據結果重新計算,A 分類外的需要根據結果重新計算選擇 B 分類的選項後需要記住 A 分類的數量,然後 B 不再重新計算,計算 A 分類已選之外的選項……請原諒我沒辦法回憶清楚那份邏輯,太晦澀太難懂了,要記錄和判斷各種條件,沒等看完就扔了。在我看來,HTTP 的無狀态特性是不太适合這種需要記錄各個環節的需求的,既然已經有人實現了,那我可以認為一定存在函數 fn1 和 fn2 給定相同條件 x 時能返回我要的 分類統計 和 查詢結果,我現在隻要實現這個黑盒就能解決這個問題。分析結果是确實我不需要存放已經計算過的 A 分類、B 分類的結果(排除需要優化運算量的情況),也不用管什麼先點後點的順序,我隻需要給出已經選擇的選項值即可,以這個條件我就能得到左側的分類和統計以及右側的結果,而整個過程我不需要用到 Session,Cookie 等任何暫存狀态的東西。如果你先點 A 再點 B 然後 A、B 已選的條件的統計數量不能改變,這根本就是個現象而不是條件;這個查詢對應的 URL 在另一個新開的不同的浏覽器同一用戶打開看到結果和統計值應當一緻,産品需要這樣的 URL 來做信息分類推廣,這個需求同樣隻是個現象而已。可以通過現象來檢驗程序,但不要用現象來約束程序。事實上,隻要在計算數量時排除此分類對應的條件就 OK 了,根本沒什麼點擊順序,我敢打保票效果一緻,就這麼簡單。你說這效率是不是不高,那把左側計算和查詢分開請求好啦,還不夠就再來點緩存啦;但緩存不應當是一個優先考慮的措施,如果把一個程序看作一個洋蔥,應當先把裡面那個芯弄活了,至于外面的皮(緩存、過濾)多一層少一層能決定它将來活得好不好,不應當決定它此刻的生死。其實類似這樣的搜索篩選邏輯現在到處都是,你可以去 LinkedIn 也可以去京東、淘寶嘗試。至于我給我們公司寫的程序,那沒法公開也沒必要,這裡我寫了個類似功能的代碼: SearchHelper,雖是單機也能撐起還湊合的數量,感興趣的可以看看提提意見。
2. 什麼樣的文檔是恰到好處的文檔文檔是産品與其他部門交流的重要工具。以前在魔都某公司,拼盡力氣抗下一個項目,初期隻有我和産品兩人。每次去見客戶都由他牽頭,會議紀要卻都是客戶發,回到公司商量細節,他也從來不記錄,我隻好每次在白闆上盡量畫清楚然後拿手機拍照然後發封郵件請他确認。這個經曆實在很糟糕,最後這個項目也成了我的滑鐵盧;當然了,錯不能全推給人家,我當時也自認為自己夠牛B、能做到原型即産品一步到位快速開發。産品主要的文檔有 BRD、MRD、PRD、原型,前兩者一般不用給技術看,但也不能什麼都掖着藏着,那是心虛的表現。一個老練的程序員最怕(不喜歡)什麼呢?就是你跟他說:“你别管了,老闆(客戶)就要這樣”。還有些産品沉迷于原型、仿真(這裡不讨論 UI、UX 等分工),畫得很精細,但不外乎還是在傳達一個命令:“照我的來做别問為什麼”。其實到我這個年紀還真懶得問“為什麼”了,老油條了嘛,但你要想你的産品夠健壯,想最大限度的挖掘開發人員的能力,很有必要講明白這個“為什麼”。
3. 我女兒很愛玩類似的遊戲,在一堆圖案裡找相同的或不同的。晚飯時我妻子還問我産品經理跟程序員有什麼區别?我想想指了桌子上兩個水壺,一個大的我女兒的,一個小的是她的。産品看到是兩個水壺,一個粉色的,上面有卡通圖案,有杯蓋,裡面有内膽;一個紅色的,彈簧蓋,裡面有内膽。而程序員看到的是:你會說這也太小瞧産品了吧,這個誰不會畫。是的,誰都會如此分析,但是根本的地方在于産品感受不到痛。産品會在一個項目啟動時畫,會在新需求來時畫,畫很多很多這樣的樹叉子,卻很少想或感受不到背後的代價,如果再來第三個給我這大老爺們用的杯子時,要如何并入這棵樹。假設,這回來了一個爆發戶,他要一個 L 形狀的杯子,錢多人嘛傻不傻不知道。尼瑪這讓人咋搞,老子模具一直都是造圓筒形;産品說那還不簡單拿兩個圓筒焊到一起不就得了;我靠,我這可是全自動化封閉式車間;産品說那你就在末端人工處理一下嘛别跟錢過不去嘛;操,那我外殼、噴漆、包裝咋辦……我不懂制造業上面的類比可能不太恰當。很多時候情況就像這樣,曾經拍胸脯說“不會變了、你寫死吧”,到某天變起來牽一發動全身。
4. 程序 or 數據庫那看來是不是産品就必須深入前線體察一下軍情呢?我的回答是沒必要且不需要。如果你真的想了解點技術,從程序入手不如從數據庫入手(此觀點限于信息系統或類信息系統)。了解一點數據庫結構、ERM 知識對産品的底層認知會更徹底,因為在信息系統中,所有的程序都是圍繞着數據的增删改查來展開的,HTTP 的 REST 規範也是将衆多我們看到各種五花八門的動作規範為資源的 4 類狀态轉換。包括程序員,如果你隻糾結于程序邏輯,很可能會“不識廬山真面目”,“隻緣身在此山中”。樹總歸還是那棵樹,隻是多了、少了些葉子而已。很多所謂複雜的邏輯不外乎幾個 CRUD 互相調用罷了,比如:保存完新聞要聯動索引并給運營發條審核消息,獲取新聞内容同時要附帶作者信息和統計信息以及熱門評論;有的可能查詢套查詢,有的可能要遠程調用其他接口。但是其背後,為什麼可以這樣調用、關聯,都是 ERM 上描述好了的,一對一、一對多、多對多 這些關系就在那裡,它是靜态的,與外面能看到的東西是相映射的。我沒有書可以推薦,因為我也沒有買過,而這個經驗就是一位産品經理曾經教給我的,在那之前我了解 ERM、UML,但從來沒有重視過。
5. 與敏捷共舞有人說程序員跟妓女一樣,吃的是青春飯,30 歲以後要想辦法轉管理。呵呵,這行當是辛苦了點,什麼熱門什麼就更新快,就像現在的前端技術進展得我這個10多年前就從創意到數據通吃的老家夥(别捅、讓我慢慢裝個 B)都看不懂了。我覺得程序員就要像特種兵(某些服務程序員的程序員除外,他們是後勤保障,也可能是火箭軍),必須邁開腿,從海底爬過去、從飛機跳下去,到前線去才能打勝仗;留在首長身邊當個卷簾大将撐門面?看我們也有研發部也是科技公司耶——呸、無聊。好吧,别跑題了,說回來。産品經理好歹有個 Manager 的頭銜,雖然很多産品經理自嘲自己就是個光杆司令,我們來講點經理該幹的活。上面扯了那麼多“術”的層面,可融合的“道”在哪呢?項目總是延期、技術叫苦不疊,本該是融洽的上下遊(注意了不是上下級)關系,我們的好政委,咋就能鬧翻呢?救贖之道在“敏捷”,來,大聲朗讀:個體和交互 勝過 過程和工具;可以工作的軟件 勝過 面面俱到的文檔;客戶合作 勝過 合同談判;響應變化 勝過 遵循計劃;雖然右項也有價值,但是我們認為左項具有更大的價值。千萬、千萬别把第五句給漏了,這很重要、這很重要、這很重要。不要一開始敏捷了,就再不寫文檔、不做紀要、不記錄 QA 了,搞一塊白闆鬼畫符頂多拍個照就完事了。這個意思是說,兩邊都很重要,如果做得到當然也要做到右邊的,隻是我們認為(來不及了)可以适當的放棄右邊的一部分,更看重結果而不拘泥于形式;但顯然你得視項目大小、時間跨度來考量,哪些右邊的措施是必須的,保障項目長期正常運轉的。需要注意,上面說希望程序員像特種兵一樣主動出擊,但從團體來講,表現更像海盜,精力旺盛而又神經脆弱,要有活幹,有新活幹,有挑戰性的活幹,留夠 10%~20% 的連續的自由時間、思考空間,這也許會給您的公司帶來意想不到的效果。“敏捷”也不是靈丹妙藥,我甚至感覺這有點像宗教,光一個小圈子沒有外在配合(擴張)是玩不轉的。
6. 再來扯個蛋《舊約》裡有個“巴别塔”的故事都聽過吧,講的是起初人類都講一樣的語言所以合作很順暢,可以構建能通天的巴别塔好去找神聊聊,神怒了神馬玩意還吵吵嚷嚷的還讓不讓好好睡覺了,如是把人類拔散了趕到各地,讓人們說不同的語言用不同的文字,從此世界吵歸吵但吵不到他老人家了。這個故事放在這裡有相通的道理,“人心齊、泰山移”。往大了說産品要跟研發一條心,要和諧不要分裂;往小了說,沒有名詞解釋、組件設計的産品文檔都是耍流氓。你都沒定義好關鍵詞,開個會雞同鴨講扯又扯不清楚;或是沒有個組件定義,講什麼都要來一大段,不能把信息壓縮,傳來傳去變了味。當然我作為一個曾經轉産品沒轉成功的碼農,呵呵,此文章寫得立場不明,雙方都不要罵我好吧。--------剛想起點再補充下,我這人鍵盤唠。上面說到不要随便“教”人寫程序,即使你就是程序員也不要這麼幹,對方不提出需要幫助不要去幫助,而那些解決不了問題還不呼叫支援的隻會發愣的程序員讓他自生自滅好了。所以我不會主動去“教”我們的前端程序員如何做,他做得很棒讓我眼前一亮,瞎指揮什麼呢;同樣我不會去指揮我們的 App 開發,盡管 Java 我會 C 也沒忘幹淨,但那畢竟不是我的領域,不要去裝什麼大尾巴狼,正确的目标會指引着一切正确的運轉。當然了,我不發号施令也不會偷閑躲靜,不會停止寫程序和實踐新技術。讓人們能走到一起的是道,不是術。
“革命隻有分工不同,沒有高低貴賤之分”。産品經理有産品經理該幹得活,程序員有程序員該幹的活,不存在誰踹了誰飯碗的問題,實際情況中可能存在出了偏差領導光罵産品不罵技術的,一是因為産品經理蹲在上遊,離得近;二是很多老闆不是技術出身,怎麼聊?
有些軟手段可能在某些環境下也不太玩得轉,但總要有些東西要堅持的。
文章來源于網絡

(2)