亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: 如何做好項目管理，其中的門道你怎么看？ [打印本頁]

作者: CUTianrui007 時間: 2015-05-07 22:16
標題: 如何做好項目管理，其中的門道你怎么看？
獲獎名單已公布：http://72891.cn/thread-4179155-1-1.html

話題背景

不想當領(lǐng)導(dǎo)的程序猿/媛不是好的程序猿/媛，但當領(lǐng)導(dǎo)也有相應(yīng)的能力。如何管理好人、事、時間、項目，等等各種亂七八糟的事情，這真是一門學(xué)問。計算機的發(fā)展同時伴隨著軟件工程的發(fā)展，如何領(lǐng)導(dǎo)好一個項目，前輩給我們指出了經(jīng)驗之談，對于在實際工作中，我們應(yīng)該怎么處理好這一切，歡迎大家盡情暢談。

討論話題

1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？

討論時間
2015-05-08至2015-05-31

活動獎勵
活動結(jié)束后將選取4名討論精彩的童鞋，每人贈送一本《人月神話 40周年中文紀念版》作為獎勵。

獎品簡介

原書名：The Mythical Man-Month: Essays on Software Engineering,Anniversary Edition
作者： (美)小弗雷德里克·布魯克斯(Brooks,F.P.)
譯者： UML China翻譯組汪穎
出版社：清華大學(xué)出版社
出版日期：2015 年5月
開本：16開
頁碼：369
版次：1-2

內(nèi)容簡介

在軟件領(lǐng)域，很少能有像《人月神話》一樣具有深遠影響力和長銷不衰的著作。Brooks博士為人們管理復(fù)雜項目提供了頗具洞察力的見解，從宏觀角度有層次地分析了軟件工程的方方面面，不僅邏輯嚴謹，而且充滿文化底蘊。本書內(nèi)容主要來自Brooks博士在IBM公司研發(fā)并管理System／360計算機家族和OS／360軟件支持包期間的項目管理經(jīng)驗．該項目堪稱軟件開發(fā)項目管理的典范。

本書英文版一經(jīng)面世，即引起業(yè)內(nèi)人士的強烈反響，后譯為德、法、日、俄、中、韓等多種文字，成為軟件開發(fā)和管理人員的必讀經(jīng)典。在本書出版40年后的今天，我們重新整理了Brooks博士的經(jīng)典之作，收錄國內(nèi)外眾多業(yè)內(nèi)先行者對本書的實踐及系統(tǒng)理論的使用經(jīng)驗和心得與大家分享。

樣章試讀

ch01.pdf (1.02 MB, 下載次數(shù): 56)

ch02.pdf (1.22 MB, 下載次數(shù): 37)

關(guān)注CU官方微信“ChinaUnix”微博“ChinaUnix官方微博”

我們會及時為您公布最近活動的獲獎名單以及最新的活動資訊，更多精彩內(nèi)容，敬請期待。

作者: lyhabc 時間: 2015-05-07 23:27
我印象中用project這個軟件

作者: xkf01 時間: 2015-05-08 07:57
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: qingduo04 時間: 2015-05-08 09:25
這個話題不錯，書不錯。
現(xiàn)在PM正在帶我們學(xué)習(xí)管理

作者: little_angel 時間: 2015-05-08 09:47
話題很好，不錯。。。頂一個

作者: 資深項目經(jīng)理 時間: 2015-05-08 10:18
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？

項目早期規(guī)劃，是無法做到全面細致的。在早期做項目總體計劃時，主要對項目的需求范圍、預(yù)算、進度、資源投入程度、干系人等收集信息，各個部分細節(jié)越多越好。
經(jīng)驗不足時，不可能不出差錯，關(guān)鍵是能控制住差錯的程度。項目差錯要針對范圍蔓延、預(yù)算實現(xiàn)程度、進度延誤、資源及時投入等進行監(jiān)控，實時掌控項目狀態(tài)，與相關(guān)干系人的的及時耐心溝通，控制好項目質(zhì)量。

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的

敏捷時代文檔已現(xiàn)在不那么重要了，盡早交付可用的產(chǎn)品才是重中之中。文檔的目的是為了推進項目進度，文檔不是根本目的。

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？

能對目標有清晰的認識，能對目標有堅定的信念，與甲方能和諧相處控制好范圍，能與團隊成員凝結(jié)一心推動進度，能對質(zhì)量毫不放松控制好產(chǎn)品質(zhì)量，為人正直能確保做好成本控制，優(yōu)秀的領(lǐng)導(dǎo)能力、自我控制能力、團隊協(xié)作能力。

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？

客戶需求不明確項目時間緊的條件下，可以采用原型模型，從最初的原型開始，敏捷迭代不斷交付功能更多性能更加穩(wěn)定性更好的產(chǎn)品，在項目開發(fā)過程中一定要要求最終用戶積極參與。項目需求是會不斷變更的，這是正�，F(xiàn)象，在甲方發(fā)起項目變更時項目團隊應(yīng)積極評估變更帶來的影響，在變更項價值權(quán)重較高時更應(yīng)尊重甲方的變更請求，對于變更項價值權(quán)重不高的可以與甲方協(xié)商，項目需求的變更必然帶來項目范圍的調(diào)整進而引起項目WBS的調(diào)整甚至是項目整體計劃的調(diào)整；PM必須在每次變更之后謹慎評估進度計劃的變化，通過使用關(guān)鍵路徑法等方法調(diào)整項目進度計劃，確保項目進度能滿足甲方需求。

作者: forgaoqiang 時間: 2015-05-08 11:46
本帖最后由 forgaoqiang 于 2015-05-10 13:41 編輯

1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？
項目前期對項目的了解不是完全的，都是隨著項目的進行而進一步的了解項目本身，無法做到提前萬無一失的。在PMBOK中有整體管理和風(fēng)險管理，就是為了控制項目的。
項目經(jīng)理有很多的實用工具來規(guī)劃項目，在經(jīng)驗不足的時候就可以使用一些風(fēng)險控制模型進行控制。
控制項目主要可以從下面三個方面保證：
①時間控制
對活動進行定義、排序，計算好項目依賴關(guān)系，估算活動工期，采用前導(dǎo)圖或者箭線圖法表示出來，

②成本控制
根據(jù)信息系統(tǒng)項目管理，只要保證好 PV/EV/AC 的關(guān)系，隨時注意項目中成本的偏差，進行有效控制

③質(zhì)量控制
必要的測試和各里程碑的集成測試，保證產(chǎn)品的質(zhì)量，盡量避免返工等問題。

個人認為只要做好上面的三個主要的管理，同時對風(fēng)險進行預(yù)留資源，項目即使出現(xiàn)風(fēng)險也可以有效的進行控制。

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的
文檔是必須的，沒有文檔的項目是不可維護的，但是文檔的詳細程度是可以商討的，文檔本身可能會導(dǎo)致項目延遲交付，這個也是很正常的。
程序員討厭文檔也是正常的，與其讓程序員自己寫文檔，不如在寫代碼的時候做規(guī)范要求，按照標準的 doc 語法格式進行編寫代碼和備注，這樣可以使用自動化的工具將代碼自動生成文檔，然后雇傭?qū)ｉT的人員完成文檔部分的編寫，這是一個不錯的選擇，程序員一聽可以“不用寫”文檔，也會更加樂意編寫這種代碼。

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？
領(lǐng)導(dǎo)的主要作用并不是投入代碼的編寫，而是對整體項目的把控能力、對人員的管控能力。假設(shè)這里的項目經(jīng)理是項目型的項目經(jīng)理，與職能型的相比就有較大的項目權(quán)利。項目經(jīng)理相對技術(shù)來說，應(yīng)該有更大的

領(lǐng)導(dǎo)能力（是一種影響力，對人們施加影響，從而使人們心甘情愿地為實現(xiàn)組織的目標而努力的藝術(shù)過程。）越是基層的項目經(jīng)理，需要的管理能力越強。越是高層的管理經(jīng)理，如特大項目的管理經(jīng)理，需要的領(lǐng)導(dǎo)能力越強。最能體現(xiàn)領(lǐng)導(dǎo)能力的是：確立方向、招募人員，激發(fā)和鼓勵他人。

因此項目經(jīng)理要有技術(shù)功底，對整個項目框架要有整體把控，同時對于項目的成員有領(lǐng)導(dǎo)能力。

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？
這種情況下比較適合采用原始開發(fā)方式，快速開發(fā)出能夠演示的產(chǎn)品，然后與客戶進行溝通交流，逐步迭代的完成產(chǎn)品的開發(fā)，這種開發(fā)方式非常適合客戶需求不明確的情況。
變更管理最好還是能夠走標準的變更流程，每次變更都要有文旦記錄，只對合理的變更要求進行響應(yīng)，避免程序員直接修改需求，按照標準的項目變更流程來做。
對于這種情況下的進度控制，首先要明確每次變更的內(nèi)容并進行評估，然后安排工作，保證進度。

作者: shenlanyouyu 時間: 2015-05-08 13:04
在項目早期規(guī)劃時，很難做到全面細致。艾森豪威爾說過一句話：計劃是沒有價值的，但計劃的過程是必不可少的。
規(guī)劃的時候需要留出一段時間的緩沖。例如新的功能需求，解決bug，整合問題。

作者: Shell_HAT 時間: 2015-05-08 14:38
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？

首先要想清楚一個道理，不出差錯是不可能的。墨菲定律說的好：如果事情有變壞的可能，不管這種可能性有多小，它總會發(fā)生。
（1）早期情況不明朗的情況下，找以前相似的項目，用類比估算的方法制定范圍、時間、成本等管理計劃
（2）讓核心團隊成員參與制定項目管理計劃
（3）在整個項目生命周期內(nèi)采用波浪式滾動規(guī)劃

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的

程序猿討厭文檔是因為很多coder的目光只能看到自己的一畝三分地。在他們眼中，PM不是在開會就是在給自己派任務(wù)。他們看不到的是，PM在外部會議上跟各方妖魔鬼怪斗智斗勇、千方百計地幫忙coder們擋掉了多少磨難。

僅憑PM一己之力無法維護世界和平，也無法改變社會風(fēng)氣，不同情況區(qū)別對待吧：
（1）PM本身就是coding專家。利用自己的技術(shù)威信、人格魅力去感召和引領(lǐng)那些coder吧。
（2）PM本身不是coding專家。首先拉攏和說服核心團隊成員，其它小弟們自然跟著走。
總之，使用正式權(quán)利強迫coder是下策。

有人說，在“敏捷”大行其道的時代，文檔神馬的都是浮云。但是我親身經(jīng)歷的很多項目不是這個樣子滴。
甲方往往會要求最終交付成果包含源代碼、設(shè)計文檔、使用手冊、維護手冊等，一個都不能少。否則運維團隊拒絕在交接文檔上簽字。更要命的是主管領(lǐng)導(dǎo)拒絕在驗收文檔上簽字，這就意味著你的項目無法及時收到錢。錢啊，同志們！

客戶不滿意，無法及時收到錢。項目大大滴失敗。咱先不說財務(wù)部門天天拿著小鞭子抽你，單說客戶不滿意這一條就是最大的失敗了。本來可能長期合作的客戶被你PM做成了一錘子買賣，而且是失敗的一錘子買賣。引咎辭職吧騷年^_^

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？

【項目經(jīng)理的一般要求】
足夠的知識
豐富的項目管理經(jīng)驗
良好的溝通和協(xié)調(diào)能力
良好的職業(yè)道德
一定的領(lǐng)導(dǎo)和管理能力

【優(yōu)秀項目經(jīng)理的條件】
真正理解項目經(jīng)理的角色
領(lǐng)導(dǎo)并管理項目團隊
合理制定計劃，監(jiān)控項目執(zhí)行，管理變更
真正理解“一把手工程”
注重客戶和用戶的參與

如果能爭取到公司報銷（土豪就無所謂啦），可以去考考證書：
PMP --- 全球通用的。尤其是外企，對這個證書是比較認可的。
系統(tǒng)集成項目經(jīng)理 --- 工信部的。對個人來說，可以評中級高級職稱（實際上我想說呵呵）。對公司來說，有助于申請系統(tǒng)集成資質(zhì)。一級資質(zhì)需要至少10個高級證書和30個中級高級證書。

考證書的過程至少是一個學(xué)習(xí)的過程，它能提醒你按照“最佳實踐”去做事。

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？

需求變更屬于范圍管理領(lǐng)域。
從實際經(jīng)驗來看，主要從兩個方面著手：
（1）成立變更控制委員會，也就是CCB。人員組成上一般要包括甲方和乙方的項目經(jīng)理和高級管理人員。尤其是想盡一切辦法把乙方高級管理人員拉進來。所有的需求變更都要經(jīng)過CCB的審批，未審批的需求變更統(tǒng)統(tǒng)拒絕。一方面可以防止甲方的需求變更太任性，另一方面可以防止加了需求但最后不認賬不付款。
（2）嚴格按照變更控制流程做事。書面提出變更申請 >> 影響分析 >> CCB審批 >> 更新項目計劃 >> 干系人溝通 >> 執(zhí)行變更 >> 驗證變更 >> 記錄存檔。其中，影響分析非常重要，一定要有核心團隊成員共同參與完成。因為有些看似很簡單的需求變更，會牽一發(fā)動全身。還有就是干系人溝通也很重要，有時大佬A提出的需求變更你照著做了，但是大佬B不知道什么時候會跳出來說“我擦，這么大的事我咋不知道，影響了我的業(yè)務(wù)功能，怎么變過來的麻溜地怎么給我變回去”。囧囧囧

控制進度屬于時間管理領(lǐng)域。
需求變更通常是導(dǎo)致進度落后的主要原因之一。壓縮進度就兩種方法：
（1）趕工。也就是加班（嚴重影響團隊士氣，下下策）或加人（很多時候加人會讓進度變得更慢）。
（2）快速跟進。也就是把原來串行的工作變成并行。一般是重新繪制進度網(wǎng)絡(luò)圖，使用關(guān)鍵路徑法（CPM）找出關(guān)鍵路徑，壓縮工期。
V模型就是并行的一個好例子：
在需求分析階段同時編制驗收測試計劃
在概要設(shè)計階段同時編制系統(tǒng)測試計劃
在詳細設(shè)計階段同時編制集成測試計劃
在編碼階段同時編制單元測試計劃

作者: jszxcyit 時間: 2015-05-08 14:50
本帖最后由 jszxcyit 于 2015-05-19 17:25 編輯

首先感謝小編又拋出新的話題討論，辛苦小編了。以下是我對內(nèi)容的一些回答。希望滿意。

1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？
   對于信息化的早期項目規(guī)劃，是十分有必要的。首先我們右邊要先了解什么是信息化：信息化是指用戶利用信息技術(shù)來改造和提升自身管理水平的過程，它是一項相當艱巨復(fù)雜的系統(tǒng)工程，具有很大的風(fēng)險。而信息化規(guī)劃是指用戶信息化的目標，以及為實現(xiàn)該目標而制定出的相關(guān)措施和工作計劃。了解了這兩個概念后，我們的心里就有了底，要想信息化成功，就必須先做信息化規(guī)劃。
   項目規(guī)劃全面細致是必不可少的，項目的背景要有企業(yè)的戰(zhàn)略高度融合，從大的方向去規(guī)劃，其次包括項目的擴展性，技術(shù)的前瞻性，項目干系人的穩(wěn)定性，合作廠家的實力等等，每一個細小的細節(jié)都應(yīng)該項目經(jīng)理去把控，換一句話說，一個完美的項目規(guī)劃，離不開一個優(yōu)秀的項目經(jīng)理。
   在很多的信息化項目實施過程中，確實也存在經(jīng)驗不足的情況，對于這種情況，項目前期一定要有周密的項目計劃，按照計劃去開展項目工作，從人員、成本等多個角度對把控項目。

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的
   對于一個合格的程序猿來說，代碼和文檔是缺一不可的，代碼在完善也不可能指導(dǎo)人員操作，文檔的出現(xiàn)更好的彌補了項目交接過程中的工作規(guī)范。通過代碼的編寫，文檔的同步規(guī)范，更好的控制的項目，對于過程中出現(xiàn)的代碼問題也能快速有效的進行定位。

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？
   看到了，這個問題聯(lián)想到了信息化項目規(guī)劃應(yīng)該由誰來做？是領(lǐng)導(dǎo)？經(jīng)理？還是其他什么人或組織？這個問題同樣確定了對這個人有了特殊的要求。無論項目負責(zé)人使哪一個級別的領(lǐng)導(dǎo)，思路一定要開闊，有大局觀，站得角度一定要高并切合實際的符合企業(yè)發(fā)展的需要。在信息化的要求之下，合理的提出指導(dǎo)意見，整理相關(guān)意見資源。最為一個名合格的項目領(lǐng)導(dǎo)者，一定要對發(fā)展戰(zhàn)略和現(xiàn)狀非常了解，同時最好可以兼顧信息化方面的知識。

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？
   其實這種問題在實際的信息化項目推進過程中時有發(fā)生，需求是變化的，尤其是客戶并不是真正了解自己需要什么。這里我覺得可以根據(jù)工期的時間，對客戶主要的需要進行實施，抓住用戶最痛的點，在按照時間進行擴散實施，。對于后期的需求變更同樣是不可避免和回避的，用戶就上帝，但也是根據(jù)現(xiàn)狀去了解用戶，在需求合理的情況下去說服客戶，保證項目進度同時滿足客戶需求。
   項目進度的控制嚴格按照計劃進行，雙贏是大家都向看到的結(jié)局。

作者: hexilanlan 時間: 2015-05-08 14:51
這個，軟考真合適。

作者: hexilanlan 時間: 2015-05-08 14:51
溝通無極限，共識促發(fā)展

作者: coolmoon_133319 時間: 2015-05-08 17:52
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？
不是要解決所有問題，而是解決關(guān)鍵問題，確保大方向正確且風(fēng)險可控。

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的
與項目相關(guān)方確認哪些文檔是必須要求的，對于必須要的文檔必須提供（敏捷開發(fā)也是有文檔的）。對于非必須的文檔，需要權(quán)衡是否需要編寫文檔，權(quán)衡的標準是那種策略更省工作量，一定程度上依賴經(jīng)驗值。

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？
a、業(yè)務(wù)熟悉程度
b、技術(shù)能力
c、大局觀
d、良好的協(xié)調(diào)溝通能力
e、領(lǐng)導(dǎo)、管理能力

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？
與客戶溝通哪些需求必需實現(xiàn)，哪些可以以后實現(xiàn)，確定任務(wù)優(yōu)先級。如果經(jīng)引導(dǎo)客戶仍不能確定，可以提供demo給客戶。

對于后期的需求變更：
a、架構(gòu)設(shè)計可擴展（比如分層，模塊化等）
b、成立變更控制委員會，對合理的變更進行管控
c、對于不合理的需求變更，需要與客戶溝通變更的利與弊，說服客戶放棄這些需求

如何控制進度：
首先分析項目大小，周期長短。如果項目小，可以采用加班方式趕進度。如果項目大，分析研發(fā)流程是否可以優(yōu)化？同時要指定合理的項目計劃并且嚴格按照計劃執(zhí)行，切忌不要因為扛不住客戶壓力而**程序員經(jīng)常加班，要不然干活的人離職你只有哭的份。

作者: niao5929 時間: 2015-05-08 17:53
人月神話之前看過，個人覺得軟件系統(tǒng)最怕陷入駱駝背水的窘境。不過自由開源軟將給了軟件開發(fā)一種新的模式。也讓軟件真正有了進化的過程。進化總是從局部開始，如果進化的好會被全局跟進，如果進化本身存在問題會被更好的進化方向吸收掉。所以我個人覺得真正的有生命的軟件系統(tǒng)必然來自與自由開源軟件

作者: stay_sun 時間: 2015-05-08 18:19
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯
做任何項目開始的時候都不可能全面，需要嚴格按照項目的流程做出管理流程，減少項目可能出現(xiàn)的問題
2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的
專門的文檔管理專員，晚產(chǎn)項目的文檔，嚴格的項目流程才是這個最主要的解決辦法
3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？
it項目的管理和別的項目有不同的地方，建議多看一些項目管理的書籍，學(xué)習(xí)項目管理的工具
4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？
需求u明確的情況下，做好項目的風(fēng)險規(guī)劃，提前做好溝通，保證項目的完成。打好客戶關(guān)系，爭取讓客戶滿意
必須簽訂變更文檔，確認變更的工作量，完成盡量打好平衡
回復(fù) 1# CUTianrui007

作者: forgaoqiang 時間: 2015-05-09 11:11
哈哈是滴《信息項目管理師》也是包含這一塊內(nèi)容的 ~

hexilanlan 發(fā)表于 2015-05-08 14:51
這個，軟考真合適。

作者: forgaoqiang 時間: 2015-05-10 14:04
親不管怎么說工信部的信管也是按照 PMP的內(nèi)容來的還是有些效果的。。。雖然PMBOK已經(jīng)更新為10大領(lǐng)域軟考跟不上趟還是9個只不過你這個 smilence（呵呵）。。。有點太不給面子了~~

Shell_HAT 發(fā)表于 2015-05-08 14:38
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？

首先要想清楚一個道理， ...

作者: Shell_HAT 時間: 2015-05-10 16:05
回復(fù) 17# forgaoqiang

前年已經(jīng)PMBOK5了，今年軟考還在PMBOK4，還TM不讓用計算器，真艸蛋

作者: xkf01 時間: 2015-05-11 10:43
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: hexilanlan 時間: 2015-05-11 11:32
考PMP的厲害

作者: bajie22 時間: 2015-05-12 16:56
關(guān)注！喜歡這樣的討論

作者: heguangwu 時間: 2015-05-13 09:23
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？
早期規(guī)劃做的細致，這個一般使用如下幾種方式：1：經(jīng)驗的積累，做的多了踩得坑多了才會知道；2：群策群力，一般依靠大家的集體智慧，所謂智者千慮必有一失愚者千慮必有一得，人多肯定能想到全面一些；3：利用一些流程和工具來保證，這個就看公司的實力了，如HW采用的研發(fā)管理流程等
在經(jīng)驗不足的情況下不出差錯誰敢保證，只能避免少出差錯，不出大差錯，這個只能是將計劃做全，萬一發(fā)生不對的情況有Plan B方案替代，同時多向有經(jīng)驗的其它同事請教

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的
文檔能指導(dǎo)代碼但不是代碼，兩者必須同步，即修改了代碼如果有必要必須要修改文檔，但千萬不要在文檔中寫偽代碼，文檔只做到需求、架構(gòu)和流程我覺得就差不多了，再細的類圖設(shè)計沒有必要，因為這個東東變化有點快，到時候修改文檔太麻煩

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？
其實個人覺得也沒有什么特殊要求，無非是對每一個點尤其是關(guān)鍵點的把控，對每天的進度和問題能持續(xù)跟蹤

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？
這個就比較狗血了，需求不明確只能先把平臺及業(yè)務(wù)無關(guān)的東西先做好，如網(wǎng)絡(luò)收發(fā)模塊，業(yè)務(wù)調(diào)度，線程池之類的，等需求確定做業(yè)務(wù)開發(fā)，如果時間充足判斷部分需求可能性很大就繼續(xù)開發(fā)這部分的

作者: cryboy2001 時間: 2015-05-13 09:35
路過支持，其實一般的項目只要與客戶相關(guān)人員搞好關(guān)系就可以了。

作者: forgaoqiang 時間: 2015-05-13 13:35
哈哈精辟 ~

的確是這樣項目質(zhì)量有時候還真的不如關(guān)系好好用呢

cryboy2001 發(fā)表于 2015-05-13 09:35
路過支持，其實一般的項目只要與客戶相關(guān)人員搞好關(guān)系就可以了。

作者: jieforest 時間: 2015-05-15 00:07
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？
在項目早期規(guī)劃時，要做好充分的市場調(diào)研和需求分析。市場調(diào)研和需求分析做得越充分，意味著隨后的開發(fā)工作越順利，后期上線也越容易取得成功。
如果經(jīng)驗不足，盡可能聘請行業(yè)專家，或者聘請咨詢機構(gòu)，這樣對需求的功能點都能得到準確的定義。而且相關(guān)的團隊也該補補課，多讀多看相關(guān)行業(yè)的背景知識、信息、材料等，從外行逐漸變成內(nèi)行。

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的
文檔是必不可少的，正確處理代碼和文檔的關(guān)系，需要在兩者之間取得一個平衡點。
如果項目進度緊急，那么可以盡可能減少文檔的擬制，以代碼開發(fā)為主，輔以注釋，少量寫簡要的文檔。
如果項目工期充分，那么應(yīng)該盡可能讓文檔詳細，把研發(fā)流程規(guī)范化，那么軟件質(zhì)量也會很高。
還可以利用一些工具，加速文檔的擬制。比如：
可以用markdown編寫需求規(guī)格書、接口文檔等，這樣文檔可以納入版本管理，而且便于比較。
可以用javadoc生成API文檔，這要求在開發(fā)中需要遵守javadoc的規(guī)范來寫注釋，做到開發(fā)代碼和寫文檔的二合一。

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？
這個問題存在陷阱。領(lǐng)導(dǎo)指的是哪一級領(lǐng)導(dǎo)？
如果是項目經(jīng)理，那么肯定要熟悉業(yè)務(wù)、熟悉技術(shù)，把控整個項目。
如果是產(chǎn)品經(jīng)理，精通業(yè)務(wù)即可，技術(shù)未必要熟悉。
如果是更高一層的領(lǐng)導(dǎo)，會用人，會管理人即可，把適合的項目分配給適合的團隊開發(fā)。

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？
引入scrum開發(fā)流程，指定Backlog計劃，每兩周（即10個工作日）制定沖刺計劃SP，反復(fù)迭代。
每個沖刺周期都會根據(jù)客戶的需求做調(diào)整，以滿足客戶的需求和保證進度為主。
這種場景，通常會意味著時常加班，通過加班來加速開發(fā)進度。

作者: forgaoqiang 時間: 2015-05-17 18:01
最后一個問題 -》先做看不見但是需要的模塊不是很好的辦法客戶需求不明確不會因為時間推移客戶就明白自己的需求了一般需要先給他們做出個原型級的產(chǎn)品再明確需求變更迭代

上來就開搞用戶看不見、摸不到的模塊，而且很有可能因為需求不明確（甚至不正確）導(dǎo)致在項目進度上出現(xiàn)問題明確需求應(yīng)該是最重要的

heguangwu 發(fā)表于 2015-05-13 09:23
1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？
早期規(guī)劃做的細致，這個一 ...

作者: heguangwu 時間: 2015-05-18 17:53
用戶其實有時候都不知道自己想要什么，或者他心里想的是A，說出來的卻是B，如果是同一個行業(yè)做久了，或者你能引導(dǎo)用戶需求，比如你跟他說行業(yè)標桿某某公司是這樣做的
然后把你之前給那個公司做的東東改吧改吧給他看看，只要你能忽悠成功就OK了
總之，這個事情挺扯淡的，很多人認為修改軟件很快，一眨眼就能改好，所以提需求就隨心所欲，而且在一些大的國企或者更復(fù)雜，每一層管理都會有對該項目的理解，他們自己都沒統(tǒng)一思想

回復(fù) 26# forgaoqiang

作者: forgaoqiang 時間: 2015-05-19 08:52
(⊙﹏⊙)b 那估計xp方法可能適合他們了吧每次都能上線使用

heguangwu 發(fā)表于 2015-05-18 17:53
用戶其實有時候都不知道自己想要什么，或者他心里想的是A，說出來的卻是B，如果是同一個行業(yè)做久了，或者你 ...

作者: heguangwu 時間: 2015-05-22 17:32
這本書我想看看，但作為非項目管理者，這些問題不好回答啊

作者: CUTianrui007 時間: 2015-05-23 17:47
無法做到全面細致，有道理

作者: CUTianrui007 時間: 2015-05-23 17:56
管理誰都會得，就看你有沒有注意總結(jié)

作者: heguangwu 時間: 2015-05-23 20:20
外行看熱鬧，表面上看起來管理好像很容易，但真實并沒有你想的那么簡單，而且絲毫不必做開發(fā)容易，開發(fā)管理自己的代碼就可以了

CUTianrui007 發(fā)表于 2015-05-23 17:56
管理誰都會得，就看你有沒有注意總結(jié)

作者: shenlanyouyu 時間: 2015-05-25 00:04
本帖最后由 shenlanyouyu 于 2015-05-25 00:35 編輯

1、在項目早期規(guī)劃時，如何做到全面細致？在經(jīng)驗不足時，如何控制項目不出差錯？
有句話：計劃是沒有價值的，但計劃的過程是必不可少的。
中國有句古話“凡事預(yù)則立，不預(yù)則廢”。
規(guī)劃的時候需要留出一段時間的緩沖。例如新的功能需求，解決bug，整合問題。
利用歷史數(shù)據(jù)，估計任務(wù)完成時間。
循證式日程規(guī)劃，分解時間，追蹤時間的用途，對未來情況進行模擬，沙盤預(yù)演。
只有一線程序員才能提出完成日期的估計值，鼓勵團隊成員加入討論，共同制定計劃。

2、項目中如何處理代碼和文檔之間的關(guān)系？我知道程序猿都比較討厭文檔的
在項目開發(fā)的前期必須要設(shè)計文檔。

3、為了實現(xiàn)對項目的有效管控，對領(lǐng)導(dǎo)有哪些方面的特殊要求？
軟件項目開發(fā)，管理者要明白軟件開發(fā)金三角(功能、資源和時間)，主要管理3件重要的事情：資源（人員和資金）、功能（產(chǎn)品及質(zhì)量）和時間進度。
主要將精力放在這三個要素上。改變?nèi)切蔚囊贿�，通常會影響到其他兩條邊。
因此，在項目開發(fā)中關(guān)注以下問題：
(1) 引入持續(xù)構(gòu)建系統(tǒng)，保證金三角的平衡。
(2) 將任務(wù)細分，構(gòu)建項目待辦事項任務(wù)列表，領(lǐng)導(dǎo)代碼審查。
(3) 領(lǐng)導(dǎo)力，心往一處想，勁往一處使。
(4) 感知風(fēng)險的能力。
(5) 評估風(fēng)險，及時適當處理風(fēng)險。

4、如果客戶需求不很明確的條件下，但是項目時間緊張，必須先開工，如何處理后期客戶需求的變更？如何控制進度？
這種情況我個人覺得適合采用迭代增量式開發(fā)。迭代增量式開發(fā)，即敏捷開發(fā)方法，混合了迭代式和增量式開發(fā)，前期只需要一點點規(guī)劃工作，就可以啟動項目。能夠?qū)⑹占答伜晚椖窟M展完美結(jié)合到一起，非常適合客戶需求不明確，時間緊張的情況。

PS:關(guān)于這本書中的觀點：在軟件項目開發(fā)中，不適當增加人員實際上可能會拖延項目進度。我覺得這句話被過度理解了，甚至認為不要給正在進行的開發(fā)項目增加人員。在大多情況下，這個觀點是恰當?shù)�，但是在具有良好管理模式的團隊中，針對進度落后的項目，增加人員是一個可行的解決方案。

作者: xkf01 時間: 2015-05-29 15:24
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: qingduo04 時間: 2015-05-30 10:06
書太好了，項目管理方面欠缺很多理論知識，向各位大俠學(xué)習(xí)了.............

歡迎光臨 Chinaunix (http://72891.cn/)

^{<blockquote id="ljhps"></blockquote>}