就能夠量化的，但是走的路多了，見識(shí)多了自然就慢慢由定性轉(zhuǎn)化為了定量。定性是大方向，而定量則是精細(xì)化;定性是全憑經(jīng)驗(yàn)，而定量則是經(jīng)驗(yàn)+邏輯;定性是宏觀把握，而定量則是精細(xì)化控制。量化的基礎(chǔ)是數(shù)據(jù)，強(qiáng)調(diào)數(shù)據(jù)的基礎(chǔ)是關(guān)注數(shù)據(jù)，而關(guān)注數(shù)據(jù)的重點(diǎn)則是可視化
6、范圍
我不得不再回顧下教科書的內(nèi)容，計(jì)劃是漸進(jìn)明細(xì)的，而范圍是一開始就確定的。計(jì)劃可以漸進(jìn)明細(xì)，但是范圍不能蔓延。但是實(shí)際的情況往往確實(shí)就是項(xiàng)目范圍在蔓延，范圍完全不變動(dòng)基本很困難，所以項(xiàng)目管理者根據(jù)應(yīng)該關(guān)注范圍受控這個(gè)概念，范圍可能會(huì)發(fā)生變化，但是一定要受控。
范圍通用涉及到兩個(gè)方面的內(nèi)容，一個(gè)是產(chǎn)品范圍，如果產(chǎn)品范圍發(fā)生變化必然會(huì)增加項(xiàng)目范圍，所以首先要控制產(chǎn)品范圍和用戶需求。其次是項(xiàng)目范圍，當(dāng)產(chǎn)品范圍沒有變化的時(shí)候，由于我們采用的過程管理策略同樣影響到項(xiàng)目范圍。即時(shí)產(chǎn)品范圍和項(xiàng)目范圍都沒有變化，如果我們采用的技術(shù)實(shí)現(xiàn)方案不同，仍然會(huì)影響到工作量，而工作量直接影響到進(jìn)度目標(biāo)。
我們無法控制范圍完全不變化，那就轉(zhuǎn)變思路，盡量讓范圍的變化盡早的被識(shí)別出來并解決掉。即使是資深的需求分析師也無法保證完全能夠通過需求規(guī)格說明書和原型覆蓋用戶的所有需求，因此唯一的方法就是短周期迭代，盡早的交付首版本，盡早的獲取用戶的范圍變更信息?！?/span>
7、計(jì)劃
計(jì)劃本身就是對(duì)項(xiàng)目的預(yù)測，如果等所有的事情都明確了再來做計(jì)劃，那么可能你始終都無法去做計(jì)劃，當(dāng)你期待的東西明確后你又發(fā)現(xiàn)了新的不明確的東西。因此計(jì)劃本身就是基于假設(shè)下的某種確定性，再簡單點(diǎn)說就是如果人員，團(tuán)隊(duì)，環(huán)境和技術(shù)怎么樣了?項(xiàng)目團(tuán)隊(duì)?wèi)?yīng)該可以完成哪些事情。而假設(shè)即是風(fēng)險(xiǎn)，所以計(jì)劃是基于風(fēng)險(xiǎn)的一種對(duì)事物發(fā)展趨勢的預(yù)測。
當(dāng)你面對(duì)一個(gè)大的不明確的事物的時(shí)候，首要工作仍然是分解，只有通過分解才能夠把確定的東西和不確定的東西分離出來。對(duì)于確定性的事物可以先行，對(duì)于不確定性的可以考慮風(fēng)險(xiǎn)應(yīng)對(duì)和替代方案。當(dāng)我們面臨一個(gè)關(guān)鍵技術(shù)沒有解決的時(shí)候，我們往往第一反映是無法做計(jì)劃，但是我們需要的卻是基于假設(shè)和風(fēng)險(xiǎn)的計(jì)劃。比如：
假設(shè)關(guān)鍵技術(shù)A能夠在一周內(nèi)預(yù)研成功和解決，項(xiàng)目應(yīng)該在6周左右時(shí)間完成。如果關(guān)鍵技術(shù)在一周內(nèi)無法解決，我們需要啟動(dòng)替代方案2，當(dāng)采用替代方案2時(shí)候項(xiàng)目在8周左右時(shí)間能夠完成。這種陳述方式本身就是計(jì)劃，并且可以看到如果這樣描述讓我們會(huì)根據(jù)高度關(guān)注風(fēng)險(xiǎn)和不確定性。
8、平衡
平衡是我們?cè)陧?xiàng)目管理中談的比較多的一個(gè)詞，平衡也是項(xiàng)目經(jīng)理的一個(gè)重要能力。但是平衡仍然是相對(duì)的，很多時(shí)候我們談平衡是項(xiàng)目目標(biāo)驅(qū)動(dòng)的，但是更應(yīng)該談平衡是用戶滿意驅(qū)動(dòng)的。一個(gè)項(xiàng)目延期交付2個(gè)月，投入增加了30%是否就一定不成功呢?顯然不是，因?yàn)樵谶@段時(shí)間可能是用戶驅(qū)動(dòng)增加了一個(gè)關(guān)鍵需求和功能，而且也增加了投資，及時(shí)晚交付仍然可能是用戶滿意。
平衡不能犧牲質(zhì)量，因?yàn)橘|(zhì)量的一個(gè)衡量本身就是用戶滿意，要意識(shí)到其余都可以變化而質(zhì)量不能變化。很多時(shí)候項(xiàng)目失敗的原因就是去降低質(zhì)量，導(dǎo)致了錢也花了，項(xiàng)目也延期了，最后仍然是用戶無法滿意。
9、進(jìn)度
很多時(shí)候我們是知道進(jìn)度會(huì)延期，但是卻無能為力。由于導(dǎo)致進(jìn)度延期的原因，涉及到的人，團(tuán)隊(duì)環(huán)境等因素太多了，導(dǎo)致我們無法快速的作出相應(yīng)的應(yīng)對(duì)決策。那好吧，還是抓緊時(shí)間趕進(jìn)度吧，連溝通都免了，而最后結(jié)果往往確是進(jìn)度惡化。如果我們只是發(fā)現(xiàn)問題，而不去解決問題，那發(fā)現(xiàn)問題本身也就沒有了意義。進(jìn)度都知道要延期了，還需要開會(huì)浪費(fèi)時(shí)間嗎?答案往往是暫停并集體思考和決策比貿(mào)然前進(jìn)更加重要。
從軟件開發(fā)生命周期來說，軟件開發(fā)包括了需求，設(shè)計(jì)，編碼，測試等諸多過程。前面需求，設(shè)計(jì)，編碼都沒有延期為何測試延期這么多呢?測試應(yīng)該來背這個(gè)責(zé)任嗎?要知道測試的時(shí)間長短首先是跟前面各個(gè)階段的工件質(zhì)量相關(guān)，其次才是和測試人員本身的效率相關(guān)。進(jìn)度延期的根源往往是前面各個(gè)階段不切實(shí)際的進(jìn)度，我們采用可視化項(xiàng)目管理和增量迭代，冒煙測試和每日構(gòu)建都是為了讓前面階段的進(jìn)度盡早的可視化。