讓技術不要成為「背鍋俠」！

多麼喜感的照片，這鍋就背了怎麼地吧

今天終於把最近出現的「技術問題」處理了差不多了，估計老婆再也不說我晚上睡覺說夢話都是這方面內容了。事業線領導投訴了技術團隊，讓團隊氣氛有點緊張，業務人員感覺在前方因為產品體驗不好推動受阻，技術團隊認為如果有問題應該溝通而不是投訴。更何況開會討論后，其實真正的技術問題不到兩成，大部分還是職責不清晰，協作溝通的問題。

技術經常成為「背鍋俠」，這是經常性的事情，我想起三年前和今天相似的一幕，我也不會忘剛參加工作做內部信息支持時業務部門對我們的指責，更讓我感到可笑的是當年動車出事故時最終的原因是程序員寫錯了代碼。為什麼技術那麼「悲催」呢？因為不管是外部項目還是內部服務，技術方永遠都是乙方，苦逼的乙方，你怨誰呢？在一個互聯網的產品團隊里，技術也往往是成本部門而非利潤部門，不批你批誰呢？

所以，要想不成為「背鍋俠」，就要想著不要出問題（呵呵，沒有一點問題也許真是大問題）！怎麼才能少出問題呢？作為技術團隊來說：

1、技術能力很重要！

這裡的技術能力不僅僅是有一兩個出色的技術人員，而是整體的技術能力。很多問題往往都出現在團隊中能力最差的那個人身上，這就是木桶效益。所以一個優秀的技術團隊總是通過自己積累的技術體系來彌補人員的能力差異。特別在一個產品團隊，積累非常重要，因為我們所做的不是一個短周期的項目，而是一個不斷迭代的長周期產品，積累的越充分，效率越高、成本越低、質量越好！

2、重構是一項貫穿始終的工程！

重構（Refactoring）就是通過調整程序代碼改善軟體的質量、性能，使其程序的設計模式和架構更趨合理，提高軟體的擴展性和維護性。我們因為時間、資源以及人員能力差異、變更造成代碼或者軟體設計的不夠優秀，或者隱藏著問題。不能等到出現問題才想起重構，也更不要等到架構不適應時才想起重構，重構就是日常的一項工程，需要不斷的重複它，重構是一種未雨綢繆的行動！

3、具備產品思維和用戶思維！

這點非常非常重要，也不是因為我是技術轉向產品才這麼說。技術最終的價值不是說你寫了多少的代碼，而是自己開發的東西能很好的被應用。所以站在產品的角度來思考，站在服務用戶的角度來思考，體驗好不好，如果我是用戶我會喜歡嗎？所以有時候一定要跳出技術思維的框框，更上一層的去看待自己所做的東西。

4、樂於溝通，善於溝通！

對於大部分技術人員來說，總是很木納，不善言談。而且做技術的，說話做事都直來直去，不善於包裝，經常說話得罪人。我作為技術出身的人就存在這樣的問題，有時候無法控制自己的情緒，說話直接，沒眼力價！這很正常，但是需要不斷的加強，要樂於溝通，善於去溝通。就像這次事件一樣，有些問題其實就是因為技術私自改進了產品而沒和產品經理溝通，有時候就好心可能辦了壞事。做技術的人雖然不會四面玲瓏，八面來風（這樣的技術人員也不敢要），但是要善於去表達自己的意見，去溝通問題。

5、擺脫那顆玻璃心！

技術人員都是比較內秀的人，雖然可以熬夜加班，可以通宵達旦，但是大部分都是一顆玻璃心，非常的脆弱。就像這次，一次非正常溝通，讓我也控制不了情緒，有人更是想要對簿公堂。去年有一次因為一個方案溝通的失誤，我批評了一下我們的技術負責人，可能因為自尊心受到傷害，導致技術負責人離職。我到現在還特別內疚，所以從此和技術溝通總是小心翼翼，生怕傷害了他們。但是從技術人員角度，我們不僅僅能承受身體疲憊，更要能承受心理的壓力，多理解別人，多一些包容，這有利於我們自我的發展。

不管是對外做項目還是內部做產品，甲方和乙方，需求方和支持方都是希望能把東西做好，所以雙方最重要的是保持良好的協作關係，共同去面對問題和解決問題，才是我們真正正確的做事方式。所以站在技術的角度上，我想給需求方，特別是互聯網公司內的需求方提一些建議：

1、熟悉產品團隊的溝通渠道

首先我們要清楚產品開發過程所涉及的崗位有哪些？產品經理、產品設計、交互設計、項目經理、前端開發、後端開發、架構師、技術經理、測試、運維工程師等等，每個團隊根據規模所存在的崗位是有差別的，根據業務性質這些崗位所處的組織架構也是不同的。有的會把產品和技術全放到研發中心，有些產品部和技術部分開，有些產品人員跟著產品線，有些大點的團隊技術也是跟著產品線。現在大部分團隊都採用敏捷的迭代開發，只是迭代周期不同，敏捷程度不同。所以當出現問題時，我們能清晰的知道是誰的問題，問題的嚴重程度，當前的版本規劃是否包含此問題等。如果一個互聯網團隊的前端業務人員這些都區分不了，那最好溝通一下補補課，這樣更便於協作。實在不知道該找誰，很簡單，找產品經理。大多數的產品團隊，都實行產品經理負責制，由他作為統一的溝通后負責前後協調。為了更好的溝通、跟蹤和責任劃分，大部分產品團隊都會參與協作工具來管理，所以這些問題最好要在這些工具上體現出來，否則口頭交代的問題，真的很難跟蹤並且劃分責任。溝通建議是多方溝通，兩個人溝通不清容易扯皮。比如我們用tita，我們不僅僅可以把任務指定負責人，還能引進相關人。當問題很多很雜，最好開會溝通，分析問題在哪，尋求解決方法。像這次問題出現后，一個會議全部搞定，技術的解決技術的，產品的解決產品的，設計的解決設計的，如果一開始就開一個小會，大家都愉快的解決問題了，也不至於全部讓技術背鍋挨批，蒙冤受屈！

2、資源不足的情況下懂得取捨

項目管理的平衡術

做過項目管理的人對這張圖肯定不會陌生，項目範圍一定的基礎上，成本、時間和質量是三角關係，最多只能正向改變兩個，所以這就需要平衡。不可能又想消減成本，還想縮短時間，還得保證質量，這是沒法實現的。只能根據實際情況保證兩個，除非改變範圍，增加資源或者消減需求。所以處在項目中的各類人，大家都要懂得去平衡，如果各自都為了自己的利益去索取，必然會陷入混戰的狀態。對於產品開發管理更應該掌握平衡，為了保證業務推進，很多時候不是去爭取，而是去放棄。前幾天聽的SFE的培訓，其核心思想也是在資源不足的情況下，如何做市場細分，客戶細分，什麼都想做是不可能的，有舍才有得。

技術人員直接、不圓滑、不隱藏、有啥說啥在一定階段是好的品質，但踩得坑多了自己還是要注意解決問題的方式。我自己做了接近十年的技術，也做了幾年的產品，其實做這兩件事的確是很有意思的事情，做技術可以讓人專註，做產品可以讓人全面，雖然也經常碰到一些著急上火的事情，處理起來不夠成熟，但是我們既然選擇了愛這個職業，就不能因為碰點小困難，踩點小坑就灰心傷氣，把問題當成磨練自己的工具，完善自己，早日擺脫「背鍋俠」！