> For the complete documentation index, see [llms.txt](https://willh.gitbook.io/it-startup/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://willh.gitbook.io/it-startup/23/27.md). # 承接大型專案的兩難 **隨著公司業務年年增長，公司的人也越來越多，相對的管銷與薪資成本自然也逐年攀升，如果還座小型專案，恐怕無法應付公司的現金流量需求，所以公司也開始出現越來越多百萬等級的專案。不過，越大的專案越難結案，製作過程中遇到的困難與挑戰不小，需求變動的幅度也更大，所以公司內部自然也會不斷累積負面情緒，打擊公司士氣。但公司不接大案子將會無法應付公司管銷，這真的是一件非常糾結的事。** ![](/files/-M6EeuLt9SUFr_onMNtm) 圖片來源 我們從 2008 年開始，因為公司轉向微軟開發技術一些時間，累積了一些經驗，再搭配自己經營部落格多年，有越來越多客戶主動找上我們，而大部分的客戶正好就是以微軟平台為主，所以不謀而合。在台灣，微軟的作業系統市佔率超過 9 成，這是一塊很大的餅，但以前玩 PHP 的時候，完全不覺得這有什麼，只覺得 Windows 能做到的，Linux 也能做到，光只想著要省錢與玩技術，都沒想到做生意要看整體，不能單只看一個地方。 在台灣雖然以中小企業為大宗，但也有不少中型與大型的企業，慢慢的也跟我們公司建立起連結，讓我們有機會為他們服務。我們公司多年以來大多以服務與技術為訴求，靠著口碑一個介紹一個客戶，並建立起品質信譽，所以才能逐年穩定成長。以前常有人問我「當公司有越來越多工程師的時候，你怎樣維持公司的程式碼品質」，靠的是什麼獨特的開發流程？還是什麼好用工具？爾或是其他因素？ 我必須很老實的告訴各位，品質是用時間換出來的。記得有次有個客戶在晚上 12 點的時候找我聊天，問我怎麼管理公司的程式碼品質。我跟他說「我現在正在做 Code Review 檢查底下工程師寫的程式碼品質」，遇到不好的寫法，就發信叫工程師改。剛轉 ASP.NET 的前幾年，幾乎都是這樣渡過的，沒有什麼神奇的銀子彈，就是花心思下去看、下去改，如此而已。難道就沒有好用的工具或開發流程可以改善品質嗎？有，當然有，但沒有品質的意識，在好的工具在你手裡，你還是不會用。大多數工程師都只想趕快做完工作後下班，要讓大家願意為品質做出 110 分的努力是不切實際的，但這件事總要有人做，才能撐起一間公司的品牌，很自然的，這就淪為我閒暇之餘的工作了。 做什麼生意都一樣，品質永遠要擺在第一位。只要品質能維持在一定水平之上，公司就能穩定成長，沒什麼好擔心的，尤其是軟體這個行業更是如此。很多人經常抱怨「好廠商難找」，確實是如此，因為選擇軟體廠商的成本很高，轉換廠商的成本也很高，所以遇到「不會太差」的廠商，通常不會隨意更換，勉強點用，但這件事並不是所有老闆或公司高層都知道，所以隱含付出了許多無形成本。 也因為多年累積了口碑，客戶越來越大，需求也越來越複雜，相對網站與軟體的變動性也就變多。這一點，並不是所有工程師都能接受，脾氣好的人或許忍一忍就過去了，但情緒多少會有點累積。脾氣不好的人就會開始抱怨，抱怨客戶為什麼要提這種奇怪的需求，明明不合理，又要我們硬做，做了一段時間，又叫我們改回來，實在氣人啊；抱怨PM，抱怨客戶說什麼你都答應，你是豬嗎；抱怨公司，抱怨這間公司真是個血汗工廠，經常為了客戶的需求趕到晚上九點十點。 身為一個經營者，這是個很兩難的決定。若只願意接小案子，公司賺不到錢，薪水與獎金也發不多；若開始承接大專案，就要擔心每做完一個案子就有一批人要離職的事實，嚴重者可能是案子還沒做完人就跑光了。無論怎麼做，都不會有漂亮的答案出現，所以勢必要在這兩難中間找出一些平衡點才行，我也是跌跌撞撞了很久才慢慢找出這個複雜的平衡點。 我後來想想，專案開發的過程，遇到最多的問題並不在技術，而是在「溝通」。無論大案子、小案子，會遇到的溝通問題其實差不多，不就是需求變更、時程太短、遇到暴走族的客戶還有最常見的情緒問題，主要的問題大概就這些。與其這樣，你會傾向選擇承接大型專案還是小型專案呢？這個答案應該是明確的，當然是「大型專案」。但專案開發過程中的「副作用」就必須靠一些機制來「改善」。 沒錯，是「改善」，不是「解決」。因為有些事情是解決不了的，尤其是人的問題，你要等別人改變，倒不如自己先改，才能適應這個艱困的環境，適應不了，那也就只好黯然下台。當公司的定位確定後，我便開始研究各種改善「副作用」的方法，例如需求變更的問題，透過前期企劃人員來限縮專案的範疇，大幅降低需求異動的幅度。時程太短的問題，其實每個客戶都是這樣，你只要問客戶「你什麼時候要上線？」這幾乎只有一個標準答案「越快越好」，不是嗎！遇到暴走族的客戶，你還能怎麼辦？只能放下尊嚴讓他罵囉，我有次去客戶端開會，被臭罵 30 分鐘，回來還是開心的有說有笑，雖然我失去了 30 分鐘的尊嚴，但更不想失去未來 3 個小時可以開心的情緒，這是你可以控制的！但叔叔有練過，小朋友要再加油！XD 最後，也最難搞的，就是情緒管理問題。在一間公司裡，由於每個人因為生活背景不同，價值觀也不同，對每一件事情的見解也不盡相同，所以當專案遇到不合理或不合邏輯的情況時，身為ＩＴ人往往會強烈抗拒，有些人強力抗拒在心中、有些人強力在表現的事情上。這確實是個難解的難題，我最後則是盡量讓他們不要把工作的焦點放在「專案」上，而是｢學習｣上。因為專案開發是幫助一個人學習成長最快的方式，雖然副作用很多，但我唯一能做的，是幫助他們專注在自己想得到事情上面，而不是他們不想面對的那些副作用。當你能夠專注於正面的事情，心情上自然會舒緩很多，進一步壓下那些專案製作過程中的負面情緒，而這，就是「正面思考」的力量。