|
|
您現在的位置 > 新聞動態
企業如何保證研發數控卷板機項目的可控性 |
| 發布時間：2019/9/16 |
一般所說的數控卷板機項目可控性，是指針對數控卷板機項目啟動后，保證數控卷板機項目進度可控、質量可控和風險可控。數控卷板機項目進度可控，是指數控卷板機項目開發實施中能按數控卷板機項目計劃進行，在客觀條件不變的情況下，合理調配資源、優化工作流程，數控卷板機項目可以較好按計劃進行，允許數控卷板機項目在小階段內具有一定的靈活性(比如小的超前和落后)，保證數控卷板機項目整體進度平穩進行。數控卷板機項目質量可控，是指數控卷板機項目進行的每個小階段，質量都能得到有效控制，時時進行檢查和監督，發現問題就及時解決，以便保證數控卷板機項目整體質量較好發展。數控卷板機項目風險可控，是指要能預測到數控卷板機項目可能會出現的風險，并能對可能出現的風險提供多種解決辦法。如人力資源方面，如果有人離隊，這時要能及時補充和調配，或在適當安排加班；物質資源出現短缺時，能在最短時間里尋求到資源等。
本章所說的“研發可控性”，指的是更細節的內容，是如何在日常工作中通過把控最常發生的事情而保證數控卷板機項目的進度、質量和風險可控。比如，數控卷板機項目會議是數控卷板機項目中幾乎每天都要發生的，會議的內容可能與數控卷板機項目進度、數控卷板機項目質量或數控卷板機項目風險都有關；再比如，數控卷板機項目某些事項的具體負責(分配)和追蹤是數控卷板機項目中幾乎每天都要發生的，而這些事項可能涉及數控卷板機項目進度、數控卷板機項目質量或數控卷板機項目風險等多個層次的內容。通過把握這些數控卷板機項目中的瑣碎環節而保證數控卷板機項目的進度、質量和風險可控，從而保證這個研發過程的可控性。
1、研發中的“化"與“合"
這里所說的“化”與“合”，是指將研發工作“拆解”與“合并”的過程。“拆解”指的是將較大的研發功能模塊拆解為適合一個開發人員2-3天能夠完成的工作包，這與我們在前述章節說的“碎石”是一個意思，只不過這里的“碎石”不是針對用戶故事的，針對的是開發工作包?！昂喜指的是將功能進行集成、將各個開發人員開發的工作包集成在一起直至實現整個產品的過程。
“拆解”，即將可交付成果細分為更小的、易于管理的工作包，通過拆解讓原本復雜的數控卷板機項目可以簡化、工程師的工作可以聚焦、有利于厘清開發內容和估算人力成本。不論是多大的數控卷板機項目，都要有一套很好的細部分解動作與產品的參考指南。這套參考指南其實就是所謂的工作分解結構(№rk Breakd。wn Structure，WBS 0維基百科(Wikipedia)對于WBS的解釋是：WBS是一種樹狀結構，提供了一套共通的框架、標準，顯示為了達成計劃、數控卷板機項目或合約目標所要付出的努力。美國數控卷板機項目管理協會(PMI)的《數控卷板機項目管理知識體系指南》(PMB。K Guide)對于WBS的定義則是：WBS是數控卷板機項目管理的基礎，針對數控卷板機項目的“可交付成果”拆解成更小、更易于管理分解結構的過程。從上述兩種對媳S的說明可以看出：惦S是一種對數控卷板機項目過程的拆解，是一套框架、是數控卷板機項目的基礎，最終必須產生一個“可交付成果”的拆解方式。
WBS把那種條列式界定的數控卷板機項目范圍，透過拆解、解構的方式展現出來，以一種階層式的架構呈現。 WBS可以使用列表式、組織結構、魚骨圖等方式呈現，使用逐漸普遍的心警圈工具(Mind MaP)，也可以用來拆解WBS。常用的工作分解結構主要形式有如下兩種。
(1)樹形結構圖，如下圖所示。
樹形結構圖的優點是：層次清晰、直觀、結構性強。缺點是：不容易被修改。適用范圍：中小型數控卷板機項目。
表形式的優點是：便于反映所有的工作要素。缺點是：直觀性差。適用范圍大型數控卷板機項目。
其實，拆解wBS并沒有硬性規定的形式，階層式、大綱條列式、組織圖、魚骨圖、心智圖等形式都可以。只要能夠順利將復雜的工作數控卷板機項目轉化成簡單、容易掌握管理的工作內容即可，形式不重要。而且拆解WBS也不在乎用什么樣的工具，不見得要專業的數控卷板機項目管理軟件，甚至只要有筆及便利貼，就能完成。不同數控卷板機項目拆解WBS所分的層次也不一樣，這往往跟數控卷板機項目的規模大小與復雜度正相關。既然拆解wBS有這么多“不重要”的方面，那么什么才是重要的?或者說，拆解WBS的精髓是什么?
其實只有兩點是最重要的。第一，拆解WBS的第一要務就是，不論拆解對或錯，一定要先寫下來，才有進一步改善和修正的空間，沒有寫下來就形同虛設。落實WBS拆解最難的關鍵確是“寫下來”這個動作。尤其是越資深的數控卷板機項目經理往往負責更大的數控卷板機項目，但這些資深經理有時候卻會仗著經驗豐富，不愿意把WBS寫下來，這樣其實是給數控卷板機項目增加了計劃的混亂和遺漏重要環節的風險。
第二，WBS真正的精髓在于，在WBS中要體現“交什么”和“做什么”。即：WBS的頂層環節體現的是“要交什么東西”，WBS底層拆解體現的是“做什么事情，東西才做得出來”；“交什么”體現的是從三輥卷板機客戶角度來看，產品需求層面的東西，“做什么”體現的是從技術角度來看，數控卷板機項目交付范圍層面的東西；一個好的WBS會很好地銜接這兩個方面。
“合并”，即功能集成，一方面是指功能合并，使合并后的系統具備合并前各模塊的所有功能。另一方面是指功能互補，平時各自獨立工作的功能模塊，在發生某些觸發條件時，需要備功能模塊之間能夠協同工作，以提高整個系統對事件的處理能力，實現全局性的功能。
功能集成的頗利性取決于拆解時的準確性，如果拆解功能時沒有把功能之間的接口和約定規定好，那么可想而知集成起來的功能的可用性會怎樣。所以，我們要強調功能拆解時，對于不同功能模塊的“驗收標準”，“驗收標準”中就包含了對功毹模塊的接口規定、通信約定、性能規定等，這樣集成后的各個功甏模塊才能聯合工作起來。
功能集成后，系統整體的可用性和穩定性取決于架構設計的合理性，并依賴測試對問題的發現程度。如果架構設計不合理，功能修改所帶來的系統改動可能是非常大的工作量，而且任何小的修改都可能造成整個系統的不穩定。集成測試對應于發現功能集成中所產生的軟件缺陷，是把控功能模塊質量的重要一關。
2、防止開會“六無"現象
所謂“開會六無”現象，是指由于未掌握開會的技巧，而造成一些開會時的混亂：“會前無準備，會中無主題，會后無執行，與會無必要，時間無控制，發言無邊際”。這種只“溝”不“通”的現象是不是在很多場合似曾相識呢?
其實在一些公司里，的確很多會議組織召開得比較混亂，會議主題不清楚、會議議程沒有提前定、會議時間沒有把握、會議人員選擇不嚴謹等等，很多會議的召開都很浪費時間，很多人參加過一次會，會議開了兩個小時，也就亂了兩個小時，也就是白白浪費了兩個小時。
所以，尤其是作為數控卷板機項目的管理者，組織會議要做到：會而有議、議而有決、決而有行、行而有果，最大限度地提升會議效率。最基本的幾種開會的技巧有：提前確定主題、會議議程、會議時間；選擇合適的人參加會議；對于發言漫無邊際或拓展內容太多的，主持人要及時制止，或者對于拓展話題另外組織會議討論：過程中有人記錄：對于待辦的事項要有人負責、有時間節點；會后有人整理會議紀要，對會上決定的待辦事項列表要有人跟進和檢查。
3、多人負責其實是無人負責
我們經常講“匹夫有責”或者“人人有責”，但一般見到的結果是沒人負責，從來沒見過哪個“人人有責”的事情發生了失誤之后有人站出來承擔責任或者推到某個人身上并心甘情愿，這種“人人有責”的事情發生了失誤后往往是“法不責眾”，沒有人負責。
一般來講，責任和權力是成正比關系的，權力越大所擔負的責任越大，如果責任均等那么意味著權力也是均等的，權力均等就等于沒有權力。所以，“權”就意味著“特權”，既然存在就不可能人人均等；“責”就意味著“特責”，既然存在就不可能人人一樣。假如一只足球隊只要求人人有責而沒有規定隊長，即使人人都想負責，也無法踢好；沒有獨特責任和權力的一群人在一起就好像一起吃飯喝酒的朋友聚會，那只能稱為是“群體”而不是“團隊”?！耙粋€和尚提水吃，兩個和尚抬水吃，三個和尚沒水吃”也是這個道理，責和權相統一，權和力相聯系，有責無權難以盡責，有權無力無人作為。一個和尚提水吃，是因為提水做飯是他的責任，他有權決定這樣做，力就在于就他可以吃上水：兩個和尚抬水吃，是因為兩個和尚都有提水的責任，并且也有權自己決定這樣做，而力在于如果兩個人采取抬水的方法就可以減輕勞動的強度、吃到同樣份額的水；而三個和尚在一起，雖然責任都一樣。權力也一樣大。但力是不同的——因為如果有兩個和尚抬水，另一個和尚要么提水、要么就干脆不干，勞動強度明顯不一樣，卻可以同樣吃到等份額的水；在利益分配不公的情況下，要么大家就都回到起點(都去自己提自己的水)，要么就誰都不干，結果就是“三個和尚沒水吃”。
帶數控卷板機項目的過程中要注意這個問題，任何工作包的安排、調研課題的安排，盡量安排給一個人去做，人們對于“屬于”自己的東話十分在意，會有這種責任心作為驅動力讓他完成指派的工作。對于某個工作安排的責任人做這個事情的“權”其實在分配“責”的時候就確定了——他在做這個事情時如果遇到需要協調資源的問題，數控卷板機項目經理有義務去協助他；而他在做這個事情時的“力”至少包括獲得工作成果的認同。如果一個工作的完成涉及多人的配合，就需要指定主導者，這個主導者擔負責任的同時，也獲得了“權”——他可以針對指派的工作進行資源協調、匯報，其他配合的同事需要為其開綠燈，完成工作所獲得的“力”除了工作成就感之外，能力也得到了鍛煉、 KPI(Key Performance Indicator，關鍵績效指標)考核也會記上一筆。
4、防止技術人員偏離道路
大多數開發工程師喜歡“玩技術”，但不保證開發出來的東西是正確的，這在產品開發公司里并不是稀奇的事。很多開發工程師熱衷于學習新的東西，能學以致用更是技術方蠶的追求。但新技術總是帶來了一些不確定的風險：技術穩定性、第三方庫的支持、遘到問藏后需求解決的途徑及可查找資料、與其他人協同開發時的共同語言及交滾成本、楱塊集成時接口配食，這些技術風險都屬于數控卷板機項目風險的一部分，為了減少或規避這方面的風臉，數控卷板機項目經理囊把控這種現象。當然，阻止開發工程師對于某種新技術在數控卷板機項目中的應用總會使工程炳感到些許的不愉快，這種事情可以通過其他方法進行平衡，比如實現數控卷板機項目需要的功能同時，可以允許工程師花一部分時間對某種新技術進行調研，并且讓他給數控卷板機項目其他成員做知識分享，也算是工程師“學以致用”表達方式的一種吧。
防止技術人員偏離道路的另一個方面就是：不要相信過程爛得一塌糊涂的數控卷板機項目，曩后能交付好的卷板機產品。數控卷板機項目經理可能經常會昕到研發工程師說“這個可以放到后面來優化”，卻不是當時就優化；“這段代碼很不好，需要后面來修改”，卻不是現在修改：“先實現吧，再調整。，卻不是現在調整。結果，實現了一個月還是沒有去優化，后來功能勉強實囊了，就不愿意優化了；一方面功能做好了、經過了測試的東西大家都怕改出薪的問題，另一方爵實現了一個成形的東西后，工程師去推翻自己做好的東西的主觀意愿低；還有就是產品設計中的“破窗效應”導致大家對一個漏洞百出的東西根本就沒有提高其質量的意愿。最終，數控卷板機項目經理也基于工程師的抗拒情緒和數控卷板機項目時間的壓力兩妥協了j于是產品終于從開始做的時候“爛一點”到。爛一片”，徹底成了個不經綴。看”的爛產晶。所以，如果要做一個質量好的產品，從數控卷板機項目管控的角度說。一開始的設計和實現就要把好關，有小問題就要及時改(這個時候讓工程師做修改還是較容易的)，以免積弊成患。一個產品如果是好產品，那么從開始設計、到實現、到優化都是精妙的過程，而不是等到最后才發現很優秀；優化是錦上添花，而不是事后補救。
5、監督中間環節保證結果可控
我們如果把數控卷板機項目管理水平分為幾個層次，有一種劃分可以這樣：第一層次是最原始的管理，也就是差不多沒有管理或者自發的一些管理，數控卷板機項目經理本身是技術專家，帶著幾個研發工程師一起做產品，產品做完后就忙著去維護這個產品或開發新的產品，數控卷板機項目的質量把控、評審環節幾乎沒有。第二個層次是引入了相對比較科學的管理方法，比如目標管理、績效考評等，數控卷板機項目會在結項的時候做各種檢查、評審和最終歸檔，個人績效考評與數控卷板機項目交付掛鉤；但各種檢查和評審多數集中于數控卷板機項目結尾階段，收集這些數據為的是做績效考評和檢查數控卷板機項目是否達到了設定目標，對于中間過程的管控力度不夠口第三個層次是引入了比較完善的過程管理，數控卷板機項目之外有一些虛擬團隊例如“數控卷板機項目管理委員會”負責對數控卷板機項目做一些中問過程的管控。抓數控卷板機項目的關鍵過程指標，并對數控卷板機項目中存在的問題及時進行決策、處理和協助，從而通過對過程的管控實現對結果的可控。
只有過程是可以追求的，不抓過程是無法強求結果的。抵過程其實就是在抵結果，只抓結暴不瓠過程其實是一種賭博行為；好的過程一般也兢有好的結果，沒有好韻過程很難有好韻結果。抓過程就要有市場觀念，及時反饋用戶對產品的評價、及時根據市場數據對產品方案或策略徽調整、及時反饋競爭對手的新行動、及時把產品原型推向市場收集用戶需求；掇過程就要有時問觀念。耵緊時閣劐度，把握好時間節點。把工作安簿到月，明齲到周，盤點到日；抓過程就要有多環節的質量度量。對數控卷板機項目中每一個環節的質量做好檢查，比如文檔評審、代碼評審、靜態檢查、單元測試、集成測試、系統測試、回歸測試等，而不是只在驗收環節把關；抓過程就要有功能模塊之悶的接口和交付標準約定，而不是在功能集成時才發現前面的技術溝通不到位、開發工作浪費了時聞。
|
|
