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