我毕业后的第一份工作是进入一家IT公司担任程序员，这份工作距今已经20年了。现在我在一家企业担任高管，工作中IT可能只是我某个项目中的部分。回顾从IT行业起步的我，从程序员-系统分析师-咨询管理-项目经理-项目总监，一步步走上来，再到转型到运营和公司管理，而身边的朋友有的继续着IT技术的研究，有的转型成了产品经理。
最近和一家IT公司的老总聊天，他告诉我前一段时间公司做了一次员工调研，问员工对于自身发展有什么想法，调研结果让他觉得不太理想，因为许多员工非常迷茫，总结下来大概就是下面几个问题。
- 现在年轻做程序员，但是年纪大了之后还能继续做技术吗？
- 其实并不喜欢IT，只是毕业为了找一份工资还可以的工作，IT工资还可以，门槛也不高，试试看
- 不知道将来怎么发展，感觉自己都可以尝试，但并不明确哪个适合自己
- 做乙方老是受气，想去做甲方
我觉得有这些问题也挺正常的，毕竟现在的 会比较浮躁，对于IT行业来说也是一样，于是我义务帮他的员工做了一次座谈会，结果反响还挺不错。那么在这里也记录下我的看法，大家也可以看看，如果对大家有帮助我也会非常快乐。
程序员行业是目前所有行业中最单纯的行业没有之一，因为基本上程序员的思维逻辑都在“如何实现”“如何调优”上，没有人有空闲去考虑怎么“解决掉一个人”“怎么扩大自己的势力范围”“怎么去阿谀奉承”，而体现自己地位的无非是“技术大牛”“发现一个重大BUG”“解决了一个性能问题”。
程序员是目前所有行业中门槛较低，但前期发展很快的一个行业，无论你是怎样的一个新人，只要你敢于去学习，在你的技术领域扩充一年，你的月薪酬至少在5位数以上。
程序员也是前期冲得快，后期趋于平坦收入的一个行业，一个新人如果纯从技术角度去走，可能最快在2-3年达到一定的月薪酬顶峰大概2-3个5位数，但是如果你要继续提升你的薪酬或者想要赚到第一桶金，那就得有一个清晰的发展道路。（这里我们撇开独角兽或者BAT的行业领域，毕竟不是所有人都有机会进去）
程序员行业相对比较闭塞，对于一个事物的看法很容易停留在“它是怎么实现的”，而不是“它在什么场景下能帮助人们解决什么问题”。
程序员遵从垂直的协作，而在平行环节上喜好单打独斗，经常陷入自己一个人就能拯救世界的梦想中（这也解释了为什么程序员的行业比较单纯，因为平行之间没有太多交集）。
程序员需要不断学习，由于技术的发展很快，框架、体系、模式的快速增长与演变，程序员也必须随波逐流，来持续扩充自己。
综上所述，程序员，简单来说就是前期薪酬涨幅很快后期需要看个人造化，且只需要个人努力，不用太多人际能力的二次元英雄型职业。
为了方便阅读，我写的比较口语化，如果不是新人可以略过这一步
基础技能指的是：
语言
框架
数据库
服务器
程序员的基础技能获得是一种自然过程。有两种途径获得这种自然过程，其一是学习，其二是入职后培训和自我研究。
所谓学习就是，你可能是计算机系毕业的，或者你自己已经学过。
但无论你是否学过，课本上的知识可能也只是学院派的教学，真正的实战必然会在入职后。
所以重中之重是某个语言，因为对于新人的面试与沟通，一般企业只需要你有IT的知识，比如你会装电脑，你会装软件，最为重要的是你了解一种高级语言。
（所谓高级语言就是比低级语言高级，其实是废话，那么低级语言就是机器语言、汇编语言这种，高级语言高级的地方在于有编译器会帮你把你编写好的源代码变成程序，机器语言让机器来执行，而且高级语言比较易学，有让人看得懂的语法，更重要的是它让你不用太过关心所谓的内存、缓存、屏幕显示等底层机器逻辑，只要关心你想实现的部分。常见的高级语言，比如JAVA、CC++、C#、Object-C等等）
其他的框架、数据库、服务器知识，其实完全可以不用懂，这个是入职后可以慢慢学的，因此最重要的是掌握一门语言。
当你入职后根据公司需要，公司会对你进行培训。刚入职的新人在懂得一门语言后，必然会有老程序员来带你，而且公司也会让你从最简单的一个“重复劳动”型的做起。
这个时候你可能碰到的问题是“我怎么啥懂看不懂”，然后是“我要问啥问题”。
嗯，这也是非常正常的，所以我需要帮你拎一下初级程序员的思维逻辑。
一般初级程序员要面临的第一件工作，应该是搭环境。
所谓环境就是用某些工具虚拟出来了一套用来编写高级语言，且可以被发布成程序，能被运行。
搭环境的工作如果是新人的话，一般会由老程序员来帮你搭建，做的好些的话代码管理、生产环境发布等等管理工作也会被涉及，当然新人暂时不用管这些，这些都不复杂已经有人做了，所以也会有人告诉你怎么完成。
接下来就开始开发工作了，下面这个东西是新人要装在脑子里的
页面展示-业务逻辑-存储数据
基本上新人的第一项工作无非是一个简单的上述三步的集合，或者其中的某一个步骤的开发。所以必须要理解的是绝大多数开发都是在这三个东西上打交道。
而这三个东西联系起来就完成了程序开发，由于语言的专职性，一般这三个东西可能是三种语言，而且是靠接口来完成互相之间的数据通信的，比如：页面要靠接口把页面上的数据传给业务逻辑，而业务逻辑在完成逻辑后可能还要靠接口和存储数据打交道，再或者从存储数据的地方拿到数据返回给页面展示出来。存储数据的地方就是数据库这种东西了。
这些都是接口来进行。
于是你可以去问老程序员问题了：哪个地方是页面展示的代码，哪个地方是业务逻辑的代码，数据库是啥怎么连接的，他们之间传输数据的方式是啥。
这些简单的问题被解决后，就要真正开始开发了。
真正开发的新人绝对法则：
对，无脑做这件事情，复制粘贴。
哦，对了，还忘了你需要学会SQL，这是数据库语言，很有可能用得上，当然你不要学太复杂的，只要学会Select、Insert、Delete、Update这三种语法就够了，这个学会大概也就半天一天吧，反正能写就行，如果用到了写错了就会 错，改正就是了，所以对新人来说绝对有容忍度的就是编译器或者数据库只要你错了它就会 错。
再解释一下框架和服务器这两个东西。
所谓框架就是先人总结出来的一种体系化的且已经被实现了的，它需要你遵循它的法则来配置或者写代码，然后它就会帮你省略许多复杂的要写的代码或者要关心的奇怪的技术问题。
那服务器其实就是一台台电脑，因为有页面、有业务逻辑、有存储的数据库，所以为了更方便性能调优，就会有展示层的服务器、应用服务器和数据库服务器这么些硬件设备，然后装上软件，就成了，当然你把这些装在一台电脑上也是可以的，只要电脑跑得动就行。对于新人来说全部装在自己的电脑上，你就可以回家干活了。
之后的工作，没错，你就持续的复制粘贴吧，但是手速要快，Ctrl+C Ctrl+V一定要学会，再学学Alt+Tab，用你的笔记本电脑看看什么小视频只要手速快也没人会发觉的。
这些基础技能一旦全用上了，恭喜你，你混程序员绝对没问题的了。
因为有了基础技能后，你会不断挑战难度更高些的开发任务，然后你会深刻理解什么服务器啊、什么框架啊、什么语言语法啊、什么O/R Mapping啊、什么事务啊等等等等，不会的话还有个好伙伴就是百度，去查吧。于是你逐渐成长起来了。
接下来就是你要考虑的问题了。
先得说一句，并不是说马上就要去转型，如果没有两年以上的程序员经历，所谓的直接转型几乎是靠不住脚的，安安心心先做技术是当前的事，但思考上面的问题是非常有必要的。
其实除了做技术以外，后续两项转型都需要准备的，并不是说今天想着要转了，明天就能转了，其实后两项转型也是在你工作中积累的经验后才行的。
这里为什么只说转型做管理和产品呢？因为管理包含的方面很多啊，有项目管理、运营管理等等等等，那做产品呢，因为是和需求有关的条线，所以就说这两个，总之不要管说得全不全，这两个基本已经包含了所谓转型的绝大多数，当然如果要转行，那也是各人的机遇，这里不多做赘述。
再说做管理的方面，大家先要知道所谓“管理”的定义，最新的定义就不要去管它了，国外已经定义得天花乱坠了，但是在国内，最基础的就是“管人理事”。
管理学是门高深的学问，大的方面比如系统论、科学管理、价值链管理等等，然后到了专项又会有项目管理、营销管理、人事管理等等。这些管理理念都是非常了不起的，其内在和细节也能让人受益匪浅，但在国内对绝大多数人来说，恐怕你都学不全，或者更简单的说，无法全部“学以致用”。
原因也很简单，你的公司没有条件让你去用这些管理学的全部，那很多朋友都会问有许多商人非常成功，创业路也走得很不错，他们难道都不依靠管理学的吗？
答案当然是否定的，商人们有许多是靠天赋的，也就是说他们处理事务的手法我们都能从管理学中找到相关的理论，只是他们可能已经把这些理论融合在自己的言行上，说是天赋，是因为他们可能没学过，但会用。
举个简单的例子：如果我们在S市开发了一款产品，接下来我们要进行推广，我们该怎么做。
我们做IT的朋友一定会从系统角度去考虑这个问题，既然要市场推广，那么我们先要看看产品面向哪些人，画画用户画像，然后考虑市场推广的方法地推还是互联 ，嗯，好像现在“群裂变”用得挺多，从这个入手，以此类推。
但是成功的商人们可不会这么考虑问题，他们可能只会用一个手段“去把竞争对手的营销总监给挖过来”。
是的，从管理学角度这个就叫“资源整合”，没人会告诉你“挖人”就是资源整合的一种方式。配置最佳资源来将问题解决。而不是细节上应该做什么。
说这些并不意味着大家都从这个角度去思考问题，毕竟所有事情都有其背景和环境，导致你无法完全理想化的去完成工作，否则这就叫眼高手低了。
但是，我们需要深刻理解无论处于什么层级，大的管理还是小的管理，我们的思维都是不同的，而且大家看问题的角度和处理手法也是不同的。
如果我们要向管理转型，那么先期的准备就是了解你想转型的这个管理职级的目标是什么。
每个管理层的目标是不一致的，比如，一个Team Leader，他的主要目标是保证自己整个团队每个开发人员能按时按质的完成任务，而一个技术经理，他的主要目标是保证前期技术选型，以及后续奇异bug的处理。再往上走，项目经理是为了保证整个项目按时按质的完成，同时保证项目目标的达成。项目总监是为了保证多个项目的完成以及在一定时间里的业绩达标。
其他诸如此类的管理层级的不同其目标不同。
这些你可以从一些招聘JD上看到，但是招聘JD有时候也只是抄书，所以真正理解每一个管理职级的目标也需要与整个企业对其的要求或称之为“价值观”一致。
接着我们需要了解你想转型的这个管理职级，他到底在管什么，也就是本段开头我们说的“管什么人，理什么事”。
这个我们就需要意会一个很简单的概念“层层分解”，理什么事是从整个企业战略开始的，比如一家公司，股东是为了赚钱，董事会是为了向股东负责如何投资如何赚钱，而管理层则是在参与投资和赚钱的方法讨论后，来实际执行董事会的设想，也就是所谓的执行，那么管理层再向下就会有总监、经理、员工等等，他们则是在执行过程中不断完成被分解下来的小目标。
所以在你是程序员的时候，你被分配的小目标就是完成你的程序让它贴近设计或需求，没有Bug。
再接着我们还要理解一个概念叫“垂直管理”，所谓垂直管理，就是一条线下来的，大部门到小组再到下属员工，这种管理模式在软件企业很常见，你的上级是开发组长（Team Leader）或是项目经理，这些基本上是垂直管理的范畴，那么垂直管理靠什么来保证目标完成呢？靠的是“过程控制”。
举个例子：传统开发一般是需求-设计-开发-测试，那么控制每个子过程来修正其每个环节，为每个环节设定目标，比如需求用例的测试完成度、Bug率、代码行数、测试覆盖率等等。
设定这些目标，就是在这样一整套流程性的过程中，使得每个子流程结果可靠，从而让整个流程结果是可靠的，尽量向目标保持一致。
有了目标就需要计划，计划中体现目标，这些就是基本的管理基础。
至于“扁平化管理”，我一直认为它和“垂直管理”不是一个层级的东西，“垂直管理”有经典的方法论和工具，甚至于我们的祖先以及我们的国家都是垂直管理的，而“扁平化管理”则更趋向于最高层管理者的理念来带动，并能完全应对自己企业的业务活动和模式，否则毫无意义。所以在基础管理的学习上我并不推荐直接去学习它。
上面基本上说的是“理事”的基础思想，接着再说说“管人”这件事，“管人”的原则，建立在“理事”的依据上。有了公司管理的组织架构、计划、目标，才有了“管人”的依据。
常常我们说“对事不对人”，通常说这句话的人想表达的意思是“我对你没有偏见，我只看事情做没做好”。那么，什么叫“事情做没做好”呢？不能因为你有了下属就等同于你在管理他们，而在于你要深刻了解，你在管他们什么。很显然，准则就是“目标”。
只有有了目标，我们才能继续分解子过程，从而使得你的下属能有被判断的依据。
所以在“管人”这件事上第一步是清晰表达我们的目标，或者让所有一起工作的人完全理解这个目标，接着依据这个目标制定激励。
有了判断依据和激励后，第二步，是将信息清楚传达到下面去。所以如何更好的传达信息，就又成了管理上的学问。
第三步，是定义清楚你所管的人，狭义的认为，通常是管理下属，但要朝管理真正去发展，我们就要把管理的受众拓宽到更多，上司、客户、合作伙伴。你没看错，上司是需要被管理的。
对于上司的管理当然不是颐指气使，除非你是想走人，而是追寻认同和反复确认目标。不同的人不同的风格，但是你得明白你自己的目标，那你就得明白你领导为啥给你这个目标，而随着市场变化，上司的思维也会被变化，所以目标是有可能会被改变的。
对于上司的另一个管理就是把他视作资源来使用，鉴于你目前的处境和地位，有些他能做而你不能做的，你就需要寻找他的认同并希望他能帮助你。
至于客户和合作伙伴的管理，也有许多方式方法，但无论如何，明确大家的目标才是进行探讨的前提。
“管人”的最后一步思维是自己的领导者个人魅力，这个东西呢，主要和你平时的言行有关，尤其是你能不能说，当然这个和每个人的性格有关，所以不用急，有了刚才说的判断依据、传达信息、沟通对象这些思维后，如何把他们做到更好，就是领导人个人魅力的体现，这个能力可以慢慢提升的。
有了这些思维后，我们该做什么呢？前期一定是多观察，多沟通，这样逐渐构建一套自己的管理思维，对于将来的转型是有帮助的。
以上这些是管理上最基础的思维。（由于转型管理的过程比较复杂，后续有时间我会再出专题来详细讲讲，怎么转一些具体的职别，比如项目经理、项目总监、运营总监等等）
产品系是我所见过的最有前途和个人能力体现的一种职业，因为它集合了 会学、科学技术、资源整合等各方面才能的精华。
一个好的产品虽然与各方面的合作紧密不可分，但是能创造出这个产品的人，等同于跑通了这个假设中的业务模型，那是相当了不起的。
所以产品系是非常有前途的一个职业。
从程序员向产品系转型是一件可行的事，因为程序员是完成产品的其中不可获取的一部分，它把这个产品给实现了。
其实传统的软件开发方法论中有许多种方式，比如结构化开发、快速原型、敏捷等等，但是无论哪种方法，它总归遵循的是下面这条路径：
需求-设计-开发-测试
所谓敏捷开发，只是将这条路径打得更散，更细节，更偏向于向程序员靠拢的快速实现和迭代，以追求更高的效率。
我知道现在很多做项目的和做产品的企业，为了快速，它会把整条开发分支中的设计给取代掉，你会发觉没有设计这个工种。但是，其实设计这件事依然是存在的，存在于开发中那些有经验的程序员的脑海中，只是这样的工种缺失会导致开发的代码不一致性相当多，虽然实现了整个开发过程，但当你打开他们的程序去阅读，会发觉各种自我炫技或者自我羞辱的表现。
那么设计是什么呢，设计是从需求向开发的中间过程，也就是代码级的抽象，有时候会用伪代码来表达，也是一些模式的体现，来保证一个业务需求，如果在UML里就是系统用例，而在面向对象里就会有许多程序员用接口来抽象。
再往上就是需求，需求就是有人提出来，然后你把它记录下来，然后完成一组在头脑中的系统搭建，既要有界面，也要有业务逻辑，还要有受众，简单说，就是谁来用，用什么，做什么。
项目型公司的需求是与客户谈的，而许多互联 公司或产品型公司需求有可能是和老板谈，或者由老板说一个抽象概念，然后由产品经理来具象化。
但无论在哪个公司工作，要向产品去转型，其实都是逃不开“需求”。
需求的第一要素，搞清楚用的人，也就是受众。
第二要素，是用户体验。
第三要素，是业务逻辑，但是这个业务逻辑就相当有学问了，因为面对的产业行业不同，这里的业务逻辑就有可能是商业模式、管理模式、业务模式。
第四要素，是资源配置，完成这次业务逻辑。
合起来就是在怎样的场景下，谁做了什么，需要什么东西的协助才能完成。这是需要具体问题具体分析的，但是思维逻辑应该这样去思考。
软件的主要目的是什么呢？无非三点，节约成本提升效率、收集有效信息、赚钱。
所以当你得到一个抽象概念的时候，脑子里就必然要有这样一组思维，这个产品或者这个项目到底是为啥存在的。这个我们称之为背景和目的。这是很重要的，又可以称之为“结果化思维”，只有有了这些思维，我们才能真正去搞清楚这次的需求是为了解决什么问题。
经过两年左右的技术实战，作为程序员，向产品系去转型的最大优势是，当你设计出一个产品了以后，其实头脑里基本上已经产生了怎么实现的通路，这是经验使然，所以在向后续设计开发沟通时，你可能会有很多话语权来清晰表达你的目的或者关键路径。无论是文档也好，技术讨论也好，可以节省许多不必要的沟通，比如技术团队说无法实现的问题。
但是向产品系去转型的劣势也很明显，因为程序员只考虑看着需求或设计来构思开发，所以受众、用户体验是考虑的最少的，而更为麻烦的是商业模式、管理模式、业务模式的构思，这是需要积累的。
比如：有时候你以为你在和需求方谈需求，其实他们更多的是和你谈一种管理构思，商业模式构思，这些如果你能积累更多，可能一听就明白，而没有积累的话，可能一头雾水。但是思维逻辑只要是对的，你就会从背景、目的去反向思考，再加上百度的帮助，也至少能搞得懂。
再比如：有时候，只是一个主题或者一个行业的大致构思，而需要你自己去把握怎么做出这个产品，这是最困难的，如果有类似产品，你可以参考，如果没有，则需要了解这个主题或者行业然后自己去体会构建出来。
如果确定了要向产品系去转型，那么我有这样的建议，首先你要有观察和积累，当你在开发时，你就可以去观察为什么是这样的界面设计，这样的界面设计是不是会有更多人使用，后台业务逻辑为什么是这样的，这是怎样链路里的一个环节，为什么需要这个环节，这条链路解决了什么，这是积累的过程。
一个产品是2C还是2B也是个重点，2B难度更大，因为不同行业产业链模式你就要去完整了解，而2C因为市面上很多，尤其是受众、用户体验这两个部分有很多可以参考的，所以平时就可以去积累去思考，更重要的是总结下市面上客户体验最有口碑的一些软件的细节，整理成模式。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！