登錄企業(yè)郵箱
收藏本站
關(guān)注
用微信掃一掃
1.做產(chǎn)品的主人
因為團(tuán)隊職責(zé)的劃分，PO/PM 是容易被大家認(rèn)為是產(chǎn)品的主人，是他或者她的項目，工程師只是實現(xiàn)一下而已。如果對產(chǎn)品沒有歸屬意識，這是個很要命的問題，接下來就是責(zé)任心的缺失，各種懈怠和對立。這里希望 PO/PM 也能意識到這個問題，鼓勵每個人對產(chǎn)品發(fā)聲，一定程度的參與設(shè)計和討論。
對開發(fā)來說，如果對產(chǎn)品沒有理解，不能形成自己的體驗見解，說明根本沒吃透設(shè)計文檔，只是按圖索驥，小心畫虎不成反成貓;對決策者來說吸收產(chǎn)品建議的確需要綜合考量，但工程師并不笨，相反他們是最聰明的一幫人，我就不信整個產(chǎn)品里面連一個由工程師發(fā)起設(shè)計或者優(yōu)化的點都沒有。
如果團(tuán)隊里有對產(chǎn)品理解深刻的工程師，請珍惜。
2.擁抱隊友
擁抱你的隊友，站在隊方(不是錯別字，的確不是對方)的立場思考問題。工程師可能經(jīng)常會聽到 “不是吧，你竟然這么做了，我有個方法比你好 XX 倍!” 或者是 “你這么寫有問題的，應(yīng)該這樣 blablabla”。第一反應(yīng)絕對是不爽到爆，很明顯，除非團(tuán)隊里混進(jìn)了競爭對手的內(nèi)奸，那么大家都是一條繩上的螞蚱，明確一點，那就是除了你之外，其他人也都是希望產(chǎn)品好少出 bug 效率高。
不妨先靜心聽一聽隊友的方法，如果合理，那兩個人一起比較一下差別在哪里，如果自己的里面隱藏了一個很深的 bug，那你得感謝你的隊友;如果隊友的方法只是效率更好，那么再評估一下修改的時間開銷，問問負(fù)責(zé)的 PM，看看把優(yōu)化插在哪個節(jié)點比較好，然后代碼里寫個 TODO 注釋，結(jié)束。程序員大多數(shù)不重視溝通方式，但技術(shù)牛掰加上一點點溝通技巧，那么恭喜你會立即脫穎而出!
這個問題可以這么說 “昨天咱們做的那個模塊，功能 OK，就是效率稍低了一點，我另外又做了一個修正版，這里是測試運行效率的數(shù)據(jù)...不用謝了...請叫我雷鋒”，對，是 “咱們” 不是 “你”!
3.打破開發(fā)的職責(zé)邊界
打破開發(fā)的職責(zé)邊界，只需要多延伸一步而已。Richard Clayton 在 Failing at Microservices 一文中提到了他的困惑，“服務(wù)由不同的人來負(fù)責(zé)，工程師開始抱怨服務(wù) A 被服務(wù) B 的任務(wù)擋住了。盡管服務(wù)和服務(wù)之間不會有編譯時間依賴，但還是會抱怨。沒有人去幫助服務(wù) B 的工程師，或者是把與其他服務(wù)相關(guān)的任務(wù)從清單里分擔(dān)掉，而是升起了他們所屬服務(wù)的吊橋，就好像他們是城堡一樣，然后就等著這一輪沖刺結(jié)束”。相信每個團(tuán)隊都會遇上這樣的事，就連 Debug 也會聽到推諉的聲音，前端與后端聯(lián)調(diào)時，先是測試者 “前端顯示不對哦”，然后是前端應(yīng)聲而起 “不會吧，是后端協(xié)議數(shù)據(jù)給的不對吧”，后端也按捺不住了 “另一個應(yīng)用也在用這條協(xié)議，沒有問題啊”。
工程師 Debug 有三重境界，第一重初級水平 “找到并解決自己的模塊的問題”，第二重高級水平 “找到隊友負(fù)責(zé)模塊的問題并幫他解決”，第三重專家水平 “設(shè)計一種方法，讓以后再寫類似模塊的人不可能犯這樣的錯誤”。
團(tuán)隊管理者應(yīng)該鼓勵工程師在搞定自己事情的前提下，發(fā)揮更大的作用，去幫助團(tuán)隊解決問題，本幫正是發(fā)揚這種超越自己職責(zé)的 “狼性文化”，能延伸多少看個人能力，但哪怕只從自己的領(lǐng)地向外延伸一步，也會給團(tuán)隊合作帶來巨大的改變，所以前面那種情況你聽到應(yīng)該會是：測試者 “前端顯示不對哦，但抓了包看可能是后端給的數(shù)據(jù)不對”，前端 “另一個應(yīng)用也用這條協(xié)議沒問題，我去查一下配置”，策劃 “不用看了，我配的數(shù)值有問題，馬上更新一版”，后端笑笑繼續(xù)思考怎么改善體驗。
4.活用結(jié)對
活用結(jié)對攻克問題，開拓思路，提高效率，降低學(xué)習(xí)成本。結(jié)對是敏捷最佳實踐里面的一個小方法，但我并不認(rèn)為他只屬于敏捷，在某些關(guān)鍵時刻使用非常有效，比如開發(fā)非常精細(xì)的功能、復(fù)雜算法、尋找重現(xiàn)機制復(fù)雜的 bug。
這時1+1 的作用遠(yuǎn)大于 2，首先結(jié)對的專注度更高，心情也更放松，好基友的效果不一定比鼓勵師的效果差，不容易受 QQ\郵件\電話的各種打斷，結(jié)果就是代碼質(zhì)量高，生產(chǎn)速度快;俗話說 3 分開發(fā) 7 分測試，用在測試和 bug 修復(fù)的時間會少很多，把多投入一個人力的成本給追回來，更不用談一些邊際效應(yīng)帶來的成本。在 debug 非常難的問題上，當(dāng)陷入困境，隊友可以幫助查疑補缺開拓思路，甚至有時只需要把思路講一遍給隊友聽，自己立刻就知道問題出在哪里了。另外結(jié)對的一個非常好的副作用就是降低學(xué)習(xí)成本，這個功能點你的好基友下次在你請假的時候也可以來維護(hù)。
5.從用戶身上尋找信心和動力
加班和趕時間節(jié)點是大部分工程師反感和造成效率低下的事情，但是 PO/PM 非常清楚，如果不踩準(zhǔn)這個節(jié)點，那么會導(dǎo)致 XX 天之后的某個版本不能按時交付，造成市場上一系列的被動局面。
有一次為了踩準(zhǔn)一個熱點事件的推廣，我們團(tuán)隊的工程師們連續(xù)作戰(zhàn) 16 個小時，完全沒有怨言，反而干勁十足。其實那是我們第一次做這樣的應(yīng)用，時間非常苛刻，從決定做開始，設(shè)計、美術(shù)、編碼實現(xiàn)，測試部署上線只有 1 天時間，分?jǐn)偟矫總�環(huán)節(jié)其實只有兩三個小時，但竟然沒有人質(zhì)疑這樣的決定。原因就是每個人都清楚，熱點事件轉(zhuǎn)瞬即逝，工作的成果將直接由用戶來考評，這并不是 PO/PM 貼在墻上的沖刺清單。
“產(chǎn)品唯快不破”，所以如果你想快，請讓工程師直面市場和用戶，同樣重要的是，根據(jù)時間點來匹配開發(fā)內(nèi)容，用最小化的產(chǎn)品上線，接著持續(xù)迭代，并持續(xù)部署交付。
結(jié)語——寫給工程師的
最后還想提醒諸位，人是團(tuán)隊最寶貴的財富，以上幾點的領(lǐng)悟和運用，縱然需要團(tuán)隊管理者意識的轉(zhuǎn)變，但最終能走到哪一步，還是要依靠高素質(zhì)的團(tuán)隊成員。
關(guān)注官方微信：北京影響力培訓(xùn)，了解更多精彩內(nèi)容
