Oracle神諭

Geoserver 下載后運(yùn)行有比較弱智的問題：
在運(yùn)行startup.bat后，系統(tǒng)沒有正常運(yùn)行起來。原因是因?yàn)閖ava_home的放在Program Files下，郁悶了小半天，移動(dòng)了一下位置，終于運(yùn)行起來了。

（1）產(chǎn)品的核心競爭力。一定要有比別的公司具有競爭力的特性和功能。為什么比別的公司優(yōu)秀？產(chǎn)品的管理提升（成本、收入）細(xì)節(jié)點(diǎn)的提升？圍繞公司戰(zhàn)略層面提升核心的競爭力；
（2）品牌。公司的知名度，公司的市場推廣力度，行業(yè)中的口碑；
（3）客戶關(guān)系管理。對客戶需求的理解和把握，對客戶相關(guān)執(zhí)行的利益體的分析與規(guī)劃。

面對未來充滿憧憬與向往，但是一定要面對現(xiàn)實(shí)，腳踏實(shí)地，將理想轉(zhuǎn)化為理性的可以操作的實(shí)際行動(dòng)。
從理想主義到實(shí)用主義的轉(zhuǎn)變。

日常工作的安排對一個(gè)公司來說，是至關(guān)重要的。每個(gè)人要明確知道下一步的工作計(jì)劃，現(xiàn)在要做什么？這是很有必要的。

有人喝酒絕對不含糊，每人喝上一杯，然后就安排相應(yīng)的人或者自己就回去了，知道自己酒量但是不得不喝的；
有人喝酒就不考慮酒量，喝了再說；面對自己的戰(zhàn)友和面對別人的勸酒，結(jié)果往往喝的酩酊大醉；
有人是先低頭吃，吃了又吃，喝酒啊，慢慢來啊，酒量啊，大得很；
喝酒的幾個(gè)原則：
（1）最好不喝酒，如果一定要喝酒，知道自己的量，適合而止；
（2）如果是很多人一起喝，不得不喝的，避免勸酒，喝更大的份量，這是要避諱的；
（3）埋頭先吃，這是對的，最好不要主動(dòng)敬酒。

    變革是痛苦的，但同時(shí)也是必要的。企業(yè)要想獲得相應(yīng)的持續(xù)發(fā)展，必須要拿出相應(yīng)的措施和手段來促進(jìn)相應(yīng)的發(fā)展。
    作為個(gè)人也是一樣的，要隨著企業(yè)環(huán)境和外在環(huán)境的變化，不斷調(diào)整自己的角色，適應(yīng)相應(yīng)的發(fā)展。
    從一個(gè)資深的軟件工程師轉(zhuǎn)變成項(xiàng)目經(jīng)理，從一個(gè)項(xiàng)目經(jīng)理到項(xiàng)目管理辦公室，從項(xiàng)目辦公室到相應(yīng)的市場營銷管理，從市場營銷管理到公司整個(gè)研發(fā)、市場、測試實(shí)施、銷售、財(cái)務(wù)、行政、人事等等方面的全面管理，需要不斷的提升自己，自我充電，方能實(shí)現(xiàn)一步步的調(diào)整。
     整個(gè)過程是痛苦的，也是艱辛的。
     今天看了對話視頻中糧集團(tuán)的董事長說，最終活下來，或者說生存下來的，不是最強(qiáng)大的，也不是最聰明的，而是最適應(yīng)外界環(huán)境的。物競天擇，適者生存。

時(shí)間飛一般的流逝，匆匆地趕不上它的腳步。
08年，是在技術(shù)和商務(wù)上游離的一年；是有很多失敗與教訓(xùn)的一年；
08年，是忙碌的一年；是能拼搏敢吃苦的隊(duì)伍鑄造的一年；是有將領(lǐng)暫露頭角的一年；
09年，即將是收獲的一年；也是繼續(xù)耕耘的一年；也是將帥團(tuán)隊(duì)共建的一年。祝愿我們理性、收獲、成長。

    不知不覺公司又剩下最后一天的時(shí)間，可是事情卻依然很多沒有處理掉。溝通很重要，很多事情寧愿多打幾個(gè)電話，短信不可靠。時(shí)間是不等人的，時(shí)間一點(diǎn)點(diǎn)過去，不依賴于人的意志，可是人這個(gè)主觀的動(dòng)物總也不能擺脫懶惰、散漫的本性。
    辦事情的人總也很少，而人總是有這樣那樣的缺陷，如何進(jìn)行有效利用更好？用還是不用？都會成為難題。

（1）事情越來越多，在項(xiàng)目中的有N多To Do List的，如何靜心？
//不要情緒化，理性，做事情能平和的處理每一件事情。
（2）如何以最快的速度進(jìn)入進(jìn)入狀態(tài)非常關(guān)鍵？
//拿到的事情能快速進(jìn)入到思維中。
（3）因?yàn)樘幚硪患虑楹螅焖龠M(jìn)入到相應(yīng)的其他事情的處理；How?
//退出機(jī)制，一旦退出后，就不再進(jìn)入。
（4）另外很多事情做到一半打斷，如何做？
//除非很重要很緊急的事情，否則一律擋掉，一心不能兩用。

最后，不要隨心所欲的處理事情，要有計(jì)劃性，否則如野馬在荒原中馳騁永遠(yuǎn)找不到相應(yīng)的目標(biāo)。

需求變更控制
　
　　前面已經(jīng)說過了，在軟件開發(fā)項(xiàng)目開始之前，就要消除“絕不允許發(fā)生需求變更”的思想。在項(xiàng)目進(jìn)行，一旦發(fā)生需求變更，更不要不一味的抱怨，也不要去一味地迎合客戶的“新需求”，而是要管理和控制需求變更。
　
　　1、 分級管理客戶需求
　
　　軟件開發(fā)項(xiàng)目中，“客戶永遠(yuǎn)是對的”和“客戶是上帝”并不完全的正確，因?yàn)樵谝呀?jīng)簽定的項(xiàng)目合同中，任何新需求的變更和增加除了影響項(xiàng)目的正常進(jìn)行以外，還影響到了客戶的投入收益，所以有的時(shí)候項(xiàng)目經(jīng)理反倒應(yīng)該為客戶著想。
　
　　對于項(xiàng)目中的需求，可以實(shí)行分級管理，以達(dá)到對需求變更的控制和管理。
　
　　一級需求（或變更）是關(guān)鍵性的需求，這種需求如果不滿足，意味著整個(gè)項(xiàng)目不能正常交付使用，前期工作也會被全部否定。這個(gè)級別的需求是必須滿足的，否則就意味著否定自已的項(xiàng)目成員和成員的所有努力，所以定為“Urgent”。 這通常是屬于補(bǔ)救性的debug類型，要救火。
　
　　二級需求（或變更）是后續(xù)關(guān)鍵性需求，它不影響前面工作內(nèi)容的交付，但不加以滿足，新的項(xiàng)目內(nèi)容無法提交或繼續(xù)，所以是“Necessary”。一般新模塊關(guān)鍵性的基礎(chǔ)組件，屬于這個(gè)級別。
　
　　三級需求是后續(xù)重要的需求，如果不被滿足會令整體項(xiàng)目工作的價(jià)值下降，為了體現(xiàn)項(xiàng)目價(jià)值，也是開發(fā)人員自已的技術(shù)價(jià)值的證明，所以定為“Needed”。一般性的重大的有價(jià)值的全新模塊開發(fā)，屬于這個(gè)級別。  項(xiàng)目管理者聯(lián)盟，項(xiàng)目管理問題。
　
　　以上三個(gè)等級是應(yīng)該實(shí)施的，但時(shí)間性上可以作優(yōu)先級的排列。

　　四級需求是改良性需求，沒有滿足這類需求并不影響已有功能的使用，但如果實(shí)現(xiàn)了則會更好，定級為“Better”。界面和使用方式的需求，一般在這個(gè)檔次。
　
　　五級需求是可選性需求，更多的是偶是一種設(shè)想，以及一種可能，通常只是客戶的的一種個(gè)人喜好而已，定級為“Maybe”。
　
　　對于四級需求，如果時(shí)間和資源條件都允許的話，不妨做下去。對于五級需求，正如對它的描述一樣，做與不做是“Maybe”。
　
　　2、全生命周期的需求變更管理
　
　　各種規(guī)模和類型的軟件項(xiàng)目的生命周期大致可以分為三個(gè)階段，即項(xiàng)目啟動(dòng)、項(xiàng)目實(shí)施、項(xiàng)目收尾。不要以為需求變更的管理和控制只是發(fā)生在項(xiàng)目實(shí)施階段，而是要貫穿在整個(gè)項(xiàng)目生命周期的全過程中。
　
　　站在全局角度的需求變更管理，需要采用綜合變更控制的方法。
　
　　（1） 項(xiàng)目啟動(dòng)階段的變更預(yù)防
　
　　正如前面強(qiáng)調(diào)的，對于任何軟件項(xiàng)目，需求變更都無可避免，也無從逃避，無論是項(xiàng)目經(jīng)理還是開發(fā)人員只能積極應(yīng)對，而這個(gè)應(yīng)對應(yīng)該是從項(xiàng)目啟動(dòng)的需求分析階段就開始了。
　
　　對一個(gè)需求分析做得很好的項(xiàng)目來說，基準(zhǔn)文件定義的范圍越詳細(xì)清晰，用戶跟項(xiàng)目經(jīng)理提出需求變更的幾率就越小。如果需求沒做好，基準(zhǔn)文件里的范圍含糊不清，被客戶發(fā)現(xiàn)還有很大的“新需求空間”，這時(shí)候項(xiàng)目組往往要付出許多無謂的犧牲。
　
　　如果需求分析做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費(fèi)。這個(gè)時(shí)候，項(xiàng)目經(jīng)理一定要據(jù)理力爭，此時(shí)這并非要刻意賺取客戶的錢財(cái)，而是不能讓客戶養(yǎng)成經(jīng)常變更的習(xí)慣，否則后患無窮。 
　
　　（2） 項(xiàng)目實(shí)施階段的需求變更
　
　　成功的軟件項(xiàng)目和失敗項(xiàng)目的區(qū)別就在于項(xiàng)目的整個(gè)過程是否是可控的。
　
　　項(xiàng)目經(jīng)理應(yīng)該樹立一個(gè)理念，即“需求變更是必然的、可控的，并且是有益的”。項(xiàng)目實(shí)施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風(fēng)險(xiǎn)和修改基準(zhǔn)文件。
　
　　控制需求漸變需要注意以下幾點(diǎn)：
　
　　需求一定要與投入有聯(lián)系，如果需求變更的成本由開發(fā)方來承擔(dān)，則項(xiàng)目需求的變更就成為必然了。所以，在項(xiàng)目的開始，無論是開發(fā)方還是出資方都要明確這一條：需求變，軟件開發(fā)的投人也要變。
　
　　需求的變更要經(jīng)過出資者的認(rèn)可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。
　
　　小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多。

　在實(shí)踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認(rèn)為降低了開發(fā)效率，浪費(fèi)了時(shí)間。但正是由于這種觀念才使需求逐漸變?yōu)椴豢煽兀罱K導(dǎo)致項(xiàng)目的失敗。
　
　　精確的需求與范圍定義并不會阻止需求的變更。
　
　　并非對需求定義得越細(xì)，就越能避免需求的漸變，這是兩個(gè)層面的問題。太細(xì)的需求定義對需求漸變沒有任何效果。因?yàn)樾枨蟮淖兓怯篮愕模⒎切枨髮懠?xì)了，它就不會變化了。
　
　　注意溝通的技巧。
　
　　項(xiàng)目開發(fā)過程中的實(shí)際情況是用戶、開發(fā)者都認(rèn)識到了上面的幾點(diǎn)間題，但是由于需求的變更可能來自客戶方，也可能來自開發(fā)方，因此，作為需求管理者，項(xiàng)目經(jīng)理需要采用各種溝通技巧來使項(xiàng)目的各方各得其所。