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