从大公司跑到小公司去（团队建设）

--项目管理学习总结（9）—史上最全互联网八大技术岗位详解- https://blog.csdn.net/u012562943/article/details/78312211
  互联网技术岗位详解，涉及到前段开发、后端开发、移动端开发、大数据、项目管理、测试、运维、技术管理等八大领域。
  大部分的HR不会问你岗位专业问题，有一句话是说技术面试看你做事，人事面试看你做人。无非是看你的沟通能力、性格、企业忠贞度、对岗位的热情等。
  建议最好是说自身原因且能让HR信服的，比如说觉得目前个人发展已经没有什么空间，想要在技术上再多历练提升下自己。回答是积极正面的就好。

-- 1.技术专家路线，成为架构师，优化系统中的瓶颈；
2.项目经理,逐步学会协调各类资源；
3.技术管理方向：技术经理/总监；
4.产品方向：产品经理、产品总监。
5.往运营和市场方向转型。
站在技术牛人的肩膀上，你会看的更高看的更远，从而避免很多弯路，弯路过多那是对时间的浪费。
站在技术牛人的肩膀上，将帮你更清晰的规划自己的职业发展方向。
不断从你身边的牛人身上汲取过往的经验和教训，找到一个你可以参考的榜样，去开启你未来的职业生涯。

 

> 从一个上市公司的某平台技术总监，来到新型的O2O公司来做CTO. 感受最深的说下四点。
有长期激励目标。
经验能力到了一定程度，就会关注于做的事情有没有挑战，有没有意义。对于我来说，找不到做事的意义和挑战，便无法激励自己和团队，有混日子的感觉，浪费自己的时间。而跳到创业公司，前提就是看好公司发展的方向，加入公司一起努力，这便是长期激励自己的事业。这便是我们的星辰大海！
之前看到新闻，前几年还是红火的世界级企业，突然卖掉裁员。而公司的员工，为了多获得几个月补尝，而楼下拉横幅抗争。 虽然我支持这样的抗争，但并不希望出现在自己身上。

无平台光环，需要真正实力
很多人员在原有公司做不错，但很可能是平台有光环，有资源。 在你做了正确的事，就取得业绩不错。但在创业公司却不同，你需要为公司提供资源,推动发展。
以招人来举例。
在大公司，但只要你和HR 努力，你可以建立一支还不错的技术团队(在大公司都不能建立起团队，创业就不要当技术负责人）。 而创业公司，所有面试中你看得上的，手里都有很多个Offer, 这时你感受到是，面试者在面试你和公司。你需要说明公司的发展前景，展示团队的愿景，更要展现个人的实力与感召力。
在大公司踏实认真做过的事情，最终都会成为你的经验和能力,让你有信心来面对创业的挑战。

能力越强，空间越大

大公司，有不少做法落后时代，虽然大家都知道不好，但是没有办法改变。 比如GitHub发展如火如荼，但有公司还用着SVN. 你去推动Git 的使用，大家会推脱 "SVN不也能用么，我们还有更重要的事情要做，换GIT的收益有多少?"

做为公司的CTO, 你可以建立符合时代发展的技术价值观和技术文化。 比如,我在团队中提倡：

极致： 不论是产品还是代码质量，还是使用的工具。 要永远保持有更高的要求。
透明 : 为工作建立透明的环境，让所有的人知道你做的事情和贡献。

透明环境能降低潜规则的出现，保护人才、用好人才。


追求成功

如果创业不能成功，那成就、荣誉、收益都是空谈。不成功，将辜负那些追随自己的兄弟和一起打拼的团队。追求成功，将以更高的视角来看到工作和问题，能放下一时之得失与创始团队一起建立更高的梦想。
创业能不能成功，主要看两点：
第一、方向是否正确

在风口，猪都可以飞上天。 比如，在O2O的风口下，BAT等这样的大厂都来主动找我们合作，在宣传推广方面，我们的成本就少很多了。

第二、 领导者
现在创业者如过江之鲫，有纯忽悠、有赚快钱的、有骗投资人钱。这些基本都是坑。创业是比艰难还难的事情。怎可能侥幸成功。领导者是企业的灵魂， 领导者需要，志存高远， 脚踏实地，锲而不舍，快速成长！

还好，我选择公司这两点都不错。

选对人，做对事！
什么不知道怎么判断人和事？ 那就跟随你接触过中最优秀那个人，这样成功的概率高多了。

 

》去小公司做CTO，那么小公司能说清CTO的职责定义吗？

CTO是技术高级管理，是包括组建团队，制定技术方向，规范，人才梯队，甚至关注这个行业技术趋势，大部分时间主要是管理和沟通，并非编码，如果对方的职责定义里面仍然包含了编码，说明这个岗位也不是纯CTO，而是cto兼程序员，兼...
说实话，关键看你怎么看待这件事，是在意title，还是薪资，还是未来成长空间，还是能学到东西，还是什么？
看重任何一项，小公司有大公司缺的，你都可以去。但title一定很虚

 

》分享一位Google离职工程师的职场转型体验，有比较多的细节，希望给题主一些启发。

1、离开编程的舒适区

创业初期筹集资金的时候，我第一次遇到编程以外的挑战。和投资者周旋对一位软件工程师来说真是一件苦差事，如果你也习惯了坐在自己的工位，仅通过GChat彼此交流。突然之间，我得穿上没有洞的衬衫参加各种大型会议，并试图说服在场的人我们能实现不可能的事。

 

对于工程师来说，承诺一周以后的deadline已经很难了。投资人却会challenge你承诺今后1~2年的事情，并会在每一个节点问你问题。「真的吗？」他们中的有人说，「你要做一个AAA游戏？你怎么把2G的内容放进浏览器？你怎么让它有趣？」

 

幸运的是，多年的软件工程师生涯赋予了我一项珍贵的技能：直觉。我豪不怀疑我们在做的事情是可行的。一旦我自己深信不疑，让其他人相信也就轻松多了。

 

就像说服投资人，团结新的队伍也是一项挑战。几个月之前，我们决定做游戏，虽然不知道它会成为什么样子，但是开始做是第一步。一位合作的艺术家给我发来了一张游戏的图片：一片郁郁葱葱的草地。我把它做成了36’’x 24’’的大海报，挂在墙上。

从此，无论谁问我他们接下来要干嘛，我都会指着这张图说：「只要能让我们离这里更进一步。」这是自我驱动型工程师需要听到的话。我们有一个清晰的目标，正踏踏实实地挂在墙上，我们要做的就是努力实现它。

 

CTO的职位意味着更多的责任，却不代表冗长的会议和官僚主义。除了技术，CTO还要承担更多的管理职能：雇佣合适的员工，解雇不合适的员工，持续地创造和输出idea，带着目标团结队伍。

2、沟通的陷阱

起初，我想当然地以为在这样一支几个人的小队伍，相对于在Google，沟通应该不是问题，但是我错了。在加入Artillery的头几个月，其他的合伙人和我都已经数次激怒了对方。

 

三位Co-founders的沟通很混乱，一个人说给另一个人，第二个人又传话给第三个人。作为一名软件工程师，如果你在一支全是工程师的队伍，沟通是相对容易的。当这支队伍混入了其他职位的人，且多于10个，沟通会变得有点棘手。相信我，沟通会比你想象的难，但是必须好好地掌握。

 

所以我们准备花更多的时间一起筹划，比如花一个小时坐在房间，清楚地写出来当下在进行的事情和面临的问题。第一次这样沟通，还不到60分钟，我们就解决了能想出来的大部分问题——大部分都是由于沟通失误造成的误解（!）。从此每周，我们都会开一次这样的founder’s meeting，并把决议都记在一个长长的Google文档，方便随时查阅。从此我们再也没有出现过严重的分歧。

 

但是，仅仅增加沟通的量是不够的，更重要的是掌握沟通的技巧，提高沟通的效率。刚开始例会的时候，过了30分钟后，我们才意识到刚才是在用各自不同的话语表达同一个观点，这种无休止的争论纯粹是浪费时间，

 

另外，真诚的批评是原则：把自我关在门外，开诚布公地讨论，给彼此最坦诚的反馈。我们的会议中常会听到这句话：「哦，我不认为它会这样。」建设性的批判能帮助彼此更好地完善自我。

 

其次，email也是一个坑。通过email很难传递情绪，很容易成为误解的发源地，会影响情绪，甚至影响表现。同样的话语，如果是面对面的对话就会有完全不一样的效果。
 

分享一个简单的小技巧：当我怀疑我发出的某条信息可能会有歧义，我会加一个表情，比如 [mood: agreeable]，从而确保传达出我乐意的态度。如果你也这样做，你会发现它非常有效，可以让所有人保持冷静，避免不必要的争端。

3、选择正确的技术

Web开发是一个有创造力的快速发展的世界。各种各样的新idea和工具层出不穷，似乎换一个新框架或代码就能解决你所有的问题。但是作为CTO你要记住，挑选怎样的技术相当于你花了一笔真金白银，一旦你做了决定，很可能你就没有时间和资源再走回头路了。

 

在Artillery，我们清楚我们会写很多的JavaScript，即使大家都懂的，JavaScript有各种让你不爽的地方 。我们之前有使用过CoffeeScript，它运作的不错，我们也喜欢它的作者做的大部分决定，所以我们最终选择了它。然而最关键的原因是，我们并不会被困死在CoffeeScript上。如果哪天我们想丢弃它，我们可以将轻量级的CoffeeScript全部编译成JavaScript，并从那里继续前进。这么做合情合理的，而且成本也很低。

 

服务器端的决定就没有那么容易。Node.js显然是我们的首选，它可以轻松分享客户端和服务器端的代码。然而，那个时候Node.js还很年轻，而且它的生态圈也不成熟。当时很难评估Node.js的第三方库的质量和安全性，有很多相似功能、但又在开发的不同阶段的库。

 

这让我们停下来思考了一下。但是经过更多的研究，一件事情提醒了我们：Node.js的更新速度很快。Node.js基于的V8，已经被证明在Google Chrome上跑的又快又干净。如果只有一家公司拥有最多值得信任的聪明人在致力于语言，那就是Google。依靠这个框架似乎是一个安全的选择。Node.js的代码新版本是一致的，而且强大的Github社区又提供了频繁代码更新的便利。在仔细的审议后，我们决定用Node.js，现在很庆幸我们做了这个决定。

4、放弃side project

我很喜欢side project，我总是要做点什么——一个游戏、一个WebApp，或其他的什么工具。这是我保持学习，玩儿新东西的方法。但是当Artillery成为现实，我的兴趣突然成为我的全职，我该怎么度过我的空闲时间呢？

 

我曾经花了一个周末，和一个朋友做一个电商网站的原型。「花不了多长时间的」我记得我还这样说过，「我只需要用Django、PayPal和一个购物车。」它的确只花了两天，却耗尽了我一个礼拜的精力。

 

从此，我才意识到精神充电是必须的。在其他项目上分脑力让我在工作中降低了效率。作为CTO，跟上新技术是我的责任，为什么我还要做那些无益于我提高的事情呢？做外部的项目会给我的正职带来压力，对我的合伙人也不公平。

 

我停掉了side project，创造力和精力又回来了。虽然我有时还是会陷入卡壳，想修复一个bug却怎么也办不到，但是了解了生产力低估周期后，我放轻松了。如果此时状态不佳，不如接受它，和周围的伙伴交流一下，做一些简单的活儿。这样总比恐慌、错过deadline要好。

5、团队管理太难

开始组建团队的时候，我们会说很多在Artillery工作的美好愿景，包括各种各样的福利待遇。我们希望用有趣又有意义的工作来吸引最优秀的人才。

于是我们在网站上挂了很多福利：免费午餐、完善的医疗保险、交通报销、无限的假期、WorkStation预算、从东京买来的游戏原型手办……列出这些福利简单，然而并没有什么用。

 

比如，开始我以为无期限的假期是一个好主意。没想到似乎给员工带来了更多的压力：优秀的员工害怕他们休假太多而不敢提出请求。最后，我们决定还是采取固定期限的带薪休假模式——既能缓解员工焦虑，又能足量地满足员工的度假需求。

 

再比如，自主选择编程装备带来了各种奇葩需求：20美元的Razer Goliathus鼠标垫值不值？我想用自己的笔记本工作，把我的预算花在昂贵的外设上吧！甚至还有员工想要高昂维护费用的组装系统——至此，我终于确定每个人都应该用Mac OS X——因为它足够干净、简单。

 

要解决问题首先要理解福利的实质是什么。比如装备福利，它的目的不是无限制地满足员工的每一个细微的需求，而是为他们提供良好的工作环境，确保没有人还在使用老旧、迟缓的电脑。

 

那些员工看似在浪费你的好意，其实并没有恶意。你得帮助他们理解政策、福利背后的逻辑，他们会做出更好、更谨慎的选择。

 

Lan离开Google的原因很简单：在这里很难保持冲劲和创造力。在大公司离职工程师中，这样的理由太常见了，软件工程师很容易被隔离在业务线外，唯一的任务就是不断输出优质的代码。

创业不是解决大公司病的灵丹妙药，选择加入一家小公司当CTO，意味着生活一半是巨大的自由，另一半是巨大的责任。CTO的工作如此辛苦，会花掉全部的脑力和精力——但为什么还要选择呢？

》》 搭环境，搭框架，写ui，管产品，跑调研...

纠结svn还是git，纠结eclipse还是intellij，纠结github还是gitlab，纠结maven还是gradle...

人与人的信任是一点一点建起来的，即使老板对你再客气、再重视、再放权，你也要在初期把沟通和信任建立做为第一优先级考虑。

虽然是很大的title，但是千万别太把自己当回事，你对于公司是可有可无的，不管你创造了多少价值。。

 

 

》我才明白什么是真正的软件工程师。更重要的是，明白了软件工程中的业务是什么。这不需要知道更多的编程语言、库、算法和设计模式。这是一种思维模式。勤奋、严谨、可靠的人际关系和最终犯傻，不仅仅是软件工程师的必要素质，也是从事研究生院之外的任何职业的必要素质。

花时间来学习新的工具。不仅为了扩充你的抽象知识，而且真正了解工具可以帮助你把事情做好。你将很快的从中获得回报。

学习如何说话。看TED演讲，并注意许多经验丰富的演讲中是如何能吸引观众十五分钟，同时讲述一个引人入胜的故事的。

当我们谈论一个公司的最佳利益时，我们实际上指的是利益相关者的最佳利益。现在真正的问题是：你的CEO或主管认为这些利益相关者有哪些人，以及他们的利益有多重要？

以下是我如何看待世界的观点：

如果一种状态太熟悉，你学不到太多。然而如果你感到恐慌，你可能什么也学不到。

这里是你的舒适区。你知道池塘中的每条鱼。你的归属。你知道如何处理问题。太阳底下没有什么新鲜事。如果你想要学习新东西并且成长，你必须离开你的舒适区。这是学习的开始。这是有趣的事情开始的地方。这是你不会立即对一切事情做出反应的地方。

》了解自己的特性以及希望迈入怎样的管理岗位绝对是最值得大家认真反思的首要议题。

  领导与引导是这份素质清单中的核心项目--甚至足以决定一切。

发现帮助最大的还是来自同事、管理者以及整个团队的反馈意见，我也通过 审视角色模型并了解其为何能够确切起效而得到了切实助益。

  一位专家指出，管理岗位会给从业者带来大量同样的挑战与不确定因素。他随后补充称，我们绝对不能采取直白的表达方式--否则必然招致被整个团队所疏远的风险。有鉴于此，类比与提醒才是最理想的沟通手段，而这正是作为职业转变的基础性蓝图。

 只有最糟糕的管理者才会过分施加控制，”Long指出。但这些事必躬亲的领导总以为自己是在做正确的事。您能将自己的全部精力用于指导、支持、点拨以及鼓励他人吗？这种心态是最基本的前提。总之，请确保自己做好了登上这辆过山车的全部心理准备。”

 我们还认为，成功实现晋升后的工程技术人员不妨偶尔回顾过往，审视将代码构建与部署作为核心工作--而非管理产品、预算与团队--的那段时光。

 作为一位管理者，大家的职责将较少专注于工作，而更多集中在帮助他人获得成功上。”