案例情況：1、
ss提出了乙個稱為銷售獎勵程式
sbp（用來管理支付地區**佣金的軟體）的單機版軟體產品建議書，預計開發周期為1年。
26個月，儘管
ss認為沒有多大可能在
6個月內完成，但公司決策層主意已定，認為只要技術人員加倍努力應沒問題，允許擴大專案組規模。3、
ss試圖：（1
）採用c++
和物件導向的設計方法；（2
）採用一種報表自動生成工具；（3
）擁有更新、更快的硬體裝置；（4
）僱傭到頂尖的開發人員。
公司進一步要求加班加點拼命工作，將專案計畫壓縮到
6個月內。4、
ss組建了專案組，由於公司內部固定的開發成員無法完成一些特定任務，招聘了
1個合同制開發成員，該合同開發者被面試人員建議不宜僱傭，但專案經理急於用人，而且覺得他具備了相應開發技能，還是僱傭了他。
5、在專案組的第一次會議上，公司高管向專案組闡明了
abc公司對於
sbp專案的關注，如果專案取得成功，會獲得豐厚的獎賞。接著，專案經理與成員粗略討論了專案計畫，並與測試經理約定
5個月後交付功能完備並通過測試的版本。
6、專案組用不到
1個月時間完成了需求分析報告和設計工作，似乎很好地發揮了
c++的功能優勢。然後開始了瘋狂的編碼，以滿足在第
4個月時發布第乙個測試版本的要求。
7、專案進展並非一帆風順，大家都不喜歡那個合同工，抱怨他不讓任何人靠近他的**，專案經理將這些歸結於由於人們長時間工作所導致的個性衝突。
8、然而到了第
4個月中旬，
cs通知新的銷售獎勵制度已經發布，專案組發現他們必須改變輸入對話方塊、資料庫設計以及資料訪問物件和通訊物件，以適應新的結構。
※
陷入修改的混亂當中
9、轉眼間數週過去了，預計第
5個月初交付測試通過的完全版的日期到來並過去了，專案組還是沒能提交第
1個測試版，存在許多遺留問題
※
報表生成程式不如預想那樣工作；人員互相埋怨和不協作；…10
、公司高管又召開了專案組會議，要求專案組努力工作以按時交付產品，每天工作
10小時。每個人為了按期交付而加班加點，終於在在第
7個月初提交第乙個完整版本供測試。乙個半月每週
60小時的工作幾乎壓垮了他們，這期間個別開發人員被他以前的專案組經常叫去做一些技術支援工作（大約每天得為他們工作
2小時）。
※
2
天後，測試經理發布了第
1個問題報告，在程式中發現了
200多個問題，包括必須處理的一類嚴重錯誤數十個。
※
測試組每小時還在發現新的錯誤。
11、經過
1天的討論並估算修正每個錯誤所需要的時間，公司高管被迫同意專案計畫延期
4周，要求每個人被要求每天工作
12小時，每週工作
6天，高管則開始了自己為期
1個月的年假去度假了。
12、接下的
1個月時間裡，專案組每天都要在辦公室呆上
12小時，但他們會花許多時間看雜誌、**聊天，他們每處理乙個錯誤，測試人員就會發現
2個新的錯誤，一些本來估計花幾分鐘就可以解決的問題由於牽扯到專案各方，變成需花數天時間才能解決。
13、這期間，那名合同工接受了另外一家公司的合約而離職，專案經理只好又緊急僱傭了乙個程式設計師來幫助處理其所編**，但經過1周的
「鏖戰」，發現程式中存在一些深層缺陷，被迫重新設計和編寫程式。由於新人不了解團隊的工作規則，經常覆蓋其他成員的工作檔案，導致工作的重複與時間的浪費。
14、半年後，專案終於正式發布，得到了市場及使用者的認可。
※
abc
公司向專案組每位成員頒發了
250元的獎金，以感謝他們辛勤的工作。
※
幾周以後，部分人員跳槽到另外一家公司去了。
2010-12-13 組長工作日誌
1.公司決策層，以砍半開發周期的前提下通過方案，方案提出者僅僅認為是湊合的前提下，草草接下專案 顯然是公司決策層過高的為了工程進度而不考慮專案的投資與回報的雙面關係。誇張的決策無不為最後 專案開發團隊解散之事埋下伏筆。
2.ss經理試圖採取的開發方案，太趨於完美開發條件（自動報表，更新、更快的裝置、僱傭頂尖開發人員 ）作為開發經理能如此大的動作，噹噹專案風險評估不說，從投入與回報這個角度分析，這麼大的投 入 作為專案的開發經理花費開銷如此之大，必然給你帶來巨大的壓力，畢竟公司是乙個盈利為目的的 企業，高投入肯定要帶來高回報的效應。以微軟的「msf」開發模式來說，這麼完美的開發條件風險系 數恐怕專案經理的在任時期不長。
3.專案經理單單為了趕工程進度而執意亂聘人員，急功近利最後往往造成無功而返。聘用技術人員不能單 看技術層面，更重要的是乙個適應能力，開發是乙個團隊的集體的工作成果，單看個體他可能是一塊冰
個頭十足，放在一杯水裡當時看來效果滿滿，放在水裡它遲早要化的，冰和水體積存在1/10之差，最終
肯定會水滿自溢。
4.專案經理在第一次會後，僅僅是粗略的跟下屬人員專案計畫，在沒有充分徵求專案團隊人員的分析後草 率的與測試經理約定5個月後交付測試版本。專案經理再次犯了團隊開發之大忌---一意孤行。團隊還沒 開發就對團隊工作效率肯定是好事，但也不能太誇張。拔苗助長、好高顧遠 最終肯定不成成大氣候。
5.需求工作和設計開發周期縮短為乙個月，而其目的是為了趕在4個月後交付測試版本，專案經理完全不 懂的開發周期的程序安排，把重點放在編寫**，完全沒有考慮到專案前期開發編寫文件的重要性，沒 有乙個統一標準，也沒有開發完善的規格說明、概要設計、詳細設計，初初的把前輩整理出來的先進的 開發模式猶如糟粕一樣一一卡掉。這麼草率的開發，必然會讓團隊開發走很多彎路，**的增刪改動作 時時發生，程式顯得相當臃腫，後期維護費用暴增。這些都是開發軟體不願看到的。在這點專案經理做 的太草率了。
6.在團隊開發過程中，團隊成員出現矛盾，專案經理沒有做到自己的責任，認為是個性衝突，成員**不 開放在開發團隊中，在我認為是非常嚴重的問題，怎麼能乙個個性來囊括的，在這個方面專案經理可以 說是極端的不負責任。在一艘木船上，哪怕只有乙個乘客做熱鍋上的螞蟻，船伕不及時調停，這個形成 可想而知。
7.cs接到通知客服需求發生變動，程式結構發生變化，陷入修改**混亂中。僅僅是乙個版本更新問題， 為什麼會如此大的動作，在軟體開發在版本公升級方面是必須要做的一件事，因為每個程式設計師都想自己的 軟體是活的，這就是這個團隊在開發前期沒有制定統一的標準，以及日後維護工作做好書面分析，只是 為了縮短專案開發周期，根基不牢，亡羊補牢就更困難甚至是人羊全毀。
8.高管在開發發生嚴重的情況下，放開管理獨自去度假，接下來的乙個月員工群龍無首，沒有統一的管理 開始散漫，無所事事，效率平平。工程進度嚴重滯後，錯誤頻頻。
9.在工程進行極度不順的情況，人員變動，沒有讓新手了解工作規則就讓新手著手工作。導致工作的重複 與時間的浪費。
10.半年後專案發布，得到了社會的認可。然後高層的獎勵措施發生的相當有戲劇性。250元的專案獎金給 部分人員買了張車票，送走了他們。
Hive UDF開發案例
bin hive中操作 臨時函式的使用 add jar home hadoop lib train 1.0 snapshot.jar 將上傳的jar包匯入到classpath變數裡 list jars 檢視匯入的jar包 create temporary function say hello as ...
移動端開發案例
touchstart touchmove touchend 可以實現拖動元素 但是拖動元素需要當前手指的座標值 我們可以使用 targettouches 0 裡面的pagex 和 pagey 移動端拖動的原理 手指移動中，計算出手指移動的距離。然後用盒子原來的位置 手指移動的距離 手指移動的距離 手...
MIS系統開發案例
一 專案背景 本專案是為一家電視配件生產廠家做mis系統，該公司規模比較大，其產品在國內市場占有半數以上份額。本期專案是二期工程，系統的一期工程也是我公司做的，由於在使用上存在一些問題，啟動二期工程做優化和改進。二 專案特點 1 開發周期 從簽訂合同到驗收週期為1年 2 工作組成員 1個專案經理 在...