不專業的最反感，現在產品跟獵頭和中介差不多了，什麼人都混進來了，一些基本常識都不知道還JJYY，連反駁都不想反駁了。

我老公是程式設計師，問了一下這個問題，他跟我痛訴了以下10點：

1. 頻繁改需求，不管是不是業務要改的；

2. 和外部對接的時候不做工作直接拉群；

3. 不寫文件；

4. 不懂業務邏輯要反問；

5. 查資料都不會要幫忙；

6. 仗著自己是女的撒嬌推卸責任；

7. 開會讓碼農背鍋；

8. 覺得上線後由於設計造成的bug和自己沒關係；

9. 見人說人話見鬼說鬼話；

10. 不陪碼農加班

基本總結起來看，可以歸類一下：

1、2、4基本可以歸為這一類。

第1、4點，產品經理儘量在評審的時候就把所有情況和邏輯考慮清楚，如果你覺得自己能力還不夠，就多找人幫你過需求。

第一遍拉上提需求的同學（一般可能是運營），讓他看看你的設計是否符合他的預期。最好是給他完整演示一遍。

第二遍拉上你組內的PM，讓他們給你提意見，這種一般叫做組內評審。

第三遍拉上你的UI（小公司可能都有），讓他給你看看互動設計等是否合理。

綜合幾遍意見下來，你對這個需求就會考慮得更全面了，這時，你再去跟研發溝通，才能遊刃有餘，也不會說都進入開發了還不停的改之前設計得不合理的地方。

第2點，隨便拉群這個其實還挺普遍的，有時候著急就直接把RD拉進來了，然後他一臉懵逼。所以這個最好是已經跟外部門的人溝通好了，產品方案和流程都確定了，你再跟RD的領導私底下說一下這個大概是什麼事情，需要誰的介入，然後RD的領導就會說你去找誰誰誰吧。這時候你再去跟他把背景和方案跟那個程式設計師說明白，再把他拉到群裡，他就不懵逼了。

3、5、10基本可以歸為這一類。

3不寫文件，直接在群裡說功能就讓RD開發的，這個真的要避免啊，即使你認為只是一個小的修改，最好還是正式的發個郵件，說明詳細的邏輯。要不然測試都不知道該怎麼測，上線出了bug你又去怪程式設計師。所以最好有一個詳細的說明，留下“案底”，最後大家也好追根溯源。

5這個其實好多大公司會提供取數的工具，自己寫一段sql就能提取想要的資料了，小公司你也可以去問RD，求他幫忙告訴你連線上資料庫的方法，然後自己去提數，很多產品是嫌麻煩，但是其實一通百通，多寫幾次就會了，開始可以讓RD寫好，你自己改一改其實下次就可以複用的。

10這個其實在最後上線的時候我們都要求陪到上線後做完迴歸測試才能回家的，開發的時候可以比程式設計師早下班，但是如果他們有問題也一定要在工作群中及時解答，不要耽誤開發進度。

6、7、8基本可以歸為這一類。

要讓程式設計師GG對你建立起信任其實是非常難的，你做對一件事情，可以+1分，但是做錯了一件，可能就是-10分。都說程式設計師掙的是加班的錢，PM掙的是背鍋的錢，其實不假的，一個產品成不成很大程度上不是技術上的問題（只要不是太離譜的需求，技術上現在一般不是問題），而是“是否滿足了使用者的剛需”的問題，所以PM該背鍋的時候要主動點，特別是自己設計得不好才導致的bug一定要主動承認錯誤，說下次一定改正，要不在程式設計師心中的地位只會急劇下降。

當然，如果確實是因為研發導致的重大線上問題，還是需要跟研發經理溝通，進行快速修復及後續覆盤，怎麼避免後續類似問題的出現。在這個過程中PM不要忙著推卸責任，主動去解決並想好後續規避方法才是重中之重。

第9點，其實有點像產品經理的職業病，因為幹這職業需要接觸的人太多了，都需要產品經理這個角色去串聯起來，所謂的“見人說人話，見鬼說鬼話”其實不要讓人覺得油嘴滑舌，而是真誠的站在對方的角色角度來考慮整個專案的，他們也會真誠的迴應你。