技术管理

初做管理，想快速成长，而不想只依赖磨时间来带动“管理”的能力成长。所以，找到此书。 我期望从这本书中弄清楚的是管理过程中，到底会遇到哪些难题，以及别人解决这些难题的思路是什么样的。很幸运，这本书没有辜负我。 以下是书摘： 管理者，是不可能花大量时间去查阅几百本书之后再下决定 商业界却比以往任何时候都要复杂和扑朔迷离，管理者需要在更短的时间内对不同的观点和建议做出判断。但是他们通常工作繁忙，日程紧张，不可能花大量时间去查阅几百本书之后再下决定，他们需要的是马上就能帮助解决问题的答案或思路。 管理者，每天都有各种问题等着做决策，不论是自己的还是别人提出的。而且，还会面对有不少问题是之前从来没有想过的，也需要做决策。 这里并不是在抱怨做管理需要不停地做决策，心累。而是要说明，1. 管理者需要有一些原则来指导决策；2. 管理者平时就需要多思考，必须提前对自己提问，而不是等到问题出现再去考虑；3. 管理者必须有能力对问题进行抽象、分类。 其实我们自己在写代码时，也会不停地做决策。这个类要怎样的命名，这段逻辑到底要不要抽出来等等。编程时的决策大多已经有前人总结出来，只要你多学习前人经验+自己勤思考，基本上也就能成为合格的程序员了。但是管理不一样。很多问题，是必须你即时做决策的，比如员工当面向你提出离职，没有时间留给你查资料后做决定。那么如何才能更即时地做出更正确的决策呢？这个没有答案的问题

来自：IT人的职场进阶（ID：BestITer） “我，程序员，32岁，距离退休，只剩3年了！” 这句话用来形容2019年互联网行业最适合不过了。从18年开始，大大小小的互联网公司开始了不止一轮的裁员，19年网上开始充斥一类文章，专门写互联网公司超过35岁的人，如果到这个年龄，还不是leader，业务又不核心，那么请焦虑吧。 上次听罗胖的跨年演讲，主题是：基本盘。意思是不要受到人云亦云的情绪影响，而是转过头，看手中的资源，基于基本盘看清自己的努力方向，非常感慨和受启发。中国互联网经过过去十多年野蛮式的发展，似乎这2年开始慢下来了，程序员35岁的退休年龄虽然只是贩卖焦虑的一种说法，但是整个行业对人的要求越来越高是不争的事实，要求我们的成长速度必须跟上。2020年开始，希望自己在技术、管理、业务3个维度再做更深层次的学习，体系化个人的认知，做一个有特点的IT人。 下面要写的主题是关于『工程师如何从技术转型做管理』，这是我在团队管理上第一篇系统性的总结。之所以选择这个主题，一方面，个人觉得转型做管理是当前环境下大部分程序员会选择的职业路径，另一方面，自己亲身经历了比较漫长的转型过程，应该能写出点心得体会。希望下面的内容对于『正在转型挣扎期』或者『后续有规划往管理转型』的同学，让你们有所启发，内容大概分成以下4个部分： 什么样的工程师会被提拔做管理？ 你选择做管理的初衷是什么？

有些企业选择从内部管理的数字化出发，通过数据技术提升内部的运营管理效率，以及经营和管理的精准性。数据技术带来了新的组织管理方式，甚至是新的生产方式。数据技术在企业内部的应用能够发挥的价值也是巨大的，只是很多企业还未意识到而已。笔者曾在多家“世界五百强”的外资企业任职，并且所在的外资企业信息系统建设基本上比较完善，数据记录比较完整和规范，数据分析都有固定的方法和模板，并由专人负责。但是，国内的企业一直不太重视在管理上的投资，在信息化建设方面相对较弱，在数字时代来临时，还没有搞清楚数据技术到底是什么，更不会明白数据技术究竟会对目前的行业和市场及其经营产生什么影响，所以需要启蒙，需要从底层的基本逻辑启蒙。 其实，数据技术的应用能够彻底改变人们的沟通方式、管理方式、决策方式、生产方式，这些改变都是首先从内部改变开始的。过度强调外部的变革是跟风的企业，不见得不会成功，但从内部做好准备的企业一定是具有前瞻性思想的企业。 1．利用数据技术改变沟通方式 信息技术和数据技术的应用首先改变的是人们的沟通方式。企业内部是否使用目前最流行的、大家最习惯的聊天方式进行沟通，决定着这家企业是否与时俱进，是否有一个开放的态度接受最新鲜的事物。目前，微信和钉钉等各种公共聊天工具已经非常完善，企业内部在工作中的使用就是一种对外部沟通方式的适应。企业管理，首要的工作就是沟通，如果没有有效的沟通，管理就不会存在

管理项目和管理房屋装修有很多相似点。首先需求分析-中式装修还是欧式装修，架构设计-绘制装饰图；接着模块实现-硬装，软装，水工，电工，木工，瓦工；再者联调-各工种合作；最后家具进场保洁交付-产品上线。 要想项目管的好，就需要客户需求提炼本质，架构设计的扩展性好，层级划分清晰，模块内聚，具体实施者做事靠谱，开发有实力，逻辑清晰，联调配合顺畅，测试case覆盖需求全面。 若涉及到结构件，电子件，还需要确认模具，EMC，若有无线传输，还需要无线准入测试，以及产品的认证。 大多数员工工作的主要动力是薪水，其次是兴趣。若把兴趣调动起来，工作效率就变高了。拉来项目的是老板，老板精通财务或市场，对技术是门外汉。因而公司组织架构对产品开发不是最优的，往往流程不畅。流程不畅往往会导致扯皮。这时很强的人格魅力，沟通技巧，处事的方法，深入浅出的技术解释能力，就会派上用场。真心诚意的和一线开发者沟通，效果最好。从经济效益出发，才能得到市场人员的赞同。 项目管理，心理要装着一条线（产品开发流程） ，各部门接口（考虑的方面全），抓住两头（需求，交付）。同时要学会控制自己的心情，不以对方修为高低，语言粗俗和高雅，都不需要记心里。学会适当的放空自己，放下心中以有成见，才能做到客观公正。 来源： CSDN 作者： 糟心的事太多，唯有写作可以解忧！ 链接： https://blog.csdn.net/weixin

软件项目管理（Software Project Management） 该条目对应的页面分类是 软件项目管理 。 目录 [ 隐藏 ] 1 软件项目管理的概述 2 软件项目的计划 3 软件项目的控制 4 软件项目管理的特性 5 软件项目管理的组织模式 6 软件项目管理的内容 7 软件项目管理的成功原则 [ 编辑 ] 软件项目管理的概述 　　所谓软件项目管理就是为了使软件项目能够按照预定的 成本 、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和 项目 ( Project )进行分析和管理的活动。软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期。 　　软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个 软件生命周期 （从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，以预定成本按期，按质的完成软件交付用户使用。而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则，方法，同时避免前人的失误。 　　软件项目管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期

昨天，邀请了一位 专业人士 来公司给大家作了一个职业规划的分享，效果非常好。一方面，系统的梳理了一下职业规划的方式方法，另外一方面创造了一个非常好的交流机会，让大家把平时憋在肚子里话讲出来。 　　就现场的一些感受，谈谈自己的想法。 大家的困惑主要来自于两个方面： 1、如何选择一个适合自己的方向 2、如何“立足于现状”达到目标职位的“实际要求” 我们分别展开。 一、如何选择一个适合自己的方向 　　首先，对于技术人员来说，典型的发展方向就两个：技术路线和管理路线。 　　技术路线：工程师－架构师…科学家 　　管理路线：工程师－项目经理－部门经理…首席技术官 　 　 　　各个企业可能因为自己的业务特点，进行大同小异的调整，比如我们公司是这样的： 　 　技术线：工程师－高级工程师－架构师－高级架构师－资深架构师… 　　管理线：工程师－高级工程师－项目主管－项目经理－部门经理… 　　因为我们是技术类的工种，不管是技术线还是管理线， 共同的要求是起码是一位优秀的工程师 ，然后才去考虑发展路线的问题。为什么呢？因为考虑的太早，跟没考虑一样。让一位初入职场的人来做职业规划，基本上还是处于理论上的假想而已，很难落地的，因为那时你 还不曾感知这个社会中看不到的却存在的种种限制，更重要的是你根本不了解作为一位职业人的自己 。所以，我们至少需要两三年的时间，去亲自感受一下职场，感受一下职场中的自己

最近有朋友与我探讨了软件基层技术管理工作方面的话题，借此从动机和方法两方面谈谈我的看法。 动机 要做好基层技术管理工作，首先要确保自己有良好的动机，即明白自己为何要走上技术管理岗位。做管理的根本是为了获得权力，但获得权力的动机却存在很大的差别。 第一种单纯是为了利己。有相当数量的人往技术管理岗位“挤”，是为了获得以后在工作中可以少做或挑做工作内容的权力；也有的人是为了更快、更多地获得公司动向的资讯，以体现“领导”的“与众不同”；还有人是为了更高的薪资。 第二种是为了通过利他实现利已，是一种共赢的思想。这类人对技术工作有着自认为清晰的看法，相信自己能带领团队走得更好，获得权力是为了更好地调配团队资源和实施自己的技术想法。显然，实施想法的过程也是提高自己的过程。 如果走上技术管理岗位完全是第一种动机使然那就麻烦了，这类人说到底根本不相信或敬畏技术的博大精深，容易错误地以为“关系才是一切”，甚至玩弄“欺下瞒上”的伎俩。很难获得团队成员的认可与尊重，要带好团队没有成功的可能（什么是成功？）。 与之不同的是，持有第二种动机的人在工作中总会表现出积极的行为并被团队成员感知，其开展团队工作更容易获得认可与支持。 我曾在多篇文章中指出，技术管理者对技术需要有很好的敏感度，否则很难做好技术管理工作，很容易将“技术管理”变成只有“管理”。以中国目前的国情来看

软件团队的建设和软件开发管理 毕业以后一直在从事软件工作，历经了10年坎坷，现在是一家IT企业的软件开发主管。在不断的摸索、失败、成功中，有不少的经验和教训，希望能和一些成长中的软件从业者分享。 软件组织中什么是最重要的呢？团队和开发管理。今天我们的主要话题就是围绕着团队和开发管理展开的。 在很多场合，我们都听到人们说“人才是最重要的资产”，我想，这不是一句空话。有了人才就有一切，这是一个真理。对于软件开发来说更是如此。当然，对人才的关注并不意味着要人才堆积甚至浪费，人才浪费反而会影响整个团队。 人才只是一个个的点，如果没有形成一个有效的团队，人才再多也毫无意义。软件开发是一个需要协同作战的工作，团队是软件开发工作的基本组织，因此形成一个有效的团队是软件组织成功的基础。 很多时候，团队作战听起来容易做起来难。有一次，我和一个大型软件企业的CTO聊起了软件组织的模式，他打了一个比方，说软件开发就象做外科手术，外科主任应该是技术最强的人，熟知每一项技术细节的人，所以软件组织的领导也应该是技术最全面，每个细节都精通的人。软件开发真的象医生看病做手术吗？我们来看看这里面有什么不同。医生通常面对的是一个病人，通常处理的是一个个案，当然一个复杂的手术也需要麻醉、影像、护士、助手的配合才能完成。一个软件项目呢？软件项目也有大小的区别，小的项目一个人处理所有环节，前端、业务逻辑、数据库

怎么做才算靠谱？ 主人翁意识，积极主动的精神。 认真负责的态度。 作为研发，我们要对我们交付的结果负责，每一个文档、每一行代码都需要认真完成，要对它的质量负责。 保证 QA 在测试的时候，不能有太多的 Bug，不能影响与 PM 约定的上线日期。不能让协同工作的团队产生不信任感。 另外，随着业务的不断迭代，还要考虑系统架构是否需要改进，接口文档是否需要完善，日志是否记录完整，数据库或缓存是否需要扩容 等等。 即时反馈 凡事有交代；件件有着落；事事有回音。 抠细节 项目谁都能做到 60 分，细节往往决定最终结果。 细节是魔鬼，细节决定成败。 我觉得做到以上就有提拔的可能，当然还可以做到更好，具体参考《高效能人士的七个习惯》，积极主动、以终为始、要事第一、双赢思维、知彼解己、统合综效、不断更新。 假如公司发展很快，领导看你表现不错，决定提拔你带团队，你怎么看待这个事？ 做管理的初衷是什么？ 领导让我带，我就带，反正自己也没办法。 管理者工资高。 指挥做事就行了，不用 Coding 了，会比较轻松。 很难在管理路上走的很远。 技术管理是极其复杂和繁琐的工作，它远没有你想象中的轻松和风光，当你做出决策后的结果很多时候跟你的预期不一致时，你的怨气和转型痛苦就会出现，这个时候你就会想走这条路是不是走错了。 作为管理者应该怎么看待这个事？ 对公司：能带领技术团队支撑好业务

why -- 是否要做管理 对于互联网技术人来说，“带团队”不再是一个可选项，而是迟早都要面对的事儿。做技术和带团队，更像是职业发展的两条腿，而不是完全叉开的两条路。 技能清单 如果说你前面问我“适不适合”，主要是指“你是否可以很好地胜任”，以及“能否拿到自己想要的回报”。那么，此时你就知道要回答好这两个问题，是需要首先回答另外两问题的，即：这个选择是否更符合“你的初衷”，以及是否更能激发“你投入的意愿”。因为，这两个问题里蕴含着你的价值观、你的核心诉求，以及你的擅长和热爱，这些底层的动力，正是你面对挑战、走向卓越所需要的最重要的东西。 外驱让我们可以做好本职工作，而内驱才能让我们成就卓越。 所以你看，想被提拔为一个管理者最好的方式，就是你首先成为一个实际上的管理者，我们常常把这样的晋升理念叫“既定事实” 1.好的管理者或许不是技术最牛的人，但可以让技术好的人在team中发挥更大的价值～2技术要有敏感性需要了解的更多，关键时刻可以根据不同技术方案进行取舍～3.如何让团队目标一致，完成目标，各方面的资源协调等，也是管理者应该思考的，这些和我们做一线工程师的能力要求确实不同 “患得患失” 无论从哪个方面讲，你都并没有放弃技术，只是换了一种方式去学习和运用技术 你一定会有所得，会在做管理过程中有丰富的收获，既然一定能“得到”，所以不需要去“患得”。 既然你避无可避，不如奋力向前