軟件開發(fā)在追蹤上的難題
一般在企業(yè)內部要開始一個軟件開發(fā)的項目有很多時候是老板忽然靈機一動地問說：“我們來開發(fā)一個某某軟件墓阀，你覺得需要多久媳友？” 有經驗的人聽到這個問題時就知道這是考驗專業(yè)能力與職場敏感度的時刻圣猎，因為這是一個兩難的問題看峻。在好傻好天真的時期會想：“天案仓隆！軟件要做到什么程度蚌本、有多少人參與、要給多少資源都還沒確定隘梨，就要押完成日程癌？” 會有這樣的想法不意外，就像是要蓋一個房子轴猎，連要蓋幾層都不確定嵌莉、設計圖都還沒畫，更別提建材和工人都還沒有著落的情況下就要問何時入住税稼，回答得出來才有鬼烦秩！
但在老板面前為了展現專業(yè)與工作經驗、彰顯自己存在的價值郎仆，那就只好照之前類似軟件開發(fā)的經驗抓個時程只祠，再加上安全緩沖的時間做為答案。只是對于這種答案老板大多第一個反射的回答是：“怎么會要這么久扰肌？不能在某月某日前上線嗎抛寝？” 哇！專業(yè)的光環(huán)當場缺角曙旭，于是就要開始搬出一大堆的說詞來證明自己不是漫天要價盗舰，同時心里咒罵著：“是你說要給個時間的，倒底是真心地想要征詢專業(yè)意見桂躏？還是要猜你心里的理想日期钻趋？”
打滾了一陣子，不再好傻好天真后被問到同樣的問題剂习，開始學會先用感覺抓出時程再打個折當做答案蛮位。只不過一旦日期落入老板的理想日期或更早，老板則是會見獵心喜地說：“這個日期是你自己說的哦鳞绕，那就照這樣訂了失仁！” 結果就是挖了一個大坑并且自己往下跳！所以吃過虧的人才會知道老板這簡單的問句是一個深奧又富含職場哲理的問題们何，而最后還得因五斗米而折腰萄焦，為了要討好老板明知是陷阱也得含淚跳下去。
剛才的情境還只是前菜冤竹，等到軟件開始建構了拂封，老板就改成三不五時來問說：“目前進度如何茬射？” 又是一個容易動輒得咎的問題，因為老板其實想要問的是：“何時可以上線烘苹？有沒有可能提早躲株？” 不要說軟件開發(fā)項目是個保證會延期的項目類型了，就連很多的大型工程項目不也是一延再延镣衡？但這卻是個眾所皆知而不能說的秘密霜定！“不知道”更是絕對不能被接受的答案，所以要如何“知道”是一個管理上很重要的課題廊鸥。畢竟就算老板不問望浩，身為管理者心理也要有個譜，才不會事到臨頭了才驚覺大事不妙惰说。
想要掌握軟件開發(fā)項目的進度磨德，有一個前提非常重要，其實不只是軟件開發(fā)項目吆视，任何的項目都是典挑。有接觸過 PMP (Project Management Professional) 的人應該都知道，所謂的監(jiān)控已經是整個項目管理過程中比較后期的工作流程啦吧。在進入到監(jiān)控之前要先進行規(guī)劃您觉、安排，最基本的得要先設定好項目的 Scope授滓，不然就像一開始說的連要蓋幾層樓都不清楚琳水，跟瞎子摸象一般，就算知道現在蓋好了多少層也無法確定何時可以入住般堆。
在東在孝、西方文化的差異下，西方比較講求按部就班淮摔，東方文化就偏重實事求是私沮，所以像 PMP 這樣的知識體系大多都是來自于西方，而要將這樣的管理精神套用在我們的工作環(huán)境之中也很容易迫于氛圍只剩下半套和橙。所以在軟件開發(fā)項目通常就只會有執(zhí)行及監(jiān)控這種有產值的流程出現仔燕，Scope？是啥胃碾？能吃嗎？想當然爾筋搏，開發(fā)的工作都只能在有個大概輪廓的狀態(tài)下進行仆百，細節(jié)的部份則是邊做邊確認，想要掌握進度更是如同霧里看花奔脐。
這是最糟的情況嗎俄周？不是吁讨！經常變動才是開發(fā)工作上的大挑戰(zhàn)，絕大部份的軟件開發(fā)項目不太可能會有需求凍結這種事峦朗。就像房子蓋好了底下的二建丧、三層，老板看了覺得似乎加個幾層會更好波势，金口一開瞬間四層就變八層翎朱。但八層的房子要設計的耐重和四層樓明顯地不一樣，在趕工的情況下大多是設計得夠用就好尺铣，一旦要加樓層整個結構拴曲、甚至地基都要打掉重來。但如果要拿房子的例子和老板解釋這樣變動帶來的沖擊凛忿，老板才沒空聽你扯什么房子的問題澈灼，又不是要你弄得臟兮兮、揮汗如雨的店溢，不是只要坐在電腦前面打打字叁熔、剪剪貼貼就可以收工了，能花多少時間床牧？這種情況之下怎么可能會有準確的進度資訊荣回？
在管理軟件開發(fā)項目上還有另一個棘手的問題，如果真的是照著 PMP 的規(guī)范走叠赦，這類型的項目要界定所謂的 Scope驹马，大致上就是在進行需求分析的工作，或許還夾雜著一部份的系統(tǒng)分析在其中除秀。就整個軟件開發(fā)的流程來看糯累，這部份的工作所占的比重并不低，甚至有很多規(guī)模不大的系統(tǒng)在分析完之后就沒剩多少工作項目册踩，如此說來理論上這部份應該也要被列入追蹤的范圍內泳姐。這時就會形成了一個雞生蛋、蛋生雞的矛盾情境：這些工作就是要弄清楚開發(fā)的范圍暂吉，如果要把這些工作列入管理但范圍還沒有確定胖秒，所以得先完成這些工作... 結論就是想要順利完成一個軟件開發(fā)項目，就只能盡人事聽天命了慕的！
時程估算的準確度
好吧阎肝，關關難過、關關過肮街，排除萬難把工作項目都開出來风题，甚至搞了一整個 WBS 就一切順利嗎？軟件開發(fā)的工作特性與一般的項目最大的不同是不確定性很高，每一個工作項目都像拓荒一樣是一種從無到有新的經驗沛硅。因為每次都是要把不同的工作知識轉換成可運作的源代碼眼刃，程序要怎么寫和數據的特性有很大的關連。再以蓋房子做比喻摇肌，開發(fā)不同的軟件并不像是重復地蓋磚墻的房子般擂红，因為同樣都是砌磚的施工手法，經驗是確定的围小。比較像是每次蓋房子時使用的是新建材昵骤，所以在蓋的同時都要不斷地摸索建材施作的特性，而很容易出現技術上的瓶頸吩抓。
每一個開發(fā)人員的素質不同涉茧，需要摸索的時間就會不一樣，再加上遇到技術瓶頸時解決問題能力的高低疹娶，不太可能套用一致性的法則伴栓，這也增加時程上的變數、直接牽動著工作進度的快慢雨饺。所以要估算軟件開發(fā)的工時是一項復雜度钳垮、不確定性都很高的工作。軟件工程里有提到一些艱深難懂的估算公式额港，但通常需要取得很多的參數饺窿，老實說一點都不實用、在實作上也沒有太大的意義移斩，因為算出來也不保證百分之一百精確肚医。
那倒底要怎么估才好？這個嘛... 站在技術人員的立場真心地覺得不要估最好向瓷，估了也只是求心安的肠套，就像生小孩的預產期一樣，源代碼時候到了自然就會生出來猖任，催也沒用你稚，押了日期沒寫完還不是得延，何苦來哉爸焯伞刁赖！但是這種說法大概也只有寫過程序的苦主才能夠認同，有時候還滿羨慕所謂的藝術家长搀，同樣是不確定性很高的工作宇弛，大家都可以認同創(chuàng)作需要時間也不用給時間表，但明明程序的用途是比藝術家的成果還具有實用價值源请，大家卻選擇盛贊藝術家然后壓榨工程師枪芒。
至于怎么估轿钠，基本的原則是：如果想要精確一點，當然工作項目單位愈小愈好病苗。要估算一個函式多久可以完成，一定是比估算一整個軟件的時程來得貼近現況症汹，但相對的要花的時間也比較多硫朦。同時有能力切到以函式為單位做工作項目，剩下要做的事打概也只有打字背镇，每個工作項目得到的數字也許都是以分鐘為單位咬展。這樣的管理方式真的有意義嗎？老板會希望等了大半年后才知道接下來的工作只要二周的時間嗎瞒斩？所以不是說了破婆，不要估最好！
Burndown Chart 在管理上的問題
只不過胸囱，怎么估并不是這篇文章的重點祷舀，這篇文章主要是想說明怎么追蹤。面對這類型的問題烹笔，業(yè)界還是有發(fā)展出一些簡單的方法裳扯，有聽過、參與過 Scurm 的人應該會想到 Burndown Chart谤职。這是一個好工具饰豺、簡單明了，可以很快速地讓所有項目參與的人或是有利益相關的人了解目前項目的狀態(tài)允蜈，不管懂不懂 Scurm冤吨。基本上在制作 Burndown Chart 的時候饶套，不見得要把每一項工作都精算出對應的工時漩蟆，只要評估好工作項目的規(guī)模大小，以 Story Point 的相對數值來表達即可凤跑，這會大幅地減少計算工時所需投入的成本爆安。
Burndown Chart 是用還剩下多少工作做為基準，在團隊工作產值沒有大變化的情況下仔引，繪制出一條由 Y 軸某一點出發(fā)向下延伸的斜線一直到和 X 軸交會扔仓，交會的點即為完工的日期。在現實中當然不可能會有這么理想的情況咖耘，所以實際的曲線應該是呈現鋸齒狀并且和那條理想的斜線交纏著翘簇，項目人員借此來判斷是否能及時在指定的日期前完成工作。
凡事有利就有弊儿倒，Burndown Chart 的呈現比較偏向項目或團隊整體的資訊版保。在遇到進度不如預期的時候呜笑，不太容易從 Burndown Chart 中界定問題的責任歸屬。當然會來從事開發(fā)工作的人絕大部份都是單純彻犁、善良的叫胁，在跟團隊成員討論進度時把圖表亮出來，該誰需要改進的都自己心理有數并且能夠負起責任汞幢。但總會遇到少數幾個刁鉆又具有心機的人驼鹅，這時通常會需要有個明確的數據來讓管理上的對應措施有個底。尤其是身為上頭還有高層森篷、被夾在中間的管理者输钩，當情況開始失去掌握時，也可做為向上尋求協(xié)助的其中一項依據仲智。否則一旦讓不好的行為在團隊中引起破窗效應买乃、對工作氛圍造成影響，所產生的后果就會變得很難收拾钓辆。
除此之外剪验，在一般企業(yè)里大多都是數個開發(fā)案同時進行，團隊中可能根本就沒有一個人是專職在自己手上的項目里前联，同一個開發(fā)人員會需要負責多個系統(tǒng)碉咆，有時還要再加上既有的系統(tǒng)維護。在有的軟件要開發(fā)新的功能蛀恩、有的軟件要進行維護疫铜、有的軟件要除錯的情況之下，如果只針對單一個開發(fā)項目來看双谆，同一位工程師的產值可能就會有大有小壳咕，不太可能維持一定的量。就算有心想要幫開發(fā)人員排除時程上不利的因素顽馋、保持產值的穩(wěn)定谓厘，勢必要考量到各系統(tǒng)在上頭的重視程度、使用對象的重要性寸谜、時程的緊迫程度竟稳，更麻煩的是會牽涉到各系統(tǒng)負責人之間搶人的政治角力，結果不如預期乃是兵家常事熊痴。排除不了他爸，進度的延遲就成了開發(fā)人員的非戰(zhàn)之罪，管理者就沒有立場去做苛責果善，畢竟這是管理者的責任诊笤。只是如果像之前提到的，成員中出現少數不屬于善良的那一種類型巾陕，利用游走各系統(tǒng)來掩飾進度問題讨跟，以 Burndown Chart 所提供的資訊在管理上也是無從判別的纪他。
使用 EVM 追蹤進度
能夠身處在教科書的理想環(huán)境與團隊的組合中做管理畢竟是可遇而不可求，面對這種現實的情況還是要有一套有效的管理方式晾匠，在 PMP 中有提供一個進度追蹤的方法叫 EVM (Earned Value Management) 可以提供一些輔助茶袒。但在這篇文章里使用的是簡化過的 EVM，主要是取幾個 EVM 中提到的數據來做為管理上的參考凉馆。用最白話的方式來說明 EVM 就是用預期要投入多少成本做為基準弹谁，比較實際獲得的價值與目前預計進度、累計投入的成本間的差異句喜。其中目前預計進度為 Planed Value 簡稱 PV、目前累計投入的成本為 Actual Cost 簡稱 AC沟于、與實際獲得的價值為 Earned Value 簡稱 EV咳胃。
舉個例子來說，假設今天有一個項目要鋪設一條一百公尺的道路旷太，工程預計進行五天展懈，總投入的金額預估是十萬元，相當于這條道路完工之后價值十萬元供璧。平均來看每一天照計劃完成工作應獲得相當于二萬元的價值存崖，或者每完成一公尺就會產生一千元的價值。當工程進行到第三天睡毒，如果完成超過六十公尺代表進度超前来惧、反之則為進度落后。這時如果完成六十公尺的道路但投入的金額少于六萬代表績效超前演顾、反之則為績效落后供搀。
套用在軟件開發(fā)項目上，由于在軟件開發(fā)的項目中很多時候不太容易計算出完成的功能值多少錢钠至、每一行的源代碼代表多少錢葛虐，對企業(yè)內部的軟件來說更是如此。所以在這里就可以用一小時來代表一塊錢棉钧，看幣值是要設定成一人民幣屿脐、一美元、一歐元還是一個單位的比特幣宪卿，總之就是一單位金錢的價值的诵，而先前的計算模式可以改為以時間單位來統(tǒng)計數據。
所以在實作軟件開發(fā)項目的 EVM 時佑钾，假設一個功能預計投入 40 個小時奢驯、在五天之內完成。當開發(fā)工作進行到第三天時次绘，如果完成進度大于 60% 則代表進度超前瘪阁、反之則為進度落后撒遣。而當完成的進度是 60% 但投入的時數小于 24 小時代表績效超前，反之則為績效落后管跺。這里用百分比來做為統(tǒng)計 EV 的模式是在經驗法則上所得出比較直覺义黎、一致、符合人性的做法豁跑，回報進度的人不需要了解什么是 EVM廉涕，只要記錄今天花多少時間開發(fā)、完成多少百分比。而百分比則可以依照預計要完成多少源代碼点楼、區(qū)塊雾棺、函式、功能等等的基準來和完成的部份比對以估計進度的百分比层释，在這樣的評估方法之下成員之間不太容易有很大的差異出現，獲得的進度數據比較平均快集、比較成員間進度差異時會比較客觀贡羔。
在上述的數值中，PV 是累計到目前為止預計投入的時數个初、AC 則為累計到目前為止已經投入的時數乖寒、EV 則是 PV 的總數乘上進度的百分比。為什么 PV 是用預計投入的時數加總院溺，而不是和 EV 一樣使用百分比是有原因的楣嘁。之前提到過每一個成員產值在單一的項目中不見得是個定值，礙于現實珍逸，在進行時程排定作業(yè)時有可能這個成員今天只搶到三小時马澈、明天五小時，所以每天排定的預計投入時數都不一樣弄息，如此使用百分比這種平均法來計算會和實際的情況有落差痊班。
使用 EVM 在管理上的重點
有人可能會想問如果成員浮報進度資訊有辦法即時發(fā)覺嗎？的確摹量，也許是文化使然涤伐，總是會有一些人喜歡便宜行事。像是會覺得評估進度百分比很麻煩缨称，所以固定在工作一開始就只設定一個固定的進度值凝果，例如：50% 或 30%，等工作完成后再回報為 100%睦尽∑骶唬或者是有好大喜功的心態(tài)，所有開始進行的工作都設定為 100%当凡。這時可以由 EV 值的變化中發(fā)現山害，此時一開始 EV 數值會先出現不合理的拉高纠俭，但接下來卻一直沒有變化。而另外一種常見的情況是投入時數漏報浪慌、浮報冤荆，這種情況可以由 AC 與 PV 的差距異常地大來判別。最難察覺的是回報的數據是在配合計算規(guī)則下所“設計”出來的权纤，這時數據會呈現夢幻般完美的狀態(tài)钓简，稍一不注意則可能要到截止日才發(fā)現進度不如預期，不過這時有配合 Code Review 還是可以看出一些端倪汹想。
這套收集數據的模式有一個優(yōu)點是每一個工作項目可以是獨立的觀察基準外邓，也可以依據情境將不同的工作項目集中觀察」盘停可以是以整個項目為集中的單位损话、可以是以 Product Backlog 為集中的單位、可以是以 Sprint Backlog 為集中的單位冗茸、也可以是以某一個開發(fā)人員所負責的工作為集中的單位。尤其是最后一項觀察基準匹中，對于角色是屬于 Functional Manager 的人來說是一個很好用的工具夏漱。在以人為單位所產出的 EVM 資訊可以獲得二項重要的情報，一是透過時程安排的情況來了解在多重項目交互之下是否有負荷超載的情況顶捷，并且可以精細到每一天挂绰。第二項情報是在將清單中所有工作項目數據合并之后，可以得到單一開發(fā)人員的綜合進度數據服赎，同時不會因為實際執(zhí)行工作的順序與 PV 設定不同而有差異葵蒂。可以有效地降低項目之間的界線重虑，避免因項目間資訊不通透而無法反映個人進度上的問題践付。
同樣的優(yōu)點也可以展現在以項目為單位的觀察基準，在進行開發(fā)項目時缺厉，很多時候是多個工作項目同時開始永高，而開發(fā)人員并不需要受限于原本設定好的工作執(zhí)行順序，只要依照實際工作的情況回報數據即可提针。假設原本排定 B 工作要接在 A 工作之后才開始命爬，而今天上工后同時進行 A、B 二項工作一共花了六小時辐脖。此時饲宛，進度百分比可以明確地分別依工作項目產出的狀態(tài)計算出來，不會有什么問題嗜价。而投入的時數則可以視情況艇抠，如果有精確到記錄每一項工作投入的時間最好幕庐，如果沒有，都合并記錄在特定一項工作項目也行练链。在這樣的情況下翔脱，也許單一的工作項目在數據上會呈現失真的狀態(tài)，但拉高層次來看時卻不會有差別媒鼓，因為數字加總過后會消弭掉工作項目之間的界線届吁。
如果要硬性要求開發(fā)人員必須照著設定好的工作執(zhí)行順序按步就班完成工作，最大的問題是可能會造成開發(fā)的工作無法進行绿鸣，或是要花更多的時間在來回修正工作項目間不同步的源代碼疚沐。如此一來，在回報數據上也許不會有項目歸屬的爭議潮模，但卻阻礙了開發(fā)工作且失去了管理的意義亮蛔。所以這個手法在實作時其實沒有必要執(zhí)著在 PV 的設定結果，這只是一個收集數據的參考基準擎厢，重點應放在投入的時數與完成的進度究流。
這套方法還有另一個彈性是在需求有異動、要調整某一項工作項目的預估投入時數時动遭，也只要在適合的時間點補上差異的時數即可芬探，不用特意重新調整過去 PV 的狀態(tài)，也不會影響成員回報的模式厘惦，所統(tǒng)計到的數據可以在過去的資訊基礎上持續(xù)地演進偷仿。時程會不斷的變化就讓他變化吧，反正重點是要隨時掌握目前的進度情況宵蕉。
當然酝静，天下沒有白吃的午餐，這套追蹤的方法可以比 Burndown Chart 提供更多的資訊羡玛，是因為在輸入數據時要投入更多的功夫别智。如果想要以天為觀察的單位，在安排時程的時候就必須要為每一天設定好 PV 值稼稿，相對地在情況有變動時數據的調整工作也會變得比較繁瑣亿遂。用拉大時間間距的方式，改為以周渺杉、月為單位雖然可以有效減少數據維護的頻率蛇数，同時也會降低數據反映問題的敏感度，這取決于每個團隊的管理需求是越。
把 EVM 的信息視覺化
只是盯著數字看可能還不夠直觀耳舅，依據 EVM 的公式可以得到二項數據 SPI 及 CPI，分別是 EV 與 PV 及 EV 與 AC 的比值，把 SPI 與 CPI 做成圖表就如同以下所示：
圖上所示范的曲線代表不同時間點數據的位置所連接起來的結果浦徊，紅色星形為最早的時間點馏予。圖中兩軸交會的點并不是原點，而是座標 (1, 1)盔性，或許可以稱為理想點吧霞丧！原點在圖上左下角的位置。這樣繪制的原因是因為 SPI 及 CPI 都是二個數值的相除結果冕香，大于一代表超出預期蛹尝，小于一代表不如預期。所以當二個數值所形成的座標落在圖上兩軸交會處悉尾，代表目前投入的工時與產值是符合原本規(guī)劃的時程突那，也就是說理想化的情況之下所有的點應該都集中在同一點，不過理想歸理想构眯，如果一切都這么完美就不需要管理人員了愕难。
透過這二個數據呈現的圖形可以直觀地了解目前項目進度的狀態(tài)、并隨著時間的演進呈現出進度的趨勢惫霸，范例的圖上四個象限都分別用文字標示出所代表的意義猫缭。SPI 是用來看已完成的進度有沒有依照計劃進行，如果小于一會落在 Y 軸的左方壹店、大于一則是會出現在 Y 軸的右方猜丹。CPI 是用來代表投入的時數是否有獲得對等的價值，如果小于一會落在 X 軸的下方茫打、大于一則是會出現在 X 軸的上方居触。最接近理想的情況應該是像上圖所示范的妖混，所有的落點都繞著理想點打轉老赤。
所以當點都落在第一象限上就是值得欣慰，而落在第三象限上就是待改進嗎制市？其實并不盡然抬旺，會影響 SPI 與 CPI 的數值不單單只有人的產值，PV 值估算的精確程度祥楣、投入工時的方式都有很大的影響开财。比如說，SPI 大于一有可能是因為 PV 值在估算時過于寬松误褪，原本二個小時的工作估到四小時责鳍，所以照計劃投入了一小時反而得到了四小時一半也就是二小時的價值∈藜洌或者也有可能是人員爆肝历葛、加班趕工所換來的假象，而類似的情況也會反映在 CPI 的結果上嘀略。
透過這樣一個圖表在管理時要關注的問題恤溶，不外是觀察團隊中成員基本的個人工作效率與負載問題乓诽、是不是遇到技術瓶頸以致進度遲滯不前、還是因外在或個人的因素導致工作無法順利開展咒程。在使用這個圖表進行管理時鸠天，不用太在意點所落下的位置，應該要像 Burndown Chart 的概念一般帐姻，只要確認有維持產值的穩(wěn)定就是一個可以接受的情況稠集。就如同打靶時所形成的彈著點，彈著點的集中度要比有多少顆落在中心區(qū)域要來得重要卖宠。彈著點集中代表射手是穩(wěn)定的巍杈，很有可能只是槍枝沒有進行歸零，反之則是各種因素都有可能扛伍，反而不容易進行調校筷畦。同時還要透過每一個點之間的關系來觀察移動的趨勢，如果開始朝著第一象限以外的區(qū)域移就應考慮著手找出原因并改善刺洒。所以當所有的點都落在第三象限時鳖宾，不一定是表示目前進度的情況很糟，如果能讓后續(xù)落下的點不會一直朝著原點的方向移動逆航，就可以預測得出系統(tǒng)完成的日期鼎文，但日期是不是符合老板的期望就又是另外一件事了。
避免落入管理上的盲點
誠然因俐，判讀圖表的方法很重要拇惋，如何判讀圖表卻不是一個絕對值。所謂的管理是要找到一抹剩、二個合用的工具撑帖，并且在心中設定一把尺為做為使用工具時的衡量準則，這個準則是要依據現況來做調整澳眷。因為每一個項目都是獨特的胡嘿，項目外在的因素、團隊的成員钳踊、工作時的氣氛衷敌，都不會有一模一樣的情況出現。教科書上的理論永遠不可能完美地實現在工作的場合里拓瞪，硬是要把理論套用在管理上有的時候只會適得其反缴罗。
像是如果拿著上面 EVM 的圖表當令箭，強制一定要讓回報的數據所形成的點都落在之前說的理想點上祭埂，可以想見團隊在工作時的感覺一定是非常的斯巴達面氓，最后搞得成員怨聲載道，而管理的人也會因為緊迫盯人變得工作量大增，結果是讓所有人都工作得不開心侧但。
管理的情況就像全職獵人漫畫中矢空，杰在貪婪之島中為了要得到一坪的海岸線與關主磊札用排球對打的時想出來的接球組合：
中間的奇犽是管理階層，夾在老板 (杰) 與團隊 (西索) 之間禀横，老板要負責承接來自外界的壓力并創(chuàng)造機會屁药，團隊則要負責把握住機會。管理者看起來沒做什么柏锄，但其實位在最關鍵的位置酿箭，在中間的管理者要如何分配力道、協(xié)調二邊趾娃，只有站在中間的人才最清楚缭嫡，也是管理者展現修為的時刻。在面對情況要怎么因應是管理者必須審慎以對的抬闷，一旦稍有差池就有可能像漫畫劇情中所敘妇蛀，整個團隊會因受到外力沖擊而潰散。
結語
所以笤成，每一個人在面對管理上的情況要如何拿捏评架，還真得沒有人能夠說得準。因為處理的結果好與壞炕泳，在現實中就是結果論纵诞，成王敗寇沒什么好說的。在這篇文章中培遵，只是把個人過去的工作心得整理出來浙芙，讓大家做個參考，也許可以對同樣是管理者的人有所啟發(fā)籽腕，找到適合自己的工具嗡呼、建立起心中的那把尺。
