實施項目--如何推進項目實施進度
周末的時候和一群驢友(22人)到蘇州小小自虐了一下，15公里短途穿越,路線規劃：靈巖山（走后山）-->大焦山（走非常規線） -->羊腸嶺（走小路）-->壽星嶺-->白馬澗-->花山-->鹿山-->皇冠山。雖說是短途，但還是有點小挑戰性的，步行7個半小時左右，回來一身的疲憊，不過很舒坦，非常喜歡這樣的運動
路途中遇到了一位神人，真的是佩服的五體投地，竟然搞了一輛山地自行車上去，差點就要跪地膜拜了. 下面言歸正傳，說正經事情！
一. 項目實施進度緩慢
在徒步的過程中，因為遇到了各種問題，山路叫難走，有人摔倒，有人沒有水等，從而導致后面預計進度比規劃的時候慢了很多。當然這只是一次活動而已，慢一點快一點無可厚非。我就在想在項目實施的過程中也出現了這樣的緩慢問題，到底如何去解決。也正是因為最近有兩個項目推進的進度實在太慢了，壓力山大所以出來自虐一下，希望放松一下自己。
最近在實施一個工廠的項目，項目周期已經非常長了，預計幾月份幾月份要完成，而具體的時間一次次推遲，現在貌似都沒有時間概念了。現在雙方差不多都疲軟了，進度非常的緩慢，這里總結一下相關的問題，可以供大家參考一下。
二. 銷售,技術,實施,客戶
在一個項目中基本會出現如上幾個角色，這也是一個項目中最基本的角色。但是根據公司的規模還有項目的大小會出現更多的角色，首先聲明我們這里是小公司，小團隊，問題有我都承認，團隊經驗不足我也承認，請不要一口否認這樣的模式，這樣的團隊很垃圾。任何公司團隊都是從小做起的，任何人，任何項目，任何團隊，任何企業都有問題，這里我們只討論為何出現這樣的問題，我們該怎么解決。
銷售: 先項目前期會給客戶“畫餅“,有水平的銷售這個畫的有滋有味，沒有本事的銷售那就是牛皮吹上天; 銷售本事一般都不懂技術，而且銷售人員一般為了拿下這個客戶都會有一點水分在這個里面，會有一些過多的承諾。如果和銷售人員接觸的多話應該可以體會出來，特別是技術人員，技術人員最怕過渡承諾，因為爽在你口，痛在我身！
技術：在一個以項目為主的公司里就是一個悲劇角色，在整場戲里面就是一個讓人無法理解卻又值得同情的人物，有問題要擔住，有獎勵只能默默埋頭。這也許是最普遍的一種現象，而且是有苦不能言，啞巴吃黃蓮之后還要往肚子吞的。看這篇文章的人應該都能夠體會，聲明一下我不是在貶低技術，因為我曾經也做過一個名技術人員。
實施：除去銷售外的一個面對客戶最多的角色，要負責的事情就是將開發完成的項目給客戶安裝實施好，并且能夠讓客戶正常使用，并且提供相應的使用培訓。我目前就是處于這種角色之中，這個角色是最能夠直接了解和分析客戶需求的一個人。同時負責收集和反饋問題給技術人員，并且協調好公司技術人員與客戶之間的問題溝通傳遞。
客戶：一個想罵他們千百遍的角色，當然這個是對于技術和實施來說的，甚至有時候有一種恨之入骨的角色。但是銷售非常喜歡這類角色，因為客戶能夠給他們更多的資源和機會，因為連帶的關系所以有時候技術和實施也不喜歡銷售。
三. 相互之間的矛盾和沖突
剛才簡單介紹了上面的四種角色，可能有些公司的角色劃分更加明細，這是我們團隊目前的一種角色劃分，再次說明我們是小團隊，團隊很不完善，也不成規模，我們是在實際的環境中討論問題。
銷售和客戶：銷售首先和客戶接洽，銷售會和客戶說我們公司會做什么，我們的產品有什么優勢，我們能夠給你們解決什么問題，我們能夠提供什么樣的服務(我們公司主要提供倉庫，生產等條碼解決方案)。客戶對此非常感興趣，決定要上什么項目，于是銷售和客戶一拍即合。在這個過程中銷售因為不懂技術，有時候會過度承諾給客戶一些需求，往往這個時候過度的要求在于其他公司看來也是一個難點，客戶也許正為這個為難，所以問題的癥結點扣準，那么你就能夠拿下客戶。銷售給客戶說我們能夠解決這個問題，客戶一定對此非常感興趣，但是這個時候往往會給技術留下一個坑，可能解決這個問題所花費的人力時間都超出想象。但是要說明的是，有時候會為了一種商業目的，往往會有這樣的一種銷售手段來提高銷售的成功率，這個也是無可厚非的，技術問題一般都是可以解決的，只是難易程度問題。
銷售的過渡承諾往往在項目還是沒有開始的時候就決定了后面的開發以及實施的難度，然后銷售人員為了簽單也不可避免的做一些承諾。我這里不是貶低或者抵制銷售的過渡承諾，相反還比較支持銷售有時候的適當承諾，從公司的整個的整體出發點來說這樣是沒有錯的，只不過需要承擔更多的風險和壓力，而這些壓力會實際體現在開發和實施人員的身上。為了讓項目良好的推進，在項目前期在適當的時間可以讓有資質和經驗的技術人員和銷售一起去了解項目的內容，而不是等到最后簽單之后才決定讓技術人員介入此事,這是保證項目推進的一個比較不錯的方式！
(1) 銷售人員在前期明確自己公司的整體實力，整體實力是:能夠做什么，做到什么程度有難度，完全不能完成
(2) 了解客戶的真實需求和目的,不是細節需求而且想解決一個什么問題。比如我要解決排產人工計劃的問題，要能夠使用軟件編輯計劃和調整計劃
(3) 銷售可以和技術在適當的時間同時去拜訪了解客戶問題，并且多做溝通
實施和客戶: 實施是在項目推進過程中直接和客戶接觸的，他能夠在項目推進的過程中及時的發現問題。但是項目實施有時候又是項目開發經理來擔任的，這是一個非常重要的過程，在很多時候我們一直在強調如何使用文檔管理項目的需求等等，客戶說話要算數，讓客戶明確自己的需求等等，無論我們使用何種方式來管理這個需求和確認需求，在開發的過程中總是新需求不斷的出現和需求的變更。往往項目延期我們都會認為項目是因為不斷的有新需求和需求變更導致項目無法把控，當然我承認事實是如此，難道我們就無法減少這種不可控的因素么？
項目實施的過程中就要不斷的和客戶去溝通，我們知道有些事情無法避免，那么當問題出現的時候我們應該努力去找客戶商量解決辦法，而不是等問題完全暴露無遺的時候再去努力抱怨。可以加強和客戶的溝通，你可以現場操作，你可以去問實際的操作人員，甚至在某段時間你可以幫助他們去做某項工作，只有這樣你才能理解他們是怎么做的，你才能發覺項目的需求。客戶領導可能會抱怨你的實施進度很慢，但是實施人員一定要努力去面對這些問題，而不是去逃避客戶的問題。
(1) 實施人員可以現場操作，實際跟蹤，甚至某段時間協助他們完成相應的工作
(2) 向實際操作的人員了解具體如何使用的，他們的工作難點在哪里，不同的工種操作你都要去了解，最好是實際操作
(3) 跟客戶領導反饋你發現的真實問題，有時候客戶領導和公司領導一樣根本不可能知道實際的問題，而只是表面的知道問題，并且讓客戶確認。
(4) 放下自己的身段，就作為一個普通的操作工。我覺得這點很重要，很多做這種相對高級點的工作，在實際的項目實施過程中都怕去做這種流水線的工作，就和技術人員很多不敢給客戶打電話一樣的。
實施和技術：在項目過程中，技術和實施及時親兄弟，用一句話來形容就是"唇亡齒寒"，所以這兩個一般情況下關系是相當不錯的，但是有時候也會有沖突的。實施人員在實施的過程中軟件出現問題，那么最直接的問題就是技術人員沒有做好，而這個關鍵的時候如果客戶知道了，倒霉的肯定是實施人員。實施人員受罪了技術人員還會好過么。因為實施人員直接接觸客戶所以能夠知道客戶具體需要什么東西，這個決定了技術人員的開發方向，這個過程也會影響項目的推進。
(1) 實施人員要能夠把握住客戶的確實要求，了解他們的問題之后要能夠總結歸類然后反饋。我在實施過程中會先將客戶的問題給記錄下來并且分析難以程度以及緊急程度再反饋給技術開發人員。
(2) 過濾偽需求排除不再范圍內的需求，有些客戶提出的要求并不是一個可行性的需求，也有一些不是在我們范圍內的需求。我們這個需要明確把握，在項目實施的過程中我有幾次充當爛好人，結果也沒有得到什么好處，反而適得其反。先做好本職工作再在有能力的情況下去幫助客戶解決問題。
(3) 技術人員要能虛心的接受實施反饋的問題，在某種情況下技術人員認為不太可能的事情但是對于客戶來說是非常重要的。比如在一個表格中第一列和隊列顯示的內容問題，你認為第一列和第二列位置無所謂，但是對于客戶來說卻是非常重要，為什么這樣你體會不出來，或許是習慣問題！所以技術人員要能夠接受莫名的問題。
四. 表和里的問題
可能是因為我沒有大局觀，也可能是我沒有考慮問題的本質。以前我一直做互聯網方面的開發，但是個人認為這對于自己來說不是一個什么太好的事情，所以現在退居一步做一些傳統行業方面的軟件。我公司現在的軟件方面主要是以條碼,二維碼,RFID 為基礎的倉庫管理系統和生產管理系統。但是在做互聯網和傳統軟件上我覺得有很大的區別，這個區別不知道我自己是否理解的正確，可能也是因為我站的角度不一樣。
講一個真實的事情: 同事A和我在探討一個項目問題的時候，我們發生了一些問題的偏岐。我們給客戶實施一套倉庫管理系統，難度較大。我們定好某一天去客戶現場部分實施，但是項目從整體上是沒有成型的，只是部分功能可以使用完全算不上一個軟件。同事A卻希望能夠多開發一些功能界面，即使功能不好也可以，只要能夠看到是那么一回事就好了,他是想讓客戶知道我們做了很多事情。 而我認為這是一種虛假的做法，從開發多個"仿制"界面來說，本身就是一個耗費時間的過程，而且開發了對后期的真實需求的完成沒有太大的作用，反而有時候會讓給自己埋下很多坑。
這是一個公說公有理婆說婆有理的事情，我暫且不討論誰對誰錯。從根本上來說這是給項目推進自己挖坑，后面自己好跳下去，這是對項目的推進極為不利的。一直到目前為止我仍然認為自己的想法沒有錯，在多次的實施過程中客戶關心的是你所有的東西完成沒有，你畫了很多仿制的界面對于整個項目來說仍然沒有完成，不僅浪費了時間而且給自己挖了一個很大的坑。當然也不是說同事的想法錯了，這個只是出發點的問題。
(1) 從公司的角度來出發我們要考慮表的問題，這個時候我們可以對客戶做適當的事實隱瞞，因為這是一種策略，當然你有足夠的能力就不需要這些。
(2) 項目已經開始實施，還是暴露所有的問題比較好，這個問題暴露可以不讓客戶知道，但是自己一定要明白這個問題的存在性和嚴重性。
(3) 個人覺得不要讓客戶產生我們快完成了的這種錯覺，最好是實事求是，千萬不要打腫臉充胖子，欠的總是要還的。
(4) 暫時擱淺問題下次解決，問題也是逐步積累出來的，到了一定程度就會集中爆發。這是大部分人都會犯的錯，這個問題小問題下次再解決，往往到了后面就忘記了這個問題，又為自己埋下了一顆地雷。
#p#
五. 計劃性
我們在發開軟件的時候有這樣一個功能，做生產排產計劃，做過相關工作的人應該都知道：工廠在加工某個產品的時候，會先做一個排產計劃，比如這周要排產什么產品，排產數量是多少，所需要領料是多少，產品的先后順序是什么。 做排產計劃的目的是為了讓工作更加有序的進行，在規定的期限達到相應的目的，軟件開發這個功能方面我們都非常擅長。但是你真的會做計劃嗎？
任何事情都要有計劃，這樣才能保證自己的事情按照既定的目標和軌跡推進，雖然不能完全一致，但是至少讓你有一個目標感！在開發和項目實施的過程中，我們往往缺少這樣的計劃任務，事情想到哪里做到哪里，導致所做的的事情毫無章法頭緒。先做這個發現問題做不下去然后又走另外一個，最終一個都沒有做成。個人做計劃應該達到如下幾個要求:
(1) 針對目的： 做這個計劃是針對什么，也就是我們的目標，我們要達到什么目標
(2) 明確任務: 這個計劃是要做具體什么事情，甚至包括具體的實施推進步驟
(3) 時間限制： 做計劃一定要有時間限制，這個計劃實施要在什么時間范圍內完成
以上是自己總結的幾點，可能做計劃還有更多的方式，每個人都可以根據自己的工作方式和習慣來制定目標計劃，很多時候我們任務不能如期完成也是因為沒有計劃性，我們不明確自己的目標，不知道如何去實施和補救，沒有時間概念。
個人比較自豪的是在多年的工作中養成了做計劃的習慣，不說自己是百分之百按照此計劃來執行的，也不是所有的目標都達到了，但是讓自己每個時間段有一個明確的目標,比如:
1. 工作日每天6:30起床，爭取八點到達公司，做每天的工作計劃，當然我外出的情況較多會做好每天的行程安排
2. 今天要解決客戶現場機器問題，使用**方式來解決，備用方案是真么處理
3. 和客戶當面確認某個需求問題，找**人，并且讓其做出明確的回復，如果不能處理也給出相應的反饋
4. 寫一篇技術博客，總結最近的工作問題
5. 。。。。。。。
在做計劃的時候最好使用筆記本記錄下來，而不是使用電子檔來記錄，在用筆記錄的時候可以思考這個事情的深層問題，并且有一種莊重的感覺，會讓你非常的重視你做的計劃，而對于在電腦上做計劃覺得有那種可看可不看的感覺。
從學做計劃開始我就使用筆來記錄，而且已經記錄了多個筆記本，而且后來發現做這個事情的重要性，個人最近一年每天工作計劃和安排目前都應該可以查詢到相關的記錄。這是保證自己要做的事情穩步推進的一個重要過程。
六. 技術方案
這里單獨說技術問題，是因為自己也做過技術開發，自己以前是一個非常專技術研究的人，雖然現在還有點改不了這個習慣，但是不得不說從不同的角度來看這個技術問題。這里也講一個真實的案例:
之前接到過一個項目，項目是一個在線報考系統(非考試系統)，就是能夠申請報考，并且可以查看相應的成績等，屬于一個非常簡單的項目，時間期限一個月。我將此項目外包給了一個技術非常厲害的朋友來做，因為我絕對的相信他的技術能力。然而最后做的東西我非常失望，先不理會項目的具體問題，最終就是一個月東西沒有完成，只完成了一個非常簡單的功能，核心部分都沒有做。那個時候我就開始真正思考這個技術問題，一個技術牛人為什么會出現這個差錯？
(1) 在做用戶系統的時候他用了單獨的數據庫，登錄功能就涉及了好幾個存儲過程
(2) 登錄驗證超級復雜，使用啥啥技術
(3) 數據庫結構也超級復雜，而且表，字段名都是非常長的名字(也無所謂)
.........
這是屬于典型的過度架構，我不得不承認他這種寫能夠充分展示其技術能力，因為我當時還沒有辦法很明確的知道其具體運行流程，一個登錄注冊就如此的復雜，一個月過去了就完成這些東西，可能是其他的原因導致的不能完成。但是客戶只是需要一個簡單的登錄，用戶注冊就可以了，單表完全可以搞定，完全滿足客戶的要求，一個月時間綽綽有余完成這個項目。
(1) 根據具體的項目選擇合適的技術: 這是一個非常典型的技術使用不當的問題，簡單的項目為什么一定要用那么復雜的技術，炫技還是虛榮心！你炫我炫就看誰亮瞎對方的眼睛。
(2) 明確項目真實目的: 項目最重要的就是完成客戶的需求，而不是要使用多高深的技術，技術和需求本末倒置了。
(3) 時間概念優先級：一個月完成項目是目的，這個項目核心是考試系統，及時不能完成全部最起碼核心部分要能夠有所實質上的突破而不是完全沒有做。
這里不是去貶低技術的不重要性，只是要讓大家明確做事情的目的是什么，技術的作用又是什么，對于技術的專研是一件好事情，但是也不能只能專注于技術的發展，否則就成為了井底之蛙。
技術是為了更好的解決項目問題
七. 團隊問題
很多時候都在說團隊，只有團隊才能干好一件事，這是毋庸置疑的。一個項目不可能一人完成，一個人的能力往往是有限的。很多人在談到團隊的時候只能想到技術的團隊，個人覺得企業就是一個團隊，這個團隊中有不同的角色，每個角色都很重要。在上面提到了項目過程中的幾種角色，我不認為這是最好的團隊組合，也不一定是最優秀的團隊組合，但目前是最適合我們的一種團隊組合。
在我們之間也會有矛盾，但是所有的事情我們都只針對問題的本質，我們所處的角度不一樣，看待的問題也不一樣，但共同的目的就是將這件事做好。而一個項目進度緩慢的最核心問題就源于團隊是否默契配合，如果技術人員和銷售人員對著干，實施和技術之間愛理不理，諸如此類的問題項目如何推進實施，如何能夠快速完成的項目。
(1) 團隊不是指技術人員，也不是只銷售人員，也不是實施人員，而是這個項目關聯的所有人員甚至包括客戶，每一個角色都影響著項目的進度
(2) 公司內部小團隊之間可以有意見分歧，但是對外必須是一致的
(3) 不同角色的人員之間要加強溝通問題，反饋響應問題必須及時
(4) 團隊的成員要達到高度一致的目標，無論工作有多少矛盾和沖突，完成項目是共同的目標
(5) 不同角色工種之間要能夠相互理解和包容對方的工作
當然影響項目實施推進的因素還有很多，這是我在作為一個項目實施人員過程中所思考的一些問題，可能不一定正確，每個團隊都有自己的問題和不足，每個人也有自己的解決問題方式，從一個單純的技術人員向另外一個方面的轉化中會遇到很多的問題，但是也會學到很多新的東西，你會知道站在不同的角度去思考一些問題。
最近最有感觸的事情還是周末去15公里穿越的事情，在路途中遇到很多的困難，但是無論多么困難我們都得堅持，只有堅持我們才能到達目的地！
