文章轉(zhuǎn)載自:http://www.javaeye.com/topic/646406
工作五年,一晃已年過三十了。讀研時,獨立做項目,畢業(yè)頭三年,主要在大公司工作,后來,也就是08年,半創(chuàng)業(yè)。具體點,合伙人吧,自己負責IT部門,到現(xiàn)在6人,公司總共20來人,旅游業(yè)。這兩年嚴酷的創(chuàng)業(yè)經(jīng)歷,讓我越發(fā)覺得管理(做事),以及領(lǐng)導(帶人、待人,不是管人)的重要性。因為,隨著組織的擴大,混亂度無形中就會增大,管理和領(lǐng)導,就是讓這種混亂重歸有序,重歸單人作戰(zhàn)那種意圖和行動的高度統(tǒng)一。
說得功利點吧,一個人的財富和其影響力是成正比的。影響力本質(zhì)上就是對他人的價值。比如,郎_xian_評的出場費一天超過15萬。作為技術(shù)人員,如果我們只能影響周邊幾個人,那么我們憑什么拿那么高的報酬,除非我們做的事情影響了很多人,比如楊勃的豆瓣網(wǎng)。所以,我還是覺得,技術(shù)人員往高處發(fā)展,逐漸應該有管理意識、培養(yǎng)自己的管理能力。技術(shù)從書本上可以學到很多,管理還真得實踐,書上看到的,你覺得很弱智的問題,比如盲目擴張,自己親身經(jīng)歷時,一樣會犯,也許是行為習慣在起作用,看書不足以改變行為。
回到正題上。
也許是自己曾經(jīng)在較大公司或團隊的做事習慣和視野,剛創(chuàng)業(yè)時,用在這種小團隊的商業(yè)項目開發(fā)上,幾乎慘敗。
先說項目開發(fā)這塊吧。
大家知道,項目管理和過程管理是兩碼事,前者關(guān)注目標和進度,成本和收益;后者關(guān)注做事流程、方法。
項目管理,體會最深的,就是目標和任務分解、進度控制,以及溝通。
項目管理軟件
從大公司出來的人,我想最喜歡玩的,就是借助于項目管理軟件(核心是甘特圖)。市面上的大多數(shù)知名的項目管理軟件,無論是桌面版還是網(wǎng)頁版的,我都試過。當然最后也選擇了一款:ConceptDraw Project,用了一年多,也多少有些用。但最后還是發(fā)現(xiàn),它其實對項目進度和質(zhì)量關(guān)系并不大。也許,一個Excel表格更實用。
項目管理軟件,本質(zhì)上是解決一種溝通和職責分配的問題。比如,一個項目,折疊成一個三層樹形結(jié)構(gòu),老板只關(guān)心第一層,也就是整體進度;中間是項目經(jīng)理關(guān)注的功能層,最后一層,也就是具體的任務,是開發(fā)人員關(guān)注的。想想,如果沒有這玩意,你怎么告訴其它項目干系人進度?但又引出幾個問題:
靠文檔來溝通,還是靠信任? 太在乎文檔,往往導致每天去關(guān)注文檔如何漂亮、有說服力,并為此花大量時間,而不是項目如何漂亮。另外,是否有文檔就可以防止扯皮、兌現(xiàn)承諾?我們是關(guān)于項目目標,還是關(guān)注彼此的博弈?
進度偏差 創(chuàng)業(yè)型項目,往往都是以前沒有接觸過,其進度評估往往有很大誤差,比如業(yè)務需求的挖掘和變化,技術(shù)難點,開發(fā)人員素質(zhì)。我們是關(guān)注進度,還是關(guān)注項目本身的質(zhì)量?兩者都要,但如何兼顧?雖然有方法學,比如砍掉優(yōu)先級低的,但你怎么讓老板相信某個核心功能就得四天時間。
在我們的進度設(shè)計不合理情況下,是否開發(fā)人員完成甘特圖(WBS)下的任務就ok?遠遠不夠,任務分得太細,往往限制了開發(fā)人員的創(chuàng)造性和自我評估能力,如果提前兩天完成呢?
我們現(xiàn)在是以項目管理軟件為輔,任務的下達主要以郵件傳達,每周一上午的周例會會白板宣布。我發(fā)現(xiàn)白板比投影儀PPT好用。
關(guān)于規(guī)范
這也是大公司特別喜歡玩的。
也許我們前期會制定一個的架構(gòu)、設(shè)計文檔,代碼規(guī)范,這有一個規(guī)范建立的時間成本以及規(guī)范本書的合理性,再說如果一個開發(fā)人員,特別是高手,如果不認同你的設(shè)計和規(guī)范,你要強推,他要么走人要么怠工。規(guī)范的本質(zhì)是為了協(xié)作和后期可維護,如果只有兩個人或一個人寫某個模塊,你覺得有這個必要嗎?規(guī)范整潔的代碼,在項目初期,對用戶的價值關(guān)系很小,你會關(guān)心豆瓣網(wǎng)的js代碼寫得很漂亮嗎?我們應該關(guān)注代碼的健壯性而不是可維護性,我們不是在開發(fā)Windows。
人適應項目,還是項目適應人
大公司,往往是來了一個項目,趕快招人,人來適應項目。小公司呢,我現(xiàn)在的看法是,項目適應人。小公司,往往一個項目做砸,公司就面臨解散。所以,我認為,最好還是按照開發(fā)人員的擅長,保證功能質(zhì)量,最快的速度上線。另外,為了達成進度,可以在上線初期砍掉不太重要的欄目或功能。
我在這個上面栽過跟頭的。比如開發(fā)人員的擅長,如果他擅長jsp開發(fā)模式,而不是Hibernate+Spring的分層開發(fā),就讓他按自己的意思做吧。因為,創(chuàng)業(yè)型項目都不會太大;即使技術(shù)實現(xiàn)你感覺完美了,用戶可能感覺不爽;再說,項目開發(fā),涉及到業(yè)務調(diào)研、需求分析、原型界面、架構(gòu)、開發(fā)、部署、推廣。開發(fā),也就是代碼實現(xiàn),占去項目時間,也許不到30%。項目如果證實有商業(yè)前景,代碼重新實現(xiàn)一遍,花不了多少時間。
但我也深深地意識到我們項目管理的級別,就如同CMM1到CMM4。但我還是覺得目前是最好的選擇。
如果最低層次的用戶需求目標都達不到,直接考慮代碼怎么有可擴展性、可維護性,對于小公司就是找死。
另外,尊重和信任、支持開發(fā)人員的技術(shù)選擇,往往是一種激勵、增強團隊凝聚力的方式。萬眾一心,比什么目標、進度更有效、實際。
我們應該培養(yǎng)一種團隊成員的內(nèi)部創(chuàng)業(yè)心態(tài),而不只是敬業(yè)。
在進度把控上,我現(xiàn)在更傾向于強調(diào)我們的項目目標和緊迫性,而不是他們的任務。因為我希望大家的關(guān)注點是項目,而不是他的上級,他應該對項目負責,而不只是對上級負責。
說說溝通
項目管理中最難處理好的,就是溝通。以前,我比較關(guān)注于工具,如郵件、文檔、ppt講稿會議,逐漸我關(guān)注效率和效能,特別是態(tài)度。溝通最基礎(chǔ)的就是態(tài)度。如果網(wǎng)站上線后,訂單提交出現(xiàn)一個核心bug,你是直接找開發(fā)人員問責;還是告訴他哪兒出了問題,這個問題的嚴重,并且自己反省,比如測試流程出了問題。出現(xiàn)這種事情,也許需要負責人舉重若輕的氣度。但更深層次的,如果負責人能夠培養(yǎng)其員工質(zhì)量意識,危機意識,才是治本。因為一個有強烈質(zhì)量意識的團隊,他自然會去對代碼健壯性、功能易用性精益求精,自然會去配合測試流程。
剛才那個溝通問題,對開發(fā)人員的態(tài)度,前者是負面,后者是中立。那么前者,開發(fā)人員的反應是如何不讓領(lǐng)導下次責怪自己,比如只做領(lǐng)導安排的事情;后者的反應是怎么去改進,不讓這樣的事情發(fā)生。
如果你認可創(chuàng)新就可能出錯,如果你認可開發(fā)人員都是想做好的。那么所有的事情,朝正向發(fā)展邁出了最決定性的第一步。
溝通:命令式還是征詢式
在溝通,特別是下達任務或做決策這類事情上。應該說中國絕大多少管理者都是用命令式。我過去經(jīng)常在用,但一直在試圖改正,改用建議式和征詢式。管理者最需要、最難開口的一句話是:Do you think so?命令的方式,經(jīng)常出現(xiàn)下級不能理解上級的意圖,嚴重的出現(xiàn)抵觸。每個人,其實都喜歡別人按自己的想法做事,但你怎么知道自己的想法或決策是對或不是偏頗的,怎么讓團隊愿意去執(zhí)行?去征詢團隊其他成員的意見,讓他們參與,往往能夠培養(yǎng)其主人翁意識、責任感、向心力,還能夠完善自己的想法。但要將員工參與意識,轉(zhuǎn)化為一種習慣,太難。
當大家都沒有主見時,需要領(lǐng)導者的果斷、魄力和強勢,但這種機會并不多,而且這種情況,需要團隊成員對領(lǐng)導者的信任。
遵守制度,還是建立信任
在大公司,往往是告訴你怎么去遵守公司制度。在小公司,我認為最基礎(chǔ)、最核心的一件事,就是建立信任,讓團隊信任你的人品(說到做到),信任你的能力(能夠把大家?guī)У揭粋€新的高度)。建立了信任后,下一步的核心工作,怎么將你的個人目標,也就是團隊目標,轉(zhuǎn)化為每個成員的個人目標。
有了信任這個基礎(chǔ),才會有了團隊建設(shè)的第二個核心:激勵。
是激勵,而不是約束、監(jiān)督,讓團隊有戰(zhàn)斗力。但大公司往往喜歡后者。也許,大公司都是職業(yè)經(jīng)理人,反正是打工,太關(guān)注于事。如果說有個所謂的中國式領(lǐng)導,我覺得就是以人為本,對人的尊重。人的關(guān)系處理好了,事情就好做。
加班、考勤、上網(wǎng)監(jiān)控,這類對信任、激勵極具破壞力的行為,也許是工業(yè)型社會對我們這個思考性創(chuàng)造性行業(yè)的侵蝕。知識型勞動者,需要一種與體力型勞動者完全不同的管理模式,這種模式也許需要一個從萌芽、生長到成熟期?,F(xiàn)在在目前的中國,還只是剛走出萌芽期。
以前完整看過余世維的11套視頻,還看過幾遍。他那種人本理念我還是很認同,只是,他在大公司、規(guī)范公司的做事情方法和風格,完全照搬拿到小公司,非常危險。你能夠拿幼兒園那種教育方法來教育成年人嗎?小公司不具備大公司那種職業(yè)化的環(huán)境,也不具備大公司在行業(yè)中的市場地位及資金實力。
如果說大公司講究做事方法、流程,如SWOT分析法、BCG矩陣,小公司更看重靈活性、市場適應性。小公司應該適當短視、急功近利,否則在你實施一個三年計劃時,第二年還不賺錢可能就撐不下去。
所以我覺得,在跨國大企業(yè)呆慣了,出來創(chuàng)業(yè)很危險。一個是做事方法不適應,另外一個就是沒有平臺。如果要出來創(chuàng)業(yè),以前那種大企業(yè)的經(jīng)歷可能更是一種劣勢。 也許有一種情況,你是大公司的高官,拿到一筆很大的風險投資,然后出來創(chuàng)業(yè)。
人事招聘
薪水 如果公司給得起,并且應聘者能力差不多。 就不要太在乎那200、300。雖然說至少要不低于行業(yè)平均值(IT人員是IT行業(yè)平均值,而不是本公司所在的行業(yè)平均值),但最重要的,還是不要低于當事人的期望值,因為最核心的是滿意度,而滿意度決定于期望值和實際值的差距。對于小公司,往往一個人技術(shù)人員的成本和收益,和其工資差距非常大,有可能10倍。所以,我們的關(guān)注點,應該是怎么一開始留住這位人才。然后,怎么讓其充分發(fā)揮潛力。小公司往往不是因為節(jié)省那幾千幾萬的工資成本死掉的,而是充分利用這位人才才活下去了。
另外,不要以為有多少人才選擇的機會,小公司往往不受高級人才的青睞。太高級的人才,可能養(yǎng)不起,而且往往太有個性,很難合作愉快,除非在來公司前有很長時間的了解。
招聘到合適人才后,應該讓其忘掉薪水,專注于工作,尋找工作本身的樂趣。當然,要做到讓其在薪水上有優(yōu)越感,也許是項目很盈利的那一天,開始時很難。
人才標準 如果其能力和你預期相差不大的話,更應該考慮其態(tài)度、做事風格,甚至是價值觀。因為其能力的發(fā)揮,和這個環(huán)境,特別是他的直接利益相關(guān)者,也就是上司,關(guān)系太大。如果配合得好,一個人可以頂三個。否則,那種內(nèi)耗導致的進度延期,由此引起的市場機會喪失,公司財力無法支撐,往往是致命的。因為一個幾人的IT團隊,每一個人的職責就如同那木桶的一塊板,缺了那塊都存不了水。
比如關(guān)于質(zhì)量,更確切說是內(nèi)容質(zhì)量,我們目前做旅游電子商務,我認為內(nèi)容質(zhì)量很核心。但你招進來的同事,始終認為先要量,什么都可以抄,而我強調(diào)質(zhì),原創(chuàng)、半原創(chuàng),可以少而精,而不能多而亂。除開項目進度,怎么去溝通?最好兩個人一開始都認同原創(chuàng)的力量。
提升一個人的技能不難,但改變一個人的態(tài)度比較難,改變一個人的價值觀幾乎不現(xiàn)實。所以先找志同道合的人吧。
別期望人才是可替代的。我們不是大公司,我們?nèi)绷苏l,那一塊就不轉(zhuǎn)。
大家都知道,松耦合要付出代價,比如SOAP協(xié)議的低性能,AMF私有協(xié)議的高性能。創(chuàng)業(yè)期,不要太多考慮人才替換,而是關(guān)注怎么發(fā)揮人的潛力,留住人,盡快高質(zhì)量完成項目。人才替換的一個假設(shè),可能是你對自己管理的不自信,因為你不相信自己能夠留住人。
這次就寫這么多吧。
我似乎有這種體會,考大學、四六級這類資格、證書類考試最好混,因為只要勤奮就可以,再加點方法就可以出類拔萃了。 上班也比較好混,說找工作吧,像我搞技術(shù)的,本身對技術(shù)很狂熱,根本就不愁找不到工作,因為面試時我覺得那家伙應該比我牛,正好可以切磋切磋,沒想太多所以沒啥怯場或不自信。工作吧,如果是技術(shù)類,特別是商業(yè)軟件,技術(shù)難度都不大,按上司意思來,很容易搞定。創(chuàng)業(yè)呢,自己要做商業(yè)判斷、業(yè)務決策,還要協(xié)調(diào)若干人的工作(協(xié)調(diào)的本質(zhì)是協(xié)調(diào)利益)。做事和管事,完全是兩碼事,有些難。不過,創(chuàng)業(yè)還是很有意思,因為你可以按自己的意愿去工作去生活,當然也是受限環(huán)境的自由。
我將我的一個回復放在這個地方,特示警醒:
引用
告誡各位處于開發(fā)第一線的朋友,千萬不要受本文的誤導,把規(guī)范和設(shè)計文檔不當回事。
我的看法:
1、文檔的多少和深度決定于項目環(huán)境。
如果是大項目,比如二三十開發(fā)人員,架構(gòu)文檔、需求文檔、代碼規(guī)范等都是必須,否則開發(fā)人員不能迅速了解項目技術(shù)和業(yè)務特點,從而無法快速開發(fā),也即是規(guī)范可以降低培訓成本和團隊溝通;另外,項目開發(fā)中后期可能根本不可控,誰都看不懂其它人的代碼。部署時看到的一些bug無法及時修復,因為到處都有地雷。我以前經(jīng)歷過這樣的項目,最后加班都沒用。
如果是產(chǎn)品型,規(guī)范更重要。當然我說的產(chǎn)品可能是2.0版以后,因為這時候的產(chǎn)品基本得到了市場的認可。而在初版時,代碼寫得爛都沒關(guān)系,因為你不不知道用戶會不會買單,也不知道能否按進度開發(fā)完成。而在后續(xù)版本,如果沒有規(guī)范文檔,維護的成本都不亞于重新開發(fā)。特別是處于一線的開發(fā)人員會怨聲載道:為什么要我來收拾殘局?那么,這樣的士氣,開發(fā)效率怎么會高,項目質(zhì)量怎么會高?
2、成熟型大公司那套做事流程,可能高手受不了,但可能是最優(yōu)的方案。因為,到項目后期維護,往往只是一些業(yè)務功能的刪減改進,不需要技術(shù)高手,這個過程可能漫漫幾年,項目維護成本會非常高,雇傭高手一來他不愿意干二來也不需要這種人,如果項目代碼還維持在一種“秩序”,初中級開發(fā)人員就可以勝任,有什么不好呢?
項目上線時,是為了追求利潤。項目維護期,是為了省成本。
3、剛?cè)氲赖呐笥眩詈檬前匆?guī)范來,就像學武術(shù),先要學套路。否則,養(yǎng)成的編程壞習慣,比如文件名叫Aaa1.java,代碼沒有縮進。過幾年非常難改。而好的編程習慣,可以提升開發(fā)效率,還能讓自己思維清晰。
學技術(shù)階段,一定要注意代碼的可維護性、健壯性及靈活性,只有養(yǎng)成對代碼精益求精的態(tài)度,你才可能成為技術(shù)高手。技術(shù)學好,做技術(shù)管理就有了基礎(chǔ),而且別人也會服你。