久久大香香蕉国产,久久影视这里只有精品国产,国产无线乱码一区二三区

使用SMART原則制定目標

eliza — Tue, 19 Jul 2016 05:26:03 +0000

編寫目的

公司很多人對于工作目標不清楚怎么寫，或者寫的目標都很籠統，沒有具體的激勵作用和考核價值，分享一個國際公認的理論——SMART原則。希望大家以此為原則，加強目標管理，提高報告質量。

背景知識

目標管理是使工作變被動為主動的一個很好的手段，實施目標管理不但是有利于員工更加明確高效地工作，更是為未來的績效考核制定了目標和考核標準，使考核更加科學化、規范化，更能保證考核的公開、公平與公正，沒有目標是無法考核員工的。

具體理論

SMART由 5個字母組成，代表5個維度：

S For Specific 明確性

所謂明確就是要用具體的語言清楚地說明要達成的行為標準。明確的目標幾乎是所有成功團隊的一致特點。很多團隊不成功的重要原因之一就因為目標定的模棱兩可，或沒有將目標有效的傳達給相關成員。

示例：目標——“需要增強項目質量”。這種對目標的描述就很不明確，因為增強項目質量有許多具體做法，如：減少Bug數量，增加自測時間，增加代碼檢查的次數，增加互查等等。

改進：有這么多增強項目質量的做法，我們所說的“增強項目質量”到底指哪一塊？不明確就沒有辦法評判、衡量。所以建議這樣修改:”我們將在下周增加2 Hour代碼自測，將Bug數量減少到10個以內。”

實施要求：目標設置要有項目、衡量標準、達成措施、完成期限以及資源要求，使考核人能夠很清晰的看到部門或人員計劃要做哪些那些事情，計劃完成到什么樣的程度。

M For Measurable 可衡量性

衡量性就是指目標應該是明確的，而不是模糊的。應該有一組明確的數據，作為衡量是否達成目標的依據。如果制定的目標沒有辦法衡量，就無法判斷這個目標是否實現。

示例： “為所有的老員工安排進一步的管理培訓”。”進一步”是一個既不明確也不容易衡量的概念，到底指什么？是不是只要安排了這個培訓，不管誰講，也不管效果好壞都叫“進一步”？

改進：準確地說，在什么時間完成對所有老員工關于某個主題的培訓，并且在這個課程結束后，學員的評分在85分以上，低于85分就認為效果不理想，高于85分就是所期待的結果。這樣目標變得可以衡量。

實施要求：目標的衡量標準遵循“能量化的量化，不能量化的質化”。使制定人與考核人有一個統一的、標準的、清晰的可度量的標尺，杜絕在目標設置中使用形容詞等概念模糊、無法衡量的描述。對于目標的可衡量性應該首先從數量、質量、成本、時間、上級或客戶的滿意程度五個方面來進行，如果仍不能進行衡量，其次可考慮將目標細化，細化成分目標后再從以上五個方面衡量，如果仍不能衡量，還可以將完成目標的工作進行流程化，通過流程化使目標可衡量。

A For Attainable 可實現性

我們在制定目標的時候，也要充分考慮自己的能力，制定自己能夠實現的目標。

實施要求：既要使工作內容飽滿，也要具有可達性。可以制定出跳起來”摘桃”的目標，不能制定出跳起來“摘星星”的目標。

R For Relevant 相關性

目標的相關性是指實現此目標與其他目標的關聯情況。如果實現了這個目標，但對其他的目標完全不相關，或者相關度很低，那這個目標即使被達到了，意義也不是很大。

實施要求：我們在制定工作目標的時候，要制定與項目本身相關的目標，或者是今后在項目中可能會產生有利影響的目標。

T For Time-bound 時限性

目標特性的時限性就是指目標是有時間限制的。

示例：“我將在2014年4月30日之前完成某事。”4月30日就是一個確定的時間限制。沒有時間限制的目標沒有辦法考核，或帶來考核的不公。項目經理和團隊成員之間對目標輕重緩急的認識程度不同，項目經理著急，但團隊成員不知道。項目經理應該根據工作任務的優先級，合理安排各個目標的達成時間。

實施要求：目標設置要具有時間限制，根據工作任務的權重、事情的輕重緩急，擬定出完成目標項目的時間要求，定期檢查項目的完成進度，及時掌握項目進展的變化情況，以方便對團隊成員進行及時的工作指導，以及根據工作計劃的異常情況變化及時地調整工作計劃。

總結

綜上所述，在制定工作目標時，參考SMART原則的5個維度，去制定自己的工作目標，可以幫助我們制定出一個可行的、有效的、清晰的工作目標，并對我們的工作帶來幫助。只有當一個目標是SMART的，才能在考核的時候檢驗自己的實際執行效果，從而幫助我們不斷進步。運用SMART原則來制定工作目標，可以讓目標計劃從虛的落到實處，從一拍腦門想到就寫，寫完之后自己都不記得，變成深思熟慮之后定下目標，并在執行中不斷檢查自己的達成情況。一個SMART的工作目標，在考核的時候只有兩種結果：達成和未達成。不會出現基本達成的結果。請在做總結的時候看看自己制定的工作目標是否符合SMART的5個原則。希望大家都能將SMART原則運用到自己的工作中，幫助大家進步。

諾懷博客標簽:

項目管理

目標管理

項目管理案例分析（一）

eliza — Tue, 19 Jul 2016 05:17:18 +0000

以下的這個案例非常常見，相信大部分項目經理都遇到過類似的問題。

項目背景：

某項目的主要工作已經基本完成，經核對項目的“未完成任務清單”后，終于可以提交客戶方代表老劉驗收了。在驗收過程中，老劉提出了一些小問題。項目經理張某帶領團隊很快妥善解決了這些問題。但是隨著時間的推移，客戶的問題似乎不斷。時間已經超過系統試用期，但是客戶仍然提出一些小問題，而有些問題都是客戶方曾經提出過，并實際已經解決了的問題。時間一天一天的過去，張某不知道什么時候項目才能驗收，才能結項，才能得到最后一批款項。

請分析發生這件事情可能的原因：

（1）合同中缺乏以下內容：

項目目標中關于產品功能和交付物組成的清晰描述；
項目驗收標準、驗收步驟和方法；
對客戶的明確服務承諾；

（2）項目實施過程中控制出現問題：

在項目實施過程中沒有及時傳遞項目進展狀態報告給客戶，因此客戶對項目的質量情況不了解；
沒有讓客戶及時對階段交付成果進行簽字確認；

（3）客戶對項目質量信息不足，怕承擔責任，因此不愿簽字；

（4）合作氛圍不良，客戶存在某種程度的抵觸情緒，雙方缺乏信任感。

請說明張某現在應該怎么辦？

只能采取補救措施，靠加強溝通來解決問題。

就項目驗收標準和客戶達成共識，確定哪些主要工作完成即可驗收通過；
就項目驗收步驟和方法和客戶達成共識；
就項目已經完成的程度讓客戶確認。例如出具系統試用報告，讓客戶簽字確認；
向客戶提出明確的服務承諾，是客戶沒有后顧之憂。

請說明應當吸取的經驗和教訓：

項目合同中要確定項目成果的正式驗收標準、驗收步驟、驗收方法和運營維護服務承諾等；
加強項目執行過程中的控制，及時向客戶提供項目績效報告，讓客戶了解項目進展；設置階段性成果的驗收，并讓客戶對階段性交付成果進行簽字確認；范圍的變更要按照變更控制程序操作；
項目文檔要齊全，使項目進展有據可查；
項目經理應及時與客戶溝通，努力促成雙方的良好合作氛圍。

諾懷博客標簽:

干系人滿意的項目才可能是成功的項目

eliza — Tue, 19 Jul 2016 03:24:45 +0000

相信很多做技術出身的項目經理在做國內項目時都會有這樣的困惑：為什么我竭盡全力，項目還是做不好？為什么受傷的總是我？

目標不能按預定的時間和成本完成、需求不斷增多、客戶抱怨重重、領導不滿意、團隊成員士氣低落且沖突不斷、項目被客戶的高層否決、項目遲遲無法結項！等等

You are not alone!很多項目經理都遇到類似的問題，但這是什么原因導致的呢？

是運氣不好總遇到奇葩客戶嗎？還是說國內的客戶都這么難搞？

NONONO，其實，國內的項目做不好，絕大多數情況是以下3點沒做好：

1、需求范圍和需求變更沒控制好；2、風險識別及風險應對沒做好；3、項目干系人沒有識別和管理好，溝通沒到位；

什么是干系人？

所有能影響項目或受到項目影響的人或組織。

公司內部的如：公司高層、開發團隊、測試團隊、部門經理、項目管理辦公室、銷售、設計、可能跟你爭奪資源的其他項目經理等等；

公司外部的如：客戶老板、客戶授權的項目經理、客戶的IT部門、客戶的業務部門、實際使用的用戶、第三方平臺、法律部門、外包人員等等；

為什么要管理？

有些干系人可能對項目及其期望結果有重大影響。項目經理正確識別并合理管理干系人的能力，能決定項目的成敗。

簡言之：干系人滿意的項目才可能是成功的項目。

如何管理干系人？

1、識別干系人；

做什么：通過各種辦法找到項目的潛在的干系人并制定如何管理他們的計劃；隨著項目的進展要不斷的去識別和規劃新的干系人；

如何識別：我們重點關注如何識別公司外部的干系人，可考慮采用如下方法：

合同中規定的客戶聯絡人和驗收人；
從銷售或市場人員處獲取相關人員信息；
與已確認的干系人進行訪談，獲取更多干系人的信息；
了解客戶的組織架構圖；
查看干系人郵件的抄送對象；
關鍵業務、成果的確認人；
根據項目的業務分析干系人；
等等

如何規劃：分析干系人的高層級需求、權利、影響力等信息，制定相應的管理策略、管理方法和溝通方式；

干系人管理策略，由干系人對項目的影響力以及干系人本身的權利來確定，有如下4種情況:

影響力高權利高：重點管理；
影響力高權利低：隨時告知；
影響力低權利高：令其滿意；
影響力低權利低：監督；

2、管理干系人參與；

做什么：在整個項目生命周期中，與干系人進行溝通和協作，以滿足其需要與期望，解決實際出現的問題，并促進干系人合理參與項目活動的過程。本過程的主要作用是，幫助項目經理提升來自干系人的支持，并把干系人的抵制降到最低，從而顯著提高項目成功的機會。

怎么做：根據《干系人登記冊》完成干系人的管理，并根據實際情況不斷完善；主要包括以下活動：

調動干系人適時參與項目，以獲取或確認他們對項目成功的持續承諾；
通過協商和溝通，管理干系人的期望，確保實現項目目標；
處理尚未成為問題的干系人關注點，預測干系人在未來可能提出的問題。需要盡早識別和討論這些關注點，以便評估相關的項目風險。
澄清和解決已識別出的問題。

通過管理干系人參與，確保干系人清晰地理解項目目的、目標、收益和風險，提高項目成功的概率。這不僅能使干系人成為項目的積極支持者，而且還能使干系人協助指導項目活動和項目決策。通過預計人們對項目的反應，可以事先采取行動來贏得支持或降低負面影響。主動管理干系人參與可以降低項目不能實現其目的和目標的風險。

諾懷博客標簽:

項目管理

干系人管理

PMP

把項目交給自由職業者還是軟件公司？

Caven — Fri, 16 Jan 2015 09:52:36 +0000

當您打算開展一個軟件項目的時候，會面臨很多問題和選擇，其中之一就是到底把項目交給軟件公司來做呢？還是外包給軟件開發自由職業者？最近跟幾個朋友都討論到這個問題，故寫此文，試圖對二者進行一些對比，給您一個參考。

結論：軟件公司和個人職業者，沒有絕對的高下，只是相對來說在某些方面各有優勢。因此它們都有自己所適合的場景，總體來說，要根據您所處的情境來選擇：

1）如果您對價格比較敏感，有較多時間來管理自己的項目，同時項目較簡單，技術風險不高，適合于一個人在短期內完成，可以更多地考慮自由職業者；

2）如果您尋找的是長期穩固的合作伙伴，而且很可能在將來擴充您的團隊；或者項目存在一定的技術風險，工作量較多較復雜，需要團隊配合才能完成；又或者是您本人不太擅長管理軟件開發項目，那么找軟件外包公司應該是個更好的選擇。

諾懷博客標簽:

企業信息化建設的三大誤區

Caven — Fri, 16 Jan 2015 08:42:35 +0000

最近有一個哥們很郁悶，找我訴苦：“我們現在軟件做得差不多了，但是實施起來難度很大，員工不愿意用，老板的意思是既然要做軟件，那么軟件就能要求員工必須用。軟件如何去迫使員工必須用呢？?”他夾在中間感覺非常為難，不知道該如何回復老板。這種情形，我一聽就感同身受，完全能夠理解他的處境，為什么？因為這現象在軟件行業，尤其是企業信息化的過程中，相當常見。

過程一般是這樣：

1. 公司高層上套新系統，員工卻不愿意用；

2. 于是高層推出行政命令強迫員工必須用；

3. 員工依然不配合，當被追究時，說軟件不好用；

4. 公司領導找到倒霉的開發團隊，說你的軟件必須要解決員工不愿意用的問題，這是你軟件的問題；

大家來評評理，到底是哪里有問題？

之所以會出現這樣的事情，究其原因有很多，然而主要的問題還在于大家對“企業信息化”的認識不夠到位，缺乏正確的方式方法。為了幫助大家少走些彎路，我這里總結了下企業信息化過程中常見的三大誤區：

誤區一：所有的問題都是軟件的問題；

這里我必須替勤勞實在的技術人員說句話，企業信息化的問題，還真不是僅用軟件就能解決的，這里面還有很多其它的問題，譬如企業文化的問題、變革的問題。為什么這樣說？因為軟件是為企業業務服務的，上新系統時，常常會對企業現有的業務流程、工作方式等帶來改變（通常都是企業管理層想對它們進行一些升級或優化），而這些改變常常會對一線人員帶來一些負擔（有時候僅僅是讓他做出改變就已經是負擔了）。如何讓基層員工主動來配合或適應這些變化，如何消除或降低基層對變革的抵觸，是軟件的問題么？

誤區二：基層用戶只需要拿到軟件去用即可；

這里我是替企業基層說句話，請不要忽略他們的需求，他們在工作中也會遇到很多問題，也需要有人能幫他們解決問題，而不是簡單地由外面來強加一套程序要求他用（通常這會增加他的工作內容）。很多時候，實際的工作情況并不是遠離一線的企業高層所想象的那樣，更不是另一家公司的程序員所能理解的。如果他們對一線工作不理解，同時又沒有讓一線人員參與到整個程序的開發過程中，做出來的東西適用么？

誤區三：可以靠行政手段實現信息化；

這是長期處于權力中心的人，最愿意相信的假象。在企業里，公司高層傾向于認為通過行政命令，以及規章制度的要求，可以迫使大家接受信息化帶來的改變。然而不要忘了中國的老話“上有政策，下有對策”，在聰明的中國人面前，要讓他接受自己所不認可的東西，那是非常困難的。要么是做做表面功夫應付下，要么就是暫時被動接受了，以后你沒盯這么緊了再反彈。無論是哪種情況，都讓企業無法充分利用信息化帶來的優勢，甚至是根本達不到上軟件系統的初衷。

那么問題來了，既然這樣行不通，我們應該如何做才好？出路在何方？

其實，引入軟件系統跟引入一套新的管理流程一樣，涉及到企業變革管理的問題。企業領導層最好平時就打造一種精益求精、擁抱變化的企業文化。并且在上系統前，內部充分溝通，讓大家了解到上這套系統對公司和他個人的意義，從意識上先讓員工接受這個變化并為之做好準備。同時，還要在系統開發的過程中，盡量讓員工代表多參與，使軟件能夠體現他們的需要，解決他們的問題（而不僅僅是企業領導層的），甚至是派員工代表跟軟件團隊一起工作。這樣在系統上線后，要求大家使用時，阻力應該會小些。如果依然遇到員工抵觸，不要簡單歸結為是這個員工的問題（行政處罰）或者是軟件的問題。要深入溝通了解下他為什么不愿意用，到底是什么阻礙了他？是個人的問題就提供幫助（如進行培訓），是軟件的問題就要求改正。另外，軟件系統也可以分為幾期逐步完善，小步快跑，不要試圖一步到位，這不但能降低實施的壓力，而且也符合“需求漸進明細”的規律。

希望這幾點認知，能幫助大家更加順利地實施企業信息化。?

諾懷博客標簽:

軟件開發項目管理-凡事預則立

Caven — Fri, 16 Jan 2015 08:38:42 +0000

近日，某軟件開發項目完成結項，在進行總結時，項目經理提出了不少問題。其中大多數都是些常見的癥狀，并不是這個項目所獨有的，也不是以前沒見過的。于是問題產生了，為什么這些教訓在不同的項目中?反復?發生？能不能采取些措施，來規避它們或降低這些問題的負面影響呢？經過這么一思考，我發現在軟件開發項目的實施過程中，還真有不少問題是可以提前預見到的，與其被動等待事情發生后再去應對，不如及早采取方案來控制它。正應了中國人的一句古話：“凡事預則立”。

下面對這幾條問題及其對策，簡單進行下分享：

問題1：在項目過程中，客戶對平臺操作不熟，很多問題都來找團隊指導、答疑；而這些導致工作時常中斷，占用不少時間，卻又不在最初的工作范圍中，沒有報價；
問題2：客戶經常出差，而且不通知團隊，項目組經常聯系不上客戶；問題得不到及時反饋，影響項目進展；
問題3：客戶看到系統后，在測試過程中提出很多不在最初需求內的改動；而這些改動所對應的工作量又在最初沒有報價，同時客戶追加預算又很困難；
問題4：幫助客戶部署時，遇到很多問題，比如:服務器里面沒有安裝任何軟件，服務器太差，時不時的死機；導致工作量大大超出最初預期；

如果是做軟件的同行，這些問題看著都不陌生吧？是不是每個項目都有可能遇到？如果一件事情我們能預見到它很可能發生，而且又會對項目帶來不利影響，那么我們就應該對其進行風險管理，不是么？其實解決這幾個問題的對策也都很簡單，就是提前預案下而已：

對策1：既然每個客戶在項目過程中，都需要或多或少的技術支持；那么制定項目計劃時，團隊直接跟客戶溝通所需要的支持內容；或者根據客戶背景來判斷所需支持程度的大小；并且把這部分工作內容放入計劃中；
對策2：每個項目都需要客戶的參與和配合，都是在跟客戶互動的過程中完成的。那么，團隊能否一開始就跟客戶確認好其參與方式和參與程度？或者把項目需要客戶參與的地方先明確告知？如果開始有這么一個溝通，就能發現“客戶可能會經常出差”，這樣就可以在項目安排上做出對應的調整。譬如項目早期需求溝通更深入一些，減少執行過程中對客戶的依賴；或者把工期拉長以配合客戶行程，etc.；
對策3：需求的變化是必然的，目前為止，還沒有聽說過需求不發生變化的軟件項目。而且，在客戶看到系統的那一刻，會產生幾十個上百個新的想法，都很正常。問題在于，這些變化可能導致工期延長、費用增加的事實，雙方如何應對？如果一開始大家沒說清楚，當變更發生時，各持一詞，就很容易演變成討價還價和扯皮，如果一開始雙方達成了共識，那么屆時都有準備，按照流程處理即可，皆大歡喜；這只需要在項目啟動之初，雙方溝通確認下需求變更處理流程，“預”一下；
對策4：大多數軟件項目，都需要幫助客戶部署；而每個部署，都必然涉及到部署環境和服務器配置的問題；團隊事先向客戶了解下其部署環境和服務器配置，再進行相應的工作量估計，自然可以規避；

總之，這些問題不難提前想到，對策也并不復雜，只需要項目經理們多“預一預”就可以規避不少風險。項目上諸如此類的問題有不少，身為項目經理，除了關注項目的任務，還應該多注意下跟客戶配合互動這個層面。雖然每個項目都存在其獨特性，但項目中經常遇到的一些問題也是有共性的，好的項目管理就是要能事先預見到這些容易出現的“坑”，并準備好對應的"蘿卜"，才不至于臨陣磨槍。

諾懷博客標簽:

如何確保客戶Demo的成功

Caven — Fri, 16 Jan 2015 08:26:47 +0000

前兩天有個項目，客戶要求在3月17號前要完成第一期工作，因為他在3月17號安排了一個重要的演示（Demonstrate），團隊根據客戶的要求，制定了在3月14號給客戶提交版本的計劃。3月14號當天，由于工作整合時發現有較多問題，未能成功交付，于是整個團隊在3月15號（周六）主動加了一天班，終于在3月15號完成提交。3月17號（周一）來上班時，發現客戶對交付物進行了驗收，并且提了一些需要修改的Bug，要求盡量在當天改完。當天經過團隊的努力，修改好了客戶反饋的Bug，并且再次提交。晚上，客戶發郵件說程序無法工作，未能成功演示，郵件中充斥著不滿的情緒。為什么團隊成員的努力工作，卻未能換來客戶的肯定和滿意？到底是哪里出了問題？如何才能避免這樣的場景呢？

仔細分析下這個案例，不難發現下面這幾個事實：

A - 項目交付之后，客戶總是需要一些時間來驗收，團隊也需要一些時間來修改Bug，程序才能達到穩定狀態；

B - 總是會出現些預料之外的事情，譬如整合時的問題，譬如提交后客戶無法運行的問題等，這些預料之外的事件會消耗掉不少時間和精力；

C - 上述兩個問題是可以提前預見的，因而可提前規劃對策，這樣會將其負面影響降到最低；

對此，總結出來的經驗教訓是：

團隊向客戶提交的日期（Deliver Day）比客戶的演示日期（Demo Day），至少要提前三個工作日；這段時間將用于客戶驗收測試、修改Bug、配置和部署演示環境、預演、以及應對預料外的事情；
如果中途情況發生變化，無法準時提交，需要盡早更新計劃，并且及時跟客戶協商對策；譬如Cut掉一兩個功能、加班趕工、或是延后演示日期等；
建議客戶提前一天進行一場預演；
1. 調試好演示時要使用的環境和設備；
2. 準備好演示時要用到的數據；
3. 過一遍演示時將展示的功能；
提前獲取客戶的演示清單，包括將演示的功能列表、操作順序等；團隊內部根據演示清單測試，盡量保持與客戶操作的一致性；
提前了解演示現場的環境，包括網絡環境、設備、操作系統、瀏覽器等；

諾懷博客標簽:

軟件開發金科玉律之-不要重復發明輪子!

Caven — Thu, 17 Apr 2014 08:29:05 +0000

?? ? 以前有個小朋友，特別有好奇心，也喜歡動手搗騰。有一天，他做出來了一個圓圓的，會滾動的東西，感到特別興奮，到處去向別人展示自己的"新發明"。結果他發現別人一點都不稀奇，原來這個東西叫做“輪子”，早在幾千年前就有了，現在已經發展出了上百種的不同規格、材質、樣式，自己的這個相比之下太不完善了，根本不能算是什么發明。這個小朋友，現在就藏在我們的心里，尤其是經驗不夠豐富的程序員身上。

??? 幾年前我曾經做過一個項目，經過長時間的掙扎之后，項目依然失敗了。主要的原因之一，就是我們重復發明了太多的輪子。事情是這樣的，時任項目核心開發人員的同事很有鉆研精神，也相當自信，當時客戶提出的一些基本功能，譬如用戶管理、輸入驗證、內容管理等，雖然市面上隨處可見現成的模塊和控件，可他總是覺得那些做得不夠好，說不如自己重新做一個方便，而且重新做更能符合客戶的特殊需求。我當時作為PM，雖然對此略有質疑，但看他自信滿滿很有激情，而項目時間也很寬松，就同意了。后來僅僅輸入驗證這個功能就推翻重來了三次，最終還是選用了一個現成的控件直接用，因為他做出來的太不具備通用性，十分難以維護；同時，用戶管理模塊也做得千瘡百孔，極不穩定，出現了很多Bug和考慮不周全的地方，最后也不得不去找現有的成熟的組件替換。結果，這些“重復發明輪子”的開發工作，不但耗費了大量的時間、金錢和精力，而且也沒能發揮預期的效用。事實證明，現成的控件“輪子”（開源的或收費的），經歷過時間的檢測和眾人的改進，總比自己重新搗騰出來的要更成熟、更穩定，同時也更加省事、好用。我們在這個項目中花費了這么多時間、金錢、心血，終于證明了“不要重復發明輪子”這句話是很有道理的，這個慘痛的教訓讓我迄今記憶猶新。

??? 雖然此事已經時過境遷，但近些年來我發現有很多人都在“重復發明輪子”，尤其是在我們軟件開發這個圈子里面，年輕的小伙伴們充滿了發明輪子的欲望和激情，就好像那個可愛的小朋友一樣。因為他們覺得這樣做會讓自己學到很多東西，如果做出來了也會很有成就感。確實，成長和成就的確是他們所需要的東西。可如果你是客戶，你會愿意為此承擔更高的費用和風險么？如果你是項目經理呢，在成員練手跟項目成功交付之間，哪個更重要？

??? 我覺得如果出于練兵的目的，重新搗騰一個輪子出來當然是個好方法，就好像比賽開始前反復練習投籃一樣正常。可如果你已經上戰場了，已經開始比賽了，已經去幫客戶做項目了，這時候才來練習是非常不合適的。因為你很可能會因此而輸掉比賽、丟掉客戶，而且因為你極其不專業的表現，會影響你的職業生涯。所以在公司里面，應該明確區分什么時候是練兵，什么時候是上陣，一定要杜絕上陣后才練兵的不專業表現。換句話說，工作中不要重復發明輪子，要練習投籃下場后自己慢慢練去，不要輕易浪費在賽場上的出手機會，just beprofessional.

諾懷博客標簽:

2014諾懷公司河邊燒烤

lizongjun — Wed, 02 Apr 2014 02:00:23 +0000

最是一年春好處，絕勝煙柳滿渝都。即是這一年中最美的時節，諾懷迎來了期盼已久的河邊燒烤，既豐富員工的業余生活，提升加深員工內部之間的了解，舒緩公司人員的工作壓力，使這一良辰美景也不被辜負。

于3月22日，一個涼爽的早晨。三兩個一行，四五個結伴，背上了準備好的帳篷，拿起早已購置好的食材，紛紛聚集到了江北大劇院前的河邊，這意味著河邊燒烤！已經開始了！河邊燒烤是公司向來的保留節目，參與人數眾多，反響良好，效果明顯。這一次燒烤是由公司副總經理冉軍帶隊，公司開發部經理劉宇翔組織，參與員工有數十人。

江風拂面，坐著松軟的草地，聞著泥土的味道，那么你試過在這樣的江邊打麻將么？別樣的經歷使得我們又多了些情趣，也多了許多回憶。

你幫著搭棚，我幫著生火，他忙著鼓風，還有的忙著理菜，倒水。燒烤井然有序的進行著，這不能不說明大家都是燒烤的好手。

搭棚，支架，生火，燒烤，好不歡樂。在這喧鬧的城市里，我們借此機會更加親近了自然，更加貼近了生活，我們忘卻了工作中的焦慮，我們互相了解的彼此，我們互相增進了情誼，我們也更加懂得了什么叫作享受。

江風拂面，坐著松軟的草地，聞著泥土的味道，那么你試過在這樣的江邊打麻將么？別樣的經歷使得我們又多了些情趣，也多了許多回憶。

時光飛逝，轉眼就燒烤日就要結束，望著眼前的江水，昨日的憂愁早已不在，憧憬的是未來，如同這一波又一波的浪濤起伏在心中。燒烤日雖然過去了，留下的是大家的歡聲笑語，是春日的那一份愜意。鋪墊的是告別13年的成就，諾懷員工在這個辭舊迎新的季節中繼續向前。

誠信：八千美金的一堂課

Caven — Fri, 21 Mar 2014 05:38:50 +0000

?? 最近丟了個價值8000美金的項目，剛開始不到一周就被客戶叫停，以前從未發生這樣的事情，被上了非常昂貴的一堂課。為了讓這堂成本8000美金的課程價值最大化，我覺得有必要把從中得到的經驗教訓分享出來，希望能警醒更多的項目經理，幫助更多的人少走彎路。

?? 事情是這樣的：上周五有一個項目啟動了，這是個老客戶轉交過來的新項目，要得比較急，因而客戶也特別關注項目的進度。通過最初的溝通，我們應允客戶每天給他發日報反饋項目進展，但由于人員受其它項目影響，未能及時到位，直到本周三項目都未能投入多少時間，因而項目經理也一直未發日報。到了周四，客戶要求Skype溝通，并且在溝通中又特別強調了需要日報反饋項目進度的問題，同時團隊也答應周四晚上向客戶提交2個功能點。而到了周四的晚上，客戶卻發郵件來強烈表示不滿，要中斷項目，原因是團隊當天并沒有按照約定發報告給他反饋項目進展，承諾的2個功能也未能如期交付。更要命的是，與此同時團隊沒有給客戶任何說明和解釋。客戶說，他對這個項目的進展非常非常擔心，對整個團隊能否按時交付項目完全沒有任何信心。而團隊這邊卻認為雖然前期投入較少，但通過后面的努力，項目總體上是能夠按時完成的，只是當天因為一些緊急問題影響了功能的提交和報告的發送，本打算第二天補上的，還未來得及補上，客戶就發飆了，似乎有點太小題大做了。這個案例里面存在哪些問題？大家可以慢慢分析，我想就把其中的誠信問題拿出來說下。

??? 所謂誠信，簡單點理解就是說到做到，答應的事情要兌現。往小里說這是獲得客戶信任的基礎，往大了說這是做人的根本。譬如一個人你跟他合作，他答應了你的事情總是跳票，不兌現，你還會選擇繼續跟他合作么？換位思考下，這個事情就是這么個簡單的道理。你答應了客戶一些事情，雖然事情較小，但你若不兌現，就會很快失去客戶有限的耐心和信任。

??? 既然誠信如此重要，那我們要如何才能做到誠信？從這個事情中，我想能吸取如下教訓：

??? 慎重承諾：一個事情如果做不到，就不要答應，寧肯拒絕；答應了卻做不到，兌不了現，這比你不答應或少承諾一些，傷害力要大得多；
??? 如果答應了，就要想盡辦法去兌現，盡自己最大的努力；
??? 如果盡了最大的努力，依然是無法做到，此時至少應該及時反饋，第一時間告訴對方；并主動向對方表達你的歉意，解釋你無法做到的原因；這樣能來得及再想其它辦法，也更能獲得諒解；

??? 總之，千萬不要像我們前面例子中這個團隊那樣，答應了做不到的事情，并且沒做到時也沒有主動反饋和解釋，這樣是很糟糕的處理。中國古人講修齊治平，說明做項目跟做人，道理都是相通的。一個公司因為一次不誠信行為，會損失一個項目或一個客戶，如果這樣的行為在公司里面擴散開來呢？或者長期積累起來呢？一個人因為一次不誠信行為，會損失一個機會或一個朋友，如果這樣的行為在他周圍擴散開來呢？或者在他身上持續累積起來呢？所以誠信無小事，要從自我做起，要從點滴做起。

諾懷博客標簽: