qileilove

　　需求 - 溝通 – 人 - 過程 - 工具

　 　項(xiàng)目要成功的最關(guān)鍵因素是什么？軟件要快速高效又高質(zhì)量的提交靠的是什么？有人說最關(guān)鍵是項(xiàng)目經(jīng)理，關(guān)鍵是溝通，有人說是技術(shù)設(shè)計(jì)，有人說是對需求的把 握… … 從我看來，都是盲人摸象，項(xiàng)目要成功，軟件要快速高效又高質(zhì)量的提交，靠的是多重因素的整合和平衡；首先要對需求的準(zhǔn)確理解和把握，貫穿全流程的溝通，做 項(xiàng)目靠人，對人/士兵的管理（物質(zhì)、心理），適合組織的先進(jìn)的過程（開發(fā)，測試，評審，組織，考核），還有工具的運(yùn)用和整合大大提升組織效率，缺少那一樣都是不行的。成功的模式只有一個(gè)，而失敗卻有各式各樣，就是這個(gè)道理。

　　溝通，隨時(shí)隨地，全方位立體的，有效的，及時(shí)的溝通

　 　溝通，溝通，隨時(shí)隨地，全方位立體的溝通。面對面、站立會(huì)議、咖啡間、IM、Email、文檔、電話。上下級、跨部門、客戶，溝通，直到雙方的理解沒有 Gap（鴻溝），沒有Misunderstanding（誤解）。主動(dòng)溝通，有問題隨時(shí)反饋。對被動(dòng)的同事，主動(dòng)問他。注意溝通的效率和時(shí)間表，不要一個(gè) 會(huì)議開兩個(gè)小時(shí)。如果有必要，盡量讓少的人參與，除非是kick-off會(huì)議。此外，溝通會(huì)影響時(shí)間表，比如你有個(gè)問題要問某人，而這個(gè)人下周開始休假 了，要早做預(yù)防。否則，吃虧的是自己。

　　白板，任務(wù)板，Sketch，Prototype

　 　Team位置必須坐在一起，最好是圓圈式的座位，旁邊有玻璃白板，上面畫好下一個(gè)里程碑和Release的Roadmap，玻璃白板便于馬上溝通。任務(wù) 板便于大家清楚當(dāng)前致力的目標(biāo)和Release。對于Sketch要用好，在產(chǎn)品或者功能還沒有做出來以前，先把Sketch或者Prototype發(fā)給 客戶看一下是否認(rèn)可，獲得用好Remarks，然后再開始動(dòng)手；畢竟動(dòng)手了再修改代價(jià)就更大了。所以一定要用好Sketch草圖。

　　Stand up meeting要不要

　 　很多人說到Scrum就要每日晨會(huì)Stand Up Meeting，但我們Team的實(shí)踐來看，并不是必須的，其實(shí)敏捷也是根據(jù)組織和項(xiàng)目實(shí)際情況因人而異的（有人說敏捷對結(jié)對開發(fā)人員的能力要求很高，我 覺得敏捷是一種境界，良好的架構(gòu)，代碼規(guī)范，成員間非常好的默契，才能敏捷的起來）。不能拘泥于形式主義，我主張實(shí)用主義。現(xiàn)在不是有反敏捷、有瀑布敏捷 （Water-Scrum-Fall）、實(shí)用敏捷嗎？關(guān)鍵是我們還沒有領(lǐng)會(huì)敏捷的深刻內(nèi)涵和思想體系，不會(huì)用敏捷的思想和思維方式高屋建瓴的思考我們的開 發(fā)流程，而只是依葫蘆畫瓢學(xué)個(gè)一招半式，那就真的不是敏捷了。我聽到有人說，敏捷只適用于產(chǎn)品型公司和小型項(xiàng)目，還有人說敏捷只適合于需求不穩(wěn)定的項(xiàng)目， 還有人說敏捷了就等于速度快，就等于客戶報(bào)價(jià)可以低一些，還有人說敏捷說的什么迭代持續(xù)集成和重構(gòu)都是理論，沒有考慮到實(shí)際執(zhí)行起來的風(fēng)險(xiǎn)……都沒有錯(cuò)， 關(guān)鍵是我們還沒有領(lǐng)會(huì)敏捷的深刻內(nèi)涵和思想體系，不會(huì)用敏捷的思想和思維方式高屋建瓴的思考我們的開發(fā)流程，而只是依葫蘆畫瓢學(xué)個(gè)一招半式，在這兒討論， 說白了還是理論，坐而論道不如起而行，所以積極實(shí)踐，加深對敏捷內(nèi)涵的深刻理解，尋找適合自己組織的最佳敏捷實(shí)踐方法才是良策。這樣子思想理順了，我們就 不會(huì)拘泥于Stand Up Meeting到底要不要的問題了。

　　保證代碼質(zhì)量

　　如何獲得高代碼質(zhì)量？打個(gè)比方，現(xiàn)在要打仗了，如何打個(gè)漂亮的勝仗。我想你肯定知道答案了。那就是你的隊(duì)伍必須各個(gè)是精兵，能力強(qiáng)，平時(shí)訓(xùn)練有素，而且還有實(shí)戰(zhàn)經(jīng)驗(yàn)，這樣的一個(gè)兵強(qiáng)馬壯的精兵隊(duì)伍你拉出去，只要指揮好，士氣高，就能打漂亮的勝仗。OK，現(xiàn)在你明白了，軟件開發(fā)何不如此？你手下的程序員是不是技術(shù)能力很強(qiáng)，是不是平時(shí)就對技術(shù)研究很深，對某科技術(shù)有很深的理解，還有很多項(xiàng)目經(jīng)驗(yàn)，是不是干勁十足，是不是對他們做了培訓(xùn)，是不是做了編程規(guī)范的要求，都明白了命名規(guī)范、異常處理、日志處理、安全性、用戶權(quán)限、配置文件、設(shè)計(jì)模式、線程安全、單元測試、調(diào)試技巧、條件編譯等項(xiàng)目標(biāo)準(zhǔn)處理；如果還沒有這些標(biāo)準(zhǔn)的貫徹，那你的士兵還需要培訓(xùn)（訓(xùn)練），這樣子上戰(zhàn)場會(huì)很危險(xiǎn)。當(dāng)然，有個(gè)變通辦法，讓資深程序員帶小弟，小弟在一邊看著，下個(gè)項(xiàng)目備用。當(dāng)然。除了培訓(xùn)以外，分享、知識庫都是團(tuán)隊(duì)很重要的機(jī)制。

　 　基礎(chǔ)不扎實(shí)的程序員代碼質(zhì)量不會(huì)高起來，比如有的C#程序員根本理解Task.Factory.StartNew這句話是異步執(zhí)行的線程池起線程，就把 它放到同步的循環(huán)里面，導(dǎo)致問題。再比如，有的程序員用匿名函數(shù)，不懂閉包，導(dǎo)致放在循環(huán)里面每次取到的都是最后一個(gè)值。再比如有的程序員不深刻理解 Session，就認(rèn)為瀏覽器關(guān)了Session就沒有了。再比如有的C#程序員不理解GC以為一個(gè)類只要實(shí)現(xiàn)了IDisposable接口就一定會(huì)內(nèi)存 釋放……舉不勝舉，都是項(xiàng)目中遇到過的（注：對基礎(chǔ)不扎實(shí)的程序員進(jìn)行代碼Review管用嗎？我們項(xiàng)目實(shí)踐來看不管用，因?yàn)橘Y深程序員很忙，不可能一行 一行去看去調(diào)試。）……所以，優(yōu)秀的程序員都是建立在對該技術(shù)的深入理解的基礎(chǔ)上的。優(yōu)秀的成熟的程序員員工都有專業(yè)化（技術(shù)方面）、職業(yè)化（服務(wù)意識、 協(xié)作能力、解決問題的能力和態(tài)度）和商業(yè)化（替客戶思考和解決問題）多方面的優(yōu)秀特質(zhì)，才能真正的為業(yè)務(wù)創(chuàng)造價(jià)值。

　　保證代碼質(zhì)量的另外一個(gè)非常重要的方面就是測試，一定要寫單元測試，使用Moq做單元測試。這可以培養(yǎng)程序員面向接口的思維方式，如果代碼不能做單元測試往往是耦合度很高的代碼，所以單元測試能發(fā)現(xiàn)代碼質(zhì)量的問題。此外，測試組的工作要及早介入，對業(yè)務(wù)的深刻理解，重復(fù)利用bug管理工具，敏捷測試。

　　在系統(tǒng)設(shè)計(jì)的時(shí)候，要考慮到未來可能的需求變化，做好面向變化的架構(gòu)設(shè)計(jì)。但不要過度設(shè)計(jì)。（這需要深入理解商業(yè)需求）

　　為維護(hù)早作準(zhǔn)備，意思是說，在編碼階段，就要考慮到系統(tǒng)的可維護(hù)性，設(shè)想你自己就是將來維護(hù)這個(gè)系統(tǒng)和這段代碼的人，這種意識很重要。有的程序 員以為系統(tǒng)提交了上線了就沒他的事情了，結(jié)果到頭來上線了出現(xiàn)問題，系統(tǒng)又沒有很好的log和trace，導(dǎo)致問題極難線上調(diào)試，而線下又不能模擬真實(shí)的 環(huán)境，這種情況下必須為維護(hù)而設(shè)計(jì)，提升系統(tǒng)的可維護(hù)性、可追溯性、可管理性。

　　不要過度設(shè)計(jì)和過早優(yōu)化

　　過度設(shè)計(jì)是敏捷開發(fā)應(yīng)該避免的，很多工程師都有過度設(shè)計(jì)的沖動(dòng)。例如，在一個(gè)web系統(tǒng)還沒有看到被大規(guī)模使用的曙光以前，就設(shè)計(jì)了系統(tǒng)規(guī)模 化，什么集群、負(fù)載均衡、讀寫分離、分布式緩存系統(tǒng)……說真的，這些東西確實(shí)是好東西，但也很貴。在系統(tǒng)還沒有被大規(guī)模的用戶接受和喜愛之前，這樣做是否 會(huì)抵消了我們把專注點(diǎn)放在核心功能和簡練和簡單的努力呢？時(shí)間是有限的，投資也是有限的。我們必須把有限的時(shí)間和有限的金錢用在當(dāng)前最核心的功能和體驗(yàn) 上。有時(shí)候系統(tǒng)初期，可能一兩臺(tái)服務(wù)器就足夠了。只有在看到產(chǎn)品有被大規(guī)模使用和用戶喜愛的曙光之后，才來增加功能和規(guī)模量。當(dāng)然，你的網(wǎng)站功能，在你只 有 10 萬用戶的時(shí)候，可能和你有 1 億用戶的時(shí)候會(huì)很不一樣。所有太多太早太頻繁的架構(gòu)上的大動(dòng)作可能會(huì)適得其反。這一點(diǎn)上，你要小心判斷。系統(tǒng)架構(gòu)需要及早規(guī)劃，但不要提前實(shí)施和過早優(yōu) 化。

　　關(guān)注非功能性需求

　　也許大多數(shù)客戶和咨詢師也會(huì)聽說過神馬TDD、迭代、原型、持續(xù)集成和持續(xù)部署、Agile等時(shí)髦的詞語，這些也讓管理者很興奮，以為軟件產(chǎn)品 是可以在很短的時(shí)間內(nèi)高質(zhì)量的完成的，即使完不成也可以在后面用TDD，快速迭代，不斷重構(gòu)，持續(xù)集成直至持續(xù)部署的方法在進(jìn)行軟件開發(fā)。這聽起來好像很 美好。但其中有個(gè)很大的陷阱，那就是客戶和咨詢師，還有原型、TDD大都只關(guān)注功能性需求，而忽略了非功能性需求，比如性能問題，高可用性問題，系統(tǒng)維護(hù) 問題（模塊的耦合問題），等等。客戶和咨詢師在項(xiàng)目前期閉口不提這些或很少提及，但一旦功能性需求都做完了他們就會(huì)抱怨這些隱藏的非功能性需求。而像性能 問題，高可用性問題，系統(tǒng)維護(hù)問題（模塊的耦合問題）等并不是很容易重構(gòu)，往往涉及到Re-design， re-architect；因此這些問題往往都在后期會(huì)成為重構(gòu)噩夢，甚至可以讓你的軟件設(shè)計(jì)重新來過！更加糟糕的是，大多數(shù)客戶不愿意為這些隱藏的功能 重構(gòu)而付錢。筆者曾經(jīng)遇到過前期只注重功能性需求而后期發(fā)現(xiàn)性能不好而進(jìn)行re-design， re-architect，這對項(xiàng)目管理來說有很大的挑戰(zhàn)，因?yàn)椴粏螁问浅绦蚝图軜?gòu)重構(gòu)的困難，還要面對時(shí)間和人力成本的增加，最難的是你還要面對的是團(tuán) 隊(duì)士氣因?yàn)椴粩嗟膔ework而逐漸低落并產(chǎn)生厭倦和懈怠情緒。這是一個(gè)很大的陷阱。

　　所以，前期就要關(guān)注非功能性需求，不要急于動(dòng)手，如果你能有多一些時(shí)間去和客戶討論一下需求和未來可能的變化，去調(diào)查一下實(shí)現(xiàn)的技術(shù)難點(diǎn)和細(xì) 節(jié)，去和其他有經(jīng)驗(yàn)的人討論并推敲一下架構(gòu)和設(shè)計(jì)，去思考設(shè)計(jì)上的缺陷，那么，你的coding會(huì)變得非常地直，直到你一眼就看到盡頭，你的測試案例也會(huì) 寫得非常地好，你會(huì)幾乎不需要重構(gòu)，于是，你會(huì)在未來少寫很多代碼，從而你的軟件開發(fā)會(huì)越來越輕松，直到技術(shù)開始換代。這就好像我們修路造橋一樣，我們需 要花大量的時(shí)間勘測地形地質(zhì)，分析數(shù)據(jù)，思考可能出現(xiàn)的各種問題（各種自然災(zāi)害），評估不同的設(shè)計(jì)方案，而不是先盡快建好再說。（：磨刀不誤砍柴工） 說到這里，有些反敏捷（反Scrum），沒錯(cuò)，好的程序員要會(huì)做權(quán)衡/平衡，好的架構(gòu)師要會(huì)做平衡，好的項(xiàng)目經(jīng)理也要會(huì)做平衡，這非常重要。

　　再補(bǔ)充一點(diǎn)，有資深經(jīng)驗(yàn)的工程師/架構(gòu)師對非功能性需求的設(shè)計(jì)和平衡很有經(jīng)驗(yàn)，這些經(jīng)驗(yàn)對系統(tǒng)設(shè)計(jì)和項(xiàng)目成功至關(guān)重要。如果你很不幸，手頭沒有 這些有經(jīng)驗(yàn)有價(jià)值的人，而只有一堆碼農(nóng)，那么恭喜你，你可以在一張白紙上畫畫了。就開發(fā)他們的潛力吧，做好這個(gè)項(xiàng)目給他們積累經(jīng)驗(yàn)的心理準(zhǔn)備吧，量力而行 吧，小馬過河吧……實(shí)在不行你就自己上吧，畢竟公司要求用最少的錢在最短的時(shí)間內(nèi)出來最優(yōu)秀的東西；如果你有話語權(quán)，那就把你的困難及早讓上層知曉。

　　嚴(yán)格控制需求和范圍，和進(jìn)度權(quán)衡，不出現(xiàn)資源空閑

　　領(lǐng)導(dǎo)一般會(huì)給項(xiàng)目經(jīng)理壓力，要求在什么時(shí)間提交一個(gè)版本趕進(jìn)度等，這時(shí)候項(xiàng)目經(jīng)理要么能調(diào)整一些需求和范圍（Scope），要么就把可能出現(xiàn)的 問題進(jìn)行報(bào)憂，因?yàn)楝F(xiàn)在如果不這樣做，你就等著現(xiàn)在報(bào)喜，后期報(bào)憂吧。所以項(xiàng)目經(jīng)理一定要嚴(yán)格控制需求和范圍（scope），和進(jìn)度，和質(zhì)量權(quán)衡。同時(shí)要 合理調(diào)配資源，不要出現(xiàn)項(xiàng)目進(jìn)行中資源空閑的情況（這個(gè)在Project工具中可以看出）。

　　項(xiàng)目風(fēng)險(xiǎn)管控

　　項(xiàng)目經(jīng)理要有項(xiàng)目風(fēng)險(xiǎn)管控能力，及時(shí)在項(xiàng)目進(jìn)行的各個(gè)階段進(jìn)行風(fēng)險(xiǎn)的預(yù)識別和管理。項(xiàng)目一般是前期工期松，風(fēng)險(xiǎn)低；而后期工期緊，風(fēng)險(xiǎn)高。所以 項(xiàng)目經(jīng)理要盡可能在項(xiàng)目早期能列出大部分的風(fēng)險(xiǎn)，這樣在項(xiàng)目的風(fēng)險(xiǎn)應(yīng)該是倒三角形狀的，就是前期風(fēng)險(xiǎn)多，后期風(fēng)險(xiǎn)少。要預(yù)先把下階段可能的風(fēng)險(xiǎn)明確告訴客 戶，讓客戶提供幫助來控制風(fēng)險(xiǎn)的發(fā)生，同時(shí)迫使客戶加強(qiáng)風(fēng)險(xiǎn)意識，不讓需求任意擴(kuò)散和蔓延。在各個(gè)階段都要有雙方風(fēng)險(xiǎn)認(rèn)知的會(huì)議紀(jì)要記錄。一般情況下，項(xiàng) 目的外部依賴條件是最不可管控的風(fēng)險(xiǎn)（比如要和第三方聯(lián)調(diào)，要第三方提供API等）。其次是需求的不明確和需求蔓延的風(fēng)險(xiǎn)（需求問題占項(xiàng)目成功的40%因 素以上，你能控制需求，你就成功60%了）。然后還有資源的可用性（如：項(xiàng)目進(jìn)行中核心人員流失，要知道項(xiàng)目進(jìn)行中間換人和加人都很是問題）。

　　資源提供者和問題解決者

　　大家都知道，打仗的時(shí)候什么最重要？對了，補(bǔ)給（后勤保障）。士兵上戰(zhàn)場了，誰做后勤？項(xiàng)目經(jīng)理。每天都要問大家，你下一步需要什么，你還缺什 么輸入？你有什么問題需要我這邊配合的？程序員旁邊有垃圾了，項(xiàng)目經(jīng)理去掃一下地，這就是后勤補(bǔ)給。所以管理者首先要理順管理者和人的關(guān)系，調(diào)整好服務(wù)的 意識，做好資源源源不斷的提供、幫助大家解決問題，系統(tǒng)就有了潤滑劑，有了源源不斷的輸入，就能順暢的開展。否則，千里馬到你手里也跑不快的。

　　管理用戶期望

　　對每一個(gè)Sprint提交，謹(jǐn)慎選擇功能集合，多和客戶溝通，管理好用戶期望，他下一階段希望有什么功能，這些功能的優(yōu)先級如何，實(shí)現(xiàn)難度如何，及早告訴他下一個(gè)版本會(huì)友什么，不會(huì)有什么。

　　增加團(tuán)隊(duì)成員之間的親密感

　　有時(shí)候如果一個(gè)團(tuán)隊(duì)成員里面有多個(gè)牛人，大家都是很有主見的人，就很容易在一些問題上爭執(zhí)，甚至產(chǎn)生內(nèi)部競爭。兩個(gè)聰明人意見采取誰的呢？緊張 關(guān)系在所難免。這種糾結(jié)的合作和競爭關(guān)系是同事關(guān)系的主線。但要保持合作為重點(diǎn)。所以，要把這樣的狀況保持在一個(gè)健康的狀態(tài)，需要加深團(tuán)隊(duì)成員的親密感。 具體來說，坐在一起聊天、吃午餐、喝咖啡、散步、打球、打牌，都是增加親密感的方法，這樣拉近人與人的距離，就不會(huì)覺得有什么競爭的緊張感了。

　　管理團(tuán)隊(duì)目標(biāo)和情緒

　　Scrum有一個(gè)優(yōu)點(diǎn)就是短周期快速迭代，每周大家都有明確的目標(biāo)，因?yàn)镽elease周期很短，大家Vision很明確，所以為什么 Sprint就是沖刺的意思。管理好團(tuán)隊(duì)的目標(biāo)、Vision，有明確的目標(biāo)，有沖刺的干勁。及時(shí)發(fā)現(xiàn)團(tuán)隊(duì)的情緒波動(dòng)，采取應(yīng)對措施（休整，腐敗，激 勵(lì)）。

　　保持耐心，不斷調(diào)整

　　技術(shù)上要重構(gòu)，架構(gòu)改進(jìn)和提煉等。信任程序員，給他們時(shí)間來重構(gòu)，來調(diào)整和優(yōu)化架構(gòu)等。管理上要重構(gòu)，代碼促進(jìn)委員會(huì)，評審組等等。改進(jìn)適合組 織規(guī)模和業(yè)務(wù)發(fā)展的流程，目標(biāo)是獲得持續(xù)、快速、更好質(zhì)量的交付產(chǎn)品和更好的客戶滿意度、更低的成本和更高的效率。總之，要不斷努力，不斷調(diào)整，不斷嘗試 新的方法，做的越來越好。要保持耐心，給員工/系統(tǒng)的成長/成熟一點(diǎn)信任和時(shí)間。

　　項(xiàng)目經(jīng)理的人格魅力和以德服人

　　作為項(xiàng)目經(jīng)理您必須與同事以團(tuán)隊(duì)合作方式才能保證項(xiàng)目的順利完成，如何鼓舞團(tuán)隊(duì)成員的士氣？讓大家心甘情愿的與你朝著共同的目標(biāo)努力。要做到這 一點(diǎn)，人格魅力非常重要。但要讓大家真正服你，真正的服是以德服人。比如，你要求所有的手下都主動(dòng)配合你的工作，但是你自己如果沒有首先要求自己主動(dòng)配合 大家，你就不會(huì)贏得大家的尊重。這只是一個(gè)例子而已，很多點(diǎn)滴細(xì)微之處會(huì)讓大家感覺到你的人格魅力，究竟是一個(gè)值得尊敬的人，還是一個(gè)不值得尊敬的、自我 的、高高在上的發(fā)布命令者。總之，做人是最要緊的，做人沒做好，做事肯定做不好了，項(xiàng)目多半要搞砸。

　　但就項(xiàng)目經(jīng)理的項(xiàng)目管理能力來說，也關(guān)系到項(xiàng)目的成敗，比如能否引導(dǎo)客戶需求、對問題的透徹理解、對復(fù)雜的任務(wù)緊密跟蹤并設(shè)定輕重緩急、利用各 種渠道和方法來溝通解決問題、有能力做出適當(dāng)?shù)娜∩帷⒄f服客戶或領(lǐng)導(dǎo)的能力、推銷自己解決方案的能力、突破性格制約的溝通技巧、面向全局思考的思維方式、 如何合理動(dòng)態(tài)分配大家的工作項(xiàng)使不被Block住……

　　總結(jié)

　　先寫這么多吧，想到了再補(bǔ)充。