其他

先說說看什麼是零和思維，以下是在網上查到的比較合適的一個答案：“所謂零和，是博弈論裡的一個概念，意思是雙方博弈，一方得益必然意味著另一方吃虧，一方得益多少，另一方就吃虧多少。之所以稱為“零和”，是因為將勝負雙方的“得”與“失”相加，總數為零。” 這種思維總是錯的嗎？不，它在某些環境下是正確的， 尤其是稀缺性的環境，譬如一共只有十個蘋果兩人來分，A多得一個B就會少分一個。但它總是對的嗎？答案也是不，它在共贏的環境中，譬如項目團隊中，就是不好的，甚至是非常危險的一種思維。 那為什麼零和思維在團隊合作

前一陣子在公司內部溝通的過程中發生了一個小插曲，看似無足輕重，實際上這裡面有些問題值得思索。 事情是這樣的，當事人提到了一個實際情況，本意是想從公司獲得一些理解和安慰，結果卻被相關管理員認為是他在提無理要求，導致了一個非常不愉快的溝通，引起了員工離職的想法。這裡面的問題是，當員工提到一些情況的時候，管理員除了立刻去拿出解決方案，還有沒有別的選擇呢？ 首先，當員工在溝通時說及一些情況，有沒有可能他並不是在尋求協助，只是在尋求理解和關心呢？其次，他提到的情況，是個真正的問題嗎？是個需要解決的問題嗎？

這是一個活生生的案例，也是一個慘痛的教訓，它給相關參與者都上了一課 -

大多總結會議的目的都有以下兩個主要的方面：一是促使每個與會者總結反省下當前的工作情況，找到可以吸取的教訓，或找到可以改進的地方；二是大家相互之間經驗分享，吸取他人的教訓，避免在自己工作中遭遇同樣的問題； 所以以下方法或許有助於提升會議的效果：會上只談大家都關心的問題或經驗，不要說太多隻有某一兩個人才關心的具體的項目問題；即使少說一些問題，會議時間短點，也比說很多隻有少數人關心的問題，而浪費大部分人的時間要強。要更加突出會議的總結和分享成分，而不要把會議變成彙報工作。很多人喜歡在會議上說自己做了些

不要忽略客戶說過的任何一句話 - 如果是通過郵件溝通，那麼收到客戶的郵件時，要仔細分析每一句話，深入思考客戶在要求背後所表達的思想，只有瞭解了客戶的思維方式，才有可能讓他滿意。 讓客戶做他應該做的事情，盡量不要用自己的工作去困擾他 - 譬如技術調研，做Demo，閱讀控制項提供的協助文檔，去論壇尋求支援人員等事情，這些都屬於technical staff，應該由接包方來做而不是客戶。客戶既然選擇外包，就不想卷到具體的細節中去，譬如team building，project

    說來慚愧，雖然在軟體行業混跡了將近八個年頭，“軟考”這個詞對我來說，依然是一個新詞，只是在最近半年之內才聽說它。說到這，順便感謝下我在神州巨龍參加PMP培訓時的同學們，正是通過他們的介紹和談論，才激起了我對軟考的興趣。所幸要弄明白軟考是怎麼一回事，報名和準備相關的考試，總體說來還不算太複雜，所以我也趕上了今年11月份的全國電腦與軟體專業技術資格水平考試。以下打算分享下個人的學習體會和考試心得。   

大家都知道jQuery（JQ）是基於js的代碼封裝，效能肯定不如原生js好，尤其是DOM操縱部分效能差異明顯。今天要研究的就是原生js和jQuery的DOM操作函數在主流瀏覽器中的效能差異究竟是多少，是否真的差距明顯。測試平台：E5400+2G DDR2+Windows 7 SP1 32bit參與測試的瀏覽器有：FireFox: 3.6.3IE6IE8Chrome: 10.0.648Safari: 5.0.1Opera:

PV3D裡的光源似乎只有點光源，PointLight3D，而且不能直接作用於物體，必須通過接受光源的材質來傳遞。點光源的建立一條代碼就夠，引用路徑org.papervision3d.lights.PointLight3D： var lt:PointLight3D = new

首先我承認，WebService技術早就不是新鮮玩意了，下面只是對整個過程的代碼總結。前台選擇jQuery發送ajax請求，代碼如下：1 $.ajax({ type: "post", url: "Service.asmx/HelloWorld",2 contentType: "application/json;charset=utf-8",3 dataType: "json",4 success: function (msg) {5 alert(msg.d);6 } 7

首先是句題外話，PV3D雖然效能不錯，但似乎很久不更新，而且許多功能還處於殘廢狀態，Away3D是在PV3D基礎上開發的，許多基礎工作還做的好的多。所以項目對效能要求不那麼高，最終選用Away3D，而非高效能的PV3D。項目需要讓使用者通過flash建立一系列幾何體，並儲存下來。作為練習，這裡先嘗試讓使用者建立最基本的幾何體：平面。首先需要弄清楚Away3D中的座標關係，Away3D採用左手座標系，座標原點依然在舞台正中央。通過stage.addEventListener方法得到的滑鼠座標是相對

    在我們的工作和日常生活中，充斥著各種各樣的項目，軟體開發也好，工地建設也罷，都是由一個個項目的形式構成的。然而在所有這些項目中，往往是失敗的比較多，成功者寥寥，這是為什麼呢？為什麼一個項目會失敗？如何才能提高這個項目的成功機率？我認為這是很有意義的問題，所以想跟大家交流下。    既然談到一個項目的失敗和成功，那我們必須對何謂“項目失敗”，何謂“項目成功”有個界定，免得在這點上爭論不休，這就失去了進一步探討的意義。另外我還想把這個討論的範圍縮小到軟體項目這塊，雖然很多問題都具有普適意義，

申明：本文沒多少技術含量，高手請繞道1.6發布那天有事在身，沒有及時Down下來讀代碼。今天用檔案差分比較子看了看1.6和1.5.2的差別。整體上看，1.6修改了約8%的代碼，主要有以下這些：1.（559行）修正了JSON解析BUG，改變了JSON解析方式。1.5.2是調用Window.execScript執行指令碼，1.6裡改成了類似JSONP的方式，把代碼直接當指令碼插入文檔了。2.（1188行）重寫了瀏覽器安全色性檢測代碼。舊版裡通過動態建立一批元素，再反向檢測他們的值來判斷瀏覽器特性。這

由於調試flash總是用trace多少有點不方便，於是打算自己做一個類似的資訊輸出框，這個輸出框應該有如下功能：1.建立簡單，添加文本簡單，不需要刪除操作，但能清空文本。可以限制最大行數，且能動態刪除最頂端的多餘行。2.能相應滑鼠滾輪事件3.帶有捲軸，捲軸與常值內容聯動 帶著這些目的，折騰了半天，寫了個TextArea類，還是吃了AS3不熟悉的虧，很多細節問題要反覆查Adobe的文檔，不過總算做完了，下面是完整代碼：package {import

6月25號經曆了四個多小時的鏖戰，終於把PMP給考完了，從報名至今，經曆了將近三個月的學習和備考周期，特在此做一總結，希望對後來者能有所協助。首先談談個人收穫，考PMP對自己有什麼用？說實話，這個問題在報名時我壓根沒有想清楚，只是因為自己一直在做專案管理，面對的客戶也大多都在歐美，所以覺得可能這個考試會對自己的工作有所協助，就去報名了。經過這幾個月下來，有了很多感觸，現在認為考PMP大概有以下幾個用途：第一，在這三個月中，如果你真想Pass，那麼必須投入大量時間和精力去學習PMBOK的專案管理體

上次做了jQuery1.5.1 DOM相關的函數效能測試，有童鞋指出我的計算方法不太合理，這裡換了計時方式。承接上一篇日誌，這次要做的是jQuery1.6與1.5.2的屬性值相關效能測試，1.6版本重寫了絕大部分屬性值函數，效果如何，慢慢道來。首先是這次的計時函數。如下所示:$(function(){var t1=new Date();var t2=new Date();var sum=0;var $input=$("#test");while(t2-t1<500){for(var i=0

越早解決品質問題，代價越低人們的經驗和一些研究機構提供的資料都告訴我們：越在軟體開發週期的後期修改Bug，付出的代價將會越高。這個不難理解：後期隨著系統規模和複雜性的增加，發現問題和定位問題的難度明顯提高；根據學習曲線理論，隔得時間越久，人們對事物所存留的印象越少；在後期回過頭來重新思考問題，會比開發剛完成時付出更多的時間；在軟體生命週期收尾階段的每次修改，都會需要大量的重新測試來保證其不會導致新的問題；所以品質管理工作不應該是在最後時刻才進行的，在後期才進行品質工作是成本最高的做法；故而第一條

    我們公司是做離岸軟體外包的，雖然大部分項目是以ODC的方式在跟客戶合作，但固定報價項目也做了不少。我們明顯感覺到在固定報價項目中，很難達到一個良好的客戶滿意度。很多時候我們的開發人員付出了不少額外的勞動，卻無法獲得客戶的滿意。這一問題無疑對雙方的合作產生了不小的負面的影響，那麼有沒有什麼辦法可以應對呢？今天跟一位朋友溝通了此問題，有點心得跟大家分享下。     首先，我們認為整個團隊要建立正確的認識客戶的期望是可以調整的，並非一成不變的；讓客戶越多瞭解實際情況，就越有助於建立合理的期望；

精益製造的第十三條原則為 "不急於作決策，以共識為基礎，充分考慮所有可能的選擇，並快速執行決策"。說的是不要因為時間緊迫或者人多難以協調，就採取武斷式地決策方法比較“快”地做出決策來。而應該在決策前盡量找到所有可能的方案，充分討論、溝通、評估、甚而實驗每種選擇，以此達成團隊的共識，在共識的基礎上再進行最終決策，以確保做出最佳的決定 - “決策”慢。另一個層面是，一旦決策制定了，整個團隊就齊心協力地快速執行和落實- “執行”快。

    根據個人的專案管理經驗和生活經驗，我覺得“明槍易躲，暗箭難防”這句話實在是太有道理了。用在專案管理方面，就是指那些相對比較大的、明顯的問題往往都容易識別，比較好預防或者解決，項目一般不太容易失敗在這些地方；而那些相對較小的，經常發生的瑣碎問題，卻通常都比較隱蔽，不太容易預防和控制，而它們最終會在無形中殺死項目。就好像一顆大樹，在雷電之中都沒有倒下，最終卻死在一群小昆蟲的口裡。        

項目獎金通常情況下都是屬於基本工資之外的一種績效獎勵，也就是說，它在員工的薪酬中，是屬於浮動的那一部分收入，而不是一種固定收入。基於這樣一種認知，跟大家討論下如何才能更合理地進行項目獎金的分配？ 首先個人認為作為擁有分配權的人，應該時刻提醒自己獎金分配的目的 -