程序員如何轉研發經理

1. java程序員怎樣才能走向項目經理的位子

升級講究流程，PG-TL-PL-PM，要想年輕就當PM的話，一定要在一個公司干，先從技術抓起，至少項目上的東西都要弄清楚,盡快達到PL，實在沒機會就換工作，應聘PL職位，到了PL，需要有人帶，和你的PM搞好關系，將來他變成部長，你就是項目經理了。外包的話，外語非常關鍵。

2. 如何從一個程序員轉變為產品經理

1. 人人不一定都能做產品。
2. 看你自己的學習能力和學習范圍。
3. 除了程序，視覺、交互、性能、運營、開發、擾燃項目管理、用戶需求及分析等你是否經歷過或感興趣。
4. 你對新產品、新技術是否感薯李沒興趣？你是否從第三條數納所說的那些方面分析過一個產品。
5. 程序員沒什麼不好，做產品也沒什麼好，不要加個經理就盲目崇拜，技術實力永遠是你的核心競爭力，PM不一定比Coder更適合你。

3. 從一名程序員過度到項目經理

從一名程序員過度到項目經理

1.從程序員到PM,是一條脫變的路，事實上程序員走的路最終不應該是項目經理。首先有一點需要明白的就是，一定規模的項目中，項目經理不需要太懂技術，他可以是一知半解。項目經理的任務不是在技術方面，技術相關的應該交給SA去做。項目經理更多地是做管理，溝通等工作，你如果可以的話到書店查看一下關於項目管理的書籍，你就會明白。當然對於小項目來說，有可能是PM,SA是同一個人，而這樣的項目經理更多隻是SA加上一些管理工作。要做項目經理，你就首先告訴自己不再去碰技術細節了。程序員並不是一個培養項目經理的好環境。所以沒有什麼從Coder到什麼developer再到SA然後是PM的路，這是一條比較悲哀的路。在大公司，SA下一個目標不是PM,而consultant,然後是seniorconsultant,PM走的是另一條路，所需要的技能不是技術，技術給PM帶來的能力提升是很少的。在項目中你最後能分清楚PM與SA的關系及各自在項目中的分工與用途。

2.其實我蠻同意gzlucky（Lucky）的看法的，確實是我們公司不少項經理就是不很能跟得上現在的一些技術，因為很多人都快年近四十，兒子都上高中了，要他們再學新技術真的難度比較大，他們的工作基本上就是天天找手下的程序員，布置這個任務，詢問那個任務做的怎麼樣了。不過我的頭倒是和我一樣編程，他手下寫代碼的就我一個人，他自己也會ASP和JSP,但是可能對。NET不熟，就由我來主負責了。我覺得項目經理還是像他這樣的好，自己也能懂不少技術，可以服人。但是我的頭兒好像在溝通這一塊不是非常出色，當然也有可能是俺太內向，不太與他溝通，所以他也只是在交待任務後就不再多詢問，而不像別的項目經理天天追程序員後頭問。我想問問各位，你們看哪種項目經理才是比較好的，像我的頭兒這樣的，還是像某些喜歡追程序員後面問進展的。

3.原來在一個小公司做過半年的.DM,一年的PM,後來為了讓自己的技術更扎實一些，離開了原來公司，現在在大公司做程序員，開始後悔了，在大公司里很難接觸管理方面的東西，也很難晉升，個人認為在小公司做DM,PM,有經驗後直接找大公司的PM,這樣也是一條路。

或者考PMP之類的證書，然後直接找管理的工作。

希望過來人能給予更好的意見和建議，我也現在想往管理層發展。

技術很硬了再去做PM,這種想法是錯誤的，我就犯了這個錯，邊搞好技術（為了生計）邊學管理知識（為了將來）,慢慢向管理發展，不能等。有句話說的好，機會是屬於那些有準備的人的。利用業余時間多學些管理方面的東西，所謂人的差異在業余時間。

要走向管理層，英語一定要學好。

溝通很重要，要做好管理者，先學會做人。多跟下屬溝通，多為下屬著想，而不要去巴解討好上司。體諒下屬，把項目計劃做的盡量合理，不要讓下屬加班，給下屬發展和晉升的空間，這樣才能是下屬有干勁，才能把項目做好，你才有更高的升遷機會。

只有把自己知道的不斷的讓你得力下屬知道，只有提拔起一些得力的下屬來，你才有時間和精力去向上爬，不然你抱著不放，就沒有升遷的機會。

管理不是喝酒抽煙那麼簡單，那隻是過去的那種不思上進，耽誤自己前程。

吃盡苦中苦，方為人上人。

做PM不是混，是要把項目做好，這跟做人是一個道理，這也就是為什麼做管理要先學會做人的道理。

pm的整個工作重點是什麼？如果做為一個PM,技術不高怎麼對付組里的牛人

我們經常會因為公司里的頂尖人才、個性化太強，不能與其他人合作而感到棘手，要解決這一問題其實也是有法可尋的。

一、在肯定其價值和優勢的前提下，明確地制定改進的目標；

二、頂尖人才能夠面對中肯的，明確及一對一的批評作正面反應，所以要加強與他溝通的力度；

三、可以根據具體情況調整考核目標，加強與其他員工合作的內容；

四、把"頂尖人才"調到相對能獨立發揮其才能的崗位，減少與別人發生矛盾的機會。

4. 最適合程序員轉行的10大職業 換什麼工作好

程序員的一個轉行出路是，可以開設公眾號來教授編程的知識，確保一定數量的粉絲後，通過廣告獲得收益。程序員一般都是擅長技術工作的，可以挑戰自己，成為it公司的產品經理，可以更好地留住客戶，以後可能會施展更大的才謹禪塌能。

程序員換什麼工作好

1、程序員轉行管理層

30歲的程序員，體力也比不上年輕人。加班熬夜是帶不動了。做技術是非常消耗腦力和體力的，伴隨著30歲的到來，身體各項技能也有會隨之下降。顯然繼續和年輕比拼技術是不太現實的。

此時，最適合程序員的工作應該是轉戰管理層。一來可以做IT服務管理;二來是可以做IT項目經理;三來可以做公司戰略資訊官

2、程序員轉行研發管理

這也是我們比較常見的軟體開發者職業生涯軌跡發展道路，現在研發一線崗位實戰錘煉，獲得更多經驗之後，逐漸走向管理崗位：工程師、項目經理、研發總監、CTO…..轉向研發管理崗位的開發者，需要具有一定的領導管理能力，當然，能夠有領袖氣質自然能夠更好的做這些工作。

3、程序員轉行產品經理

開發轉崗產品經理，一般是有幾種情況，各位對號入座一下吧。

內部轉崗：有超過60%的開發崗位或者是測試，通過內部轉崗的方式進入產品崗位。

先說什麼樣的開發會被轉崗到產品崗位，畢竟開發對比產品崗，人數多的不是一星半點，憑啥他們就可以。

程序員轉行做什麼好

1、從程序員，轉行到系統分析，到項目經理。條件：必須是大公司，工資高，福利襲歲好,有完整的發展曲線;個人對軟體開發有持續的熱情。

2、轉行到大型企業，事業單位，政府做信息化方面的工作(可以說是網管)。生活有保障，不必太辛苦。條件：一定的能力，一定的人際關系。

3、考研，考博再深造，出國或留校搞教學，培養一代不如一代的本科生，閑時打著大學的名義做做項目，賺個房錢。條件:高學歷，一定的經濟基礎和家庭背景。

4、創業：這個談起來大發了。這里只說條件：很好的項目，創業精神，一定的經濟基礎。

5、轉行共享軟體：很多程序員的夢想，自己寫個軟體全世界的賣，光注冊費夠一家人生活的了。成功少數，但只要有的都發達了。如ACDsee,優化大師，超級兔子，千千靜聽(可到共享軟體區查詢)。但我告訴你，這方面基本是沒法幹了，寫個小東西掙錢玩玩可以，要靠他吃飯，餓死吧。條件：過硬的專門的軟體技術，富有祥圓創意的頭腦。

6、轉行網站：基本情況和共享軟體差不太多，只是比共享軟體更好乾點。但奇跡照樣有，可看看hao123的神話和現在很牛的80後的富翁。關鍵你有沒有這個本事和這個命了。

7、轉行行業信息化咨詢顧問：隨著各個行業信息化的普及，企業對這方面人才需求很大。真正實現信息化的企業都需要這樣一個既懂軟體，又懂行業知識的人員，他和網管還是有區別的，他的要求更高些，更像一個自由職業者，專家類型的，這樣的人放在企業里小的是個主管，大的是個副總。

條件：很深的行業內部的技術或管理經驗，較強的軟體開發或實施經驗;通常35歲以上才是成熟人才，因為經驗是要經過歷練的。其實就是個人物了。

8、轉行，徹底的轉行。干不下去，精力不夠了，腦子不靈了，錢太少。只要你夠理由，你就走。從新開始另一段新的生活，有什麼了不起的，哪裡也餓不死干軟體的。

5. 如何從一個程序員轉變為產品經理

那麼，程序開發團隊就相當於是司機。打車的可以不會開車，但是要到目的地，知道上面的東西，可以省錢，省時間。司機可以接不同的人，不同的路線，只要能走到目的地就行。」那麼司機如何變為那個打車的人呢？知乎上一群專業人士展開了精彩的討論：我是一名程序員，想轉做產品經理，一方面覺得自己這方面更有天賦，另一方面我不想做只是面對機器的工作，熱衷於做交流溝通性強的工作，對於轉行謀職產品經理難度大嗎？修改由於不清楚現在互聯網公司對產品經理的需求是怎麼樣的，感覺大多隻有大公司對產品經理職位需求比較突出，小公司需求不明顯。朱佳祺：可能每一個搞程序的人，除了對編程有一種油然而生的愛的那種，恐怕有一個階段都會覺得產品經理是一個自然而然的出路，無外乎幾點：1，做技術太累，太枯燥（因為沒有扒襪愛，編程和其他藝術或者技術一樣，沒有若干年的重復勞作和積淀是不會有大成的）2，覺得做技術比較卑微。3，做技術不容易找對象（nerdy look， 肥胖，其他各種不招人喜歡的因素，不潮。）4，虛榮心（產品經理好歹是個經歷，有名片什麼的。程序員就是民工等等）……所以想變成產品經理，多牛逼啊！可以使喚程序員，可算報仇了！有自己主導的項目了，可以和高層直接對話了。說了一堆廢話，我想說，這不光是我的想法，我身邊有好多人都是這樣從一開始就放棄了做一個技術。現在我的想法是，做一個技術其實比做產品經理幸福很多。首先，你只需要關心你自己的東西，沒有那麼多雜七雜八的東西。第二，做技術的人比較單純，更有利於思考。第三，其實產品經理的地位還不如你。你可以罷工，如果你的技術足夠nb.但是他不可以，因為他上頭有老闆，下面有你。第四，產品經理一點也不比寫程序輕松，有時候甚至比寫程序要費勁的多。因為程序這個東西是一通百通，要搞出一個靠譜的產品可不是把一套模式復制就可以了。第五： 產品經理也是跟程序員一起混，因為圈子的影響，他們也可以看起來像nerd，肥胖，穿的很邋遢……所以如果說只是覺得做程序太辛苦，想去當產品經理，那估計這個選擇挺要命的。等於是用自己的短處在去搏別人的長處。但是如果是做程序做到一定境界了，想要更一步的努力，那麼我想說這個轉變還是很巨大的，對人也很鍛煉。一般來說，最終產品經理想要完全不去寫代碼，那除非：你的公司極其的龐大，產品經理的團隊可以組一個足球隊。或者是你已經有了一個非常牛逼的團隊和一個非常好的boss。其實上面一大堆東西都可以總結為一句話：因為小時候被老師各種虐，所以長大了也想成為老師去虐老師的娃。跟這種想法是一樣一樣的。最後祝各位想當產品經理的程序員能夠讓自己手下的it民工們都死心塌地的為你服務。陳湛翀：你不是一個好的程序員，可能是你沒有發現程序之美，沒有發現編程的魅力，沒有真正愛上程序員這個工作，沒有真正成為一個程序員。一個真正的程序員不會感覺到自己面對的是冷冰冰的機器，他面對的是一個可以實現他想法的朋友。又或者是中國的這種環境導致你產生這類想法。你的興趣並不在程序員里，我覺得人就應該跟著興趣走，應該毫無顧忌地轉型去當產品經理。一個成功的產品經理確實需要有一定的技術功底，這樣去判斷一個項目一個功能是否有需要去實現，實現起來是否技術成本太大。同時，也可以避免受到下屬的忽悠，你的技術功底足以判斷出「這個功能實現起來很有難度」這類話的真偽。最後，產品經理需要技術來實現自己的想法，程序員就可以自己去實現自己的想法了。不是產品經理才有創造力的，程序員同樣有。我是認為，程序員是幸福的。flamingtop：「覺得自己這方面更有天賦」我以前也覺得自己做產品有天賦，而且我發現不少技術人員覺得自己做產品有天賦，所以或者可以反觀一下，如果真的是「天賦」的話，不會有這么多人都不約而同地這么認為；我覺得這實在不是什麼天賦，只是你從事技術工作一段時間以後，開始有一些認識了而已；很多人都能對所謂產品說出個三五六來，就像一個畫畫畫久的人，會自然而然的覺得自己對「藝術」有了「天賦」一樣，不是春野激很可靠的；」不想做脊襲只是面對機器的工作，熱衷於做交流溝通性強的工作」這可能只能說明你不喜歡當前的技術工作，並不意味著你「適合」做交流溝通性強的工作，技術工作不總是有趣的，難免有厭倦的時候，但因為這個想去做產品是不太合適的，因為做產品也有和做技術類似的問題。下面是我的看法：我感覺國內的公司基本還沒有這樣的意識，能夠真的讓一個產品經理當起實職，對一個東西提綱挈領，有真正的職權去「負責」，因為不太可能被賦予這種職權；平時看到的所謂產品經理應該叫產品「專員」更加合適，但比其他的「專員」更虛；這個職位現在已經越來越像其他行業的各種經理了，比如保險行業人人都是經理，地產行業賣房子的都是經理，產品「經理」的語義差不多就是這個。我認為如果其他職位的人轉產品，技術職位的人應該是比較合適的，因為技術人員天天工作在產品的方方面面，對產品的需求和實現知根知底，信息的不對稱問題在這里最小；另外一方面是市場人員，也很合適，也是技術人員轉產品職位的最主要缺點，對市場的認知真的不夠；很多情況下，技術人員轉產品在管理層看來更難接受一點，因為一般管理人員不太懂技術人員的工作內容，習慣於自上而下的思考方式，覺得市場人員可能是更high level的工作，所以呢，「把握」起來更好，事實當然不一定是這樣，但這是一個現實的難度。和純技術工作相比，產品工作在不同的abstract level上，需要的知識結構更寬廣，單一的職位挺難獲得這些需要的知識（和經驗），所以就像一本書上說的那樣「人人都是產品經理」，因為確實需要這樣；產品是團隊的高級目標，團隊通常會在下意識的情況下一起完成對產品本身的認知和管理；這意味著其實無論是開發人員或者市場運營人員，實際上大家天天都在一起做產品，站高一點看，你做技術，不只是寫代碼，它還會確實地決定產品最後的工作方式，體驗和面貌；來自市場和運營的工作同樣最終體現在產品的最終形態里；所以產品就像是一個同時受內外（多方）環境決定的生命體，沒有單一方面決定產品，但任何一方面都有重要影響；所以你從技術轉產品可能是從「實際」在做產品到「看起來」在做產品。我覺得再積累積累也是不錯的選擇，真的作為技術人員，把技術做好，未嘗沒有做產品的「實」。另外，說的直白一點，要有真正的職權，真正地對結果和決定負責，要有把控方向的權力，仍然和團隊一起做產品，但產品經理的決定不能夠輕易地被override，這才叫產品經理。沒有實權的產品經理，是沒有做頭的，會非常糾結的，技術人員轉到這種角色，成本非常大，所以要看看你轉到的職位是不是」實職「，還是只是「虛招」，我個人的經歷，這個詞現在很火，小心泡沫。

6. 程序員怎麼升職

對於升職不單單是用時間來衡量吧。用人單位都是以你的工作能力優秀與否而絕定是否可升職，可以說升職與否是以你的綜合工作能力來考核的。祝 事業有成

7. Java程序員可以轉行什麼職業

創業:直接當上CEO、贏取白富美、走向人生巔峰的例子頻頻出現
研發管理:這也是我們比較常見的軟體開發者職業生涯軌跡發展道路，先在研發一線崗位實戰錘煉，獲得更多經驗之後，逐漸走向管理崗位：工程師、項目經理、研發總監、技術副總、CTO……轉向研發管理崗位的開發者，需要具有一定的領導管理能力，當然，能夠有領袖氣質自然能夠更好的做好這些工作。
產品經理:國內目前最牛逼的產品經理非微信之父張小龍莫屬，如果你擁有絕佳的洞察力，能夠了解人性需求，相信自己可以創造出人人都願意的產品，你也可以像張小龍一樣，升職加薪、當上總經理、出任CEO、迎娶白富美、走上人生巔峰。
培訓講師:三人行，必有我師」，你希望成為那個「師」嗎？口若懸河、侃侃而談，你的學生仰望著你，你看著學生一步步走向成功、升職加薪、當上總經理、出任CEO、迎娶白富美、走向人生巔峰也未嘗不是人生一大樂事。
銷售:開發出身的銷售，起碼比較務實，也比較容易和客戶建立起信任。
咨詢服務:如果你一直聚焦在一定的行業或領域項目，已然成為了業務專家，那你可以順理成章的轉行做咨詢了。
運維:即使你的代碼寫的很爛，但只要你對產品熟悉，轉行做運維還是可行的。
運營推廣:當你受夠了寫代碼，也可以試試運營和推廣你做的產品，相信當你直接面對用戶時，會打開另一個視角看待產品。
市場營銷

8. 程序員怎樣培養自己成為項目開發經理

項目開發經理?老古怪的頭銜。我知到有開發組經理。項目經理。項目開發經理是不是只是負責某個項目的開發負責人?
程序員和開發經理的區別是，一個是控制項目質量，進度，分配工作的。一個是埋頭苦寫的。兩個側重點不一樣。背負的責任也不一樣。不要以為套上個經理頭銜就是成功了。
我覺得在你為成為開發經理目標努力的過程中，你先要弄清楚，自己公司里各個部門的分工，包括你所說的項目開發經理有怎麼樣的工作智能。再看看自己缺什麼技能。你就知道自己怎麼努力了。
一般來說，開發經理需要嚴密的思維，和較強的協調能力。

9. 當程序員變成軟體項目經理怎麼辦

當你預期的那一天，也許是害怕的那一天，終於來到了：從工程師的隊伍里你被提拔到了軟體項目領導或者團隊領導的位置。這也許就是你選擇的職業道路，或許你不太情願，將就嘗試一下。無論在哪種情況下，你都可能缺少工程學科、人員管理以及領導能力的相關教育。 這需要更多的領導能力和管理（它們不是一回事），而不能象Dilbert（譯註：著名IT漫畫主角）那樣簡單地和老闆對抗了。當你考慮新的目標時，請考慮下面的活動計劃列表。一次就抓住了每個亮點，這是不可能的。但是這份建議說明可以幫助你將注意力放在可以提高你和你的團隊績效的活動上。 建立優先順序 作為經理，首先要做的、最重要的事是你需要有意識地建立優先順序。當你仍陷於繁重的軟體開發活動中時，你需要一套新的職責。過多的經理新手不能抗拒技術的吸引而陷於此類活動，這將導致項目組的其他人員想要獲得經理的幫助時，卻得不到幫助。 有成效的領導知道他們首要的任務是為其他組員提供服務。這些服務包括訓練和指導、解決問題和沖突、提供資源、建立項目目標和優先順序、提供適當的技術指引。要使每個組員都能清楚的知道，你總是可以幫助他們。我發現將自己定位於為被我監督的人工作是非常有意義的，而不是相反的。在你所作的事情中，對於組員要求你幫助他們這件事，應該具有非屏蔽中斷的優先順序。 第二重要的，是使你的客戶滿意。作為一名經理，沒有直接的能力使客戶滿意，因為你已不再是作為個人提供產品和服務完成這點。相反，你必須建立一種環境，准許你的組員最大程度上滿足客戶的需求。經理提供了強有力的方法，有效地提高客戶的滿意度。 第三重要的，是為你的項目工作。因為也許還有其他許多技術上的項目，或者其他經理的請求幫助，諸如為指導委員會工作。當這些和二個高級別的發生沖突時，都要准備推辭掉。 很明顯，使其他經理滿意的事情是你最不重要的事情。在一個有秩序的組織里，如果你在三個以上的重大環節上獲得了成功，其他的經理都會很激動的。我們並不都能很幸運地工作在一個良好的環境里，但一定要對你任務單上排在最前面的工作任務努力盡到最大的責任。集中精力有效地、快樂地、盡可能地幫助你的組員，不要將精力放在使你上司滿意的上面。 分析你的技能差距 除非你已經為新位置做好了准備，否則相對於你當前的領導能力和管理技能，你會感到一些差距。出色的技術背景或許是你被選為領導角色的一個因素，但是你要想幹得出色，你需要更多的技能。針對別人的評論和項目，真實地列出你的長處和短處，然後減少差距。 軟體人員並不以令人滿意的人際關系技能出名。你會希望增強處理人際關系的經驗：解決沖突、說服以及灌輸想法。你也不得不處理包括招聘、解僱、商談計劃表，以及在你的辦公室里評論某人業績使其傷心落淚等一些事務。 我發現從一堂傾聽技能課開始我的管理職業是非常好的。當作為個體提議人，積極地將我們自己的技術議程提交小組時，我們經常對此感到非常愜意。有效的管理要求更多的合作和善於接受的人際關系方式。要花點時間學習如何（何時）巧妙地引導自己的自然判斷。傾聽技能課提供了一種交流機制，我已經發現在許多場合下都很有用。 接著，到講台的另一側，提高你的演講能力。如果你真的不適應公開場合的講話，學習戴爾．卡內基的課會有幫助的。你會發覺，通過這樣的培訓獲得的經驗，以及獲得提高的交流能力，都可以幫助你更好地適應將來的工作。 作為項目領導，為了計劃和跟蹤項目，以及當需要項目回退而採取修正措施時，你有責任調整其他人的工作。參加項目管理的培訓課，閱讀一些有關項目和風險管理的書籍和文章。參加項目管理學會，閱讀其月刊--PMNetwork。SEI的軟體能力成熟度模型對於軟體項目計劃和項目跟蹤提供了很多有用的建議。建立優先順序的能力、控制有效果的會議、清晰的交流，對於你，作為一名經理的績效將會有實質上的影響。 定義「質量」 幾乎每個人都會認真地對待質量問題而且都希望生產出高質量的產品。然而，對於軟體的質量含義，沒有一個統一的定義。傳統上的軟體質量觀點和「足夠好」的軟體觀點有著激烈的爭論。為了幫助小組走向成功，需要花一些時間和你的組員、客戶共同探討質量的含義。 這兩種陣營在思想上經常不會有相同的定義，可以很容易的就不同目的開展工作。關注交付計劃的經理對於想正常地檢查每行代碼的工程師會不耐煩的；認為可靠性非常重要的客戶對一個帶有很少使用但帶有很多bugs的特性的產品是不會滿意的；一個很好的GUI也許會讓用戶厭煩，因為用戶已經熟記了如何有效地使用前一個版本的產品。 為了更好的理解客戶對軟體質量的看法，在Kodak，我的小組曾經邀請了我們的客戶和他們的經理就這個議題在一個開放的論壇展開討論。這個論壇是很有意義的，那些使用我們產品的人有著自己的理解，通過討論，我們可以知道我們制定質量的思路有哪些和他們是不相符的。明白了不同，就可以使你集中精力，照顧客戶的最大利益，而不是使開發人員獲得最大滿意。 軟體質量的傳統描述包括要與說明書一致，滿足客戶的需求，代碼和文檔沒有缺陷。「六個∑質量」（six-sigmaquality）這個流行詞，建立了一個非常高的尺度，用於監測失敗的頻率和密度。但它不適用於如快速產品交付，可用性，充足的特性集，已支付價錢的交付意義這樣的質量尺度，。對於我們生產和購買的產品，我們總是熱衷於盡可能涵蓋所有的這些質量特性，然而，妥協總是必須的。 在一個項目的需求階段，我們制定了包括十項質量屬性的一個列表，如效率，協同性，正確性以及宜於學習，我們認為這對於用戶來說是最重要的。我們請客戶關鍵人物代表小組以1到5的尺度評估每項屬性。一旦我們決定了哪些屬性是最重要的，我們就可以設計並實現這些目標。如果你在了解了對於客戶的質量含義並在設計實現質量屬性的過程中沒有麻煩的話，而且客戶對質量屬性表示滿意，那你是很幸運的。 在眾多關注的質量說明中，我曾聽到過一個：「客戶回來了，但產品沒有」。和你的客戶、開發人員一起對每一個產品都確定適當的質量目標。一旦決定了，就給出達到質量目標的明確的最高優先順序。以身作則，按很高的質量標准要求你自己的工作。採用這個座右銘：「力求盡善盡美，滿足於優秀。」 表彰成績 對你組員成績的表彰和獎勵，是激勵他們的一種很重要的手段。除非你的小組中已經有了一種表彰程序，否則這應是你最重要的事情之一。表彰包括象徵性的東西（證書，旅遊獎勵）以及實際的東西（電影票，餐館禮品券，兌現獎）。在送贈品時要說一些親切的話語：「感謝你所給予的幫助」或者「祝賀取得了成績」。在表彰和獎勵上花費很少的心思和錢，就可以獲得很多的友好和將來的合作。包括客戶代表，以及為項目成功做出過貢獻的支持人員等等開發組外的人員也可以獲得表彰。 和你的組員討論，了解他們感興趣的表彰和獎勵的方式。使得無論大小成就的表彰活動成為小組文化的一個標准組成部分。對每位組員對其所作的工作表現出發自內心的興趣也要給與含蓄的表揚，為消除所有影響他們戰鬥力的障礙盡你的力量。表彰是展示組員以及小組外的其他人的一種方式――你要知道並感謝他們為小組成功所作的貢獻。 學習過去 你的小組在過去承擔的一些項目有可能沒有取得完全的成功。甚至在成功的項目上，我們也能經常認為一些事情我們下次會作得更好。當你進入了新的領導角色，需要花點時間了解早期的項目為什麼失敗，並要計劃避免犯同樣的錯誤。對於軟體開發，每位經理花時間處理每種可能要發生的錯誤是非常困難的，學習過去的成功和失敗就是個成功的開始。 可以從過去你們小組承擔的一個沒有經過檢查評估的項目著手，不要管其成功還是失敗，實施項目後的回顧（有時稱作事後調查分析）。你的目標不是判定責任，而是為了在將來項目中作得更好。藉此，可以了解什麼已經作得很好，什麼應該作得更好。在當前每個項目的主要里程碑時，通過集體討論或公平的組織者，用同樣的方式，領導小組用頭腦風暴的方式對其展開分析。 另外，要了解領悟已有的軟體工業的最佳准則。一個好的起點是SteveMcConnell的JoltAward獲獎作品：快速開發（RapidDevelopment，MicrosoftPress，1996）的第三部分，敘述了27個最佳准則。也要避免McConnell敘述的36個常見的軟體開發錯誤。你的組員也許反對新的工作方式，但是你的角色是作為一名領導，要確保團隊一致連續地使用最佳可用的方法、過程和工具。積極促進組員之間的信息共享，這樣局部單個最好的實踐經驗就能成為每個開發人員的工具箱的一部分。 建立改進目標 一旦你對過去的項目建立起了回顧，確立了質量對小組的意義，你就要建立短期以及長期改進的一些目標。目標要盡可能量化，所以你要劃分幾個簡單的階段，標明你是否採取了適當的過程朝著目標前進。 例如，如果你認定由於需求的不穩定導致項目經常延期，你可以建立一個改進需求穩定的目標，在6個月內提高50%。這樣一個目標需要你確切知道每周或每月需求的變化數，清楚他們的出處，採取行動控制那些變更。這可能要求你要改變與那些提交需求改變的人的交流方式。 你的目標和階段是軟體過程改進程序的組成部分，你要使之有序。作為缺乏創造力的官僚主義的最後避難所，輕視「過程」很流行。雖然事實上，每個小組都能找到改進其工作的方式。當然，如果你總是用已有的工作方式工作，你也就不要期望你會得到比以前更好的結果。 有兩個強烈的原因要求改進過程：校正問題，防止問題。確保你的改進努力要圍繞著已知的或可預知的可能威脅項目成功的問題。領導你的小組找出當前正在使用的方法的長處和短處，以及項目面臨的風險。 我的小組召開了一次「兩段式頭腦風暴」練習，來確定改進軟體生產力和質量過程的絆腳石。在第一次會議中，參會者在便條上寫出他們關於會議主題的想法，一個便條一個想法。組織者將他們寫在便條上的想法收集上來並分組。最後，我們就會得到一打主要的分類，並將其記錄到活動掛圖上。 第二次會議，相同的參會者在便箋上寫出解決這些障礙的思路，並貼在掛圖的合適位置。進一步細化，歸納出一些詳細的活動，就可以成為我們努力的一部分，清除障礙，幫助組員實現軟體的質量和生產力的目標。 建立可度量和可達到的目標，便於你集中精力實現改進。要使目標具有明顯的優先順序，並可周期性地監視過程。記住你的目的是，提高你的項目和公司完成的技術和業務上成功，不要滿足於一些過程改進書籍里提到的期望細節。要把改進的工作視為迷你項目，具有可分發、資源、計劃和有責任的小項目。否則，過程改進活動將總處於比誘人的技術工作低的優先順序上。 緩慢的開始 這篇文章提供了許多建議，幫助你，一位軟體經理新人，帶領你的小組走向偉大的成功。在日復一日新的工作壓力面前，要努力保持你的頭腦清醒。在長時間的塑造軟體開發小組的文化和習慣上，你還是個非常重要的角色。你不必一次性都作完，可以選擇跟環境最相關的的幾個開始。 作為軟體經理，除了項目要按時按照預算完成外，你要擔負的責任還很多。你還要：領導技術人員，將他們形成一個具有凝聚力的團隊；建立協同團隊工作的環境；鼓勵和獎賞高級軟體工程師的實踐應用；平衡來自客戶、公司，組員和你自己的需求。 這是項重大的任務，祝你好運。

10. 不想做程序員，程序員如何轉行

不想做程序員，程序員如何轉行？真的很難。如果從事機械設計，我們也可以在那裡做一天，但有時需要去現場看材料和機器，但不需要加班，也可以轉行做相關銷售。反正我打算做機器對外貿易。也許你不能接受從頭開始。如果不能承受開發事業的壓力，可以去企業管理公司網站。這是為了管理一家公司的網站，但通常負責公司的信息技術工作。

同時要學會及時消除工作中的各種困難和障礙。只有這樣，你才能輕裝上陣，走得更遠。很多人在編程行業感到迷茫。其實造成混亂的有內因和外因。內在原因可能是隨著年齡的增長，不能及時更新知識體系，被自己的不安所打敗。至於外部刺激，我們現在每天都收到很多信息，所以程序員到了一定的年齡，不能上夜班，學習能力下降，體力和精力跟不上，所以程序員一定會被年輕人淘汰。