程序员如何转研发经理

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. 不想做程序员，程序员如何转行

不想做程序员，程序员如何转行？真的很难。如果从事机械设计，我们也可以在那里做一天，但有时需要去现场看材料和机器，但不需要加班，也可以转行做相关销售。反正我打算做机器对外贸易。也许你不能接受从头开始。如果不能承受开发事业的压力，可以去企业管理公司网站。这是为了管理一家公司的网站，但通常负责公司的信息技术工作。

同时要学会及时消除工作中的各种困难和障碍。只有这样，你才能轻装上阵，走得更远。很多人在编程行业感到迷茫。其实造成混乱的有内因和外因。内在原因可能是随着年龄的增长，不能及时更新知识体系，被自己的不安所打败。至于外部刺激，我们现在每天都收到很多信息，所以程序员到了一定的年龄，不能上夜班，学习能力下降，体力和精力跟不上，所以程序员一定会被年轻人淘汰。