對於那些專案管理的新手來說，他們害怕的是成功通常需要做出許多變化。乙個新專案建立的目的就是通過修改、構建或者銷毀某些事情來改變周圍的世界。除非是某些特殊情況，否則維持現狀會被認為是一種失敗的結果。世界一直在改變，如果乙個web站點或者其他專案不能和它以前的一樣好，就意味著這個專案已經過時了，出現這種失敗結果的原因或者是目標出現了偏差或者是專案的執行方式出了問題。
專案經理很難忽視那些伴隨著專案的潛在的壓力。因此他們要做就是更加出色，而不是原地踏步。通常都會有一種新的思考方式，一種新的方法或者主題去學習和應用，或者使用一種新的過程來使專案有效率並充滿樂趣。可能這種責任更類似於領導力而不是管理，但是這兩者並沒有太大的區別。無論你多努力的區別它們，事實告訴我們二者是密不可分的，好的管理需要領導力，而好的領導力同時也需要好的管理。任何參與到專案管理中的人都有責任二者兼顧。
讓我們回到壓力的主題上，我曾經看到許多經理刻意迴避那些能夠展現領導力的時刻（例如，團隊/專案需要做出果斷決定的時候），並且這些經理只是跟隨其他人而不是推動或者參與其中。如果所有人都駐足旁觀的話，那麼他們更適合於工作在審計部門。當扮演領導角色的人總是逃避壓力的時候，他就是不是在領導而是在隱藏自己。效率低下或者抗壓能力弱的專案經理往往隱匿在專案的外圍，對專案沒有太大的價值。
1.6.1
. 混淆過程與目標
許多專案經理在這種情況下常常去確定那些不需要去確定的事情。如果這些經理不能確定要做什麼，或者害怕去做那些最需要做的事情，那麼就過就是把大量的時間浪費在了那些次要的事情上。隨著專案和經理之間的間隙越來越大，花費在圖表、**、清單以及報告上的時間會越來越多。在某些方面專案經理開始相信資料和過程就是專案。他們會把精力集中在那些相對容易但卻但卻不太重要的事情上（資料表和報告），而不是那些重要的富於挑戰的事情上面（程式效果或者進度）。他們可能會逐漸相信如果他們只要遵循標準的程式並且能夠控制那些列舉在清單上的事情，專案就會確保成功（更可笑的是，任何可能發生的失敗在技術上都不是他們的錯）。
為了最低程度的減少混淆的可能性，好的專案經理能夠對那些他們願意做的事情和不願意做的事情劃分出嚴格的邊界。他們會避免跨越專案管理和專案本身之間的黃線。完全按照清單辦事只能表示一種確定的過程能產生一種特定的結果，但是這從來都不是重點。實際上，專案中只存在三件事情：乙個目標，一堆工作以及一群人。明確的角色（見第9章）能夠對組織人們的工作很有幫助，但是定義這些角色卻不是我們的目的。清單也會幫助那些人來完成目標，但是清單也不是我們的目標。混淆過程和目標是管理過程中的最大的錯誤之一。我很了解這種錯誤，因為我曾經也做過這樣的事情。
幾年前，我是ie4.0專案的專案經理，主要負責大部分使用者介面的設計。我感到了很大的壓力：因為那是我從未做過的重大任務。我當時的本能反應是，如果我把所有事情都寫在清單上，那麼我就不會失敗。然而當專案中的某些事情確實需要追蹤的時候，我發現自己已經偏離了正確的方向。我建立乙個精細的資料表來展現不同的資料檢視，並且在我的辦公室裡豎起了沾滿**和清單的白板（其他的白板擺放在走廊上）。
我的老闆允許我這樣做是因為當時所有的事情都執行的很好。直到我的團隊得到了乙個大紅叉（警告），我的老闆發現我花費越來越多的時間在我的清單上而不是和我的團隊在一起。有一天他走進我的辦公室，看見我寫的那些滑稽的清單和**，他關上門讓對我說：「斯科特，這些材料很好，但是你的專案其實就是你的團隊，你應該管理你的團隊而不是這些清單。如果這些清單能夠對你管理團隊有所幫助的話，那很好。但是如果你繼續這樣的工作方式的話，不久你就會需要你的團隊來幫你來管理這些清單了。」
這些我們將在第10章來討論，一本書的內容或某個經理所講過的話，或者上個月甚至去年應用的技術，它們在今天並不一定適用。每個團隊和專案都是不同的，對於那些陳舊的判斷我們應該保持一種懷疑的態度。正如佛瑞德在《人月神話》中所說的，應該對各種方法和過程持保守的態度，而不是讓那些不必要的方法像雪球一樣把專案毀掉。當需要用一些過程去管理另外一些過程時，很難區分什麼是真正需要做的工作。很多時候是團隊領導者或者專案經理給團隊帶來那種官僚的作風，更可笑的是，也正是他們把團隊帶到了無休止的迴圈當中。
translated by geng
汽車電子 消費類電子的壓力和困惑
一位朋友想讓我幫忙，將他的產品換個方案，使得產品的bom單成本降低一塊錢。單板外圍電路已經沒有下降的控制項了，1片電源ic，1片cpu，i片phy，那麼能動刀只有cpu了，實際上現在用的cpu只有8塊錢而已，還帶can匯流排，天呀。我一直是做動環監控的，對10塊錢以下的cpu都嗤之以鼻，而我朋友希望...
規範和壓力
這兩天因為要呼叫另外乙個專案組的webservice,去讀了他們的實現。不讀罷了,一讀發現一堆問題 svn check in沒有注釋 引數沒有檢查 呼叫函式的返回值沒有檢查 邏輯錯誤 很驚訝.因為專案經理是我挖過來的,對他的能力我有信心,有他帶著不至於出現這種低階錯誤.於是和專案經理溝通,指出這些問...
壓力測試和負載測試
一 基本概念理解 壓力測試 在一定的負荷條件下，長時間連續執行系統給系統效能造成的影響。負載測試 在一定的工作負荷下，給系統造成的負荷及系統響應的時間。壓力測試 stresstest 和負載測試 loadtest 的區別 1 可以看出壓力測試有個長時間執行，而負載測試負載型別可能是其他型別的。2 壓...