摘要: 互聯網，從今年5月~7月的準備，再到8月入職至今的半年以來，感受和經歷有很多。年末歲尾、空閑之余，來梳理那些日子里還記憶尤新的片段。
畢業后開始做程序員、工作第3年轉做了系統分析師，第5年轉做項目經理，1年之后投入互聯網產品至今。7.5年的職業生涯里，在收獲各階段經歷的同時也在感受著互聯網行業帶來的各種變化。而對于轉互聯網的初衷及時機，概括來說有如下幾點：
1.互聯網產品更加貼近生活、更有趣、更喜歡
2.積累了軟件開發、產品及項目管理工作經驗
3.積累了互聯網產品規劃、設計、管理及運營等書籍閱讀和筆記
4.積累了對一些互聯網產品的看法和見解
從開始關注互聯網產品，到感興趣和不間斷關注，到最后加入這個圈子，那些過往的情景還歷歷在目：  閱讀全文      摘要: 高速發展的世界，需要我們迭代地開發和改進業務問題的解決方案，我們需要一些方法來持續探索業務及其問題，將這些要求告訴技術專家，他們為業務提供技術解決方案。
許多組織機構不是等待需求的所有細節都得到定義，而是更喜歡迭代完成這些業務活動，定義一些需求，開發一部分解決方案，定義更多的需求，這樣增量式交付發行版本，直到解決方案被判定完成。這種迭代的方式意味著，業務環境和開發環境中的關注點、想法和變化更加同步。使開發者更了解今天的業務問題，工作的產品適合今天的業務環境。
這種持續的工作探索意味著，業務分析師持續地將新故事或需求加入分析列表，這個列表又持續地按價值進行分析，最重要的是按業務價值來分析。列表根據價值和緊急性來排列優先級，最高優先級的需求交給開發者開發。  閱讀全文      摘要: 今天的大多數軟件都不是擁有它的組織機構開發的，而是購買的。考慮到這些開發和解決方案選項，今天的業務分析師有一項額外任務：即決定最佳的策略來發現和溝通需求，不論組織機構決定采用哪種方式實現自動化。
以需求策略作為指導，決定從哪里開始，是否有足夠的細節，你需要哪個迭代循環，記錄知識時采用哪種形式，何時復查，何時讓哪些利益相關者參與，何時構建原型，何時以及如何做大量的事情，讓你的工作更接近為業務產生最優價值，每個項目的情況不同，有必要采用不同的做事順序、做事細節、溝通形式。  閱讀全文      摘要: 需求評審環節檢查了單項需求，確保它表述正確、無二義性、在范圍內、可測試、可追蹤、不是鍍金需求，從而確定制有正確的原子需求才包含在需求規格說明中。
接下來，必須考慮需求規格說明是否完整，這意味著將規格說明作為一個整體來復查，確保應該有的部分都有。
這種復查可以在任何時候進行，而不只是在發布之前，它可以是一項持續的活動。
  閱讀全文      摘要: 需求來自于人，人們并非總能確定他們需要什么，并非總能解釋他們想要什么，需求也并非總是編寫地很小心，完整無二義。
需求工作的要點是要確保交給開發者的東西是準確的、完整的、無二義的，陳述了真正的需求。任何不足都有違需求工作的初衷。開發者可以構建任何東西，但他們首先必須知道他們必須構建什么。  閱讀全文      摘要: 如果產品有一項需求，要執行某個功能或具備某種屬性，那么測試活動必須展示產品確實執行了該項功能，或具備了該項期望的屬性。為了進行這樣的測試，需求必須有一個測試基準，這樣測試者才能比較提交的產品和最初的需求。要注意的是，這里的驗收標準既不是測試，也不是對測試的設計，而是測試提交的產品必須采用的測試基準，是構建測試用例的輸入信息。  閱讀全文      摘要: 為什么所謂的‘非功能需求’也很重要？請考慮一個真實發生的故事：客戶拒絕了交付的服務臺軟件。功能是正確的，但客戶不想要它。為什么？因為客戶拒絕使用它，更愿意采用原來的人工過程。這就是需求團隊幾乎沒有注意非功能性需求。
只所以需要這些非功能需求，不是因為它們是產品的功能活動（諸如計算、操作數據活動），而是因為用戶希望這些活動以特定的方式執行，并達到特定的品質。
例如，亞馬遜網站很容易導航，這讓客戶容易找到對象，它也很友好，讓你覺得自己是尊貴的顧客，你可以寫評論，通過購物伙伴和亞馬遜推薦得到指引，很容易查看和安排送貨，等等。  閱讀全文      摘要: 通過產品用例（PUC）場景展示和確定了解決方案后，下面就需要PUC場景轉換到功能需求。
功能需求指明了產品必須做的事情，即產品為了滿足它存在的根本理由而必須執行的一些動作。需求分析師理解了產品必需的功能后，他要用功能需求告訴開發者要構建什么。
  閱讀全文      摘要: 當需求人員和客戶之間針對需求溝通中的業務本質問題達成一致時，接下來就是溝通和確定多少業務將通過產品來實現自動化。作為需求分析人員，需要在業務需求、包含的功能、用戶體驗、非功能需求、開發成本、技術可行性、限制條件這些因素之間取得平衡和折中來完成解決方案的確定和發布。
沒有公式化的方法能得到最佳的解決方案，需要實際過程中考慮和權衡。  閱讀全文      摘要: "我知道這是我提出的,但這不是我想要的。”你不必在IT這行待很長時間就能聽到這句話，看著期待的笑容從開發者臉上消失，因為這事經常發生。開發者交付了客戶提出的需求，但結果卻不能解決他們的業務問題。為什么？因為真正的問題從未闡明，所以從未正確理解。
在做需求調研和收集時如果聽到的都是客戶關于解決方案的想法，而不是描述背后要解決的問題，這可能是個好的解決方案，但更有可能的是，它受限于客戶的經驗和想象力。而且，你不清楚它是否解決了正確的問題。所以，作為需求分析人員，你的任務就是解釋客戶所說的內容，揭示它的本質。  閱讀全文      摘要: 不論哪種工作，試圖改變之前先對它有充分的理解，如果一頭沖進去，對你要改變的東西幾乎沒有理解，就進行‘改進’，那么結果不如意也不奇怪。當你開始理解原有的工作時，肯定會產生一些想法，知道如何改進它。
這里探討的比較常用的Brow Cow模型和一些用于發現業務過程的調研方法，而實際過程中不可避免地需要多種調研技巧組合使用，具體情況需要具體應對。  閱讀全文      摘要: 項目啟動過程建立了工作的范圍，即要研究的業務領域，業務領域其中的一部分將通過預期的產品實現自動化。而實際上，這個工作范圍可能太大，難以作為一個單元進行研究，正如吃東西之前先要將它切成小塊一樣，需要將工作范圍分解為一些可管理的部分，然后再來研究它以發現產品的需求。這里將需求過程中涉及到主要對象以及它們的分工界面通過一張關系圖來展示：  閱讀全文      摘要: 從通信行業的產品工作到政府行業的項目工作，一直在和‘需求’打交道，不同的行業特點和項目環境需要針對性的需求發現和實現方法，但圍繞需求調研、分析、編寫、評審、驗證到需求交付這幾個過程基本是相通的。經歷從瀑布型項目需求策略到迭代型需求策略的轉變和實踐過程，回過頭來看《軟件開發方法學-掌握需求過程》，進行摘錄和梳理的同時，也加深和沉淀一些對需求的理解和認識。以此片文章開始，分享一些讀書筆記：  閱讀全文      摘要: 剛給大輝發完郵件準備去上班，微信群里熱鬧不已，原來是pmp成績出來了，盡管考試完后心里基本有底，但聽老師說這次考試偏難，等在待結果出來的前夕，還是不免忐忑。
2013年年初報名直到2014年3月份才考試，倒也是好事，實際工作中的那些事和那些人，總能在復習的過程中讓自己反復思考和碰撞。而4m1p的成績單，算是給自己交了一份滿意的答卷，在這里簡單回顧一下，有興趣的同學可參考：
【復習歷程】：
1、 關于教材劃分（含：1本教材（2012版）、3套模擬題、1本輔導書），自己是按下面四部分來分批閱讀：
第1章 項目引論、第2章 組織影響和項目生命周期、第3章 項目管理過程
第4章 項目整合管理
第5章 項目范圍管理、第6章 項目時間管理、第7章 項目成本管理、第8章 項目質量管理
第9章 項目人力資源管理、第10章 項目溝通管理、第11章 項目風險管理、第12章 項目采購管理、  閱讀全文      摘要: 這段時間以來的產品使用過程，界面性能和易用性成為關注的重點。相比運營商項目不同，政企項目驗收過程相對簡單，沒有嚴格的測試用例，以是客戶組織的項目評審會，公司匯報階段進展、客戶做業務測試的方式開展。
簡單回顧上線期間一些工作：
1）公司側提供《需求規格說明書》、《產品使用手冊》、《角色權限清單》
2）業務部門整理《用戶申請表》、《業務制度管理辦法》
3）業務部門組織上線前項目例會
3）業務部門發布系統上線公告
4）業務部門組織用戶培訓
5）公司和業務部門提供產品使用支持，解答最終用戶的操作疑問、收集產品反饋。  閱讀全文      摘要: 項目進入試用階段，版本節奏也相對平緩，對于需求&開發&測試過程中的一些管理，分享一些個人體會，歡迎指正。開始正文之前，存在下面前置條件：
1.本輪版本要交付的功能及時間已已評估并與客戶達成一致，是以交付時間倒推來管理《需求規劃》和《研發計劃表》的方式。
2.團隊資源：有測試組長，開發組長是臨時支持（同時兼顧其他項目）。
3.開發4人、測試2人、需求1人，迭代周期1～2周。
4.需求、開發和測試在一起辦公。  閱讀全文      摘要: 項目接近尾聲，需求也逐漸收斂。面對需求變化頻繁、迭代版本周期較短的客觀情況，傳統模式已不能在此生搬硬套。雖現有的開發過程談不上正規敏捷，也算接近小步快跑的節奏。下面分‘需求開發&代碼開發、版本控制、版本發布、增量升級’幾個部分，記錄一些體會，歡迎指正：
（1）需求溝通&代碼開發：
1、針對有可以復用的現有模塊時，和開發人員溝通主體思路，由開發人員著手開發，開發人員在開發期間與需求人員充分溝通，碰到疑問及時澄清、解決。
2、針對沒有可復用的模塊且涉及較復雜的業務流程時，需求人員畫原型圖（緊急情況手繪草畫），開發人員按原型圖或草圖著手開發。
3、需求人員記錄開發過程中和開發人員、客戶溝通的需求變化點。
4、功能開發完成、客戶驗收后，及時補充到《需求規格說明書》。
（2）版本控制：
1、代碼提交前做比較再合入版本庫（嚴禁合入非自己修改的文件）。
2、合入代碼需填寫修改信息，新版本開發只填寫修改信息，優化修改還需在BU  閱讀全文      摘要: 5W1H原則：
what：用戶需求是什么，要做什么功能。
why：產生這個需求的背景是什么，原因是什么，能幫助用戶解決什么問題。
who：功能需求做出來了，哪些角色會參與使用。
where：功能需求的使用環境是什么（如：操作系統、瀏覽器環境，分辨率環境）。
when：功能需求何時交付（基于交付時間，考慮實現方案的選擇）。  閱讀全文      摘要: 8、9、10三月，需求依舊爆棚，相比純業務功能的開發，數據的匯聚、整理、分析、統計成為重點，具體細節不一一展開，按如下關鍵詞：任務計劃、項目溝通、項目流程、客戶匯報、業務關注、時間評估、管理筆記做一些筆錄，持續更新：
1、任務計劃：
1.決策前考慮充分，決策后不再懷疑。
2.任務精細、描述清晰，對內分解針對到負責人、給外匯報針對產品功能。
3.計劃制定時，請成員預審任務量，再和開發、測試確認時間，由成員承諾時間。
4.安排任務多人完成時，指定一個牽頭人。
5.大的需求，組織討論，小的需求，點對點溝通，最后要全部閘口到文檔。  閱讀全文      摘要: 6、7兩月，時間很快，周末的時間來做些梳理、小結，好的要繼承，不好的去改進。下面，分日報管理、計劃管理、客戶管理、需求管理、客戶匯報、團隊建設幾個方向，梳理一些記錄，歡迎指正。
1、日報管理
1.項目啟動會召開，介紹項目背景，時間計劃和項目目標，使團隊成員有共同的認識。讓團隊成員之間互相介紹，以彼此熟悉。
2.根據收集和掌握的需求任務，編寫項目計劃、安排日報（體現當天任務在項目計劃中的完成百分比、當天任務完成百分比）。首次發日報前，與日報匯總人員點對點溝通編寫格式，注意事項，重在量化指標。
3.根據日報匯總人員匯總的內容，了解各開發、測試成員的工作飽和度及工作質量，以針對性安排后續新任務。  閱讀全文