通信&政企產品
PMP考試
摘要: 剛給大輝發完郵件準備去上班，微信群里熱鬧不已，原來是pmp成績出來了，盡管考試完后心里基本有底，但聽老師說這次考試偏難，等在待結果出來的前夕，還是不免忐忑。
2013年年初報名直到2014年3月份才考試，倒也是好事，實際工作中的那些事和那些人，總能在復習的過程中讓自己反復思考和碰撞。而4m1p的成績單，算是給自己交了一份滿意的答卷，在這里簡單回顧一下，有興趣的同學可參考：
【復習歷程】：
1、 關于教材劃分（含：1本教材（2012版）、3套模擬題、1本輔導書），自己是按下面四部分來分批閱讀：
第1章 項目引論、第2章 組織影響和項目生命周期、第3章 項目管理過程
第4章 項目整合管理
第5章 項目范圍管理、第6章 項目時間管理、第7章 項目成本管理、第8章 項目質量管理
第9章 項目人力資源管理、第10章 項目溝通管理、第11章 項目風險管理、第12章 項目采購管理、
閱讀全文
posted @
2014-04-19 09:35 cheng 閱讀(1125) |
評論 (2) 編輯
產品上線期間的那些事
摘要: 這段時間以來的產品使用過程，界面性能和易用性成為關注的重點。相比運營商項目不同，政企項目驗收過程相對簡單，沒有嚴格的測試用例，以是客戶組織的項目評審會，公司匯報階段進展、客戶做業務測試的方式開展。
簡單回顧上線期間一些工作：
1）公司側提供《需求規格說明書》、《產品使用手冊》、《角色權限清單》
2）業務部門整理《用戶申請表》、《業務制度管理辦法》
3）業務部門組織上線前項目例會
3）業務部門發布系統上線公告
4）業務部門組織用戶培訓
5）公司和業務部門提供產品使用支持，解答最終用戶的操作疑問、收集產品反饋。
閱讀全文
posted @
2014-03-26 22:05 cheng 閱讀(1353) |
評論 (3) 編輯
需求管理和進度管理的一些體會
摘要: 項目進入試用階段，版本節奏也相對平緩，對于需求&開發&測試過程中的一些管理，分享一些個人體會，歡迎指正。開始正文之前，存在下面前置條件：
1.本輪版本要交付的功能及時間已已評估并與客戶達成一致，是以交付時間倒推來管理《需求規劃》和《研發計劃表》的方式。
2.團隊資源：有測試組長，開發組長是臨時支持（同時兼顧其他項目）。
3.開發4人、測試2人、需求1人，迭代周期1～2周。
4.需求、開發和測試在一起辦公。
閱讀全文
posted @
2014-01-19 22:40 cheng 閱讀(1919) |
評論 (5) 編輯
開發過程筆記
摘要: 項目接近尾聲，需求也逐漸收斂。面對需求變化頻繁、迭代版本周期較短的客觀情況，傳統模式已不能在此生搬硬套。雖現有的開發過程談不上正規敏捷，也算接近小步快跑的節奏。下面分‘需求開發&代碼開發、版本控制、版本發布、增量升級’幾個部分，記錄一些體會，歡迎指正：
（1）需求溝通&代碼開發：
1、針對有可以復用的現有模塊時，和開發人員溝通主體思路，由開發人員著手開發，開發人員在開發期間與需求人員充分溝通，碰到疑問及時澄清、解決。
2、針對沒有可復用的模塊且涉及較復雜的業務流程時，需求人員畫原型圖（緊急情況手繪草畫），開發人員按原型圖或草圖著手開發。
3、需求人員記錄開發過程中和開發人員、客戶溝通的需求變化點。
4、功能開發完成、客戶驗收后，及時補充到《需求規格說明書》。
（2）版本控制：
1、代碼提交前做比較再合入版本庫（嚴禁合入非自己修改的文件）。
2、合入代碼需填寫修改信息，新版本開發只填寫修改信息，優化修改還需在BU
閱讀全文
posted @
2013-12-27 20:47 cheng 閱讀(1310) |
評論 (0) 編輯
平臺軟件需求分析和設計實例
摘要: 5W1H原則：
what：用戶需求是什么，要做什么功能。
why：產生這個需求的背景是什么，原因是什么，能幫助用戶解決什么問題。
who：功能需求做出來了，哪些角色會參與使用。
where：功能需求的使用環境是什么（如：操作系統、瀏覽器環境，分辨率環境）。
when：功能需求何時交付（基于交付時間，考慮實現方案的選擇）。
閱讀全文
posted @
2013-12-01 16:30 cheng 閱讀(1812) |
評論 (0) 編輯
項目規劃與管理記錄2
摘要: 8、9、10三月，需求依舊爆棚，相比純業務功能的開發，數據的匯聚、整理、分析、統計成為重點，具體細節不一一展開，按如下關鍵詞：任務計劃、項目溝通、項目流程、客戶匯報、業務關注、時間評估、管理筆記做一些筆錄，持續更新：
1、任務計劃：
1.決策前考慮充分，決策后不再懷疑。
2.任務精細、描述清晰，對內分解針對到負責人、給外匯報針對產品功能。
3.計劃制定時，請成員預審任務量，再和開發、測試確認時間，由成員承諾時間。
4.安排任務多人完成時，指定一個牽頭人。
5.大的需求，組織討論，小的需求，點對點溝通，最后要全部閘口到文檔。
閱讀全文
posted @
2013-11-09 22:48 cheng 閱讀(2172) |
評論 (3) 編輯
項目規劃與管理記錄1
摘要: 6、7兩月，時間很快，周末的時間來做些梳理、小結，好的要繼承，不好的去改進。下面，分日報管理、計劃管理、客戶管理、需求管理、客戶匯報、團隊建設幾個方向，梳理一些記錄，歡迎指正。
1、日報管理
1.項目啟動會召開，介紹項目背景，時間計劃和項目目標，使團隊成員有共同的認識。讓團隊成員之間互相介紹，以彼此熟悉。
2.根據收集和掌握的需求任務，編寫項目計劃、安排日報（體現當天任務在項目計劃中的完成百分比、當天任務完成百分比）。首次發日報前，與日報匯總人員點對點溝通編寫格式，注意事項，重在量化指標。
3.根據日報匯總人員匯總的內容，了解各開發、測試成員的工作飽和度及工作質量，以針對性安排后續新任務。
閱讀全文
posted @
2013-08-04 10:38 cheng 閱讀(1873) |
評論 (2) 編輯
小網站交付體會
摘要: 接到任務，開發一個用于項目管理的小網站，功能比較簡單，目的在于方便會議紀要、文檔資料上傳、查閱，消息發布和消息反饋。從需求溝通、時間溝通、需求分析、原型評審、軟件開發到產品交付，歷時8天，2輪用戶需求，2次加班沖刺，可以說是階段性的完整交付使用。
時間回顧：
客戶期望的時間：1天
溝通爭取的時間：2天
產品交付的時間：延期1天（開發測試歷時4天，算上周六）
新需求期望時間：2天
溝通爭取的時間：2天
新需求交付使用：2天
閱讀全文
posted @
2013-06-23 12:24 cheng 閱讀(2524) |
評論 (1) 編輯
項目化運作思考
摘要: 新的環境、新的成員、新的客戶和新的文化，過去的2個月更多的時間忙于應戰，周末難得的梳理時間，來做些回顧和總結。
加入之初，項目啟動已經開始，對于陌生的一個產品和團隊，盡快熟悉掌握的方法莫過于通過文檔和產品環境的方式、通過日常的溝通熟悉人員。和成員一起，對產品全流程進行了驗證和記錄。市場類的項目，通過會受到直接客戶的一線壓力，尤其是新業務的項目，開始階段往往是客戶主導、公司研發，項目計劃的時間變更也相對頻繁，疲于迎戰的局面開始凸顯，但項目初始為了市場占有率，趕工和加快進度的項目方式是需要的。
閱讀全文
posted @
2013-06-16 13:57 cheng 閱讀(2592) |
評論 (2) 編輯
產品升級過程的一些活動
摘要: 對于新型產品，工程支撐力度在初期會較弱，在產品升級期間會需要產品規劃人員參與，作為牽頭人的角色，協調于工程經理、研發項目經理和工程團隊之間，扮演產品顧問的角色。同時，會參加客戶召開的需求升級討論會，和各平臺廠商的人員溝通升級計劃和安排。其中，對需要產品規劃人員親赴現場參與升級工作的情況，談談個人的一些經驗：
1）了解產品研發進展
2）安排前方工程團隊了解此次升級背景、升級業務（不限于現網的物理組網圖、現網的業務種類、現網的業務運營時段、升級后的現網業務種類、升級后的業務運營時段、業務涉及各個網元的IP地址、端口、接口模塊的帳號密碼）和客戶的升級方案。
閱讀全文
posted @
2013-04-17 21:01 cheng 閱讀(1396) |
評論 (2) 編輯
需求研發過程的一些活動
摘要: 項目生命周期中，變更和糾正錯誤的代價在項目接近完成時通常會顯著提高。所以在項目研發過程中，需求分析師要參與到產品研發過程，與開發人員、測試人員保持緊密溝通，討論和澄清在實現過程中的需求疑問，保證產品產出和需求意圖的吻合。軟件項目中的需求變更，相信做需求的人員再熟悉不過，需求變更率的高低，也是反應需求工作好壞的一個重要KPI。對于需求變更的發生，唯有面對和解決。通常的做法：了解需變更背景、評估影響程度，考慮與各干系人的溝通（客戶、市場、研發、工程和領導），將評估結果作為變更請求，提交給項目管理團隊，獲批準后，按新計劃開展產品研發。
下面是在項目研發過程中需求端會參與的一些活動：
閱讀全文
posted @
2013-03-29 11:55 cheng 閱讀(1485) |
評論 (0) 編輯
產品工作中的溝通與協調
摘要: 1）明確目標：
會議室及電話會議，開會前列出會議章程（最好可以先發個郵件或者打個招呼，告之這次參會人員的大概情況），會議后要有會議結果（及時輸出會議紀要）。
會議紀要可以包含下面幾個部分：
1.參會人員、日期、時間
2.會議議題（討論要點）
3.會議紀要（討論過程的概括及描述）
4.后續策略及關鍵事件跟蹤（后續事件及對應負責人和時間點）
閱讀全文
posted @
2013-03-10 13:36 cheng 閱讀(1779) |
評論 (0) 編輯
淺談需求分析
摘要: 開始接觸需求工作時，在對用戶需求的溝通基礎上，多依據于做軟件開發的結構化思維方式來編寫需求文檔，這種方式易陷入實現細節的陷阱。如何在用戶需求和軟件需求之間找到平衡點，使得做出的產品即是用戶想要的又在技術可行和成本上性價比最高，甚至超出用戶期望，給用戶驚喜，開展需求工作時需認真考慮。
業內談得比較多的‘六何法（what、why、when、who、where、how）’，在需求分析工作中同樣適用，可作為問題分析的基本習慣。下面談些自己的理解：
1、信息收集和初步分析：
what：需求是什么，解決什么人的什么問題（用戶群體、用戶規模、業務場景、性能指標和組網）？
why：背景是什么，為什么有這個需求（高層領導思路、團隊主動規劃需求、競品分析需求）？
when：需求的市場時間（實驗室驗收、試運營和正式上線等各階段時間）？
who：需求的用戶對象是誰（如：技術部門），是否與其他用戶對象（如：業務部、內容部、運維部門等）有關聯？
where：哪里做（現場開發還是團
閱讀全文
posted @
2013-02-18 22:53 cheng 閱讀(2676) |
評論 (2) 編輯
產品規劃這兩年
摘要: 互聯網發展速度是驚人的，回首從博客—>微博—>微信的這幾年，自己也從Java軟件開發轉到了產品規劃工作。期間經歷了大小不一的各類運營商的平臺規劃工作，選擇在此時來回顧，一方面是給自己這兩年的忙碌找個借口。另一方面，更多的是一種經歷過后的感觸，就先從產品規劃工作的定義開始，分享自己的理解吧
指通過在了解市場、了解客戶需求、了解競爭對手、了解外在機會與風險、了解市場和技術發展態勢的基礎上，根據公司自身的情況和發展方向，制定出可以把握市場機會，滿足用戶需要的產品的遠景目標以及實施該遠景目標的戰略、戰術的過程。
1）技術角度：負責需求溝通、收集、分析、評估、澄清、轉換、評審、版本規劃、研發跟蹤、版本發布。
1.溝通，從市場價值、技術可行性和時間&人力成本方面綜合考慮以確認是接受還是引導客戶。
2.收集，從客戶的市場、技術、業務、運維人員、友商人員和公司內部市場人員，多渠道獲取CI信息。
3.分析，采取自底向上、透過現象看本質以抓客戶的核心需求。
閱讀全文
posted @
2013-01-13 23:07 cheng 閱讀(1759) |
評論 (1) 編輯