IT需求如何主动支撑，快速支撑，高效支撑

对自身的文凭、技术专业和能力缺乏自信，再加之很有可能有以前面试不成功的例子，造成自身对将要面对的面试欠缺自信心，一直担忧自身会出问题。许多侯选人面试时，对将要面对的面试欠缺掌握，包含面试步骤，面试官很有可能会明确提出什么问题，面试官很有可能会调查哪层面具体内容也不太清晰而自身应当怎么看待也是找不到方向，内心免不了一直惶恐不安。

一般通过简历投递后HR通告你来参与面试，表明已大部分达到了面试企业的基础性规定，例如院校文凭或是是有关经历工作经验规定，去面试仅仅为了更好地进一步掌握你的经历及其你的性情，沟通交流表述能力，思维逻辑能力等能否合乎用人单位的规定，因此如果你能参与面试，就说明你针对这一企业这一职位是有一定竞争能力的。

个人简历中的有关经历你一定要细心整理一下，包含经历的时长，地址，企业，特别是在就是你做的事，通过步骤主题活动，获得了什么成效和销售业绩务必要非常了解。你能再融合前边你对一般面试中面试官常问的一些问题的搜集整理和掌握预置一些回答。不必焦虑不安，面试官也是平常人，你只必须把自己出色的一面展现出去，获得面试官的认同就可以。较大的问题源于自身，因此你该做的是面对自身，吸引自身的阴暗面你也就会取得成功。

碰到面试官焦虑不安是一种对陌生自然环境的害怕，面试第一次去到一个陌生的地区 很多人都是有如此的内心 如何解决呢 多去人多的地方 多去陌生的自然环境 那样养成好习惯了以后 你也就不可能有害怕内心了 怎样回应面试官的问题 绝大多数的面试 许多机构都招不上人，最先把自己穿着打扮的整洁 干净整洁 讲话要不骄不躁 按实回应就好了。

这类行业领先的IT人才外包公司工作可以获得以下两点优势：

1、更好的学习机会  多数情况下，外包公司合作的都是国内知名企业，因为他们项目多，人才需求大！因此，外包人才参与的都是具有挑战性的重量级项目。

IT人力外包公司

通常，客户提供的都是些大中型软件IT服务项目，这样的外包人员可以学到很多新的技术和知识，要是再用心点，还能够学到优秀的项目管理模式，从而形成良好的开发习惯和思维方式。而且，参与到不同公司的项目中，能够感受不同的企业文化，获得普通人难以学到的技能和经验。

2、更大的职业发展空间  在大公司进行锻炼、参与大中型项目，本身就是很好的职业选择。此外，有几年的驻场开发工作经历是一种不错的职业历程，也能为你开启日后更大的职业发展之门。

重庆电信企业信息化事业部 傅诣

      目前垂直的部门管理模式对“以客户为中心”、“零不爽”要求弊端日益明显。特别是在当前市场需求瞬息万变，需求要求快速支持的背景下，需求无法高质量的实现，首先表现在需求实施的效率与速度上，无法快速支持需求。其次表现在需求实施质量上，需求上线问题较多，带来很多次生问题，需求质量业务单位与分公司都不满意，影响IT口碑。

      以客户需求为中心，启用矩阵式需求管理，建设高、精、尖需求界面团队，在企信部设立后方资源池，深入需求一线，让需求一线指挥炮火，实现需求小前端，大后端，前端综合化、后端专业化，后端全力支持前端。

现状：目前企信部采用传统的垂直化组织架构，各域组织界面分明，容易形成部门壁垒，需求由需求前置团队接收，分派到各个域，较为复杂的联合需求由各域分别评估，各域再进行联合确认，再与需求业务单位进行沟通，期间反馈多次，效率较低，特别是在部分需求细节存在问题时，往往需要多次开会共同确认，在实现方案上各部门也往往各执一词，耽误需求实施时间，也影响需求实施质量。

措施：

1采用需求矩阵式管理：针对重要需求，采用项目制管理，由各部门部门负责人、技术专家、实施人员、厂商组建临时需求实施团队，此团队不隶属于任何一个部门，采用承包方式，将需求承包给虚拟团队，每个需求团队负责人拥有可以“呼唤炮火”的权利与“签署责任书”的义务，做到权责对立，平衡（后面会详细说明）。这样就可以整合事业部各部门的专家优势，打通部门壁垒，快速实现需求。该方式也就在事业部层面就形成了一个垂直于传统部门的需求实施矩阵，与各域的生产维护形成互补。

2“黄金四边形”：黄金四边型目标是建立贴近需求一线的敏捷化组织，在事业部层面对外形成统一的界面，能灵敏捕捉到公司领导及一线的关键需求，找准需求“痛点、关键点”，迅速调动资源，建立专项团队，灵活快速实现需求，打破部门壁垒，突破原始需求流程的烦冗。团队必须包含“项目经理”、“需求分析团队”、“方案设计实施团队”、“后期维护支撑团队”四个关键团队，形成黄金四边型。

各团队职责如下

（1）项目经理：项目经理是团队的****，是需求的第一责任人，拥有“呼唤炮火”调度资源的权利，同时，也是需求目标达成的第一责任人，签署需求实施承诺责任书，在需求完成后接受事业部对实施情况的考评。厂商负责人也纳入项目经理。

（2）需求分析团队：需求分析人员是与业务单位接触的排头兵，是第一接触人，首要任务是找到需求的“痛点”或“题眼”，其次是需求实施的桥梁，对外，负责引导业务单位按照IT“先上菜”进行推进，引导业务单位采用IT推荐的需求实施方案与分布实施的时间计划；对内，负责将需求与方案设计实施团队沟通，形成需求支撑方案，并与前端沟通。再次，在需求实施全生命周期中对需求变更进行管理。分析团队工作必须量化，每个需求必须要有需求分析说明书，每次需求会议必须要有需求沟通（或评审）会议纪要，每次需求变更需要有需求变更记录。

（3）方案设计实施团队：由各域的专家与执行人员组成，负责需求实施方案的落地，并与需求人员一起对实施方案向业务单位沟通，达成一致，最后由此团队的实施人员完成需求上线（执行人员可能与后面的“后期维护支撑团队”人员重复）。方案实施团队必须输出每个需求的方案，方案由事业部形成统一的模板输出，方案质量纳入管控。此环节是当前需求实施中的短板，很多需求在完成需求分析后，直接丢给厂商实施，实施方案中功能部分内容没有评审，界面部分在实施中也没有DEMO，没有也业务单位沟通，导致质量不被业务单位认可。该点如何提升，建议如下：

首先把需求分为5个层次，要求在方案模板中必须都进行说明，底层为功能需求，仅仅针对功能本身；第二层为服务需求，本层包含业务及流程，提升服务能力的需求；第三层为体验需求，考虑到客户感知的需求，含易用性， *** 作性，感知方面；第四层为关系需求；顶层为成功需求，即满足公司组织成功，有效推动业务发展。我们现在往往注重第一层的功能需求，对其他层次需求不够关注。即使在第一层功能需求中，还存在“简单功能做不好，复杂功能做得好”的情况，原因就是以IT惯性思维技术为导向，没有以客户需求为中心，没有抓住需求“痛点”，将IT功能做得复杂。后续，我们要多放精力到第2至第5个需求层次中，更加注重易用性， *** 作性，快速支撑。

（4）后期维护支撑团队：目前我们往往“重建设，轻维护”，需求上线后，就算完了，监控、作业计划没有跟上，上线后也不能主动发现问题，往往前端发现问题后，已经晚了，造成了较严重的后果。对此，后续维护支撑团队，首要任务是建立需求上线初期的监控保障手段，用数据说话，证明新需求上线后的运营情况，提前于业务单位发现问题，及时处理。其次，对新需求上线后的监控，作业计划进行实施，对新需求上线后出现的问题进行集中解决，为一线提供支撑。

前面说了，我们建立了矩阵式需求管理制度，组建了高、精、尖的需求团队，那么如何进行运作？

1小前方，大后方：需求分析团队直面业务单位，但我们后面有一个强大的支撑保障团队（各域专家、实施人员、战略合作伙伴等），各域整合资源形成整体支撑大平台，提供解决方案，提供技术支持，这样才能让小前方需求分析人员有底气，有引导需求，主导实施的资本。

2一线呼唤炮火：当需求人员或需求预沟通发现重点需求时，一线要迅速做出反应，立即呼唤炮火支撑，后端将根据需求难易程度，配备必要的资源，在实施过程中动态补充人员，必要时采用王牌团队或王牌专家，快速应对需求，落实方案，稳步推进。

实现小前方、大后方，一线呼唤炮火的措施：

（1）呼叫的炮火要集中在一点原则：集中在“痛点”或“需求题眼”上，才能实现“闪电战”。这也是中心领导说的先上关键“菜”。虽然我们呼唤到了火力，但是如果针对整个需求的方方面面，无法显示出火力的局部优势（火力被分散了），这就要求我们的需求项目团队，与业务单位沟通，集中火力先上关键“菜”，这个原则的度一定要控制好。

（2）组织人员保障：按不同域对不同人员进行打标，定义他们的责任，为他们指明发展方向，形成人力资源池。按照需求项目管理，需求实施需要管理者、需求分析人员、技术保障人员、上线后维护支撑人员。需要对各部门人员打标，属于哪一种角色，形成专家库，为随时组建队伍做准备。

（3）需求考评机制：事业部拟定出台《需求实施承诺书》，包含权利与义务。权利是可以在一定范围内调配资源，承诺为需求完成的目标，在完成目标时对应的奖励与惩罚。项目经理代表团队签署承诺书，并在需求上线后1个月内接受事业部考评，并进行奖励或处罚，并给团队及成员等级评定。

（4）团队及专家等级晋升机制：各种人才打标后，均成为此类型的专家，需要对组建的团队与专家根据需求实施效果进行考评，采用军队的晋升方式。通过考评筛选出王牌团队与王牌专家，在遇到重要需求，疑难问题时，优先使用王牌团队与王牌专家，使其成为“特种部队”。这样做的目的，是将事业部目前的“屯兵模式”提升为“精兵模式”，让不确定、困难复杂的关键需求，由精兵完成，提升感知。通过此方式，还可以建立企信部的战略预备队，为IT队伍的后续发展提供帮助。

（5）仲裁（指导）委员会：仲裁委员会设立的目的就是打破部门间的壁垒，具备横向传递沟通及协同作战能力。前面说到，项目经理作为需求项目实施的第一负责人，具有一定的动态调配资源的权限，但如果在需求实施工程中，出现与职能部门的壁垒或冲突，或遇到其他管理问题、人力资源问题，由仲裁委员会仲裁决定。建议仲裁委员会由事业部领导及部门领导组成，针对非技术性问题进行协调仲裁。

（6）技术委员会：事业部技术委员会负责需求实施中遇到的方案问题解决及支撑，特别是对在哪个系统实施较优方面进行确认。在需求遇到技术难题时，技术委员会将对技术细节进行指导。

（7）需求管理平台（缺失）：事业部目前使用门户及ITSM系统结合对需求流程进行管理，但缺失一个统一的需求管理平台，各部门目前均使用EXCEL对需求进行管理，哪些需求已超期，哪些需求为事业部当前重点需求，哪些需求不合理，没有一个需求管理系统进行管理，所以，建立一套需求管理分析系统，迫在眉睫。

（8）会议管理系统（缺失）：以业务部为例，上周业务部有10个会议，其中需求会议6项。业务部目前通过人员进行管理，罗敏每周五发会议周报，列举会议清单，从安徽学习后，业务部要求每个参会的人员出具会议纪要，由罗敏汇总。简单会议出简单的会议纪要，重要会议，出详细的会议纪要。我们希望有一个会议管理系统，将每次会议的纪要进行上传，纳入系统管理，这样，可以有效杜绝需求、专项工作进度上下不一致的情况。

（9）需求变更文档化：加强需求文档管理，这里重点强调一下需求变更管理，由于一些重要需求是公司领导需求，需要业务单位按照领导要求细化，并不断与领导沟通，这样必然会多次变更需求，IT为保障需求尽快上线，必然存在需求在实施中多次变更的情况。这就要求，每次需求变更必须文档化，把整个需求变更的情况记录下来，也要求需求团队与方案设计团队、后续维护支撑团队做好沟通，将每次确认的内容文档固话。这里建立事业部出具需求变更模板。

（10）需求模式固化：先选取少量需求试点此方式，在积累经验后，迅速固化实施流程，并将流程清晰、重复运营的流程及工作模板化，抓住主要的模板建设，再把相关的模板流程串起来，不断优化。形成知识库，事业部通过呼叫炮火的方式，集中支持，集中处理，解决共性问题，这些共性问题的解决要形成知识库，在后续遇到类似问题时，快速支撑。

（11）需求透明化：月初，需求版本部署会议，与业务单位沟通本月需要实现的需求；月中，由事业部整体出面（或各需求项目经理）与需求业务单位就需求进度进行沟通；次月上线后，与需求单位进行需求后评估，对需求后续维护及问题解决进行落实，对需求后评估结果进行沟通。

（12）加强需求过程管控：在建立此机制后，需要进一步加强需求过程管控，授权不等于放任，必要时实时监控。

不少软件开发团队每年都有新的开发人员要加入，其中以初级程序员居多，要想让这些初级程序员能够快速融入开发团队并实现价值，需要从以下三个方面入手：

第一：以开发实践能力进行人员划分。 新入项目组的准程序员往往有两种情况，一种情况是刚刚走出大学校门的计算机专业毕业生，另一种情况是自主学习通过面试的非计算机专业毕业生。这两种准程序员在进入岗位之前可以根据实践能力进行人员划分，实践能力较强的可以直接安排进项目组中，而实践能力较差的准程序员则安排到实习岗位上。按照 历史 经验来看，不少实践能力较差的程序员如果直接安排到开发岗位上，往往会导致其放弃这份工作。

第二：老带新。 按照 历史 经验来看，让程序员快速成长的方式无非就是通过实际项目的锻炼，对于学习能力较强的程序员来说，如果有专人指导的情况下会很快融入到开发团队中，有的程序员在一个月之内就可以完成功能模块的开发。老带新的原则有三点，其一是软件开发团队所使用的技术结构要交代清楚；其二是软件开发过程中所使用的开发工具和开发流程要交代清楚；其三是给出具体的参考案例。

第三：安排清晰的工作任务。 对于初入项目组的开发人员来说，由于其自身的专业知识积累还比较少，在项目理解力上还有待提高，所以在安排具体开发任务的时候一定要详细，越详细越好，同时要给出明确的功能边界，防止出现不可控的事情发生，比如哪些数据是不能动的，哪些功能和资源是不能调用的等等。有的时候“无知”是最可怕的敌人，不少初级程序员进行的“删库”等 *** 作都是在“实验”的心态下完成的。

如果有互联网、大数据、人工智能等方面的问题，或者是考研方面的问题，都可以在评论区留言！

我是程序员出身，现在也管理着一个项目，手下最多的时候也有十几号人；但是说实话，在管理方面，我还是比较欠缺的，我也一直在学习和摸索；当项目组入职了新的程序员的话，我经常会这样做：

先沟通，大方向要保持统一

每当项目组入职了新的程序员，我会第一时间和他们沟通，主要让对方快速地知晓项目的基本信息，并了解我们大的方向、观点、风格，我是希望在某些地方能和组员保持一致，例如：

制定计划

下面就要给新人制定计划了，这一点在前期很重要，否则新人就会面临无事可做的尴尬；

安排开发任务

通常，我们一两周后就会给新人安排一些开发任务，当然这个过程也是从易到难：

代码检查

对于新人，代码检查一定要做；如果是工作时间段的新人，每一行代码都检查一遍都不为过。

最后，我会给新人一些成长方面的建议，让他们觉得在这个项目中能学到东西；毕竟我没有权利给他们涨工资，只能通过这种方式留住员工了。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

建议从以下几方面考虑：

1、人员能力考查和培养。人员的能力参差不齐，需要根据岗位进行有目标的培养；

2、业务技能提升。想把工作做好，不了解业务，不理解自己做的东西，早晚要出现与预期偏差较大的情况。

3、工作态度和心态的培养。

4、尽早了解项目内容和项目团队，将人员在项目中的定位和需要的技术提前告知，告知项目计划和提示工作的难点。

5、组织一点团队活动，早点融入项目。

第一：熟悉你们开发工具、开发环境、运营环境……

第二：熟悉上下开发工序对接组别和责任人……比如开发该项目的前端、后台、测试等不同组别以及其他开发外项目组外的不同部门打交道的人员。

第三：项目说明书、整体功能、进程，所负责的分割模块……要完完全全提供出来。

每个人都是从新人成长过来的，在我工作的五年间也带过很多新人，最近刚好有个毕业生来公司实习，领导让我带，这边就分享一下我具体是怎么 *** 作的(开发的角度):

总而言之，带新人还是比较累的，对大部分公司而言，技术要求并不是很高，所以新人真的比较难上手的不是技术，而是业务和表结构逻辑的不熟悉，作为新人，公司的打算就是从零开始培养，因此基础并不是最重要的，学习的态度才是公司看重的。

以上为个人观点，欢迎在评论中发表自己不同的观点，喜欢的加个关注，谢谢。

以十人以下的团队来说一下。首先是和员工相处好，其实这一点做到并不难，就是正常的相处，怎么愉快怎么来（当然不能坏规矩）。我做的最大尺度一次是这样：有个毕业生干着干着就哭了，一问之后知道直接原因是程序员的工作内容和自己原来想的不一样，主要原因是刚到北京体会到了巨大的压力。当时我就拉着她到对面肯德基去坐会了，点了饮料和薯条，聊了一下，顺便开导开导她，舒缓一下情绪，这事就这么解决了。其次，作为领导请安排划分好工作内容，不要频繁变更，否则影响威望值。这也是保证工作可以顺利开展的基础。安排工作时请考虑员工的能力和经验，还要考虑员工的兴趣，这点也很重要，很大程度影响积极性。

在小团队中只要工作能顺利完成了，一般问题就不会很大了。其它：可以观察一下每个人的喜好，然后看机会适度的介绍这方面的内容。比如我就专门给一个员工培训过数据结构，而她也很愿意介绍自己认识的人来工作，双赢的结果。员工做好的地方及时表扬，自己做错的地方及时承担责任，等等。总之将心比心的对待员工，小团队还是好带的。

教会徒弟，饿死师傅，等你教会他们，你就该退了，理由：你三十多，奔四了，负担大，不能加班，养不起你！中国现状，保留必要绝活，留几招吧！为养家！

先让他做点小项目，锻炼一下，把以前已经完成客户的项目拿出来给他做，练手，看看功底如何

如果功底好，则主要锻炼他的思维能力

如果功底不好则多锻炼他的技能

首先是能力要过关，之后就是交流要能顺畅，其他的问题都不是问题，只是经验和熟悉而已。

初级IT 人员，发展为技术管理角色，再到管理技术角色，这个是在IT行业的共性路线；

但是在甲方单位，需要再从管理技术角色，到部门管理角色，更需要跳跃到企业、集团管理层面去考虑。必须使自己能做整体的信息化规划路径，并匹配企业战略发展方向，主营业务发展方向，从更多“务虚”之处，大处着手做好信息化布局才好！

最后，通过信息化推动形成的管理成果展望等，体现出信息化的 综合性 价值！

——要做到以上这些，必须以管理驱动技术，这样才符合企业决策者的管理思维！

以上就是关于参加IT公司的技术面试时，遇到不会的问题应该怎样跟面试官沟通全部的内容，包括:参加IT公司的技术面试时，遇到不会的问题应该怎样跟面试官沟通、在IT人才外包公司工作，对个人有什么帮助、IT需求如何主动支撑，快速支撑，高效支撑等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！