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