軟體專案的推進中的幾點體會(轉)

軟體專案的推進中的幾點體會
本文從溝通、簡單、反饋和勇氣四個價值觀並結合實際的專案開發過程進行了分析，為後續軟體專案的推進提供啟迪。

關鍵詞：溝通 簡單 反饋 勇氣

香江專案（事業部內部編號）作為我們消費電腦邁向家電化的一個重大的專案，雖然其作為一個C類研發專案，但其涉及到的無論從硬體上還是從軟體上都可以與一個小型的A類專案媲美。我作為專案的LEADER，從心底裡還是有點害怕，畢竟是剛加入公司的新員工，但出生牛犢不怕虎，我也很想嘗試去做一件事，只有在實際工作中才能不斷的成熟，提升自我。到目前為至，整個專案推進以香江專案計劃為關鍵路徑，相關硬體開發也在有條不絮的進行。

對於下面我想重點闡述溝通、簡單、反饋和勇氣，這是我們協作開發軟體專案的四個重要部分，對於軟體專案的管理與開發具有重大的意義。

溝通（Communicate）

或更準確地說，缺乏溝通，是幾乎所有軟體專案問題的根源。客戶沒與開發者溝通他的要求，或開發者沒與客戶溝通提供一個功能的困難之處。如果涉及的各方直接，及時地互相溝通，就可以消除大多數問題。我們不能忽視或懲罰任何誠實的溝通。

目前我們消費的定位是專案經理，從實際承擔的工作上看作為客戶（需求方）與硬體開發的角色，但作為面向消費客戶，我們最關心的是功能訴求，使用者使用流程與呈現介面，這和開發人員（程式設計師）有很大的衝突，後者更關心的是具體實現方式，如對於媒體播放器的底層API的使用與功能訴求如何在計劃時間內完成。但共同的目標是一致的，提供給使用者易用的產品，尤其對於我們一個企業內部的開發團隊，而不像外面公司間的協作。但溝通訊息的通暢性也直接制約著產品的質量。

對於軟體專案的需求內容不明確，把握不充分是其失敗的一個重要方面， 這是我們經常遇到的問題。一方面，由於客戶（需求方）IT知識缺乏，一開始自己也不知道要開發什麼樣的系統，或者懶於系統地整理出來，經常是走一步算一步，不斷地提出和更改需求，使得實現方叫苦連天。另一方面，實現方由於行業知識的缺乏和設計人員水平的低下，不能完全理解客戶的需求說明，而又沒有加以嚴格的確認，經常是以想當然的方法進行系統設計，結果是推倒重來。因此，需求分析必須注重雙方理解和認識的一致，逐項逐條地進行確認，雙方能在共同的基礎上達成功能與時間上的統一。

在香江專案中，對於需求主要涉及到後續新品的需求與本身專案發展的需求的綜合，對於實際工作中，我積極與軟體設計經理，程式設計師進行溝通，先從正式文件輸入開始，免的一開始就陷入無窮盡需求討論中。隨著專案的推進，對於某些需求由於技術上與時間上的不可實現性，因而大家及時溝通，通過專案的中期核對這樣的方式，將一部分需求作為第二次開發的要點進行剝離，從而保證專案的按計劃進行。

簡單（Simpleness）

有什麼最簡單的事情可能會起作用？我們的注意力太多放在了軟體的最複雜難解的功能上，而這些功能我們很少用到或者只是曾經用過。今天做簡單的工作，明天花點代價修改它要比今天做可能永遠用不到的複雜工作好的多。這也和我們的溝通價值緊密聯絡在一起，因為系統越簡單，需要的溝通越少。

從辨證的觀點上看，簡單與複雜是矛盾的統一體。某項技術對於某些人是簡單的，但對於另外的一些人則是複雜的！因而簡單並不是說整個功能的簡單，而是說我們掌握了該項技術後就應該有所發展的研究，比如我們知道恢復/備份功能的實現方案，但以專案的時間計劃與人力資源上講完整的實現該功能是不可能的，因而分為兩個階段的推進，這樣對於專案的開發人員就可以相對簡單的進行開發，有利於發揮主觀能動性，而不是在截止期限壓力與人力的壓制中進行開發。

反饋（Feedback）

反饋能告訴我們工作做得怎麼樣，以及以後要如何做。我們需要對正在執行的系統的反饋，以便了解它是否滿足了客戶的要求。我們需要通過反饋來了解系統將需要哪些最有價值的改進、加強和附加。我們還需要通過反饋來了解，我們什麼時候能夠交付某個特定的功能。如果不知道以前的速度又如何確定將來的速度？

一個軟體的成功與否，並不是其內含的技術有多高，其演算法有多嚴謹，而是能被使用者所接受。尤其對於我們消費軟體來說，因為我們直接面對的是客戶，強調以使用者為中心的設計始終是我們的頭等大事。但作軟體功能的需求，不是靠幾個人的腦力激盪而沒能完成的。只有通過來自第一線的聲音，從客戶需求來定我們的功能需求。

在我們的專案實施過程中，採用平臺開發與功能開發的兩條主線來進行。對於平臺開發是通過業界技術與自身技術實力作為反饋點，而功能開發以使用者的使用流程與功能本身需求為反饋，來共同完成專案需求的確認。

我想對於控制系統而言，閉環控制就是匯入了反饋的機制讓系統更加可靠。對於一個專案來說，本身就是一系統工程，無論是人員技術能力，思想，做事方式上的反饋都是對專案推進有很大幫助，試想程式設計師只是埋頭做自己的事情，研究技術細節，那麼我想做出來的軟體可能是差之千里。我想專案成員間的溝通是必要的，但同時需要的是效率，否則一味推諉是解決不了實質問題的！

形成一個良好的反饋機制，同時專案經理承認專案中存在的問題，加強風險管理，這是一個專案成功實施的必要保證。

勇氣（courage）

勇氣從表面上看好像是有勇無謀的感覺，但是如果我們每做一件事情總是畏首畏尾的，把失敗看作是洪水猛獸的，那麼有多好的規劃與人力也只是曇花一現。對於軟體開發，我們還是要把勇氣帶進了軟體開發中。我們有沒有勇氣嘗試新的、不同的東西來大幅減少專案時間？我們有沒有足夠的勇氣在即使面對鉅額預算和截止期限壓力時仍能堅持做正確的事情？這需要我們的勇氣。

勇氣（courage），我記得聽過一個笑話，大意說的是一個日本兵聽從其長官從5米高的桅杆上跳下來謂之勇氣，一個德國兵聽從其長官從10米高的桅杆上跳下來謂之勇氣，而美國兵被其長官要求從100米高桅杆上跳下來，而兵說長官瘋了，拒絕執行稱之為勇氣。對於這笑話中我們可以一笑附之，但我們卻是應該把勇氣匯入我們的實際工作中。有沒有勇氣去面對錯誤與權威，這是我們每一人應該堅持的。

我想對於我們公司來說流程的定義很清晰，執行人員可以提出改進意見。

結論

溝通、簡單、反饋和勇氣四個價值觀演繹了專案管理的全過程，從價值層面上剖析了專案經理與專案成員應該理解的含義，希望對大家有益。

溝通、簡單、反饋和勇氣是統一的，試想溝通的方式有很多種，如面談，電話和郵件，也只有通過溝通專案組成員們才能得到反饋，將複雜的事務簡單化，有力的保障專案的順利進行。只要專案成員有勇氣挑戰上級領導，在一定程度上堅持正確的方向，那麼四個層面上的價值觀可以得到淋漓盡致的發揮。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21210/，如需轉載，請註明出處，否則將追究法律責任。