專案大約開始於年月日，由於之前的****不能滿足目前的業務需求，存在**資料不準確的問題，因此採購表需要it協助完善相關指令碼。
通過前期的需求調研，了解了需要調整的格式、公式、邏輯等，經過乙個多月的深入研究，比較細緻的討論了指令碼的關鍵技術，在弄清楚需求和修改的方法之後，就是具體的實施了。
對於這個專案我的心得是這樣的： 1、
需求調研
需求是否必要？必要的話，現有的條件是否可以滿足？新開發的話，效率和成本如何？
必須了解最終客戶的真正需求，有時客戶會直接提出解決方案，但還是需要了解其真正目的，目的不同，方案自然不同。 2、
需求文件
對前一步的需求分析寫成文件，明確指出了客戶需求，並讓客戶進行簽字確認（每乙個細節最好都有確認，如計算邏輯、函式的使用等），同時，對於其他相關人員而言，也便於理解需求，方便程式設計師維護指令碼。
文件可以包含以下幾項：專案概述，目標，應用範圍，名詞定義，詳細需求，使用者用例，顯示結果等。 3、
藍圖設計
畫出邏輯關係圖，列出關鍵步驟、制定執行計畫。這一步也非常的關鍵，如果考慮不夠周全，後期就需要翻工！
如果是多個人合作完成專案，要將工作分工落實到每個人頭，以及安排出相應的時間表，時間安排要合理，同時要有彈性，可能會有臨時緊急重要需求，可能突然有重大變更，當然這時計畫也需要再安排。 4、
專案實施 a.
對相關原始指令碼進行逐行分析，了解每句的含義（如果是新專案，就需要自己寫**） b.
進行相應的修改 c.
在資料庫中搭建執行環境（排程相應的表到備庫，把錶結構設計寫下來） d.
建立外部資料表（如工作日表） e.
考慮後期影響因素，維護工作，可擴充套件性（時間範圍按系統時間自動擷取，年初可能會有問題） 5
、檢驗結果
自己檢查結果，是從技術角度檢查；客戶檢查結果，從業務角度檢查，因為在需求上可能仍存在誤解。 6
、部署實施
在真庫上建立儲存過程、檢視、物化檢視等。如果是多地系統，需要再從第三步開始。
但是之前的舊版還需要保留一段時間，在這期間兩個版本同時執行，當新版沒有問題了，再停用舊版。 7、
調整維護
在執行過一段時間後，使用者可能感覺某些方面沒有達到期望，需要修改，這時的需求應該是比較明確的，修改相對容易。將後期需要做的維護工作，注意事項等寫入相關文件。
在寫指令碼的時候，良好的編寫習慣也很重要，既可提高編寫效率，保證指令碼的正確性，同時易於擴充套件和後期維護。在操作的過程中，要時刻注意按照需求說明進行，不要一味的盯著具體的語句或者以前的邏輯，而偏離了目標。總的來說，專案的實施和具體**的編寫都要有一定的規範和流程。要有全域性的觀念，不要只專注於幾個細節，考慮周全，專案完成後還應該注意哪些方面，後續工作還有哪些。
對於乙個專案，計畫是很重要的，如果在調研了需求之後，認為專案是必須要執行的，那麼就要制定計畫了，從需求調研開始，就要拍計畫。當然這些也不是線性的，應該是螺旋上公升的，後期可能還會做一些修改，但是大的框架應該保持不變了。
工作心得之一
解決問題 pdca 找問題，找原因，找要因，定計畫，執行，檢查，反饋總結，解決問題。做事要思考 任務是否有放心頭，是否可以提前一點，多做一點，做的更好。不要讓人等你，比別人多想一步，多做一點，比昨天做的更好。溝通 減少無用溝通，直言，面對問題解決問題。減少不必要的公用開會時間。做老闆的心態 世上無難...
工作心得總結
這篇總結是我在實際工作中的一些心得體會。主要是我在工作中犯的錯誤然後進行總結，也是對自己的警示。我在這裡先丟擲乙個觀點 技術能力不等同於工作能力，只能說技術能力是工作能力的一部分，在公司裡會發現有些技術不錯的程式設計師並不得志，有些技術不如他的反而得到晉公升 事件的背景是我在乙個小組周會上進行了乙個...
工作心得（二）
對於在這次轉換的過程中技術方面的心得，主要是建儲存過程方面的。關鍵是要有規範的思想，從儲存過程名稱到儲存過程內容都要盡量保持乙個良好的程式設計習慣。一 命名規範 儲存過程以p開頭，後面加具有一些含義的單詞 p sku mara，t mara bc 二 日誌記錄 建日誌表，插入日誌的儲存過程，生成日誌...