一、需求和頁面表現形式一定要全部思考清楚、問清楚、寫清楚！
立字據！！
一定強調寫！而不是口頭，因為所有功能不是一天就能開發完的，一切沒有寫清楚的內容，以後就特別糟糕！！
一定強調首選全域性把握，首先把所有需求都理解清楚，而不是忙著功能實現！
1.1決策者問題：
1）一般需求文件有了，應該是先讓開發人員先看，有疑問地方，寫下疑問。
然後需求人員口頭解釋一遍。
最後開發人員提出疑問並記錄清楚回覆。
對於業務非常熟悉的開發人員，可以省去口頭解釋需求這一步，直接問需求人員問題。
2）但沒經驗的需求人員的上了就是說，根本不給你提前看需求文件的機會。
然後以前沒接觸的需求必然聽的模稜兩可，最後不得不仔細看需求文件。有疑問馬上找需求人員問清楚，寫下來。
3）老闆兼職需求人員，上了就是說，根本不給你提前看需求文件的機會。
然後以前沒接觸的需求必然聽的模稜兩可，最後需求文件非常簡單，比說的還粗略！！
然後如果你是新人一定要細心再細心（因為在小公司是沒有原型設計、靜態開發，只要需求文件和口頭描述），如果你是老人，有疑問馬上問清楚，並且立刻完善需求文件重發給老闆，
如果老闆懶得要（或少部分技術術語看不懂），你自己一定要有修改後的詳細需求存檔，一定要先全域性把握，寫清楚！
1.2執行者問題：
經常會出現開發人員忘記了，需求人員也忘記了，然後鍋往往是開發人員背。
需求人員理由是：我當時說清楚了，你也沒有什麼疑問，你為啥現在卻有問題了?
鬼知道他當時是說清楚了，你忘記了，還是他根本就沒說！
如果需求人員是你老闆兼職，那你千萬別去反駁，主動認錯，才是解決問題的開始。
因為你們本質上是僱傭關係，不是同級別同事關係，更不是朋友關係。
1.3解決方案：
1.31、需求人員必須說：
1功能點寫清楚，並且口頭解釋清楚！
寫清楚，並且口頭解釋清楚。
3 確定以現有的技術、人員、時間、資金投入一定能夠實現！
1.32、開發人員必須：
1 所有功能點完全理解，並且清楚具體實現的步驟，並且記錄清楚思路。
2 資料**完全理解，並且清楚資料匯入資料庫的具體步驟，並記錄清楚。
3 清楚介面編寫的具體步驟，並記錄清楚。
以上任何一點不清楚必須馬上問清楚、寫下來！！
二、對決策產生意見和分歧時。
特別是改bug和改需求時，特別是老闆兼職需求人員時。
0 執行者，首先千萬不要馬上就去反駁決策者或發表自己的看法，而是仔細聽，弄明白決策者的目的，弄清楚他到底需要你做什麼、做成什麼樣。
1 執行者，不要輕易提出意見和建議，特別是不寬容的決策者。
2執行者，提的建議， 若決策者不採納，執行者可以保留意見，但必須執行。因為決策者有決策的權利和對決策結果負責責任，而執行者無權也無責。
3若執行者盡職責了，但沒到達預期結果，決策者卻把責任歸咎於執行者的無能或低能，那麼執行者要盡快準備另謀出路了，跟著這樣的船長是走不遠的，反而會讓自己變得自卑和膽怯。
想想有點小難受，但實際就是這樣。要知道，人家是決策者或老闆，你是人家花錢聘請的員工而已，你們不是朋友關係，更不是同一級別。
案例分析一：
最近我一直在被老闆罵，我非常窩火，今天分析下。
老闆分給我和同事小c任務，完成乙個頁面，分工是：c賦值多張excel匯入資料庫，我賦值設計資料庫和程式。老闆看頁面，當然會發現一些問題，於是罵我辦事不力。程式問題我就認了，但大部分都是資料問題導致計算結果不符合要求。所以先是去比較客氣的說：小c仔細肯某頁面檢查下資料問題。
但是第二次老闆看功能依然有資料問題，依然罵我。我很窩火，解釋說資料不是我匯入的，不是我的責任。但老闆生氣的說：我哪知道是誰的問題，我只看最後顯示結果！於是我狠狠的去罵c，你對這頁面，把資料檢查好，不要讓我背鍋！！ 老闆指責我說：你不給他指出具體問題他怎麼改？小c心中當然對我有怨氣，老闆這麼說他當然更這麼想。好吧，我去找出了各種資料問題，幫小c與外部資料提供方商量解決方案，然後讓小c按照方案去解決。
這不等於我替小c幹了本該由小c自己被罵和檢查的事，且導致小c埋怨？我並不是小c的上級，不過是乙個吃了兩年工飯和剛吃一年工飯的人合作完成一件事而已，老闆也沒說讓小c聽從我安排。
我想著才是問題根源：我和小c同老闆管理和安排，我對小c沒有管理權，也就理應不對小c負責。 但由於老闆不懂技術，它只看最後結果，而我是最靠近結果上游執行者，所以所有問題他都找我，所以批評也都傳遞給我。
由此，引發下面的思考：
你不可能讓老闆去學技術，你只能給老闆乙個簡單的可操作的責任判斷依據：準備乙個正確的資料，讓老闆確認程式的正確性和完整性。同時用一些錯誤資料測試，總結出能一定程度容錯的判斷邏輯。其他資料，若出現錯誤，讓老闆直接去找小c。
還有：盡量不要與乙個被動的人合作，被動的表現：一件事情完成了，它不會主動向上級匯報；完成不了，他也不會主動向上級告知難處以讓上級去協調經驗豐富的前輩相助。他就這樣捂著，直到最後被上級詢問和責罵。 我不是他上級，合作結果更糟糕，我(替他)被上級責罵，然後替他完成一些他自己能完成的任務。
*程式設計師必須保證程式功能的正確和完整性：
1）用乙個正確的測試資料，執行程式，程式功能執行結果必須是正確和完整的。
就必須保證： 字段儲存、業務計算公式、業務判斷邏輯、許可權邏輯、安全機制、錯誤機制（記錄和提示） 等正確和完整的。
2）用乙個錯誤的測試資料，執行程式，程式功能執行結果的錯誤，必須是可解釋原因的。
就必須保證：能一定程度容錯的判斷邏輯 正確和完整。
3）需求變更後，例如：資料儲存結構改變（新增、刪除、修改資料結構）、計算規則改變，
程式設計師應重新思考 功能具體實現過程的可行性，
若不行，應要求對方給乙個可行的方案，例如計算規則。
若可行，程式修改後應滿足1和2。
此過程，應該管理者應修改合同，按新任務計算新任務時間，而不應讓執行者背黑鍋！
4）若1、2、3成立，則資料錄入錯誤，導致可解釋原因的程式執行錯誤結果，而非程式bug。
應追究錄資料提供者失查和資料入庫者失查責任。而不應讓上游執行者背黑鍋！
*依賴與外部的任務
依賴於別人的任務，應該優先順序要排在最前面；
依賴於別人的任務，有疑問，把所有問題彙總後，統一提出。
別人說的話，要仔細聽和看，立刻思考它的具體實現過程，快速產生疑問，馬上問清楚。而不是馬上執行，執行的過程中突然發現有疑問！ 茶都涼了！
開發注意事項
一 編碼方面 1.ui層面的東西，盡量畫素級復現設計稿，做完之後在ie,firefox,chrome中預覽一遍，確認沒有問題。2.拿到設計稿之前，對業務需求要有所了解，拿到設計稿之後進行推演，檢查互動是否有誤，如果有誤再三確認之後再開始做。3.元件書寫方式，如果輸入的資料能保持一致，則元件裡面處理資...
搭建直播原始碼與軟體開發的注意事項
在這個直播行業飛速發展的時代，很多公會會長在掌握了一定的主播資源後，都希望能搭建自己的直播平台，實現利益最大化，但網上打廣告的技術公司太多，原始碼質量卻良莠不齊，那麼該如何搭建直播原始碼就成了問題。直播平台的建設有很多種方式，可以選擇自主開發，也可以選擇外包研發，還可以購買成熟直播原始碼進行二次開發...
軟體開發具體流程
需求分析 1.相關系統分析員向使用者初步了解需求，然後用word列出要開發的系統的大功能模組，每個大功能模組有哪些小功能模組，對於有些需求比較明確相關的介面時，在這一步裡面可以初步定義好少量的介面。1 2.系統分析員深入了解和分析需求，根據自己的經驗和需求用word或相關的工具再做出乙份文件系統的功...