軟件項目怎麼快速響應用戶需求

作IT項目管理的朋友都知道，時間、範圍和成本是項目管控的三要素，可是對於用戶來說，他們一般更關注三要素裏面的時間，即項目進度問題，所以如何快速知足需求就成爲了一件很重要的事。

平常工做中，相信不少項目經理都有被需求方催進度的狀況，有時候需求方領導一個簡單的想法，常常會要求快速地作出來上線，極端的狀況是今天提了需求明天就要實現。

項目管理不是一件容易的事情，不少時候要平衡多方的利益，哪一邊沒照顧好，很快投訴就過來了。但無論怎麼說，凡事都有優先級，關鍵干係人如用戶高層和公司高層的需求一般是要最早須要去作的，那麼對於軟件項目的交付，從公司層面如何更好地響應需求提出方的需求呢？

見過不少面向政府也面向企業的項目，不少公司的交付無外乎分這兩類模式：

第一類是產品化交付：

好比結合在行業多年的經驗，打磨出一套所謂標準化的產品，直接在需求方提供的服務器換作快速化部署，或者把自家的雲端軟件開帳戶給用戶進行使用。

這種模式的好處是能快速鋪開市場，哪怕軟件賣便宜點也不要緊，量一上去了也能賺錢。缺點是當面向需求方定製化需求的時候，會缺乏一些靈活性，通常會盡可能說服需求方用本身的標準化產品，好比早期的金蝶和用友產品系統就是這種模式。

但現在面向企業和政府端的系統，這種模式愈來愈走不通了，如今的用戶都須要有本身特點的定製化系統，要有能出去吹牛B的亮點。

第二類是定製化交付：

不少剛進入到某個行業的企業，一般來說都是採起定製化軟件來和作產品化軟件交付的企業來進行競爭。

從用戶的角度，他們固然是歡迎作定製的，但對於軟件供應商，定製一般意味着須要較長的開發週期和較高的開發成本，一旦控制很差或者研發能力不足，虧本賺吆喝是常有的事情。

以上兩種模式各有各的優點和劣勢，但不管你是產品化交付仍是定製開發交付，假如需求方提出的功能在你的產品或過往項目中沒有作過，那麼快速響應的核心就是組件化設計和開發，能夠說沒有比這更好的解決方案了。

如何理解組件化？

簡單說就是當咱們接到一項新的需求時，在原型、UI設計和開發層面都有一套組件庫（或者叫模塊庫），可以快速的完成需求的設計開發落地。

單個的組件是經過一個一個的行業項目沉澱出來的可複用資源，組件自己通過了反覆的質量穩定性驗證，需求落地過程當中經過組件和組件的快速拼裝，從而達到快速響應軟件新需求的實現。

那麼組件的設計由誰來作合適？最好是熟悉業務和技術的架構師，這樣作出來纔會更合理、能比較接地氣地應用到不一樣的項目中去。

END

招投標軟件項目管理實戰分享