@芯享 2016 – 07
期望
【提升質量】提高項目開發的質量，規范工作流程，對開發過程和結果都進行質量監控。
【文檔驅動】規范流程的具體實現方案，有據可依，健全問責機制。
開發流程
【項目可行性分析】生成用戶的需求文檔后，仍然要進行可行性分析。為了用戶，也為了不讓自己的精力投入到注定要泡湯的項目上。最好的狀態是，伴隨著項目的經歷，積累行業的競爭力。
【合作伙伴】選擇靠譜的合作伙伴，與誠信正直的人合作，避免被套路，規避風險。更容易建立彼此的信任，形成良性合作。
【客戶檔案】
建立客戶檔案，客戶名稱，公司職責，在該項目中所起的作用，劃定職責范圍。
明確項目干系人，與對方公司的所有干系人進行溝通，明確對方的預期。
從了解客戶審美的角度來講，可以問客戶要他比較喜歡的APP或者Web，在進行視覺設計的時候，可以將其元素納入設計規范中來。
【需求分析】
客戶的需求不是需求。
爭取軟件設計的主動權，客戶提供的設計圖，有利于了解用戶需求。在溝通用戶具體的需求后可進行重新設計。
還要對設計圖中涉及的元素進行說明（名稱，定義，來源等詳細信息），落實到文檔中。要形成精細化的需求描述文檔。
【需求變更】
客戶的想法：我都付了X萬了，改一個小功能都不給我改！！<氣憤ing>
尾款還要扣一下，萬一開發組拿錢跑路了怎么辦。
需要跟用戶解釋需求變更對我方開發的成本增加，明確何為需求變更，參照文檔，有據可依。
對開發成本根據開發需求進行動態調整，需求精細化。
【實事求是】生成需求文檔后進行價格估算，實事求是。如果開的價過高，只是一時利益，后期會失去用戶。如果開的價格低了，會讓公司受損，影響開發積極性。
這樣才可以大膽的讓用戶參與到軟件的開發過程中來。
【客戶在過程中的參與，而不是僅僅驗收成果】讓客戶參與到開發進程中來，減少之間的溝通成本，讓需求提供方參與到設計中來，用戶也可以對開發進度進行監控，和及時確認。階段性成果轉化為文檔生成后，進行簽收，郵件往來。階段性驗收付款結算，最大限度降低風險。
【用戶體驗至上】以保證用戶體驗為基本原則（避免后期糾紛和債務）同理心，站在用戶的角度思考問題。用戶體驗至上，不能以給多少錢辦多少事情的心態去寫代碼。
【視覺設計稿】
客戶對于UI的需求提升（布局，顏色，切換動畫）。
用戶往往提供了一系列視覺稿，就以為需求很明確了。實際上視覺稿中的元素名稱，往往會引發歧義**。
視覺稿不代表最終效果，會讓用戶產生錯覺。
【時長估計】交互設計出來之后，根據具體的頁面，數量，復雜度，UI需求，交互動畫等等，讓UI，前端，后臺，測試，各自給出自己的時間預估，項目經理綜合考慮，加上預留時長，避免延期交付的尷尬。
【開發成本估計】根據開發所需時長，用戶要求的時長，各自的工作量，人力成本，和硬件投入（服務器，短信API，圖片視頻云存儲等）綜合考慮
【測試】不要直接丟給用戶，出現問題多了之后，影響信任感。要留出1/3的工作時間進行代碼測試（單元測試，集成測試等）。
測試專業化，可以考慮增加測試專職人員，將測試融入到整個開發流程中來。對BUG產生報告記錄。
【項目驗收】驗收時不能由需求提供方的某個領導或職員來驗收通過或不通過，發生爭執時，回到文檔中來，有據可依。
個人
【良好的溝通】項目經理的溝通能力決定項目成敗，同理心的培養。
溝通時，避免所有的瑣事都勞煩客戶，但是要考慮到軟件體量的大小，如果是大體量的軟件，還是要事無巨細為好。
【合同&郵件】先小人，后君子。口頭承諾無效。每一個項目開始前，簽訂合同，保障大家的利益，明確基本薪資待遇，讓大家有底。
【客觀 就事論事】不問情緒，基于雙方利益，看目標和成果。
團隊內部，不應該太過于考慮對方情緒，工作過程中，對事不對人，哪里不對哪里不好就應該直接說出來。批評或訓斥，會讓一個職員一時的難堪，也可以大大加快進步的速度。
【快樂】心存善念，追求員工和客戶的快樂
【追責】郵件往來，留有證據。設計有效的問責機制（內部成員的話，請客吃飯或許可行，哈哈）
【沖突】公正，善意，逐步。實在解決不了了，考慮第三方協調。
