[[391336]]

最近兩會上都談論到 996 的問題了，那我們實行 996 ，每個人每天都非常忙碌，是不是就效率很高呢？是不是很多時候都在做一些無價值的事情呢？是不是都在加著班寫著 Bug 呢？我認為真相遠沒有我們想象的那么樂觀。

春節后的幾次公司會議上都在提「增效」，隨著公司的發展，人數變多，各種成本也隨之增高，所以通過各種方式來增效，才能有正向的發展。以目前我的觀察來看，我覺得可以從兩個方面入手： 溝通和抓住關鍵點 。

在《怎樣提高開發效率》一文中主要說的是開發人員硬技能方面的提升，在上面提到的各種成本中，溝通成本是非常重要的一塊，這屬于軟技能的范疇，也是最容易被忽視的。

溝通體現在很多個方面，這里主要想說下提問和 Bug 描述。

前不久，有項目團隊同事在企業微信上問我：怎樣拉取鏡像來進行測試環境的更新？如果考慮到部門之間應該有良好的溝通的協作，我應該告訴他怎么操作，但為什么有這么低級的問題能被問出來，是一個值得思考的問題：

• 拉取鏡像更新是一個每個開發人員必備的技能，為什么還有人是不會的？

• 有沒有做相應的培訓，或者培訓了，是否每個人都能夠理解？

• 聽的時候理解了，實際操作的時候是不是還是不會？

所有有章可循的、都應該形成規范，進行培訓、然后考核，保證不同的人按照文檔進行操作能夠得出相同的結果，如果有開發人員能主動去探究其中的原理并舉一反三，那便是錦上添花了。

對于 Bug 描述經常會出現這樣的場景：

實施人員：表單上的選人控件加載部門樹很慢；

開發：經過一系列的代碼檢查、運行調試后回復，我本地很快啊；

開發人員時間花了，但并沒有解決問題，在描述 Bug 的時候，需要有更詳細的場景和上下文信息，比如：

• 客戶的部門和人員的數據量級是多少？

• 是所有用戶還是特定用戶，如果特定用戶，是否有什么特殊的權限的設置?

• 客戶使用的瀏覽器是什么版本？

• 選人控件本身有沒有什么特殊數據范圍或權限的設置？

有了更多的信息，開發人員就能有針對性地進行排查，也能更容易解決問題。

Bug 只要能重現，處理起來還比較容易，當遇到偶發 Bug 的時候，更是要盡量提供足夠的信息，但很多時候描述卻是這樣的：

實施人員：客戶點擊某某操作時，會出現系統異常，我們有時操作也會出現，但不是每次都出現；

開發：不能重現，我怎么排查呢？

實施人員在一線，離現場更近，能知道更多的信息，所以在出現問題時需要盡可能多地提供信息：

• 系統出現異常提示是有日志記錄的，是否有對日志進行過初步的分析？

• 操作的數據中有沒有特殊數據，比如附件、富文本等？

• 是否能收集到客戶用的系統以及瀏覽器的版本？

• 是否能收集到客戶的操作系統的方式？

如果每個一線實施人員都能夠去收集一些有用信息，做下初步的分析，然后將整個過程形成文字內容提交給開發，相信會大大提升解決問題的效率。

至于收集哪些有用信息，怎樣來做初步分析，隨著慢慢地沉淀，也一樣可以形成標準的文檔和操作手冊。

除了溝通，另一個能提高效率的地方就是在工作中能抓住關鍵點，根據二八法則，抓住 20% 的關鍵點就能解決 80% 的問題。

下面是最近團隊中發生的兩個個事情，正好說明了關鍵點的重要：

• 產品代碼做重構優化，讓開發人員按照思路寫出類以及空方法，然后進行評審，但開發人員會比較容易關注細節，一動手就想著對象怎樣映射，依賴注入應該怎么進行設置等等，浪費了時間；

• 讓開發排查一個 Bug，我便開會去了，一個多小時回來詢問情況，得知還沒有解決，還在繼續調試代碼分析原因，最后發現是一個配置項沒有添加導致。

第一件事情的關鍵點是代碼的思路，而不是實現，開發人員和產品負責人的目標和思想需要一致，也就是華為管理哲學中所說的「力出一孔」，如果方向偏了，努力越多，錯的越遠。

第二件事情的關鍵點是遇到問題的思考，想清楚之后再動手做，最終的做可能是檢查配置、尋求其他人員幫助、或者代碼調試。而不是任何問題一上來就進行代碼調試。

最后總結下：

1、溝通在工作和生活中無處不在，想想溝通的目的，多換位思考；

2、除了上面說的提問和 Bug 描述，還有代碼注釋、代碼提交備注、技術規范文檔等等都屬于溝通；

3、方向一致、目標明確做起事來才能最高效；

4、多思考、總結、復盤才能慢慢積累經驗，經驗豐富了才更容易找到關鍵點。

希望本文能對您有所啟發和幫助！