專案管理常見問題

專案實施全流程

科技為業務賦能 (節約人力至按點下班, 業務開心; 節約人力至裁員, 業務會強烈抵制)

監管要求 (卡上級檢查節點, 容易驗收, 不容易有額外需求)

面子工程 (前端樣式要求高)

專案發起人的滿意程度很大程度上決定專案驗收難易(一般這個層級得好看, 不然怎麼給領導寫ppt)

售前階段就會開始圈定實施的專案範圍

需要初步控制範圍，並在投標書中有所響應

商務,銷售與行方建立的關係影響很大, 可能poc分數超過第二名**商也被pass(事先了解很重要, 別投入大, 只是湊數的)

了解客戶看重點(技術型, 不冒煙不罷休; 業務型, 好用才是王道; 兩者兼具也很常見了)

poc評分規則也能看出公司產品是否符合, 評分標準是否已被其他廠商引導過(人家都是老鐵了, 就別瞎摻和了)

需初步確定的工作範圍 (專案工作說明書, sow簽訂)

特殊情況需雙方協商, 公司開具提前入場函 (還是多想想有坑沒吧, 畢竟一入豪門深似海, 金主惹不起)

控制成本的關鍵, 標準產品實施最優(完全定製化另當別論), 產品的滿足程度越高，範圍約可控 (就部署個應用爽不爽?)

適當的縮減範圍，有時也能有效縮減專案週期，滿足客戶要求的上線要求，這是乙個雙贏的結果; (往往是一期二期間的需求替換, 二期的坑就不知道誰來填了)

需求不匹配程度很高，專案範圍不可控，需要協調領導層決策(沒事少招惹領導, 不然要你幹嘛, 哎, 沒辦法了)

需求的約定需要引導客戶, 把控客戶預期, 預期過高專案易不可控 (我這就乙個炮仗, 送不了你上月球)

業務需求(主要是指專案的業務類別: 信貸審批, 交易反欺詐, 知識圖譜, 客戶畫像, 裝置指紋, 資料倉儲, 機器學習), 接入多少個渠道

功能需要(滿足客戶業務, 需要哪些功能. 登入, 許可權隔離, 字典配置, 多級審核,審批 是一些最基本的功能 )

非功能需求(資料安全, 合規性, 吞吐量, 併發數, 響應時長, 高可用, 易擴充套件, 災備等等對軟體的特殊要求)

要求對產品有一定的熟悉程度, 引導客戶向我們產品容易實現得方案進行(就是忽悠)

針對客戶定製化需求需要有清晰判斷, 規避難以實現的業務需求,避免架構上的傷筋動骨(範圍內還是範圍外; 全新開發, 還是現有產品簡單改造)

避免xy問題, 都是貸後, 現有產品只是簡單的"貸後監控", 而客戶實際需要的是貸後管理, 預警, 催收一整套系統(答應了還想跑? 又不是程式猿刪庫就好, 違約等著你)

一些單純為應付監管, 甚至客戶自己都不知道需要哪些功能,需要專業引導 (不然過條小河造個小船的事, 客戶非給你畫個航母出來), 細化, 細化, 再細化 (都有指著近期兩字問你, 為什麼只有6個月的統計? 不能統計所有的麼?為啥不寫清楚?)

大資料相關專案, 資料調研尤其重要, 前期的資料調研需投入較多人力支援, 客戶對自身的資料質量一般沒有乙個準確的判斷，抽樣具體場景的資料做判斷(不要你覺得, 我要我覺得)

現階段大部分客戶資料質量不高, 優化資料調研的流程, 列清需求重點調研項, 客戶資料質量實在非常差, 需要降低客戶預期, 提前和客戶溝通清楚(資料質量決定模型高度, 再牛叉的演算法也只是逼近這個高度)

遵循設計模式, 以應對可能出現的變更

需求範圍風險, 實施成本與時間成正比, 需求範圍控制得好實施時間就不會延長太多, 專案才能盈利(最不願做的就是附贈專案, 誰來支援? 開發聽著都沒興趣; 從開始就虧錢的專案, 沒發現風險就接了, 領導都不願理你; )

客戶風險, 客戶預期過高, 不利於實施,驗收; ps: 一般甲方科技部門與業務部門關係不會很和諧, 入場不站隊都不好意思說自己混過乙方, 優先站強勢隊伍, 另一方相對中立即可

延期風險, 避免依賴其他渠道影響進度, 先約定成文件(郵件知會干係人,扯皮關鍵), 擋板開發, (時間節點評估寧願事先扯皮多評估, 不要最後到店再提延期)

成本超支風險, 遠端開發, 節約駐場成本; 功能復用, 很多功能各個專案都是需要的, 盡量抽取復用

關鍵風險點, 會引發其他一系列風險, 保質保量完成專案的驗收結項，與這個有衝突的，都可以視為風險，都是作為專案經理需要排除的問題。

專案實施本質上是乙個服務的過程，現場人員的表現就代表服務質量

實施一項關鍵能力是換位思考的能力, 只有知道客戶真正想要什麼, 才能為題提供好服務

實施過程中, 不遇見個奇葩那就太不正常了，見人說人話, 見鬼說鬼話, 心裡抗壓唄, 不然還能來個肉體間壓力釋放啊

複雜專案問題處理, 分析問題根本原因, 針對問題作出判斷, 出解決方案, 然後執行. (需求變更: 首先從業務角度判斷客戶需求的合理性，然後看需求是否是專案範圍內，如果是專案範圍外，需要和客戶協商做需求變更流程，同時告知客戶需求變更對計畫的影響)

實施類專案的週期往往和成本成正比, 作為專案經理需要專注於專案的落地 (得盈利啊, 難啊)

sit測試

系統操作手冊, 系統培訓

引導業務uat測試, 配合驗證

上線部署操作手冊

迭代, 注意回滾方案制定

上線穩定執行報告 (系統監控指標)

配合業務提供成果展示, 讓專案發起人滿意, 讓領導滿意, 不然科技,業務拿什麼邀功, 沒啥好處給你驗啥收

生產出事了咋搞? 先止損唄, 保護好現場, 證據翻起來; 小事 -> 證據留好, 人情給我欠著; 大事 -> 鍋能甩就甩起來, 甩不動了, 領導?我這有瓶82年得二"鍋"頭, 剛溫的, 嚐嚐? 商務,法務搞起來(開玩笑, 鍋要自己抗, 不然大佬們怎麼撈你)

專案驗收在sow中有約定, 專案上線穩定執行約定期限後可按約定協商驗收

專案驗收的順利往往和客戶滿意度有關，如果專案達到或者超過預期，往往驗收會比較順利 (我們的目標不只是完成專案上線，而且需要在保證專案上線的基礎上, 也要讓客戶滿意, 問題及時處理, 小需求及時響應)

對於科技部門, 系統穩定, 易維護, 高可用; 對於業務部門, 系統易用, 穩定, 結果正確; 對於專案發起人, 展示效果達到或超過預期

了解客戶現階段痛點

與銷售配合

信貸 -> 客戶各渠道獲取的資訊數位化, 評估信用是否達標;

反欺詐 -> 歷史交易與當前交易資訊整合,評估當前交易風險狀況;

預警 -> 事中批處理, 是否達到閾值

知識圖譜 -> 將死板的**活化成圖(點->實體; 邊->實體間關聯關係)

技術是大佬, 技術評審隨便浪

產品熟練程度可以秀到飛

業務還能指導下甲方

性格好, 只要不動手你隨意

對於出差或者加班不排斥, 能抗壓, 就是落地專案

一直從事相關行業實施工作，專案管理經驗有欠缺，充當技術經理角色, 和客戶的溝通也非常多, 專案經理不在場時會充當專案經理角色, 完成專案交付是沒問題

軟體專案管理常見問題

問題一 缺乏專案管理系統培訓 問題說明 專案經理在專案管理方面的培訓較少或不夠系統。專案經理或管理人員不了解專案管理的知識體系和一些常用工具和方法，所以在實際工作中沒有專案管理知識的指導，完全依靠個人現有的知識技能，管理工作的隨意 性 盲目性比較大。有些學員說 聽了這些課才知道專案管理原來還有這麼多...

軟體專案管理常見問題分析 二

問題六 不重視專案經驗的總結 問題說明 專案經理在專案結束時有些是因為自身對寫文件工作的興趣或意識，或者是因為緊接著要參加下乙個專案，總體對專案總結的重視程度不夠。有些是專案總結報告一再拖延，有些是交上來的報告質量較低，敷衍了事。問題點評 專案經驗總結非常重要，有利於組織內部或行業內部經驗與資料的積...

專案管理工具常見問題

今天在北京為一家軟體開發公司做培訓 診斷。當談到度量與分析，他們部門經理就要求專案經理開啟他們使用的免費專案管理工具，希望讓我看看他們如何度量與監控專案。專案經理開啟專案展示了一些任務的記錄和圖表 如，敏捷的燃燒圖和任務實際完成多少 我問 從度量與分析的角度，你們度量的主要目的是什麼？他想了一下，然...