有哪些普通人覺得很容易實現，但卻讓程序員一籌莫展的技術？

每一個用戶，其實就是一位「產品經理」，用戶在使用產品的時候，只要形成了足夠多的主觀感受（好/壞），並有意願表達出這種意願。那麼，用戶其實就是在承擔「產品經理」的職責。

下面，我就說幾例，產品經理和程序員之間，因為對「簡單」的理解不同，互相傷害的故事吧。

第一種「簡單」：沒有釐清可供對方理解的地方

出現「簡單」一詞，很可能是因為相關技術點沒有釐清。

沒釐清技術點，貿然開工會導致研發過程中溝通頻繁、研發目標難以明確以使交活時有較大幾率陷入扯皮風險、具體研發時間無法估算。

場景一：這個位置，用來擺放用戶頭像，簡單做一下就好。

分析：將需求點轉化為技術點的能力，是產品經理與遊戲系統策劃的基本功。隊友基本功不行，這單需求也未必就沒救，關鍵就看需求點是否明確。

針對需求點明確的情況，如例句，可以用追問的方式細化以挽救。如：

頭像多大，多少乘多少？

——大概400*400吧。

目前定不了是嗎？

——是的。

你剛說400*400，長寬比例固定是1:1嗎？

——我想想……不一定，具體要等界面Demo出來後再看易用性。

大小不寫死，我清楚了。

只在這一個界面用嗎，其他View會有頭像展示嗎？

——可能會。那寫的時候還要照顧下復用性。

看你畫的是矩形，確定是矩形邊框嗎？

——不，是圓角。

圓角弧度多少？

——額，我要再確定下。

頭像上有可能會疊其他東西嗎

比如，加個V？

——會有類似的。我本來是想做到VIP系統再提。

以上片段，摘自產品經理和程序員之間，有關如何設定App里，「頭像」這個組建的討論。

可以看出，即使是一個簡單的頭像，尺寸、形狀、身份表示等等，在技術開發那一端，都會被拆分成不同的需求來實現。

一些新手產品經理，站在和普通用戶幾乎差不多的角度，把許多組建看成一個模塊，「一股腦兒」地要求技術人員幫他實現。這個時候，經驗豐富一些的程序員，就會幫他理清一下思路，把該拆分的需求拆分，這樣不但可以立馬解決「需求→實現」，也可以讓這個新手產品經理有所進步。

不靠譜度：★☆☆☆☆ —— 起碼知道要的是什麼

第二種「簡單」，缺少設計實現

軟體開發是一個非常複雜的行當，制定需求→繪原稿→出設計圖→程序實現是最基本的四個步驟，但普通人，往往會直接忽略前三個步驟，所以每當他們腦洞大開之時，他們就會產生這樣的想法：

「就差一個程序員了！」

舉個簡單的例子吧：

1.（同行介紹來的土豪）你好，我要做個股票分析軟體，我這兒有一套完整的公式，來給各支股評分，你出個手機版的就行，界面就是那種最普通的，重點是功能要齊全。

翻譯：聽說你們會寫代碼？界面也給一塊兒畫了吧。

分析：一般碰到這種「大白」，合計下看夠不夠再雇倆人一塊兒干，一個做UI，另一個負責跟他溝通，明確他的每個需求點。

2. （公司領導）小王，你上個項目做的不錯，年末了，交給你一個小需求，讓你去做吧。就是做個簡單的公眾號應用，接上公司的CRM系統，有重要事項時給相關負責人發個推送就行了……

小王問領導詳情，領導有以下兩種回復：

• 啊，你平時帶著做就行，啥？產品經理？這麼簡單個玩意兒，還用的著產品經理？

  你管我要案子？流程邏輯？界面圖？後台API？沒有沒有，你自己開腦洞去吧！

• 項目做完了，年景不好接不來啥單子，後面倆月沒你事兒了，年底要發獎金了。讓你做這個，是故意刁難你，識相點的，趕緊辭職吧，別耽誤大好前程，公司也得「節流」不是？

不靠譜度：★★★☆☆ ——程序員可不是「萬能」的

第三種「簡單」，蹭人情

「我這個項目很容易實現，兩千夠了吧？」

「這麼簡單的小需求，你報價一個月？」

「不就是把Flash轉成H5，用來在微信里分享的嗎，你要我這麼多！」

沒啥好分析的，直接和他說「拜拜」吧

不靠譜度：★★★★★ —— 「幫個忙嘛，這頓飯我請！」

實際上，並沒有特定的「看起來簡單實際上難以實現」的需求。

只有項目開發者，才有評判具體需求實現難易的權利。即便是同項目組的程序員之間互相提需求，在不清楚對方代碼結構的前提下，也沒有足夠的信息量去評判實現難易度。

內行尚且如此，就更不要提，外行對內行產生的粗淺認識了。

好人難當，程序員難做。

- END -

掃描上方二維碼

或點擊閱讀原文

學IT就選中公優就業

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！