如何做好項(xiàng)目管理，其中的門道你怎么看？

bajie22

關(guān)注！喜歡這樣的討論

heguangwu

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

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

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

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

cryboy2001

路過支持，其實(shí)一般的項(xiàng)目只要與客戶相關(guān)人員搞好關(guān)系就可以了。

forgaoqiang

哈哈 精辟 ~

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

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

jieforest

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

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

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

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

forgaoqiang

最后一個(gè)問題 -》 先做看不見但是需要的模塊不是很好的辦法 客戶需求不明確不會(huì)因?yàn)闀r(shí)間推移 客戶就明白自己的需求了 一般需要先給他們做出個(gè)原型級(jí)的產(chǎn)品 再明確需求 變更 迭代

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

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

heguangwu

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

回復(fù) 26# forgaoqiang


   

forgaoqiang

(⊙﹏⊙)b 那估計(jì)xp方法可能適合他們了吧 每次都能上線使用

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

heguangwu

這本書我想看看，但作為非項(xiàng)目管理者，這些問題不好回答啊

CUTianrui007

無法做到全面細(xì)致，有道理