寫給程式員

最近背景文章的留言中，發現了一些很早就關注了我的讀者，大部分都是 2013 年前後關注的。

特别感謝你們的長期陪伴，一起見證彼此成長的感覺很好。

可能有的讀者不知道，隻要留言或者贊賞，我都能在背景看到你們具體是哪天關注我的，以及你們留過幾次言、有過幾次贊賞。

而且按照微信公衆号的産品邏輯，取關後重新關注，關注時間就是按照最後一次關注的時間算起。

是以，如果不是實在受不了我，那還是别取關了。說不定哪天我給關注三年以上的老讀者發個大福利啥的呢。

當然，如果你依然還是受不了我，那也隻能江湖再見了。

怎麼樣，是不是很土？

沒辦法，當年是直男程式員，想不出啥文藝名兒。

後來轉型做産品就沒寫技術文章了，是以想改個名，思來想去不知道改啥，是以就把自己的名字放上去了。

好在，我的名字比較清奇，不是很常見。

噢，對了，還有頭像。

哪天心情好的時候，我把過去公衆号帥氣的頭像都拿出來讓你們笑話一下。

最初關注我的讀者基本都是程式員，而且大部分都是做 android 和 ios 開發的。

今天特别想跟這些依然在關注我的老讀者聊一聊，聊什麼主題呢？

想了下，覺得可以以一個産品過來人的身份，跟你們聊聊如何避免被産品經理坑。

做技術的都是兄弟，以前我也是個苦逼碼農，也做過那些無腦需求，同樣被産品經理的神邏輯折磨過。

最讨厭的，就是正寫着代碼呢，産品經理過來說正在做的需求有一點調整，或者偷摸小聲說，隻打擾你一分鐘。

他們壓根不知道，需求的變化對于代碼來說很可能是推翻重來，不是他們所了解的“隻有一點調整”。

他們也不知道，打擾的那一分鐘，可能需要再花半小時甚至更長的時間來重新梳理邏輯。

尤其是改 bug 的時候，那種突如其來的問候真的不需要，哥們兒還想早點搞定下班呢！

面對這種情況，建議程式員兄弟們貼個條在工位上，注明“攻關中，看我起身再找我”。

還有，開評審會時，一些産品經理一上來就說要做什麼功能，從來不介紹背景是什麼，也不說為啥要做，做了會帶來什麼預期結果，更别提怎麼衡量資料評估 roi 了。

他們以為研發資源都很閑呢，大家都是有夢想的人好麼。

遇到這種情況，作為地球上最理性的一類人，我們要做的就是“教他們做人”。

就像我們寫一個函數需要提前聲明一樣，要有前因後果，否則就會報錯。

當然，“教别人做人”的前提是自己已經做好了，且不說我們要多懂産品和業務，畢竟有更專業的人。

但至少，一套完整的思維架構還是需要的，上司們不就是思維模型和做事方式比一般人成熟麼。

産品功能不是獨立存在的，是基于使用者場景、業務、需求、資料和可營運性綜合構成的。

下次如果還有産品經理這麼開評審會，至少有這麼幾個問題是可以向他們提出的。

第一，業務背景是什麼？第二，什麼樣的場景解決使用者什麼問題？第三，如何通過資料衡量解決情況？第四，功能上線後誰來負責營運？

反過來看，如果産品經理的解決方案不行，咱也别就此作罷讓他們回去改方案。

看看針對具體問題有什麼可行方案，現場讨論就把問題都給解決了。

總比他們改完一圈回來然後再開一次會要節省時間，萬一下次又不行呢。

另外，做技術的都怕産品經理隻顧當下不管過往，代碼可是活生生寫在那的，所有的曆史邏輯都會毫不客氣的照常運作。

一個需求提過來，也不管跟以前的邏輯是否有沖突，隻嚷嚷着要改，不行就拿老闆說事兒，這樣的産品經理真的得治。

治法也很簡單，把邏輯卡點告訴他們，然後就可以拂袖而去幹自己的活兒了，其他的也别多管，他們自己能反思并搞定。

誰讓咱心裡有一張全局代碼圖呢，誰讓咱心裡有完整邏輯譜呢，這就是技術的優勢，不容置疑。

而且，對于不管過往的産品經理，最好的方式就是讓他們做一張産品流程全景圖，形式可以是流程圖或者腦圖。

每次做調整時，都讓他們先把這個全景圖的關鍵邏輯過一遍，以防出現上線後發現相容性問題。

當然，咱最怕的就是那些甩鍋耍賴的産品經理了，就算人家耍賴，咱也下不去狠手不是。

不管怎麼說，還是不能硬鋼。平時工作得做到位，這裡也給大家支個招。

關鍵邏輯代碼的注釋一定要寫完整，而且别光寫代碼解釋。

把邏輯決策人、時間、讨論關鍵點以及當時的決策過程寫清楚，打包時随業務代碼一起上傳。

如果到時候出現甩鍋事件，把代碼拉下來，這就是“雲證據”啊！

好了，多的也不說了。

總之，做技術的人，天生理性，學習東西快，多掌握一些關于産品、業務、營運的知識，省的被坑。

最後，産品經理們，你們看懂了麼？

···············end···············

  推薦閱讀

轉型産品能幹啥，不做産品能幹啥

推薦一本好書