實戰解析 專案目的和範圍

2022-02-18 01:53:30 字數 1124 閱讀 2698

任何有明確時間約束和結果要求的事情我們都可以稱之為專案,專案培訓上老師會給大家講所謂的

qrt三重限制:產出、資源、時間,要想產出又多有好,那勢必投入更好的資源或者延長時間,這應該不太難理解。但是根據我的真實感受,還應該在再強調:目標

(或者說動機)3

分鐘可以到現場進行救援!

我們示範的專案名稱是:

x市的電信動力監控系統

目的:當異常情況發生後

2秒內把資訊傳送到指揮中心,並產生報警。

我們每人都應該用過電信的固定**,但是可能大家沒有注意過,當停電的時候,我們的**系統卻還能正常地工作。通常在乙個市裡有多個電信動力局房,通常有幾組交流變壓器,在正常供電時給電信裝置供電,當市電停止**時自動轉為電池供電,而電池組通常只能支援個把小時,如果遇上颱風等惡劣天氣,那就只能靠柴油發電機來為大家保證通訊的動力了。所以通常每個局房都配有專員檢查維護這些裝置,檢查人員通常要檢視溫度,電壓等引數來確定機器是否正常運作。

所以這個專案就是要給

x市的電信動力保證系統上乙個台階,為此需要增加一些模數感測器安放在局房動力裝置上用於採集各項引數指標,在每個局站還要增加相應的工控機器用來收集和處理這些訊號,當出現告警時本地必須進行聲光報警,有條件的局站還可以安裝簡易的監控軟體對本地的裝置進行監視和控制。與此同時,所有的資料也必須同步送網市電信總監控站,在那裡可用統一檢視全市的動力保證系統的狀態,還可以對這些情況進行分析,發現一些隱患。在

x市成功運用後,還可能在本省其他市推廣,在省局建立本省的集中監控台。

以上是典型的傳統需求概述

(當然我已經把上百頁的

srs簡化得不能再簡化了

),使用我們的方法,可以把它改成圖形化表述如下:

為了方便後面討論核心要點,我們將約定如下:

a) 不討論標有打勾的需求,你就當它可用得了;

b) 標有美元符號的需求我會再總結時講一些心得;

c) 標有鑰匙符號的需求很明顯,是這個專案關鍵的需求(其實這也是我後來感覺到的);

雖然r21需求本次不涉及,但是他是客戶體驗的乙個關鍵需求,給大家乙個感性認識如下圖:

r23很重要,它是專案提公升商業價值的乙個好包裝,如下:

ok,我又要做其他工作了,有疑問的朋友可以跟帖,我將一邊準備設計部分的資料一邊給需求答覆。

alex 11-21

專案管理(八) 控制專案的範圍

接著上篇,確定了專案的利益相關者之後,先別急著進入開發階段,我們接下來要做的是先控制專案的範圍,專案的範圍控制好了才能保證後續的開發不會因為專案範圍變更而做大量無用功,看下面介紹 一 確定專案不做什麼 實踐經驗告訴我們,在進行專案範圍變更時,或者說在劃分專案邊界時,確定專案不做什麼比確定專案做什麼更...

實戰專案的整體思路

工作多年的人可能拿到乙個專案的瞬間,就能在腦海裡面規劃出整個專案大概的開發流程或者計畫,這都是從許多專案中磨練出來的,現在我把這些思路提煉一下,希望能幫助到剛入門的同學,主要是想讓你們提前了解一下普通公司完成乙個專案的整體流程和思路,你可以對比一下在學校裡面做專案的流程。在我之前的工作中,普通的專案...

控制軟體專案的範圍變更

範圍管理是專案成功的基礎和重要因素。如果不能合理界定專案範圍,專案就無法啟動,無法進行專案管理,意外的變更將會隨時出現,專案也會返工 費用上公升甚至不能完成。專案範圍管理的核心就是控制專案範圍變更。目前,專案在實施過程中由於受到內外多種因素的影響,使得專案範圍的變更已經不可避免,也無法避免。所以,控...