關注+星標公眾號,不錯過精彩內容

來源 |?高效程序員
需求轉換的能力或者叫理解需求的能力;
分配時間的能力;
開發質量的問題;
需求轉換的核心就兩個字“溝通”,開發成本最大的浪費是需求浪費,這分為兩方面,一方面需求方,無效需求或者需求變動帶來的研發成本浪費。另一方面是需求方和研發方需求傳遞不一致的浪費。簡單來說就是沒有充分溝通,導致研發所做的功能和需求方需要的功能不一致,導致返工的現象。
第一點是作為研發不能把控的,能做好的就是在需求傳遞的過程中,保證需求的有效性和完整性。
那么具體要怎么做呢,可以通過以下幾點:
1.開發前需求溝通,最理想的溝通方式:產品提供需求文檔 => 研發人員先過一遍,記錄有疑問的需求點 => 產品和研發討論需求,把所有的需求都過一遍,有疑問的點重點溝通 => 研發人員用產品能聽懂的話,大概地描述一下重點討論的需求和實現方式 => 產品確認無誤,啟動開發流程。
2.開發中溝通,或者是開發前模擬程序實現流程的時候,如果有未談到的需求或者有異議的需求,及時和產品溝通之后再開始做編碼。
3.測試階段,給需求方演示程序,最后一遍對接核對需求。
如果能保證以上三點,基本上在需求轉換的工程中已經算一個合格的程序員了。
做軟件開發的一般情況下都是,以功能(或叫結果)為導向,以時間為衡量標準的一項嚴謹的工種。所有“時間概念”在軟件開發中發揮著不可比擬的重量。
在說合理分配時間之前,有必要先說一下,程序開發的生命周期,在很多人眼里,程序開發有啥周期,做完不就完事了嗎?其實這是小作坊的思維方式,對于一個合格的軟件公司或者大一點的軟件公司來說,即使到了開發實施的這一步,也分為5步:
軟件設計,思考最優實現方式 => 擼碼 => 測試階段 => 修復完善 => 交付,完成開發。
一般來說,對個人而言軟件設計,思考最優實現方式要占用30%的時間,擼碼占用50%,測試和完善20%,當然,這個不能一概而論,對于新手來說思考的時間短點,關鍵點在留夠測試和完善的時間,測試和完善的時間越長,項目的成功幾率就越大;對于大咖來說思考的時間更長,因為代碼質量過硬,所有測試和完善的時間可以相對減少一點。
如果能認識到小作坊和生產線的區別,就能合理地安排時間,盡量提前完成開發,進入測試和完善的階段,才是關鍵。
影響時間規劃的還有另一個原因,項目沖突,比如當在做B項目,突然測試人員找你說A項目有一個xx問題,這個時候就要平衡一下優先級,原則上來說,是先處理優先級高的問題,但一定要把控的是盡量不影響自己的B項目計劃開發進度。如果實現迷茫可找上級來權衡,讓他做決定,這一點很重要,一定不能忽略。
------------?END?------------

●專欄《嵌入式工具》
●專欄《嵌入式開發》
●專欄《Keil教程》
●嵌入式專欄精選教程
關注公眾號回復“加群”按規則加入技術交流群,回復“1024”查看更多內容。