最近和大家一起討論了一些內(nèi)容管理方面的功能和設計，有些思考，和大家分享一下。
　　在討論內(nèi)容管理的功能需求時，我們常常會考慮某個功能各種各樣的情況，功能性、易用性、復雜的處理場景、異常的處理場景，這些無疑都是非常非常有價值的，一個系統(tǒng)做到最好的境界，從客戶角度來看，也就是這些功能了。
　　同時，我們也討論了很多軟件設計方面的一些內(nèi)容，考慮了很多靈活性、擴展性方面的內(nèi)容，同時設計和功能也是緊密相連的，設計常常對功能的具體展現(xiàn)會有一定的影響。
　　那我們實際中遇到的困難是什么呢？針對上面我們討論的兩個方面，主要是兩個問題：
　　1）功能太多了，有時候是越想越多，如何選取合適的功能集合成為討論的焦點；
　　2）還有就是設計的靈活性和擴展性的把握，感覺好的設計，往往需要更多實現(xiàn)的時間，然后項目時間似乎又不允許。
　　在說明這兩個問題之前，我想有必要稍微說明一下軟件質(zhì)量的一些分類。
　　最近看一本書（Scrum and XP from the Trenches），對軟件的質(zhì)量，劃分為內(nèi)部質(zhì)量（internal quality）和外部質(zhì)量（external quality），外部質(zhì)量指的是從客戶角度可以看到的質(zhì)量，比如軟件的功能，易用性、性能等等；內(nèi)部質(zhì)量則是是從程序員角度來看的質(zhì)量，比如代碼的健壯性、可擴展性、可維護性等等。外部質(zhì)量好的軟件，內(nèi)部質(zhì)量不一定好；但是內(nèi)部質(zhì)量不好的軟件，外部質(zhì)量一般很難好。很難想像，一個設計很糟糕，代碼質(zhì)量很糟糕的系統(tǒng)，功能、性能和易用性可以很好。內(nèi)部質(zhì)量就好比是外部質(zhì)量的基石，代碼的可維護性和擴展性，直接影響了系統(tǒng)的功能的改進和提升。
　　外部質(zhì)量和內(nèi)部質(zhì)量比較容易對于到功能和設計兩個問題上。
　　那么回過頭來看我們遇到的兩個問題，首先是功能的取舍問題。
　　我們Agile的團隊討論，大家對于某個User Story，討論起來越談就越起勁，想出了好多好多的功能點，隨之也帶來了很多麻煩，比如說要實現(xiàn)的范圍好像太大了，似乎一下子工作量變得很大，隨著而來也有很多壓力，然后接著我們有時候也會不由自主的按照項目時間點，尋找一些“捷徑”，然后可能就逐步丟掉了或者少做了一些好的功能點，甚至會轉(zhuǎn)向?qū)崿F(xiàn)一些大家雖然覺得不怎么好但是滿足項目時間點的功能，這時大家都不免感到有些失落。
　　那我們可以怎么處理呢，可以稍微分析一下我們整理出來的功能點，我們會發(fā)現(xiàn)，情況也許不是我們想像的那么糟糕。我自己覺得有四個原則可以幫助我們?nèi)ゾ駬瘢?BR><!--[if !supportLists]-->1）<!--[endif]-->功能優(yōu)先級
<!--[if !supportLists]-->2）<!--[endif]-->80/20法則
<!--[if !supportLists]-->3）<!--[endif]-->完整性
<!--[if !supportLists]-->4）<!--[endif]-->可持續(xù)性
　　1）優(yōu)先級
　　首先是我們可以按照優(yōu)先級來選擇功能點，這個是顯而易見的。重要的功能先做，次要的功能可以先放一放。特別是最基本的功能，比如客戶一定要的功能，沒有這個功能客戶就玩不轉(zhuǎn)了；比如內(nèi)容管理，如果內(nèi)容創(chuàng)建、修改和刪除，這些功能如果都沒有，那么系統(tǒng)都無法正常運轉(zhuǎn)了，肯定是不行的了。
2）80/20法則
　　80/20法則，就是先選擇哪些客戶日常使用最需要用到的功能，比如說內(nèi)容處理的基本流程，有一些內(nèi)容同步的異常情況，實現(xiàn)起來是很復雜的，但是實際中遇到的可能性相對較

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html