繼續上篇的專案總結，這篇主要來總結下做為乙個開發人員，在專案真正進入**開發期間，開發人員都需要做哪些準備工作。
乙個專案的的生命週期呢，由我們公司來看，大概有以下幾個步驟:
1:由產品部門或者叫業務，提出需要做什麼樣的產品來，產品在開發人員眼中就是我們經常說的專案，他們提供的是產品的功能需求。
2:由部門技術核心人員和產品部同事討論其功能的實現方式，這裡一般會包含產品的功能，以及如何實現產品功能，例如：實現a功能需要的資料從哪取，頁面以什麼樣的方式呈現給使用者，後台如何處理等。
3：技術核心把開會整理的需求文件以及實現方案草圖發給下面的開發人員參考，開發人員結合需求文件等材料了解專案的基本情況。
4:進入正式的開發周期。
5:提交測試部進行功能測試。
6:解bug週期。
7:正式上線。
從上面的七個步驟上我做為乙個開發人員，是從第二步開始的，但有時往往在這上面不會花太多時間，只是清楚需要做什麼，然後就開始**開發。
問題：1:需求文件往往只體現了專案中的一部分內容，有很多小地方根本不會體現，但往往是一些小地方又比較關鍵，這樣在沒有完全搞清楚需求以及業務邏輯的基礎上，出錯的機會特別大。拿上篇文章的訂單取消專案來說吧：
場景：在訂單取消時，有乙個讓使用者再次確認的頁面，提示內容如下：
2:需求文件中需求不明確。
場景：修改聯絡人的需求中，就寫了修改聯絡人資訊，規則同酒店訂單填寫頁。
問題：如果不仔細思考就開發，很難保證開發想的就和業務想的一樣。例如：酒店在下訂單時，驗證聯絡人是否包含敏感詞是在訂單介面中，並不在客戶端驗證，但需求中不明確提出來，開發修改聯絡人資訊時，就很容易把驗證敏感詞的邏輯給丟掉，一旦前期沒考慮到，到了開發周期，這額外的開發量就是以後專案延後的重要原因。
總結：凡是需求不明確的內容(和酒店填寫頁規則相同)，在開發前一定要和產品部確認。
3:開發前針對需求中提到的具體業務邏輯需要了解,這裡所說的具體業務是指：專案功能所涉及的其它功能。
1:任何時間都不能取消。
2:到店日x小時至y小時扣費取消，之後無法取消。
3:x日y點後扣費取消。
針對後面兩點取消方式，需求中給出了展示給使用者的提示語:
規則2:
此訂單已預付￥1000元房費，按規定在到店日x小時至x小時之間取消訂單將扣除首晚房費￥200元，剩餘￥800元將返還到支付時使用的銀行卡內
規則3:
訂單已預付￥800元房費和￥200元消費券，按規定在在x日x點之後取消訂單將扣除全部房費，已使用的消費券將作廢。
問題:根據此需求文件，我是這要理解的：
規則2就是指扣首晚，規則3就是扣全部房費,後來才了解到規則2規則3其實都有三種扣費方式：扣首晚，扣全額，扣比例。嚴重影響了取消確認頁的展示邏輯。
4:在初步分析完需求文件後，最好把專案功能的邏輯圖畫出來，這樣即在頭腦中清晰了要做的工作，也對以後查詢資料有幫助。下圖是此次專案關於預付訂單的一些展示邏輯流程圖。有了這樣的流程圖，再開發時條理就清楚多了。
專案開發經驗總結 2 26更新
手上的專案從06.6開始做先行研究到08.1實施完畢，開發相關人員從3人到14人，是我目前程式設計生涯中最大專案了。這期間各種角色都體驗過，現在要總結經驗。管理者部分 倘若上司不懂技術而又愛插手開發，leader的責任便更重大 要能合理拒絕不合理的功能需求，說服延時不適時宜的重構要求，拒絕不合適的人...
專案一（驅動開發經驗總結）
微控制器中的看門狗 watchdog timer 實際是乙個定時器電路，其輸入端稱為餵狗，中斷輸出端連線到系統復位。它的主要功能是定期檢查程式在晶元中的運 況，且其中斷優先順序為最高端。實際應用 在程式的主函式的while函式中新增餵狗語句。void main void 在中斷函式中，不要新增whi...
2019專案管理經驗總結
需求永遠是最重要的。在開發中後期以及驗收環節，大部分問題都是因為功能與實際需求沒有完全重合造成的。而且往往花費大量時間進行改造。相當一部分功能還是在功能測試後要求調整，所以作為管理者，如果後期比較忙的話，各種坑和隱患就會讓你慌的一筆。前期花更多時間在需求文件和設計文件上。後面會輕鬆很多很多。文件管理...