一個失敗專案的專案筆記（轉）
關鍵詞：技術心態總結
知識份子用最先進的途徑傳播非典性肺炎的恐慌。除了論壇上誰也不關心可憐的伊拉克人民
也許在起“沒頭沒尾”這個名字的時候已經有了預感，我並沒有在專案中堅持到最後，而是在專案完成之前離開了這個專案。專案由負責客戶端設計開發的同仁接手擔任技術經理。幾個月的開發經歷給我帶來了很多的想法，很多的收穫。寫專案開發筆記的過程也讓我認識了很多好朋友。這是最後一篇專案開發筆記，主要說的專案小組在選擇專案開發語言心態中的一些變化。上上一篇的專案筆記《沒頭沒尾--專案開發筆記：怎樣選擇專案開發語言 》中已經有一些說明，但是想法在兩個月的時間裡有一些變化，這裡記錄下專案小組對所採用的技術心態的三個變化。
技術心態的三個階段
由於對應用新技術專案小組成員的心態產生了很多的變化，為這些變化我們也付出很大的代價。首先是對技術的心態變化直接導致專案小組成員工作心態的變化，然後是對技術的心態變化影響對專案中其它一部必須完成部分的投入，最後是影響了我們的專案的進度。也許把一些問題歸罪去心態不好，或是歸罪於心態的變化，並不完全正確。可是我想可以透過總結減少這些心態的變化，使得每個人可以在專案中調整好遇見問題時自己的心態，從而對專案相關的事情做出正確的判斷與處理。
專案小組對採用新技術開發專案心態有過三個階段，可以說這三個階段的出現是很有代表意義。下面是對這三個階段的描述。並且說明心態的變化分別給專案帶來什麼樣的正面負面的影響，以及對專案成本的影響。
1.狂熱
專案初期對應專案之間製作了一些DEMO。並從資料與DEMO中得出了將要採用的方式（可以參見以前的專案開發筆記）。可以說這個時期專案小組的成員為這個技術框架的建立激動不已。大家集中了很多的熱情在進行對專案模式的討論，並且做了很多的實驗，大量的DEMO。為專案以後的發展打下了一定的技術基礎。
好處
1.參與的專案小組成員從廣度上了解專案技術框架，為日後的開發打下一定的技術基礎；並使各個專案小組成員很快的進入角色。
2.專案小組中決大部分成員只有VB之類的基礎，而對基於DOTNET開發的技術不熟悉。透過這種狂熱，使得專案小組成員很快的熟悉了這種新的開發工作與開發方式。
壞處
1. 廣泛的去製作DEMO使得對技術的框架的研究出現一種不求甚解的風氣。具體的來說就是很多時候天天討論FACADE，天天討論最終應該把系統劃成幾層。而對效率，安全性，例外的處理之類的框架設計中要考慮的東東放在了後面。也就是說，對技術框架的狂熱讓我們對工作時間，工作重點的分配產生了混亂。
2. 需求與設計被放到了一個次要的位置。由於我本人對業務情況並不是很瞭解，所以我並沒有去與專案小組的成員一起去將需求進行詳細的考證，以及變成設計。而是隻從我的角度對需求進行了最粗粒度的劃分，可以說是對後來專案的進展沒有起到任何作用。這個在以前的文件中也有描述。
3. 僅從DEMO得出專案的可行性分析，而沒有得到開發的可行性分析。導致專案在初期走過了很多的彎路。
綜合上面所說的好處與壞處，我的體會是專案開發過程中出現了好的因素也要保持清楚與冷靜的頭腦。始終以專案本身為思考的出發點與歸宿。不是專案中所有的人都在狂熱的工作與研究就是好事，而是應該具體的去考慮對專案的發展有沒有好處？
2. 失望與沮喪
專案的中期，由於對應開發方式進行變化（主要是指客戶端採用DELPHI進行開發）的準備並不是很充分。特別是開發方式的變化與適應的時間太短。對兩種語言透過Web Service進行介面的問題思考與準備並不充分。所以雖然我們的方案具有很多的優點，可是對應的開發過程卻顯得非常的艱苦。由於開發效率的低下，專案的時間又非常的緊，加上又有個別專案小組的成員在開發過程中不斷的宣傳從時間的因素上來看不應該用這種新的技術來進行專案的開發。導致從對技術框架最初的熱情很快的轉到了對專案所採用技術非常的失望與沮喪，很多的專案小組成員都認為我們做一個錯誤的選擇，並將專案的延期之類的責任都推到了這個原因上。
我感覺對這個事情的處理上體現的非常不成熟。我並沒根據專案小組成員在不同的時期所出現的心態進行自己的分析，以及找出方法對應進行調整。在上一個階段，我是狂熱分子而沒有清醒的意識，在這一個階段，我也成為了一個失望者與沮喪者，並沒有去仔細分析情況出現是由於選擇開發方式的錯誤還是由於對開發方式研究的深度不夠。這種全面的失望與沮喪的情緒對專案的影響是巨大的，我們的開發效率變的低起來，我們也不再為專案本身而感到驕傲。直到進入下一個心態階段。值得慶幸的是，雖然這個時期有失望情緒，但我們還是堅持了當初定義好的開發的規則。對於定義出的技術框架還是堅持了下來。
3. 平淡與麻木（體會到最佳選擇）
專案的最後時期專案小組成員對對專案使用什麼樣的技術已經不再關心。也就是說，可以用一種比較正常或麻木的心態來看待技術問題。透過仔細的考察專案本身所具有的特點可可以得出以下的結論：
1.本專案必須採用Web Service的方式來完成這個專案
2.專案選型時，開發web service
[@more@]
知識份子用最先進的途徑傳播非典性肺炎的恐慌。除了論壇上誰也不關心可憐的伊拉克人民
也許在起“沒頭沒尾”這個名字的時候已經有了預感，我並沒有在專案中堅持到最後，而是在專案完成之前離開了這個專案。專案由負責客戶端設計開發的同仁接手擔任技術經理。幾個月的開發經歷給我帶來了很多的想法，很多的收穫。寫專案開發筆記的過程也讓我認識了很多好朋友。這是最後一篇專案開發筆記，主要說的專案小組在選擇專案開發語言心態中的一些變化。上上一篇的專案筆記《沒頭沒尾--專案開發筆記：怎樣選擇專案開發語言 》中已經有一些說明，但是想法在兩個月的時間裡有一些變化，這裡記錄下專案小組對所採用的技術心態的三個變化。
技術心態的三個階段
由於對應用新技術專案小組成員的心態產生了很多的變化，為這些變化我們也付出很大的代價。首先是對技術的心態變化直接導致專案小組成員工作心態的變化，然後是對技術的心態變化影響對專案中其它一部必須完成部分的投入，最後是影響了我們的專案的進度。也許把一些問題歸罪去心態不好，或是歸罪於心態的變化，並不完全正確。可是我想可以透過總結減少這些心態的變化，使得每個人可以在專案中調整好遇見問題時自己的心態，從而對專案相關的事情做出正確的判斷與處理。
專案小組對採用新技術開發專案心態有過三個階段，可以說這三個階段的出現是很有代表意義。下面是對這三個階段的描述。並且說明心態的變化分別給專案帶來什麼樣的正面負面的影響，以及對專案成本的影響。
1.狂熱
專案初期對應專案之間製作了一些DEMO。並從資料與DEMO中得出了將要採用的方式（可以參見以前的專案開發筆記）。可以說這個時期專案小組的成員為這個技術框架的建立激動不已。大家集中了很多的熱情在進行對專案模式的討論，並且做了很多的實驗，大量的DEMO。為專案以後的發展打下了一定的技術基礎。
好處
1.參與的專案小組成員從廣度上了解專案技術框架，為日後的開發打下一定的技術基礎；並使各個專案小組成員很快的進入角色。
2.專案小組中決大部分成員只有VB之類的基礎，而對基於DOTNET開發的技術不熟悉。透過這種狂熱，使得專案小組成員很快的熟悉了這種新的開發工作與開發方式。
壞處
1. 廣泛的去製作DEMO使得對技術的框架的研究出現一種不求甚解的風氣。具體的來說就是很多時候天天討論FACADE，天天討論最終應該把系統劃成幾層。而對效率，安全性，例外的處理之類的框架設計中要考慮的東東放在了後面。也就是說，對技術框架的狂熱讓我們對工作時間，工作重點的分配產生了混亂。
2. 需求與設計被放到了一個次要的位置。由於我本人對業務情況並不是很瞭解，所以我並沒有去與專案小組的成員一起去將需求進行詳細的考證，以及變成設計。而是隻從我的角度對需求進行了最粗粒度的劃分，可以說是對後來專案的進展沒有起到任何作用。這個在以前的文件中也有描述。
3. 僅從DEMO得出專案的可行性分析，而沒有得到開發的可行性分析。導致專案在初期走過了很多的彎路。
綜合上面所說的好處與壞處，我的體會是專案開發過程中出現了好的因素也要保持清楚與冷靜的頭腦。始終以專案本身為思考的出發點與歸宿。不是專案中所有的人都在狂熱的工作與研究就是好事，而是應該具體的去考慮對專案的發展有沒有好處？
2. 失望與沮喪
專案的中期，由於對應開發方式進行變化（主要是指客戶端採用DELPHI進行開發）的準備並不是很充分。特別是開發方式的變化與適應的時間太短。對兩種語言透過Web Service進行介面的問題思考與準備並不充分。所以雖然我們的方案具有很多的優點，可是對應的開發過程卻顯得非常的艱苦。由於開發效率的低下，專案的時間又非常的緊，加上又有個別專案小組的成員在開發過程中不斷的宣傳從時間的因素上來看不應該用這種新的技術來進行專案的開發。導致從對技術框架最初的熱情很快的轉到了對專案所採用技術非常的失望與沮喪，很多的專案小組成員都認為我們做一個錯誤的選擇，並將專案的延期之類的責任都推到了這個原因上。
我感覺對這個事情的處理上體現的非常不成熟。我並沒根據專案小組成員在不同的時期所出現的心態進行自己的分析，以及找出方法對應進行調整。在上一個階段，我是狂熱分子而沒有清醒的意識，在這一個階段，我也成為了一個失望者與沮喪者，並沒有去仔細分析情況出現是由於選擇開發方式的錯誤還是由於對開發方式研究的深度不夠。這種全面的失望與沮喪的情緒對專案的影響是巨大的，我們的開發效率變的低起來，我們也不再為專案本身而感到驕傲。直到進入下一個心態階段。值得慶幸的是，雖然這個時期有失望情緒，但我們還是堅持了當初定義好的開發的規則。對於定義出的技術框架還是堅持了下來。
3. 平淡與麻木（體會到最佳選擇）
專案的最後時期專案小組成員對對專案使用什麼樣的技術已經不再關心。也就是說，可以用一種比較正常或麻木的心態來看待技術問題。透過仔細的考察專案本身所具有的特點可可以得出以下的結論：
1.本專案必須採用Web Service的方式來完成這個專案
2.專案選型時，開發web service
[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-955585/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 記一個失敗的專案
- 一個歷時3年的專案失敗記錄 (轉)
- 一個SaaS專案失敗的原因 從個人角度覆盤專案失敗的5個重要原因
- ERP專案失敗的原因(轉)
- 失敗的敏捷專案敏捷
- 專案失敗五宗罪（轉）
- 專案交付為什麼失敗？-記我在某個專案中的迷思
- 軟體專案失敗因素分析（轉）
- 大學裡面的幾個失敗專案
- 沒頭沒尾--專案開發筆記：UML，IDEF在我們專案中的失敗應用 (轉)筆記IDE
- 專案團隊管理的失敗經驗（轉）
- 專案失敗並非如想象般普遍（轉）
- 專案研發為什麼失敗？（轉）
- 專案失敗並非如想象般普遍 （轉）
- 那些騰訊投資失敗的專案
- 淺談BI專案——為失敗BI專案解惑
- ERP專案失敗的四個非技術性陷阱(轉)
- 糟糕的範圍管理導致專案失敗（轉）
- 軟體開發專案失敗的3個原因
- 軟體開發專案失敗原因分析（轉）
- 專案研發為什麼會失敗？（轉）
- 專案失敗的十種徵兆
- 一次失敗的專案經歷以及反省
- SpringBoot專案Autowired失敗Spring Boot
- 誰應該承擔專案失敗的責任？（轉）
- 機器學習專案失敗的9個原因，你中招了嗎？機器學習
- 盤點敏捷專案失敗的6個主要原因敏捷
- 一保健品專案運作失敗的原因和啟示（轉）
- 準備的一年的專案上線失敗
- 專案範圍是專案成敗的關鍵（轉）
- 社交CRM專案失敗的10大原因
- 諮詢顧問：面對註定失敗的專案 （轉）
- 諮詢顧問：面對註定失敗的專案(轉)
- Xamarin Android專案執行失敗Android
- 軟體專案為何會失敗？
- 專案範圍管理是專案成敗的關鍵 (轉)
- 案例研究：專案研發為什麼會失敗?（轉）
- 國內軟體專案失敗的根源分析