<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>網站/Mobile企劃顧問,課程,Axure RP-悠識數位 &#187; 網站專案管理</title>
	<atom:link href="http://userxper.com/topics/ue_column/project_management/feed" rel="self" type="application/rss+xml" />
	<link>http://userxper.com</link>
	<description>悠識數位(UserXper)以「網站/Mobile企劃」為服務核心，提供三種網站企劃相關服務：分別是網站企劃軟體，網站企劃培訓，網站企劃專案。悠識數位將協助您為您的顧客創造更好的「網站使用者經驗 (Web User Experience」。</description>
	<lastBuildDate>Thu, 09 Feb 2012 07:58:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
		<item>
		<title>2010年給網站企劃工作者的8個建議</title>
		<link>http://userxper.com/blog/archives/629</link>
		<comments>http://userxper.com/blog/archives/629#comments</comments>
		<pubDate>Sun, 03 Jan 2010 05:09:28 +0000</pubDate>
		<dc:creator>richard</dc:creator>
				<category><![CDATA[網站企劃]]></category>
		<category><![CDATA[網站專案管理]]></category>

		<guid isPermaLink="false">http://userxper.com/?p=629</guid>
		<description><![CDATA[進入2010年的第二天，閱讀到許多好文章，預測了2010年網路行銷/網路產業的願景或趨勢，站在資深網站企劃工作者的立場，我覺得應該給新進的朋友一些工作上建議，讓各位在以放大鏡看著大市場的變動時，也可以用顯微鏡來檢視自己的成長。 因為不管大環境是好是壞，身為網站企劃工作者，關心趨勢之餘，更應該關心自己的專業是否提昇？如果沒有提昇自己，大環境變好跟你一點關係也沒有。 2010年，提供這些建議給網站企劃工作者，歡迎指教或補充。 1. 搞清楚負責的網站，其目標是什麼？要以什麼方式來衡量網站是否成功？ 詢問自己上述問題，如果找不到準確的答案，請詢問老闆。如果連老闆也回答不出來，那麼建議你們團隊應該先弄清楚這個問題的答案，然後再繼續做下去。 身為網站企劃工作者，最不應該的工作態度是渾渾噩噩的，只為了結案而作企劃。 這問題尤其要送給那些負責政府機關類型網站的網站企劃，我能體會你們的無奈跟痛苦 (這點我不是隨口亂講的)。這問題也許找不到答案，但是這個問題一定要問，才知道為何而戰？為誰而戰？ 2. 找到價值，不要在團隊中自我「消音」 在網站企劃課程中習慣性的詢問學員們：「為什麼你要學習網站企劃？」 「因為我不會設計網頁，也不會寫程式，所以我做網站企劃。」這是我最不期待聽到的答案。 如果因為你什麼都不會，才來做網站企劃，那麼你會非常辛苦，只能被其他人使喚，沒有自己的主張，永遠就是修改文件，拜託工程師，跟客戶道歉 &#8230;。 網站企劃之於網站，就像是導演之於電影，網站的生命力是由企劃來塑造的，如果你不認同網站企劃的價值，那是你功力還不足，不是這個工作沒有價值。 這個建議送給網站企劃新手，請務必提昇自己的功力，讓自己在這個工作崗位上找到成就感。 3. 至少要閱讀一本網站企劃或網站設計的書籍 工作很忙是不讀書的好藉口，只可惜找到這個藉口並不會讓你所有成長。 好的書籍很多，不要貪多，只要下定決心，挑一本書，想辦法把它拆成12份，一年的時間你一定讀的完。 最好在BLOG上發誓你要讀完這本書，每次讀完寫下讀書心得，讓朋友們來監督你。找同事或朋友一起組成讀書會也是不錯的作法，但千萬小心三個和尚沒水喝的效應。 這個建議送給已經工作好幾年，覺得逐漸被掏空的朋友們！ 4. 跨領域的觀察與認識 網站不應該獨立存在於企業(或機構)之外，凡是與達成企業(機構)目標有關的領域，應該多去了解或認識。 你可以在網路上找到很多入門的演講或課程，費用不貴(甚至是免費的)。行銷/廣告/品牌/數位內容/IT/企管/業務/銷售/財務/物流/設計/美學/文化&#8230;..都是可以涉獵的範圍。 5. 保持好奇心 當工作一件件丟進來的時候，為了處理掉工作，可能會降低好奇心，這會讓你損失更多。網站企劃的工作樂趣之一是接觸網路上層出不窮的新創意或新服務。保持好奇心，花點時間去嘗試或碰觸。 跟隨潮流，聽起來似乎不太入流，但是當別人問起你知道XXX或OOO時，至少你接觸過。(但是要提醒自己：接觸過不等於理解) 這個問題送給資深的網路行銷人員，保持好奇心，同時不要用過去的經驗，來看現在網際網路上正在發生的事物。 6. 偶爾離開數位世界，站在真實世界的角度 不要全然投入在虛擬的數位世界中，別忘了你的網站是給活生生的人們使用的，而他們並不是0與1組成的程式。 偶爾去認識一下網站的真正使用者，聽聽他們的話，認識他們的使用環境，觀察他們使用哪些服務，花多少時間在網際網路上&#8230; 。 這些並不需要花錢去找市調公司做研究，因為我們不是要一份冷冰冰的數據，而是要讓這些使用者存活在你的企劃思維裡頭。只要你願意，你一定可以找到真正的使用者，而他們也絕對願意提供意見的。 7. 嘗試理解網站製作的其他專業 找一件跟整個網站專案有關，而卻是你最不想或最害怕的事情，去嘗試了解或參與。不要因為工作定位在網站企劃，就不去碰觸』黑手』的網站製作專業。 沒學過網頁設計的企劃，請你去學HTML語法。 最不喜歡跟視覺設計師溝通，請你去詢問設計師關於視覺傳達，或者設計概念的知識。 覺得Flash非常難的的企劃，請你去找本Flash書籍，來弄懂Flash的設計方式。 覺得工程師很討人厭的企劃，請你去找工程師，弄懂最簡單的 『Hello World』網頁或資料庫查詢語法。 8. 加強表達與溝通能力 隨著網站專案的發展，你要面對的溝通對象，只會越來越多，越來越複雜。表達/溝通是網站企劃的基本能力。 關於表達與溝通，你可以給自己一些目標，比如： 學習利用不同的形式或方法，組織你想表達的邏輯 (除了Word/Powerpoint的文字書寫, 還有很多其他的方式跟工具) 思考在Email/電話/MSN上的表達，如何在不同的媒介上達到溝通的最佳化？ [...]]]></description>
		<wfw:commentRss>http://userxper.com/blog/archives/629/feed</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>關於網站開發 &#8211; 老闆該知道的10要及10不要</title>
		<link>http://userxper.com/blog/archives/536</link>
		<comments>http://userxper.com/blog/archives/536#comments</comments>
		<pubDate>Tue, 15 Dec 2009 15:39:22 +0000</pubDate>
		<dc:creator>richard</dc:creator>
				<category><![CDATA[網站專案管理]]></category>

		<guid isPermaLink="false">http://userxper.com/?p=536</guid>
		<description><![CDATA[「關於網站開發 &#8211; 老闆該知道的10要及10不要 (The 10 dos and don’ts of website development, every CEO should know) 」- 本文作者是FatDUX Group 的CEO， Eric Reiss。FatDUX這家互動行銷公司位於丹麥的哥本哈根 (當下全球暖化議題最關注的城市)。 這裡僅摘要這10個DOs和DON&#8217;Ts的標題，至於內文及闡釋請參考原文PDF。 關於網站開發 &#8211; 老闆該知道的10要及10不要 The 10 dos and don’ts of website development, every CEO should know 作者：Eric Reiss, CEO,  FatDUX Group 由於經濟不景氣，大量裁員的情況下，把網站視為顧客溝通的管道變得比以往更重要。但我還沒有遇到哪個CEO喜歡網站開發這回事。 網站開發這件事情讓企業領導人感到不舒服。因為，網站專家總是講一些讓CEO們聽不懂的話- CMS, KM, XML, CSS。而且，網站似乎一直都在建置修改，專案成本高過預期，網站價值卻低於預期。 坦白說，絕對沒有人喜歡簽一張支票卻不知道可以買到什麼好東西。因此，如果你是企業的領導者，這裡有一些基本的，非技術的觀念，可以提高您的網站成功機會。這些觀念可以讓你只需要做你最擅長的事情- 領導企業。 第1點 DON&#8217;T：不要把行銷手段視為溝通 DO：要將網站視為企業整體客戶服務的環節之一 第2點 [...]]]></description>
		<wfw:commentRss>http://userxper.com/blog/archives/536/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>需求管理是專案成功的根本</title>
		<link>http://userxper.com/blog/archives/196</link>
		<comments>http://userxper.com/blog/archives/196#comments</comments>
		<pubDate>Tue, 25 Nov 2008 04:05:10 +0000</pubDate>
		<dc:creator>richard</dc:creator>
				<category><![CDATA[網站專案管理]]></category>

		<guid isPermaLink="false">http://userxper.com/blog/archives/196</guid>
		<description><![CDATA[根據 Standish Group發表的專案成功因素調查報告 &#8211; 2003 Chaos Chronicles Report，大約 66% 的軟體開發專案不是失敗，就是超出預算、超出專案時間，或是交付縮水的功能。 專案失敗或虧損的前三大原因為： 1. 缺乏使用者的參與 2. 需求或規格不完整 3. 需求或規格變更 傳統需求管理工具不合時宜 在過去，需求管理(Requirement Management)工具或工作表中所儲存的數千個需求與上百頁的文件早已不合時宜，現在，這些需求更是不適用於目前快速發展的環境。 專案的關係人(Stakeholder) / 需求單位或使用者通常都不是專業人員，一般的需求整理跟定義，光依賴文字敘述以及簡易的畫面，往往造成對於規格認知的落差，到最後就演變成災難，無法收拾。 Prototype將需求視覺化可以有效定義需求 解決對於需求以及規格認知落差的方式，最好採用原型設計方法(Prototyping Methodology)。製作Prototype是個有效簡化文件製作、吸引使用者參與、早期辨認需求遺漏，與將外在需求降到最低的方法。 以專案關係人(stakeholder)與使用者看了有感覺的互動性畫面，直接感受設計結果，來取代大量的文字敘述，如此更能抓住使用者的意見回饋，形成共識。 只是傳統製作prototype的方法不但昂貴而且費時，讓程式設計師很難在開發過程中搭配合作。專案經理/系統分析師或企劃人員也不斷的在使用簡報與圖示的工具建立Prototype和持續對製作過程與結果不滿意之間掙扎著。 Axure RP提供原型設計的效率，進而創造專案效益 為了要能有效且快速的建立Prototype，Axure RP 結合了廣受歡迎的簡報與圖示工具中簡易操作的特性和其他必要的功能，這樣一來，專案經理/系統分析師或企劃人員就可以在不需要大量文件製作下快速的建立Prototype，而專案成員與專案關係人也可以在不中斷開發的情況下輕鬆完成Prototype。 Axure RP很容易學習，而且可以產出多元文件格式，包括HTML/Word/圖檔/Excel/CHM格式。所以當專案成員將Axure RP應用在第一個專案時，就會發現這項投資快速得到顯著的回報，不只省下了在需求蒐集與溝通需求上的時間與成本，同時也降低了改善需求時的重工，透過Prototype 可以省下驚人的成本，以及預防潛在性的商業損失、機會損失與專案關係人信心喪失等的災難成本。 日本NTT DATA公司透過Axure RP節省30%的專案執行時間 NTT DATA公司 &#8211; 日本最大的系統整合公司之一，發表一項新的專案管理方法─在系統開發時以Axure RP定義需求。使用Axure RP之後，NTT DATA發現在專案執行過程可節省30%的專案執行時間，並改善需求管理的品質。 想知道NTT DATA如何辦到？請繼續閱讀本文http://userxper.com/blog/archives/364]]></description>
		<wfw:commentRss>http://userxper.com/blog/archives/196/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>給新手PM之4 &#8211; 提升客戶與執行團隊的專業</title>
		<link>http://userxper.com/blog/archives/54</link>
		<comments>http://userxper.com/blog/archives/54#comments</comments>
		<pubDate>Mon, 13 Aug 2007 04:51:30 +0000</pubDate>
		<dc:creator>richard</dc:creator>
				<category><![CDATA[網站專案管理]]></category>

		<guid isPermaLink="false">http://userxper.com/blog/archives/54</guid>
		<description><![CDATA[距離上一封寫給你的信，大約隔了兩個半個月了。非常高興得知，在我不能隨時提供諮詢的這段時間，你有自己的歷練跟成長，而且還獲得客戶的肯定，很欣慰！ 言歸正傳，繼續我們的「函授」教學…還記得我前面兩封信提到我多年功力的菁華嗎？第一個重點是建立共識，第二個重點是配置資源，今天我們要來談談第三個重點。 專案成功的第三個關鍵，以前我只放在心裡面，不講出來的。不講出來的原因是這個講法聽起來一點也不專業，甚至不入流，那個關鍵叫做「運氣」，不過現在我認為第三個關鍵可以修正為「雙方團隊專業程度的乘積」。 為什麼「運氣」竟然是專案成功的第三關鍵呢？我們都知道專案時程，範疇，需求都是委託方賦予的，所以如果運氣好，遇到好客戶，專案就有較高的成功機率。運氣好的專案經理，會遇到好的委託方，明理的客戶，有合理的時程要求與專案範疇，找得到強力支持專案的高階主管，預算夠用甚至還可以到飯店來個期末慶功。 回想我過去的經驗，同時遇到這些極佳條件的機率非常的低，如果遇到了，表示手氣好到買到樂透頭彩了。只是專案本身都成立在這種理想狀況，專案經理就不需要太厲害了，當然也看不出專案經理的貢獻。這就是我上一封信提醒你的，沒有好牌也要打出好的牌局。 照這個道理來說，專案的命運豈不是永遠掌握在客戶手中了嗎？那專案經理不就得背負著這個原罪，那也太倒楣了，誰還來當專案經理呢？因此把專案成功與否推給「運氣」這是很不洽當的想法。就好像把專案能否成功的責任通通推給客戶一樣，這種講法是完全說不過去，畢竟客戶會將專案委託給你，有一種可能性就是他本身的專業上不足，需要你的協助，哪裡可以藉口客戶水準不足而導致專案失敗呢！ 不過最近幾年，我發現這第三關鍵「運氣」應該修正為「雙方團隊專業程度的乘積」。這個概念把被動的，運氣的，宿命的消極工作觀，調整成比較主動的，客觀的，積極的工作態度。你聽聽看有沒有道理？ 經過我的觀察，實際上專案的最後成果，往往都是委託端的努力加上執行端專案團隊的努力一起合力創造出來的。假設滿分是100%，如果客戶的水準達到80%，而專案團隊也有80%，那麼專案的成功指數就達到80% X 80% = 64%，大於60%勉強及格。 如果你的專案團隊的專業指數達到100%，但是遇到一個30%的客戶，你想專案會成功嗎? 成功指數就只有100% x 30% = 30%，不及格。反之亦然，一個專業水準有100%程度的客戶，若遇到只有20%水準的專案團隊，大概也就祇有等著遭受打擊的份了。 因此在專業水準上能夠門當戶對的專案團隊與客戶，才有促成專案成功的底子。重點在於雙方的專業必須是互相彌補的：能夠提昇執行端專案團隊水準的客戶，是好客戶；相對的，能夠培養客戶素質的專案團隊，才是一個好的專案團隊。 所謂的雙方的專業必須互相彌補，在網站建置類型的專案上，尤其容易看得出來這一點的重要性。委託端－也就是客戶，必須很清楚自己的需求，以及所在產業的相關知識（Domain Knowledge）；執行端－也就是你所帶領的專案團隊，則必須擁有良好的網站規劃建置各項專業。 當客戶對自己的需求掌握90%，合作初期也能將他們的產業知識傳遞（或傳授）給你的專案團隊，再加上你所帶領一群專業水準達90%的好手，我們放到公式裡頭就可以得到90% x 90% = 81%的好成績。我曾經遇到一個客戶，他把產品網站委外給小設計工作室，結果工作室倒了，人跑不見了，他的網站也跟著消失找不回來，因為他連備份的觀念都沒有。這個情境大概是50% x 40% = 20%吧！下場也夠悽慘的。 換個積極的角度來檢視第三關鍵「雙方團隊專業程度的乘積」。你要創造好的專案成果，在專案一開始就必須考慮到，如何為第三關鍵的兩個變數Ａ，Ｂ創造出好的水準。 變數Ａ是「客戶水準」，如果有機會一開始就篩選出好的客戶，那很不錯，假設沒這種條件，就得跟客戶「博」感情，藉著多次的互動與接觸，來教育客戶，讓客戶素質成長。當客戶體認到，你來做專案不只是做事情而已，他本身也可以獲得很多的成長，客戶會越來越信任你，依賴你，以後的事情就會越來越容易做。 變數B是「團隊水準」。一樣的道理，專案團隊的素質，就是專案品質的基礎。如果你沒有辦法篩選，組織出好的專案團隊，那麼就得藉著你手上的資源，陸陸續續將自己的團隊素質加以提升，比如花更多的時間在學習，聘請專業顧問，編列教育訓練預算等。經歷這個過程，你的團隊成員也認知到跟著你做專案，不只是做事，自己的專業也會提升，那麼團隊向心力就會越來越強，大家也會願意跟隨著你，以後的專案就會更容易成功了。 所以，下一次不用太介意客戶有多差勁，或者工程師/設計師有多不配合了，這些都是你在專案管理工作上必須經歷的，而且這種情況發生時，你更應該要先做自我檢討，與其抱怨，不如更用心去提升各方水準，當你付出更多，很快的，你就會獲得更多！不相信嗎？試試看便知道！]]></description>
		<wfw:commentRss>http://userxper.com/blog/archives/54/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>給新手PM之3 &#8211; 配置資源</title>
		<link>http://userxper.com/blog/archives/53</link>
		<comments>http://userxper.com/blog/archives/53#comments</comments>
		<pubDate>Sun, 27 May 2007 04:50:20 +0000</pubDate>
		<dc:creator>richard</dc:creator>
				<category><![CDATA[網站專案管理]]></category>

		<guid isPermaLink="false">http://userxper.com/blog/archives/53</guid>
		<description><![CDATA[沒有兵的將領無法打仗，沒有子彈的兵無法戰鬥，巧婦難為無米炊，專案經理沒有資源就無法完成任務，這些都是一樣的道理。這些道理的意義都在表達「資源」的重要性。而「配置資源」正是影響專案成功的第二個關鍵因素，資源的配置包括資源的評估、分配、取得、運用 。 對新手PM來說，配給什麼樣的資源往往是別人做的主，這是比較無奈的一點。但是既然公司能夠賦予你擔任PM的要職，多多少少都相信你具備應用資源/管理資源的能力，換句話說，你自己得評估資源是否足夠，萬一領了軍令上了前線，回頭尋求後方火力支援時，才發現後頭是漫漫荒野沒有後援，恐怕你就準備陣亡了。 「資源」包括什麼? 包含為了達成專案任務所需要的「有形資源」，及「無形資源」。 預算是資源，時間是資源，人手是資源，顧問是資源，下包廠商也是資源，為了達成專案所需要的各種實體物件，軟體/硬體/圖庫/音樂版權，專案的大老闆的某種授權或背書，皇上給的免死金牌/尚方寶劍等等都屬於專案資源。 理論上，擁有「無限」資源的專案，有最大的成功機率。不過這個描述已經違背的「專案 (Project)」的基本定義 (專案本身就有時間限制，否則不叫做專案)。參考wikipedia對Project的定義 英文 中文。 正由於各種資源都有其限制，因此將資源最佳化，達成最佳的專案產出與品質，就是專案之所以得被賦予「管理」概念的由來。 反之，一個專案沒有足夠的資源，天生就埋下了失敗的隱憂，所以，專案的關鍵成功因素之一就是先取得資源，或者講白一點，取得足夠的資源，而資源當然是越多越好。 但站在專案經理的頂頭上司或者專案委託人的立場，通常這兩位大人是提供資源的重要人物，他們對於資源的取得或分配，考慮的角度是「資源最佳化」，說穿了，就是「足以達到專案產出基本品質的最低資源」。這不能怪他們，因為從你的角度你也許只看管一個專案，從他們的角度得看管十個或數十個專案，當然得顧及各專案的資源配置。 曾經有很長一段時期，取得專案資源一直是我心目中專案成功的第一重要因素。在踏入這個行業的初期，曾受到一位軟體業界前輩的指點，我也跟你一樣想尋求專案管理專家的協助，前輩給我一個很重要的觀念，我一直記在心裡頭，他說「專案要成功，首先你要有自己的團隊」。換句話說，沒有專案團隊的專案經理，就像是沒有兵的將領，無法戰鬥。 擁有專案團隊(Team)最快的方式，你知道是什麼方式嗎? 很簡單，只要僱用一個英文名字叫做Tim 的人，就可以跟客戶宣稱我們有 Team了。這是一位好友在非常無奈的情境下，想出來的冷笑話，當時他就在沒有Team的情況下苦中作樂，才想得出這種冷笑話。 為了把專案資源做評估與規劃，很多專案管理的理論都有談到。首先專案目標與目的的定義，範疇的界定，規格的界定，人力/預算/時間的估計，將這些林林總總的項目作好完善的安排，形成專案計畫，這些細節我們以後再來討論。 最後，幫你做個心理建設，沒有一副好牌卻仍能打出一場好牌局的PM，才是真正的高手。如果每個專案都能夠賦予專案經理夠多好用的籌碼，每副都是好牌，坦白說，專案管理就沒有什麼價值了，我們今天也不用花心思做討論了。不管你手上拿到什麼牌，想辦法打出屬於你的一場好牌局，這是PM要最用心的地方。]]></description>
		<wfw:commentRss>http://userxper.com/blog/archives/53/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>給新手PM之2 &#8211; 建立共識</title>
		<link>http://userxper.com/blog/archives/52</link>
		<comments>http://userxper.com/blog/archives/52#comments</comments>
		<pubDate>Thu, 24 May 2007 04:48:54 +0000</pubDate>
		<dc:creator>richard</dc:creator>
				<category><![CDATA[網站專案管理]]></category>
		<category><![CDATA[專案管理]]></category>

		<guid isPermaLink="false">http://userxper.com/blog/archives/52</guid>
		<description><![CDATA[你上回說現在接手一個客戶的小型網站改版專案，每次開會或者討論事情，感覺大家都在看著你的意見跟表現，讓你壓力很大。你很想知道有沒有什麼祕笈可以快速的學好專案管理。這個問題很有趣，我也被許多人詢問過同樣的問題，只可惜，管理好專案沒有捷徑，我能夠告訴你的東西，沒辦法速成，可是卻是成功關鍵。 如果你想了解到我過去做網站專案管理心得，那麼我可以在這裡告訴你，接下來的這個重點是我多年功力的菁華。 評估專案經理能力高低，就看專案管的好不好。影響專案管的好與不好的因素很多，若全面分析所有因素並且逐一探討跟檢視，恐怕講三天三夜也講不完。 今天我先講第一個成功關鍵因素，這個因素是我認為最難最難的一件事情，如果能夠把這件事情做好，即便是專案結果不如預期，但大家可能都不會怪罪到專案經理頭上。 第一個關鍵因素是「建立共識」。 什麼叫做共識? 簡單說，就是全體人員有相近的看法或者支持相同的決議。 那麼哪些人要有共識呢? 首先，你的內部團隊要有共識，包括上頭的老闆，甚至老闆的老闆，你的技術團隊，你的設計團隊，你的企畫研究幕僚，甚至你的下包廠商， 再加上客戶端的共識 (這裡所指的客戶端，也包含專案委託單位是自己企業機構內的其他部門)，客戶的專案小組，客戶窗口的老闆，或客戶窗口的老闆的老闆。 最後則是你的專案團隊與客戶端的專案相關人之間要有相同的共識。 專案管理理論所談到的各種管理作為，有許多都是為了促成共識的措施，包括定義專案的產出規格與品質，專案工作的分工與接力，合約/計畫書/會議紀錄，溝通技巧與方式 (各種形式的溝通, 會議, 電話, email, 文件…)。 管理專案的共識，根本上必須是專案經理的習慣，連想都不用想，隨時隨地要意識到讓大家形成共識。在專案過程中的每一個動作跟步驟，都要提醒自己是否已經形成共識? 如果還沒有共識, 會造成什麼後果? 要透過什麼樣的決策機制來定義共識? 總之，專案的任何一個環節疏忽了建立共識，就有可能埋下後面造成專案範疇或規格變動的隱憂。形成共識，被我視為專案經理的第一要務，只要能夠做好共識的塑造與形成，就是大功一件。 由於共識的建立牽涉到人的認知與溝通，偏偏只要跟人有關的事情，就是最難搞定的。只有兩種情況，共識相當於等於專案經理的個人意識，此時幾乎沒有溝通成本或溝通問題。 第一種情況，專案經理自己是委託端及執行端，而且是自己獨立執行的專案。這種情況也許很像是有些程式設計師自己設計一些軟體或網站，自己玩一玩。 第二種情況，是所有人都聽專案經理的。什麼情況會這樣? 當專案經理的專業夠水準，足以服眾，此時所謂的共識幾乎就是專案經理的個人意見，而這種情況不多見。但假使專案經理的專業水準能夠提高，就更有機會快速的凝聚共識。 關於共識的建立，我們會再用更多更多的篇幅來討論，如果你在這部份有什麼心得或問題，我們可以隨時回頭再來檢視這個題目。加油了!]]></description>
		<wfw:commentRss>http://userxper.com/blog/archives/52/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>給新手PM之1 &#8211; PM像什麼?</title>
		<link>http://userxper.com/blog/archives/51</link>
		<comments>http://userxper.com/blog/archives/51#comments</comments>
		<pubDate>Thu, 10 May 2007 04:46:56 +0000</pubDate>
		<dc:creator>richard</dc:creator>
				<category><![CDATA[網站專案管理]]></category>
		<category><![CDATA[2007]]></category>

		<guid isPermaLink="false">http://userxper.com/blog/archives/51</guid>
		<description><![CDATA[你好！恭喜！ 你選擇了踏上專案管理這條路，這是很棒的方向，可以學到最廣泛的經驗，非常恭喜你！在這個行業裡頭，需要很多專案管理人才，尤其是好的專案管理人才，這絕對是值得你努力耕耘的方向。 你問我：”什麼樣的專案經理才是好的專案經理？”這個問題很好，但是很難簡短的回答。以後我會慢慢告訴你，如何當一個稱職的專案經理，不過既然你問的這麼誠懇，為師的也不能隨隨便便回答。 我們換個簡單一點的講法好了，好的專案經理應該要像什麼？ 首先，好的專案經理要像獅子，要具備獅子的自信與領導氣質。獅子是萬獸之王，能夠鎮懾其他動物，像獅子一樣的專案經理，就是一個具備領導力的專案經理。任何一個稍具規模的專案都必須整合多人跨領域的團隊或資源，才能完成任務，如果團隊沒有好的領導人，再多個厲害角色湊在一起也只能算是烏合之眾。而專案經理名為管理專案，實際上卻不只管理專案團隊而已，而是必須領導專案團隊。至於什麼是領導，我們改天再說。你呢？其實也不用想太多，就先當自己還是小獅子吧！總有一天會長大的。 好的專案經理要像磁鐵，要能夠把專案團隊及資源牢牢吸住，但這個牢牢吸住卻又不是鎖螺絲那麼難拆解，萬一團隊成員要更換或者資源安排到另一個更重要的專案，也不能太難處理，像那句有名的廣告詞＂有點黏又不會太黏＂就對了。我想強調的重點其實是＂凝聚＂的力量，如果專案經理是夠強的磁鐵，就會將專案團隊緊緊拉攏在一起。而且這個拉攏的力量，是有擴散性的，被吸住的團隊成員就像具備磁力的鐵片一樣，會自動吸住他該關注的項目跟任務。 好的專案經理要像大海，要有肚量。這不是件容易的事情，如果你不當專案經理也許就不用太在意，要當專案經理肚量太小，恐怕很快的就會高血壓心臟病了。因為專案經理身處專案風暴的核心，上有老闆，下有團隊，旁邊可能是其他專案團隊或者部門主管，外面還有客戶跟外發廠商，每個人有每個人的意見跟看法，如果肚量不能像大海，海納百川而闊，大概天天都在跟其他人爭辯意見，那就不妙了。 好的專案經理要像水，不管專案過程有多麼崎嶇難行，你的身段得柔軟地去適應並且撫平。這絕對不是簡單的本事，遇到凹陷的地方，這是你的專案團隊的不足之處，你必須注入你的能量加以撫平。遇到客戶要求過多，就好像平地上冒出的土丘，要不把土丘給抹平，要不就放大水來淹沒 (仔細想想&#8230;這個描述真有點離譜)。能夠讓專案的表面看起來平平整整的，那是專案經理的上等功夫。當然，水面下的起起伏伏，那就是鴨子滑水了，該不該讓其他人知道你的勞累跟貢獻，如何讓其他人知道，這就得看場合跟狀況了。 好的專案經理要像竹子，韌性要夠，要不怕風吹雨打。雖然要像大海聽別人的意見，要有水一般柔軟的身段，但這可不是教你去奉承逢迎，別忘了專案經理要領導團隊不是只靠附和他人意見，最基本的還是自己的專業要夠，要挺得住，即便是被巨大的範疇 / 無理的時程要求 / 誇張的需求變更所打擊，也不能倒，倒了就沒有尊嚴了。當然很多時候專案經理是可以稍微退一步以取得緩衝，便於在緩衝中找到解決方案。總之，不卑不亢就是最好的態度，只要最後能靠自己的實力站起來不被擊倒，以後就會獲得他人的尊重與認同了。 用這種講法好像篇幅再多也講不完，以後想到再叮嚀你，希望到時候你別嫌我太囉唆！]]></description>
		<wfw:commentRss>http://userxper.com/blog/archives/51/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

