工作五年，一晃已年過三十了。讀研時，獨立做項目，畢業(yè)頭三年，主要在大公司工作，后來，也就是08年，半創(chuàng)業(yè)。具體點，合伙人吧，自己負責IT部門，到現(xiàn)在6人，公司總共20來人，旅游業(yè)。這兩年嚴酷的創(chuàng)業(yè)經(jīng)歷，讓我越發(fā)覺得管理(做事)，以及領(lǐng)導(dǎo)(帶人、待人，不是管人)的重要性。因為，隨著組織的擴大，混亂度無形中就會增大，管理和領(lǐng)導(dǎo)，就是讓這種混亂重歸有序，重歸單人作戰(zhàn)那種意圖和行動的高度統(tǒng)一。

    說得功利點吧，一個人的財富和其影響力是成正比的。影響力本質(zhì)上就是對他人的價值。比如，郎_xian_評的出場費一天超過15萬。作為技術(shù)人員，如果我們只能影響周邊幾個人，那么我們憑什么拿那么高的報酬，除非我們做的事情影響了很多人，比如楊勃的豆瓣網(wǎng)。所以，我還是覺得，技術(shù)人員往高處發(fā)展，逐漸應(yīng)該有管理意識、培養(yǎng)自己的管理能力。技術(shù)從書本上可以學到很多，管理還真得實踐，書上看到的，你覺得很弱智的問題，比如盲目擴張，自己親身經(jīng)歷時，一樣會犯，也許是行為習慣在起作用，看書不足以改變行為。

    回到正題上。
    也許是自己曾經(jīng)在較大公司或團隊的做事習慣和視野，剛創(chuàng)業(yè)時，用在這種小團隊的商業(yè)項目開發(fā)上，幾乎慘敗。
    先說項目開發(fā)這塊吧。
    大家知道，項目管理和過程管理是兩碼事，前者關(guān)注目標和進度，成本和收益；后者關(guān)注做事流程、方法。
    項目管理，體會最深的，就是目標和任務(wù)分解、進度控制，以及溝通。

    項目管理軟件
    從大公司出來的人，我想最喜歡玩的，就是借助于項目管理軟件(核心是甘特圖)。市面上的大多數(shù)知名的項目管理軟件，無論是桌面版還是網(wǎng)頁版的，我都試過。當然最后也選擇了一款：ConceptDraw Project，用了一年多，也多少有些用。但最后還是發(fā)現(xiàn)，它其實對項目進度和質(zhì)量關(guān)系并不大。也許，一個Excel表格更實用。
     項目管理軟件，本質(zhì)上是解決一種溝通和職責分配的問題。比如，一個項目，折疊成一個三層樹形結(jié)構(gòu)，老板只關(guān)心第一層，也就是整體進度；中間是項目經(jīng)理關(guān)注的功能層，最后一層，也就是具體的任務(wù)，是開發(fā)人員關(guān)注的。想想，如果沒有這玩意，你怎么告訴其它項目干系人進度？但又引出幾個問題：
    靠文檔來溝通，還是靠信任? 太在乎文檔，往往導(dǎo)致每天去關(guān)注文檔如何漂亮、有說服力，并為此花大量時間，而不是項目如何漂亮。另外，是否有文檔就可以防止扯皮、兌現(xiàn)承諾？我們是關(guān)于項目目標，還是關(guān)注彼此的博弈？

    進度偏差 創(chuàng)業(yè)型項目，往往都是以前沒有接觸過，其進度評估往往有很大誤差，比如業(yè)務(wù)需求的挖掘和變化，技術(shù)難點，開發(fā)人員素質(zhì)。我們是關(guān)注進度，還是關(guān)注項目本身的質(zhì)量？兩者都要，但如何兼顧？雖然有方法學，比如砍掉優(yōu)先級低的，但你怎么讓老板相信某個核心功能就得四天時間。
    在我們的進度設(shè)計不合理情況下，是否開發(fā)人員完成甘特圖(WBS)下的任務(wù)就ok？遠遠不夠，任務(wù)分得太細，往往限制了開發(fā)人員的創(chuàng)造性和自我評估能力，如果提前兩天完成呢？
    我們現(xiàn)在是以項目管理軟件為輔，任務(wù)的下達主要以郵件傳達，每周一上午的周例會會白板宣布。我發(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代碼寫得很漂亮嗎？我們應(yīng)該關(guān)注代碼的健壯性而不是可維護性，我們不是在開發(fā)Windows。

    人適應(yīng)項目，還是項目適應(yīng)人
    大公司，往往是來了一個項目，趕快招人，人來適應(yīng)項目。小公司呢，我現(xiàn)在的看法是，項目適應(yīng)人。小公司，往往一個項目做砸，公司就面臨解散。所以，我認為，最好還是按照開發(fā)人員的擅長，保證功能質(zhì)量，最快的速度上線。另外，為了達成進度，可以在上線初期砍掉不太重要的欄目或功能。
    我在這個上面栽過跟頭的。比如開發(fā)人員的擅長，如果他擅長jsp開發(fā)模式，而不是Hibernate+Spring的分層開發(fā)，就讓他按自己的意思做吧。因為，創(chuàng)業(yè)型項目都不會太大；即使技術(shù)實現(xiàn)你感覺完美了，用戶可能感覺不爽；再說，項目開發(fā)，涉及到業(yè)務(wù)調(diào)研、需求分析、原型界面、架構(gòu)、開發(fā)、部署、推廣。開發(fā)，也就是代碼實現(xiàn)，占去項目時間，也許不到30%。項目如果證實有商業(yè)前景，代碼重新實現(xiàn)一遍，花不了多少時間。
    但我也深深地意識到我們項目管理的級別，就如同CMM1到CMM4。但我還是覺得目前是最好的選擇。
    如果最低層次的用戶需求目標都達不到，直接考慮代碼怎么有可擴展性、可維護性，對于小公司就是找死。
    另外，尊重和信任、支持開發(fā)人員的技術(shù)選擇，往往是一種激勵、增強團隊凝聚力的方式。萬眾一心，比什么目標、進度更有效、實際。
    我們應(yīng)該培養(yǎng)一種團隊成員的內(nèi)部創(chuàng)業(yè)心態(tài)，而不只是敬業(yè)。

    在進度把控上，我現(xiàn)在更傾向于強調(diào)我們的項目目標和緊迫性，而不是他們的任務(wù)。因為我希望大家的關(guān)注點是項目，而不是他的上級，他應(yīng)該對項目負責，而不只是對上級負責。

    說說溝通
    項目管理中最難處理好的，就是溝通。以前，我比較關(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ā)人員的反應(yīng)是如何不讓領(lǐng)導(dǎo)下次責怪自己，比如只做領(lǐng)導(dǎo)安排的事情；后者的反應(yīng)是怎么去改進，不讓這樣的事情發(fā)生。
   如果你認可創(chuàng)新就可能出錯，如果你認可開發(fā)人員都是想做好的。那么所有的事情，朝正向發(fā)展邁出了最決定性的第一步。

   溝通:命令式還是征詢式
   在溝通，特別是下達任務(wù)或做決策這類事情上。應(yīng)該說中國絕大多少管理者都是用命令式。我過去經(jīng)常在用，但一直在試圖改正，改用建議式和征詢式。管理者最需要、最難開口的一句話是：Do you think so？命令的方式，經(jīng)常出現(xiàn)下級不能理解上級的意圖，嚴重的出現(xiàn)抵觸。每個人，其實都喜歡別人按自己的想法做事，但你怎么知道自己的想法或決策是對或不是偏頗的，怎么讓團隊愿意去執(zhí)行？去征詢團隊其他成員的意見，讓他們參與，往往能夠培養(yǎng)其主人翁意識、責任感、向心力，還能夠完善自己的想法。但要將員工參與意識，轉(zhuǎn)化為一種習慣，太難。
    當大家都沒有主見時，需要領(lǐng)導(dǎo)者的果斷、魄力和強勢，但這種機會并不多，而且這種情況，需要團隊成員對領(lǐng)導(dǎo)者的信任。
   
    遵守制度，還是建立信任
     在大公司，往往是告訴你怎么去遵守公司制度。在小公司，我認為最基礎(chǔ)、最核心的一件事，就是建立信任，讓團隊信任你的人品(說到做到)，信任你的能力(能夠把大家?guī)У揭粋€新的高度)。建立了信任后，下一步的核心工作，怎么將你的個人目標，也就是團隊目標，轉(zhuǎn)化為每個成員的個人目標。
    有了信任這個基礎(chǔ)，才會有了團隊建設(shè)的第二個核心：激勵。
    是激勵，而不是約束、監(jiān)督，讓團隊有戰(zhàn)斗力。但大公司往往喜歡后者。也許，大公司都是職業(yè)經(jīng)理人，反正是打工，太關(guān)注于事。如果說有個所謂的中國式領(lǐng)導(dǎo)，我覺得就是以人為本，對人的尊重。人的關(guān)系處理好了，事情就好做。
    加班、考勤、上網(wǎng)監(jiān)控，這類對信任、激勵極具破壞力的行為，也許是工業(yè)型社會對我們這個思考性創(chuàng)造性行業(yè)的侵蝕。知識型勞動者，需要一種與體力型勞動者完全不同的管理模式，這種模式也許需要一個從萌芽、生長到成熟期。現(xiàn)在在目前的中國，還只是剛走出萌芽期。
   
    以前完整看過余世維的11套視頻，還看過幾遍。他那種人本理念我還是很認同，只是，他在大公司、規(guī)范公司的做事情方法和風格，完全照搬拿到小公司，非常危險。你能夠拿幼兒園那種教育方法來教育成年人嗎？小公司不具備大公司那種職業(yè)化的環(huán)境，也不具備大公司在行業(yè)中的市場地位及資金實力。
    如果說大公司講究做事方法、流程，如SWOT分析法、BCG矩陣，小公司更看重靈活性、市場適應(yīng)性。小公司應(yīng)該適當短視、急功近利，否則在你實施一個三年計劃時，第二年還不賺錢可能就撐不下去。
    所以我覺得，在跨國大企業(yè)呆慣了，出來創(chuàng)業(yè)很危險。一個是做事方法不適應(yīng)，另外一個就是沒有平臺。如果要出來創(chuàng)業(yè)，以前那種大企業(yè)的經(jīng)歷可能更是一種劣勢。 也許有一種情況，你是大公司的高官，拿到一筆很大的風險投資，然后出來創(chuàng)業(yè)。
    
    人事招聘
     薪水  如果公司給得起，并且應(yīng)聘者能力差不多。 就不要太在乎那200、300。雖然說至少要不低于行業(yè)平均值（IT人員是IT行業(yè)平均值，而不是本公司所在的行業(yè)平均值），但最重要的，還是不要低于當事人的期望值，因為最核心的是滿意度，而滿意度決定于期望值和實際值的差距。對于小公司，往往一個人技術(shù)人員的成本和收益，和其工資差距非常大，有可能10倍。所以，我們的關(guān)注點，應(yīng)該是怎么一開始留住這位人才。然后，怎么讓其充分發(fā)揮潛力。小公司往往不是因為節(jié)省那幾千幾萬的工資成本死掉的，而是充分利用這位人才才活下去了。

     另外，不要以為有多少人才選擇的機會，小公司往往不受高級人才的青睞。太高級的人才，可能養(yǎng)不起，而且往往太有個性，很難合作愉快，除非在來公司前有很長時間的了解。
     招聘到合適人才后，應(yīng)該讓其忘掉薪水，專注于工作，尋找工作本身的樂趣。當然，要做到讓其在薪水上有優(yōu)越感，也許是項目很盈利的那一天，開始時很難。

     人才標準 如果其能力和你預(yù)期相差不大的話，更應(yīng)該考慮其態(tài)度、做事風格，甚至是價值觀。因為其能力的發(fā)揮，和這個環(huán)境，特別是他的直接利益相關(guān)者，也就是上司，關(guān)系太大。如果配合得好，一個人可以頂三個。否則，那種內(nèi)耗導(dǎo)致的進度延期，由此引起的市場機會喪失，公司財力無法支撐，往往是致命的。因為一個幾人的IT團隊，每一個人的職責就如同那木桶的一塊板，缺了那塊都存不了水。
     比如關(guān)于質(zhì)量，更確切說是內(nèi)容質(zhì)量，我們目前做旅游電子商務(wù)，我認為內(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ù)很狂熱，根本就不愁找不到工作，因為面試時我覺得那家伙應(yīng)該比我牛，正好可以切磋切磋，沒想太多所以沒啥怯場或不自信。工作吧，如果是技術(shù)類，特別是商業(yè)軟件，技術(shù)難度都不大，按上司意思來，很容易搞定。創(chuàng)業(yè)呢，自己要做商業(yè)判斷、業(yè)務(wù)決策，還要協(xié)調(diào)若干人的工作(協(xié)調(diào)的本質(zhì)是協(xié)調(diào)利益)。做事和管事，完全是兩碼事，有些難。不過，創(chuàng)業(yè)還是很有意思，因為你可以按自己的意愿去工作去生活，當然也是受限環(huán)境的自由。


我將我的一個回復(fù)放在這個地方，特示警醒：
原文地址：http://www.javaeye.com/topic/646406      摘要: 開發(fā)和架構(gòu)的界限難以捉摸。有些人告訴你它根本不存在，架構(gòu)只是開發(fā)者們所做的設(shè)計過程的簡單擴展。 另外一些人認為這是一個鴻溝，它只能由那些做到高度抽象，而且不會陷入實現(xiàn)細節(jié)的開發(fā)者才能跨越。通常，在這兩個極端的觀點中間某處有個可操作的平衡點；不論如何，怎么從開發(fā)轉(zhuǎn)換為架構(gòu)師都是個有趣的問題。

經(jīng)常被用來區(qū)分軟件架構(gòu)和軟件設(shè)計開發(fā)的關(guān)鍵幾點包括 伸縮性和抽象程度的增加以及作出正確設(shè)計決策意義的增強。軟件架構(gòu)是通過一個全局的觀點，宏觀的視角來理解軟件系統(tǒng)作為一個整體如何工作。

即使這能夠幫助區(qū)分軟件開發(fā)和架構(gòu)，它并不能幫助理解某人如何從開發(fā)提升到架構(gòu)。 并且，它也不能幫助識別誰能夠成為一個好的軟件架構(gòu)師，如果你想雇人的話你如何去尋找他們以及你是否是一個軟件架構(gòu)師。
  閱讀全文      摘要: Flashback 技術(shù)是以Undo segment中的內(nèi)容為基礎(chǔ)的， 因此受限于UNDO_RETENTON參數(shù)。要使用flashback 的特性，必須啟用自動撤銷管理表空間。
在Oracle 10g中， Flash back家族分為以下成員： Flashback Database， Flashback Drop，F(xiàn)lashback Query(分Flashback Query,Flashback Version Query， Flashback Transaction Query 三種) 和Flashback Table。  閱讀全文      摘要: 代碼檢查是白盒測試的一種靜態(tài)測試方法，是眾多軟件測試方法中發(fā)現(xiàn)軟件缺陷最有效的方法之一。本文結(jié)合國內(nèi)外學者在相關(guān)領(lǐng)域的研究情況，介紹代碼檢查相關(guān)的基本概念、過程和分析方法。  閱讀全文      摘要: 為什么需要對參數(shù)進行編碼？相信有過開發(fā)的經(jīng)驗的廣大程序員都知道，在Web中，若是直接在Url地址上傳遞參數(shù)值，若是中文，或者+等什么的就會出現(xiàn)亂碼現(xiàn)象，若是數(shù)字或者英文的好象沒有什么問題，簡言之，傳遞過來的參數(shù)是需要進行編碼的。 在這里，也許有人會說，為什么不直接用Server.UrlDecode和Server.UrlEncode這兩個來進行編碼和解碼的操作呢？ 的確，這兩個服務(wù)器端對象很...  閱讀全文      摘要: Spring Framework最得以出名的是與Hibernate的無縫鏈接，基本上用Spring，就會用Hibernate。可惜的是Spring提供的 HibernateTemplate功能顯得不夠，使用起來也不是很方便。我們編程序時，一般先寫B(tài)usinessService，由 BusinessService調(diào)DAO來執(zhí)行存儲，在這方面Spring沒有很好的例子，造成真正想用好它，并不容易。  閱讀全文      摘要: Spring Framework從誕生之日起，受到了越來越多的關(guān)注。最近，新的開源項目大多支持Spring Framework。國內(nèi)目前也有專門的網(wǎng)站（http://spring.jactiongroup.net/）。那它為什么如此受歡迎呢？

我想最重要的是，EJB讓每個人都痛恨。要編寫一個EJB，需要寫LocalHome, RemoteHome, Bean, LocalInterface, RemoteInterface，需要一個標準描述符，一個特殊廠商描述符（Weblogic、WebSphere都不一樣），如果是Entity Bean，還需要Mapping文件。如此之多，實在麻煩。但EJB最重要的是解決Transaction問題，沒有Spring之前，沒有其他方法能夠描述式的解決它。每個人、每個公司為了解決Transaction的問題，編程的寫法都不一樣，百花齊放。于是，在最需要它的時候，Spring出現(xiàn)了。  閱讀全文      摘要: Spring Framework  【Java開源 J2EE框架】 Spring 是一個解決了許多在J2EE開發(fā)中常見的問題的強大框架。 Spring提供了管理業(yè)務(wù)對象的一致方法并且鼓勵了注入對接口編程而不是對類編程的良好習慣。Spring的架構(gòu)基礎(chǔ)是基于使用JavaBean屬性的 Inversion of Control容器。然而，這僅僅是完整圖景中的一部...  閱讀全文

 

Chasing an OSGi vision

OSGi技術(shù)的研究和討論