中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

伴隨著互聯網的發展，軟件開發的節奏越來越快，無論是不斷拔高的對用戶的重視程度，還是來自于同行業的競爭，都推動著開發思路和方法的不斷演進，--也改變著團隊協作的面貌。瀑布、螺旋漸行漸遠，迭代、敏捷才逐漸被廣為接受，持續部署和交付又在前面招手了。這里并不想對它們展開比對，或者討論一番優劣。在我的理解中這些開發模式都不是最重要的，無論哪種開發模式，都離不開人，每個人的思維方式決定了團隊合作的效率和結果，而每個人的協作理念合在一起就是開發模式穩固的基石，正如本幫的Mauricio明確提出的“敏捷思維比Scrum更重要”。

本文想從一些實際開發中遇到的點出發，提供一些溝通和思維的方法，希望能夠改變團隊的效率，減少問題。

做產品的主人

因為團隊職責的劃分，PO/PM是容易被大家認為是產品的主人，是他或者她的項目，工程師只是實現一下而已。如果對產品沒有歸屬意識，這是個很要命的問題。接下來就是責任心的缺失，各種懈怠和對立。這里希望PO/PM也能意識到這個問題，鼓勵每個人對產品發聲，一定程度的參與設計和討論。

對開發來說，如果對產品沒有理解，不能形成自己的體驗見解，說明根本沒吃透設計文檔，只是按圖索驥，小心畫虎不成反類犬。對決策者來說吸收產品建議的確需要綜合考量，但工程師并不笨，相反他們是最聰明的一幫人，我就不信整個產品里面連一個由工程師發起設計或者優化的點都沒有。如果團隊里有對產品理解深刻的工程師，請珍惜。

擁抱隊友

擁抱你的隊友，站在隊方（不是錯別字，的確不是對方）的立場思考問題。工程師可能經常會聽到“不是吧，你竟然這么做了，我有個方法比你好XX倍！”或者是“你這么寫有問題的，應該這樣blablabla”，第一反應絕對是不爽到爆。很明顯，除非團隊里混進了競爭對手的內奸，那么大家都是一條繩上的螞蚱。明確一點：那就是除了你之外，其他人也都是希望產品好少出bug效率高。不妨先靜心聽一聽隊友的方法，如果合理，那兩個人一起比較一下差別在哪里，如果自己的里面隱藏了一個很深的bug，那你得感謝你的隊友；如果隊友的方法只是效率更好，那么再評估一下修改的時間開銷，問問負責的PM，看看把優化插在哪個節點比較好，然后代碼里寫個TODO注釋，結束。程序員大多數不重視溝通方式，但技術牛掰加上一點點溝通技巧，那么恭喜你會立即脫穎而出！

這個問題可以這么說“昨天咱們做的那個模塊，功能OK，就是效率稍低了一點，我另外又做了一個修正版，這里是測試運行效率的數據…不用謝了…請叫我雷鋒”，對，是“咱們”不是“你”！

打破開發的職責邊界

打破開發的職責邊界，只需要多延伸一步而已。Richard Clayton在Failing at Microservices一文中提到了他的困惑，“服務由不同的人來負責，工程師開始抱怨服務A被服務B的任務擋住了。盡管服務和服務之間不會有編譯時間依賴，但還是會抱怨。沒有人去幫助服務B的工程師，或者是把與其他服務相關的任務從清單里分擔掉，而是升起了他們所屬服務的吊橋，就好像他們是城堡一樣，然后就等著這一輪沖刺結束”。相信每個團隊都會遇上這樣的事，就連Debug也會聽到推諉的聲音，前端與后端聯調時，先是測試者“前端顯示不對哦”，然后是前端應聲而起“不會吧，是后端協議數據給的不對吧”，后端也按奈不住了“另一個應用也在用這條協議，沒有問題啊”。

工程師Debug有三重境界，第一重初級水平“找到并解決自己的模塊的問題”，第二重高級水平“找到隊友負責模塊的問題并幫他解決”，第三重專家水平“設計一種方法，讓以后再寫類似模塊的人不可能犯這樣的錯誤”。

團隊管理者應該鼓勵工程師在搞定自己事情的前提下，發揮更大的作用，去幫助團隊解決問題，本幫正是發揚這種超越自己職責的“狼性文化”，能延伸多少看個人能力，但哪怕只從自己的領地向外延伸一步，也會給團隊合作帶來巨大的改變，所以前面那種情況你聽到應該會是:測試者“前端顯示不對哦，但抓了包看可能是后端給的數據不對”，前端“另一個應用也用這條協議沒問題，我去查一下配置”，策劃“不用看了，我配的數值有問題，馬上更新一版”，后端笑笑繼續思考怎么改善體驗。

活用結對

活用結對攻克問題，開拓思路，提高效率，降低學習成本。結對是敏捷最佳實踐里面的一個小方法，但我并不認為他只屬于敏捷，在某些關鍵時刻使用非常有效，比如開發非常精細的功能、復雜算法、尋找重現機制復雜的bug。

這時1+1的作用遠大于2，首先結對的專注度更高，心情也更放松，好基友的效果不一定比鼓勵師的效果差，不容易受QQ\郵件\電話的各種打斷，結果就是代碼質量高，生產速度快；俗話說3分開發7分測試，用在測試和bug修復的時間會少很多，把多投入一個人力的成本給追回來，更不用談一些邊際效應帶來的成本。在debug非常難的問題上，當陷入困境，隊友可以幫助查疑補缺開拓思路，甚至有時只需要把思路講一遍給隊友聽，自己立刻就知道問題出在哪里了。另外結對的一個非常好的副作用就是降低學習成本，這個功能點你的好基友下次在你請假的時候也可以來維護。

從用戶身上尋找信心和動力

加班和趕時間節點是大部分工程師反感和造成效率低下的事情，但是PO/PM非常清楚，如果不踩準這個節點，那么會導致XX天之后的某個版本不能按時交付，造成市場上一系列的被動局面。有一次為了踩準一個熱點事件的推廣，我們團隊的工程師們連續作戰16個小時，完全沒有怨言，反而干勁十足。其實那是我們第一次做這樣的應用，時間非?？量?，從決定做開始，設計、美術、編碼實現，測試部署上線只有1天時間，分攤到每個環節其實只有兩三個小時，但竟然沒有人質疑這樣的決定。原因就是每個人都清楚，熱點事件轉瞬即逝，工作的成果將直接由用戶來考評，這并不是PO/PM貼在墻上的沖刺清單。

“產品唯快不破”，所以如果你想快，請讓工程師直面市場和用戶，同樣重要的是，根據時間點來匹配開發內容，用最小化的產品上線，接著持續迭代，并持續部署交付。

寫給工程師的

最后還想提醒諸位，人是團隊最寶貴的財富，以上幾點的領悟和運用，縱然需要團隊管理者意識的轉變，但最終能走到哪一步，還是要依靠高素質的團隊成員。

作者：Landon（梁棟，點融技術高級開發主管，曾就職Activision Blizarrd，9年開發經驗，關注前端技術、H5應用、圖形和3D技術）

本文由微信公眾號點融黑幫 @Landon 原創發布于人人都是產品經理?，未經許可，禁止轉載。