技术支持工程师

技术支持工程师

 
目录
1 序 3
2 售前 3
2.1 公司 4
2.2 客户 5
2.3 项目分析案例 5
2.3.1 无心插柳 5
2.3.2 多做点总是没错的 7
2.3.3 有心有意未必成 9
2.3.4 总结对比 10
3 售后 10
3.1 公司 11
3.2 客户 11
3.3 项目实施案例 11
3.3.1 初来乍到 11
3.3.2 未知边界 11
3.3.3 站在巨人肩上 11
3.3.4 总结对比 11
4 结语 12

文档信息
文档名称 技术支持工程师
版本编号 V1.0 保密级别
制 作 人 刘楷涛 复审人
适用范围
扩散范围

分发控制
编号 读者 权限 与文档主要关系
1
2
3

版本历史
版本编号 创建日期 制作人 说明
V1.0 2018-11-4 刘楷涛 初稿

文档声明
文档描述或者记录有错误的地方，请联系作者更正。有不同想法的同行欢迎交流。
联系邮箱：980985848@qq.com

1 序
写这个文章的原因，只是为了总结个人过去的工作内容，本人已经从事这个岗位6年多了，有一定体会，正如法国哲学家萨特对意识的理解，每个人意识是有偶然性，正因为如此，我会从自身的角度去解读这个岗位，也希望得到各位对其肯定与否定，否定的地方希望您提供宝贵的建议来完善岗位的定性，方便他人对这个岗位有更好的定性与理解。
对于这个岗位的解读，我会从公司、客户两个层面进行解读。技术支持工程师按字面理解就是通过技术认识支持公司为客户提供服务。这种服务可以是实在的产品需要，也可以非产品的技术咨询。为了满足这种服务需要，那么工程师在这个服务过程，需要提供必需的技术支持。对于这种技术支持网络其实已经有定性，被分成两方面售前与售后。
2 售前
先讨论售前的方面的工作，以项目管理学来说，在5个项目阶段（启动、规划、实施、监控、结束）中，售前属于项目的启动阶段，项目启动阶段需要的是为整个项目提供目的以及项目动机。项目规划的阶段也可以归为售前工作的范畴，这对于项目实施与项目结束是有好处的。当然个人做售前的经验不是很丰富，说错请指出。为项目提供目的与动机，需要在公司层面理解公司产品或者公司能提供服务，比如你所在公司是买传统的网络交换机、路由器，你连这个产品不了解，不知道它用来做什么，那么就更不用说去推广了。而在客户层面，需要理解客户所在对应的行业标准，以及客户的业务内容。行业标准是为我们的服务提供依据，而理解客户的业务内容，你才能跟客户理解层面提供交流的需要，分析客户需求点，为项目提供必需的动机。与用户沟通交流，存在必需的语言交流与文字交流，语言交流是必需的，因为双方的交流成本相对比较低，降低分析错误与理解错误的成本，常见的交流方式见面交流、产品ppt的讲解等形式。文字交流需要花费比较多时间去梳理，一般需求点比较明确，主要是以方案、标书等形式。
2.1 公司
正如人一样，先了解自己才能知道能为别人提供什么。你所在公司就是你的工作平台，先了解并理解公司的情况，你才能以公司名义为客户提供服务。最简单理解，通过百度一下公司名称，查找公司简介，了解公司的过去与现在，你在入职的时候，公司的入职培训中，也会给你介绍公司情况。这个情况一般都是比较公司资质与公司的过去现在，还有公司的愿景（即公司的未来），这是对公司的理解，说实在对个人来说意义可能没那么大，大部分人关心的公司的财务报销这方面。大的方面及方向了解后，你才能理解公司成立目的及公司的特性，这个特性就是公司存在的原因。接下来，我们需要了解公司的组织结构，方便以后写标书找资料，必需的资料很少都在同一部门，需要其他部门的人员配合，这就有个问题你跟不同部门基层人员足够熟悉就很好拿，但是不熟悉，需要通过你的领导协调，这样周期就会变得很长。特别是今天写明天的标书，这些资料获取的时间就很有意义。
公司大的方面把握后，就是公司服务及产品了解与理解，个人学习需要了解这些方面的东西，这也是你在公司价值体现，将公司的产品及服务组合到用户需求中。所以需要了解公司产品及服务，那么怎么了解呢？
可以通过几个方式，因为项目是连接用户与公司的事情或者说是点，所以最直接有效的方式，自己进入到一个项目中，通过项目落地过程，熟悉公司产品及服务可以给用户提供什么，在没有领导指引的情况下，容易发生以下事情，项目进度缓慢影响公司形象，个人迷茫不知道下一步做什么，所以做完事情需要总结，总结本次项目的经验教训方可以提高自身对公司产品的理解，方便日后设计方案及与用户交流。
其次，通过公司的项目资料，以前公司的项目总结文件、方案等等，从项目资料中分析，提炼出可用文件，方便自身使用等。团队的一些模拟环境的测试也是一种雷同的学习方式，与实际情况靠近。
还有一种就是公司内部培训，这类内部培训一般是以产品为主的培训，介绍公司的产品功能，让员工明白产品的功能，产品的市场定位。当然也有的情况是，公司同事分享工作案例，分解项目操作过程。两者培训过程均以推方式沟通交流为主，所以主观上讲个人吸收是比较少的，需要后续工作过程中不断磨合，但是后者培训内容就比较有吸引力，因为靠近实际多点。
正因为主动学习比被动学习上手快，所以当工程师在项目中，有项目压力推动个人主动去学习会学习比较快，很多时候，公司也怕新兵坏了公司的项目，所以被动学习的方式还有情况会比较多，那么也就只能以积极的心态，主动去了解必需的资料及内容。其实，主动了解后，有一个情况就是东西不用很快就忘记了，那怎么办呢？个人是有一个笨方法，把整理资料，重新自己编写，写成一个新的技术方案或者文档，在写的过程中，自己就会主动去理解并转化成自己东西。当然，也可以整理成ppt进行宣讲，或者在公司模拟拜访环境中测试都是可行的。
2.2 客户
语言交流的好处在于沟通快，反馈快，成本低，所以大部分情况下，都是以这种方式为主，当时相对应的它的信用度也低，最好在达到口头协议后形成文字协议，保障双方利益。与用户交流最先的是语言沟通，那么就需要快速与用户站在一起，这需要你对用户所在行业及用户所面对环境有所了解。这些了解大部分来源与公司资料，当然你也可以自己积累。用户愿意与你交流，可以说明用户有需求或者想你帮他挖掘需求。他的需求需要实际的业务情况分析，通过产品测试或者其他方式加以应对。
当用户需求明确后，用户也信任你，这个时候就应该出文字交流文件，比如测试报告、技术方案。技术方案或者测试报告，给客户提供立项的动机，有时候需要为客户提供动力，这个动力来源于需求点。如果进展顺利，项目将进入招标阶段，至于能否中标就需要看标书与招标文件的契合度来。
2.3 项目分析案例
2.3.1 无心插柳
刚毕业那会，刚好进入一家安全公司，因为刚毕业就像一张白纸，到社会中学习，对公司了解也就仅限于公司简介。这个确实挺尴尬，当时不关心这些就想这使用上在学校学来的技术。对于公司产品的学习，来自与公司ppt，公司培训视频这些方式，浑浑噩噩在公司学习了2个月，大概知道用户公安这个行业一个叫72号令的规范文件，还有ppt上讲的客户的业务需要，不过没有联系能力的人，所以觉得它讲的都是对的，也没有深入理解。在一次机会外派出去外地出差，年轻觉得外出出差挺好的，不过也学习了不少，主观的认识客户业务，并结合实际操作，明白公司的产品给用户带来了什么需求点。客户的业务包括了平安城市的视频流量、卡口流量、酒店人口信息等等，这些平台搭建有前端平台，通过公司的数据交换方案及视频交换方案，提供必需安全防护，并将数据以各种形式拆分，传输进入内网后，再在内部进行整合展现。通过一次深刻地个人认识，提炼出必需元素。
这里以这个学习过程做分析，2个月的被动学习，看到的概念或者听到培训人员的培训视频，你只是知道，当是个人很难去想象这个业务情况。当你在项目中，你去接触了一切相关的人员，因为你在客户的业务需要中也是重要一环，这一环需要了解前端情况，后端需要，完成对接，当然多问一句，就可以了解整个大业务的情况。这个可以作为资本，日后与其他地市的公安谈项目时，作为交流谈资，了解用户业务是否雷同，就算没有雷同的需求，也可以拉近与用户距离，给用户感觉你很了解很懂这个行业情况。公安部72号令可以作为方案设计依据。
公安部72号令是公安部的安全准则，安全大的方向上有《网络安全法》这个法规提供单位执行安全基本要求，也定义违法处罚，给安全规范落地提高动力。规范上准则iso27001安全标准，等级保护等，这类准则提供单位安全上的指引。为什么这样说呢？像这类规范准则，是同行业中的各个企业精英根据多年自身企业建设提炼总结出来，再经过多方磨合，算是精华中的精华，不过就是于实际的环境未必符合，所以可以提供指引依据，实际情况，需要客观分析实际业务，结合规范准则，找出需要安全加固的需求。这样提供的方案有实际依据，又契合实际需要，为项目推进提供必需的动机。以一个无心插柳的事情做为讨论点。
Xx地市公安局是我们的老用户，老用户对公司及工程师已经有足够信任感，从业务需求出发分析帮助用户完善安全防护。本次老用户网闸产品的巡检，所以事先打电话给用户，确定用户是否有时间。当天到达现场，检测设备运行情况，并了解用户网闸对应的业务，用户讲述网闸业务使用情况，反馈情况良好，讲述了这是一个卡口业务。由于我上面对用户的这个业务已经比较了解，细致的业务流程互动讲了一下，场景切入是很好，更何况是真实业务。聊着也讲了下，最近经手的其他市局的案例，相同的卡口业务，只是在原有网闸的基础上，演变成边界接入，也帮用户做了对比，从单一产品升级到方案，成本上是增加了，不过可以与其他业务优化到同一方案中，并且更全面做到安全防护，也能更好的响应72号令的要求。这里主要是做对比，提出优劣势，由用户做思考做判断，决定权还是在用户手中，也提供依据，告诉用户这个方式是合规的，这些都是用户做这个项目的动机。也提出了其他市局已经做了这个项目的反应，如果同市局间有竞争关系，领导就会有动力去推进项目。不过，这里也还是为用户提供第一次项目印象，有印象就有机会。随之没过多久，用户联系我们去做这个数据平台的交流，交流可以以不同方式，我们是想以ppt产品宣讲的方式，全面点，也可以找到用户的兴趣点。后来反思，其实是大环境在做，所以之前用户在特定会议中也帮我们一把，领导知道我们能做这个事情，所以才感兴趣了解一下。
方案宣讲其实也不顺利，一是本来就没多练，二是比较紧张，面对整个科室的人讲还是有一定压力，不过由于大环境为推动，用户想看看实际使用情况如何，现场答应了找测试机来测试。所以是存在机会，原本以为浪费机会，却迎来新的转机，问题来了，测试机去哪里申请，本身分公司这边没有多余的设备做测试，那么就需要公司支持。此处省略，后面是有测试机去做测试，需要测试是因为客户对自己的需求也比较模糊，通过测试可以做落地，明确方向。测试过程也不容易，因为原有的业务是需要调整的，也就是说原先搭建的卡口业务系统的数据传输方式，需要调整，作为业务厂家肯定是不想自己变，要变你这边的厂家变就好了，不需要改动自己就更好。针对这个情况分析，要比较前后的业务传输差异，原先映射并不能检验到物理隔离效果，现有可以检验这个效果，也可以为后续其他业务作为一个论证的点，当然也要拿已有项目方案告诉用户，确保方案的可行性及合规性。合规性是用户考虑问题的点，所以我们经过分析后跟用户确认，当然不改变业务系统的数据传输方式也考虑过，也是可以执行，这个方案也会跟用户讲清楚，让用户去做判断。明确，那些事情是我们能做的，那些事情不能做很重要。修改业务系统数据传输方式是其他厂家的事情，需要用户去推动，而不是我们去推动，我们能做的事情就是客观分析需要。后面，用户去推动卡口厂家做改动，方案就执行。整个测试过程还有其他问题，此处不过多的讲了，当测试做完了，方案也执行并形成文档时，对用户来说需要以公开招标的方式，为自己招需要的产品，到了这一步就需要编写标书去投标。用户的招标书不可避免是有一定的倾向性的，因为测试完成后，用户就以测试方案做为参考，来做招标文件，这个倾向性是可以提高投标的分数，综合分数是有商务、技术资质的分数，价格也是很大占比，这里不多讨论。项目的发展也是很顺利。

2.3.2 多做点总是没错的
对于一个人技术的认可，往往会跟年龄挂钩的。所以在跟比较自己年长的人一起做事情，第一反应比较年长的集成商或者客户对你是不信任的。这份不信任从你第一次交谈就可以感受到。
当时我一家比较小的集成商公司，与公司合作的客户却是当地比较知名的大企业，这个大企业，收购了五星级酒店香格里拉酒店，由于这家酒店年代也比较久，用户收购回来是为了把它拆了，重新构建其他酒店。用户把香格里拉酒店根据大楼重新构建，主楼作为一个所酒店，副楼作为另一所酒店。酒店内部进行改造，这个改造就包括网络改造，我们合作就是网络改造。公司委派我一个90后的小伙子去与客户、项目总包商交谈，年轻意味着资历不够，资历不够就会形成不信任。用户总体设想就是副楼的网络重建，主楼用原有网络，网络设备继续保留。第一次谈这个事情，总包商请来一名运维专家主持，这个过程也谈论一个多小时，我也提出自身的看法，还有理由，不过用户及总包商没有采纳。因为楼层内部重建比较久，网络方案设计及讨论也谈论几次，不过始终还没有落地，毕竟总包商人员都是85前的人员，客户79年的都有，虽然对网络认识没多深，但是不是很信任一个90后的小伙子的见解，多次讨论后都没有结果。
项目出现转机，无论项目怎么谈，也是需要检查现有网络中设备运行情况。踏入原香格里拉酒店的机房，机房的设计与运维都很有规范，看到设备就可以判断这个机房建设是有一定年龄。防火墙、ips、路由器采用cisco的，服务器是惠普的，这两者看来也很正常，网络交换机是北电，没听错，就是已经破产的加拿大公司北电。检查设备可用性就需要确定设备是否正常能使用，是谁来做呢？原本是客户来做，由于收购的问题，原有技术人员也流失了，现有技术人员对于现在所有设备不了解，，只有以前留下文档，，也不知道怎么处理，因为设备太久了，联系当时的承建公司也没联系上。当时做了个冒险的决定，就是由我来做检查判断，原因很简单，大家都不懂就找个没那么不懂的人去了解，我也觉得该接下这个活，做得好赢取信任感，做不好也就这样情况不会更糟糕。
对于北电设备处理，看到这种老古董也是我的荣幸。我讲下我处理思路，因为它也是交换机，所以交换机的基础功能也是有的，交流了解实际使用情况，明白产品功能，这是以网络基础知识概念作为测试的依据。第二部分，先从文档查看，悲剧的是只有登录的用户密码，没有留下其他资料，命令库只能去网上查看，虽然查找到，也做了记录，实际设备命令库也有很多差别，只能通过？这个命令还有自身对与语句意思的估计，透过这一系列的工作大概明白设备配置意思。下一步，命令测试，再现在接入设备做配置，测试命令配置是否与设想一致，多多尝试，同步并理解它的命令意思。根据所有设备均登录上去，获取配置后，根据配置信息，完善并画出网络拓扑图。拿着现有网络拓扑图初稿与客户及总包商交谈，验证理解是否正确，现状调研完成，这个也赢取了客户及总包商人员的信任，觉得我在网络上应该是个专家，能解决问题。
多做点分外事情，可以给推动项目向有利于自己方向发展，后面根据用户的需求划分一个网络拓扑图作为项目参考，因为新的酒店加入洲际集团，所以要参考他们的管理标准，中间协商与讨论就不过多讲也遇到各种奇葩问题，不过结果是好的，大体方案是参考我做的拓扑。补充一下，这个项目比较特殊，特殊在我入场时，这个项目已经进行了，网络方面只是这个大项目中的一小块，所以没有开标的情况，只是补充采购合同。

2.3.3 有心有意未必成
主动点是应该，但是有时候你也会发现，看似客户有心有意配合我们在做事情，想推进项目，可是项目关键点的时候，客户就不想推进，而是想回归项目初期再重新测试产品，需求挖掘。
这个项目测试是遇到的是xx医院，信息科室的事情。前期，销售电话约见，谈论了公司，谈论了需求，需求谈论，以项目谈，谈在做了医疗对应的项目，如医院内部云数据备份方案、防统方、lis系统运维、医院内部终端管控等等，以实际案例作为切入，引导用户，产生共鸣。案例谈完后，回归等级保护，用户已经完成等级保护，测评通过了。但是内部lis、his、影像系统的设备运维，设备运维产品已经有，只是暂时未满足用户的预期。深入交流过后，该部门领导是管理硬件产品，与之对应是软件部门，软件部门与业务系统挂钩，到但是设备操作，系统登录却需要硬件部门的人员点头。因为用户购买运维管控产品可以提供审批，但是不能提供多级审批。也就会出现这个情况，业务系统厂家开发系统，需要登录需要设备或者系统，这个需要硬件部门授权，但是硬件部门不知道他的行为是否是软件部门需要的。所以线下需要咨询软件部门后，确认过后，再给其做审批。这个过程涉及人员多，而且硬件部门与软件部门每天都有很多事情需要处理，线下交流再处理，效率低下，存在软件部门很久才应答，应答完后，硬件部门很久才审批授权，这样造成时间上浪费。
经过分析，这个项目可以以用户真实的需求做为动机，产品功能推进。第一次是口头交流，用户对我们信任度也不是很高。所以后续，再补充一次产品介绍，外加产品功能演示，明确用户是否存在其他需求点。PPT宣讲，非常常规，以致于客户没太大兴趣，毕竟他已经在使用运维审计产品，大致上产品功能均了解。所以快速进入产品演示功能，演示是通过teamview回到公司网络，在公司事先搭建的环境中演示。这个环境，在公司事前就做了操作配置，围绕演示过后，用户是提出很多疑惑点，现场互有交流。不过，演示的环境与用户的现场环境还是会存在差异，所以需要更进一步，申请测试机，将部分业务的运维审计工作切换至测试机，这样可以更换切合实际情况。项目进展一步一步有条不紊的进行着，向公司申请测试机也通过。测试机，在现场部署，完成基本的部署及操作，后面大致上跟用户同步操作及配置，这里不适合把事情做得太细，因为用户关注点及实际应用情况我们不熟悉，用户对设备不熟悉，所以大致部署完成后，拉到微信群中，互相交流沟通，遇到操作不明白的也可以响应解决。测试机部署操作后，用户也测试不不少功能，过完两周后，大体的功能也配置完成，这个时候销售与技术一起去了解用户需求完成情况，其实是想着推进项目执行下一步。不过，用户又提出新的问题，新的问题也一一解答，可以变通功能处理新需求点，如离线审批，用户想着移动APP审批，这个新功能暂时没有，但是我们有短信离线审批功能也可以达到类似效果，不过用户立场比较强硬，不想退让。还有几个小问题，这里就不举出。我们正视这些问题，把用户需求点及产品测试结果，一一罗列出来，形成测试报告，给用户确认，确认的目的是控制需求点，这些工作做完了，用户也确认了，对于不满足需要协调产品部与用户的需求点，这个我们是采取先满足痛点需求，至于其他需求辅助需求，可以优化的策略，目的是想尽快进入项目下一步环节，推力始终是不够。该项目一直处于这个不温不火状态，经过反思分析，技术层面上的能做的事情都做，可能是其他层面上的工作没做好，这就需要销售通过其他渠道去了解下，当时也没了解原因，项目就暂时搁置。
2.3.4 总结对比
个人举的三个案例，是从无意做售前到有意推进项目售前工作，从无心插柳到有心有意推进项目，不过售前的工作一部分是技术本身推进，一部分还是需要销售的客情关系能否做到位，两者必不可少。如果想从事售前工作，就必须具备推动项目热情，给项目提供必须的动机，也要时刻分析，为推进提供必须的动力，这个动力是指技术层面上的。
3 售后
售后工作，本人接触到的售后工作主要是项目实施，运维方面主要是甲方人员执行，甲方运维人员与项目交接也是项目实施需要去考虑，正如售前到项目实施也是一个项目交接过程。项目作为公司与客户之间的纽带，前期售前工作推进，方案及招标文件落地，合同签订，提供项目目标的指引，已经做这个项目依据。项目落地完成时间，从公司层面希望越快越好，节约人力的成本，成本回收比较快 。对于客户来说就不是，对于我们来说可能是一个项目，对于客户内部来说可能是今年的大项目中的一个小环节，关系到后面执行。这里补充一下，项目完成速度快，对客户是有好处，但有的时候，可以会觉得自己花费与得到不成正比，因为存在这种心理的可能，所以对用户期望把握就很重要。
3.1 公司
项目实施中，一个成熟的项目型公司可以提供很多帮助，比如文档、项目流程等等。一个成熟项目型公司，无论它是集成商还是厂家，它做过项目居多，每次项目都会留下必要文档，这些文档对于后续的项目优化，项目流程执行提供指引。在公司，多去浏览公司项目文档很有好处，你会了解一个项目整个执行的过程，当然一开始不懂是正常的，但是可以将为现有项目提供指引，模仿开始，一步步模仿，直到项目做完，这样就不会有做项目的迷茫感，不知道下一步做什么。公司的项目文档，可以提供一个文档的规范性，这个规范性，方便你与他人做了沟通，他人读取你的项目文档，有这个规范性，他就明白如何去获取他想知道的知识。
公司项目资料可以提供指引，提高项目实施效率，项目落地还是需要个人去实现功能，满足客户需要。项目实施对于个人而言，需要了解产品功能实现方式，那么怎么去做呢？这里集成商及厂家是要分开讲的。
你在集成商做技术工程师，那么你对产品功能实现可以通过以下几种方式，1、大品牌厂商，他的技术文档在官网都会有；2、集成商与厂家存在代理关系，可以从上游公司的技术人员获取产品操作手册；3、技术论坛，像51cto、it中国、csdn、鸿鹄论坛、不同厂家所在论坛等。集成商代理产品往往比较成熟，所以对应我的操作手册及配置案例，已经有人去编写。你已经获取到的产品资料后，第二步就要去验证。为什么要做验证，是因为有的操作文档的分享，其实分享者都没验证，从其他地方拿过来想赚取论坛上的积分。产品的版本也是部分原因，不同版本对相同功能的配置步骤是不一样的。这个验证过程，需要的是实在的环境，一是在用户现场磨刀这是不推荐的，但是对于公司来说这样成本低；二是在公司内部，搭建一个类型的环境，技术一步步的去操作这样提高技术的操作能力。三是通过厂家给的模拟器，通过模拟器去做操作，这个是折中方案，但是存在弊端是模拟器有的功能不能模拟，靠硬件支持的功能是不能通过模拟器去模拟出来的。建议每个人操作后，把操作手册做一次修改，这样才能把别人的东西转化成自己的，但是往往技术工程师觉得这个步骤浪费时间。
在厂家做技术工程师与集成商是有差别的，他对于成熟的产品可以从公司内部同事拿到操作手册已经有人编写完成，落地过项目。对于不成熟的产品（概念性产品已经有雏形），产品处于完善阶段呢？这个就需要技术工程师根据产品部对产品的设计概念，编写出一份大概的操作手册。这份操作手册的设计思路是这样的，从售前的功能介绍定好大纲，大纲完成后，下一步就要开始分解，分解的依据从产品的界面开始，然后一步步的验证。验证完每个功能后，技术工程师才开始以项目整合的思想去编写操作手册，而不是功能描述的手册。这样对产品功能实现落地有大体框架，才能去实施项目。
功能知道如何实现，这就需要结合对应售前文档做项目规划，产品到周期、实施环境、功能实现、测试依据等可以做为项目计划中的一部分，不建议太过细化，这有容错空间，因为往往签署的合同中，对于用户需求没有十分明确界定，主要来源与对于用户业务需要存在模糊地方。
3.2 客户
公司与客户的项目实施，对客户来说很重要，往往期望与需求边界比较模糊的项目工作量异常高。控制客户对项目期望就变得很重要，这就要需要对招标文件、需求方案、签署合同、测试报告等文件解读及落实。这些文件需要有用户认可，也就是用户在上面签署他的大名，才能做为依据，当用户需求改变，超越了原有合同内容时，需要重新商议，项目的目标改变了，工作量需要重新评估。有了界定的依据，用户可以考虑做与不做，不做就按原有计划进行。做的话，另外收不收费是一回事，需要让客户明白，我们做的工作内容，这种服务是有界限的。正常有一种花费一定量费用，购买更多服务的期望，控制住这个期望是需要打压。

3.3 项目实施案例
3.3.1 初来乍到
刚毕业那会，对于社会与工作不是很了解。难得进来家IT公司，从事项目路途就此开始。年轻刚毕业，一人在广州这个城市，所以对出差也不反感，没想到没毕业就开始出差，做项目实施的工作。因为没有太多工作经验，从学校学习来的只有关于技术的原理，对于项目是十分陌生，也不懂得如何去规划。幸好有领导，实施项目自然比较慢，不过自我感觉良好。第一次的项目实施印象深刻，可能碰到钉子太多了，一碰到问题就开始懵了，脑子不知道如何下手，多问多想，慢慢地事情就做好了。
吃亏是福，经验是从经历中提炼出来的。在用户业务方面，平安城市电警业务、卡口、视频分析平台、GPS平台业务展示、协作交通办案等业务有所了解，天天跟不同厂家泡在一起，听多看多自然就了解，而且数据、视频交换均要经过我这边的产品，所以需要分析其业务数据传输，协商这个传输方式，促使数据传输的合规性。数据与视频平台问题不少，我就分享个具体问题。
数据平台问题，数据量大、文件个数过多，一开始我也清楚怎么回事，主要是用户查看业务系统后，只能查到前天，而起发现时间越久，能查询的数据就更远。我只是把现象总结一下，反馈给公司其他人员，希望利用他们的经验帮我解决。后面，产品部的研发与做对接，我将信息反馈给他，他做判断，他的判断由我在现场配置做验证。这样反反复复，慢慢也学会了验证的手段，其实是因为产品底层是Linux，熟悉Linux查询命令就可以配合着查看原因。判断结果，数据量过大导致内存使用率过高，需要增加内存；文件个数太多，设备的并发数难以支撑，解决方案1、更换设备；2、前端文件大量压缩，再到内网解压；这两个问题及解决方案，告诉用户让用户做判断，后面也执行了。压缩与解压通过脚本来执行，内存增加就去购买。其实还有很多问题，不过不多做讨论，总结大部分的工作其实都在交流与验证，因为工作经验不足，无法自己判断并做验证，但是经过学习后，也开始会去查资料、验证想法，但这个阶段还没意识到控制项目沟通的重要性，只是出于项目实施初级阶段，发现问题就找资源处理，因为意识到处理问题需要所以从这方面开始提升自己。

3.3.2 未知边界
经过一段时间的项目实施，实施遇到问题越来越多，但是相对处理起来越是得心应手。面对项目情况比较简单的情况下，用户自己对需求很明确，关联业务系统比较少的情况下，不做计划，不明确项目边界，专心于处理项目中问题就比较简单，但是在比较大型的项目中，由于项目业务繁多，项目情况比较复杂，这个情况在签署合同时有事先定义好边界，项目执行中以合同条款为基础，规划项目并实施项目就很合理。不过这都是事后诸葛亮，这里分享的项目是一个占地面积一万四千多平的复合型大商场，商场基建外，其他由总包承包，总包对网络是不了解，对于视频、BA、门禁是比较熟悉。用户有自建POS系统，WIFI系统由移动承包，所有的有线网络均为我们公司承建。
信心满满，一顿打脸。按以前项目经验做事，设备到了，环境具备供电，布线到位就出发上门实施项目。刚到用户现场，除了机房装修得像样，其他地方均是水泥墙，不熟悉的人进去都分不清那跟那。由于设备数量比较多，事先将大体应用分类，办公网、智能楼宇网、POS网、无线网络。总包对于每个楼层设备部署有CAD图纸，实施前在现场规划好管理IP网段，准备好配置脚本，一台台设备分批配置管理。设备上架后，测试网络连通性，楼层与汇聚原有设计是光口，由于线路有的光纤有限，设备调整，有部分设备又需要配置成电口，带着电脑跑电井。网络环路，启用MSTP，优化线路，把某些端口优化配置。当然还有弱电问题，线路过长，信号衰减严重等等问题。只关注自身网络问题处理，花费了两周时间，看似基础的配置，需要优化地方很多。当然，如此大的网络，方案提供管控平台，部署完管控平台，将已知上线的设备监控，未在线设备，后续配置补充。
业务接入，各种问题产生开始了，由于没有界定边界，所以产生问题就会互相推卸责任。帮助总包处理问题，界定问题就异常重要，因为你帮裁判分析并界定问题归属，裁判的判决会倾向你。不过，这个分析过程比较客观。举例，视频平台采用海康威视，开始视频流都到视频平台。一次断电后，突然大面积的视频流你看不到，是网络的问题，还是视频枪的问题导致的呢？主要问题是强电，不断电不就不会出现问题，总包不会这样想的。这个时候，需要客观的分析并判断断电导致什么问题。在拓扑图上，找出问题视频枪，从设备再到链路，最后到终端，一步步测试连通性。你确定完连通性后，再去拆视频枪，发现问题，视频枪配置IP配置没有保存，问题界定完成后，还需出方案简化总包的工作量，交换机关闭端口，一个个开放，这样视频枪就可以在机房远程配置。还有其他业务系统，大体思路跟上面是一样的。这里要记住整个排查过程，找总包的人跟着你，一方面做事有根据，另一方面需要协调其他厂商的人员时，总包的话有份量，完成排查后，形成文档，给总包的人员。

3.3.3 站在巨人肩上
正常的思路是遇到问题才去学习，有切身之痛才会认真的学习。做的项目多了，多去拜读项目管理的书籍，我个人也去考了PMP，不建议你刚入行就去考这些证书。很多证书认证，确保你有这个技能，需要有实际环境做磨合，才使证书变得有价值。网络安全从业者可以学习下CISP/CISSP书籍，想了解这种思想，看看是否与工作匹配再去认证。站在巨人肩上，除了自己项目管理学习外，公司项目实施文档也可以提供更符合实际的操作，有的时候公司没有就只能靠个人做完项目总结积累。
基于管理体系来说，实施项目前，需要查看招标文件，售前方案，合同书，明确项目目标，方面计划。如果没有文档指明，还有其他方法，先与用户再次交流，先达成口头协议，可以情况下文本声明，明确本次项目实施的目标，这个过程是很有必要，对于你实施项目界定工作内容很有帮助，对于用户，他会觉得你是专业的。项目目标明确后，就是分解工作，分解工作的依据，是项目合同，项目清单，项目方案及项目需求。公司有实施过类似的案例就更好，直接套用，往往比较少。分解项目工作，估算工作时间，将情况罗列成一个excel表。完成这些工作后，再去分析可能的风险。
这里分享一个案例，实施一个企业的机房，提供给客户两台服务器、一台备份设备、一台共享存储、一台防火墙、一台上网行为管理、多个防毒墙安装点。由于前期工作是其他同事做的，现在实施由我接手，看完合同及投标文件，我也没找项目建设目标。我通过与销售了解到，用户原有机房设备比较陈旧，所以这次机房设备基本属于重购。了解原先业务情况就变得很有必要，所以约了客户了解原有业务情况，并在大体上新机房设备应用规划上达成共识，比如上网控制员工只能用钉钉、原有服务器虚拟成虚拟机迁移等。根据交流情况，我明确项目目标就是新旧机房业务接替，以原有机房业务使用情况作为依据，调整设备功能。从直接影响业务的网关设备及服务器群做起，大至分解出来，大部分工作内容及时间估算，以公司项目实施文档为参考完成。项目后续实施，也会遇到很多问题，大的问题有界定责任，小的问题，找同事支持。

3.3.4 总结对比
三个案例，大致的情况是从混乱迷茫到开始有条不紊的做计划，慢慢执行。项目因为它的临时性与独特性，在实施上碰到问题会不一样，每次完成项目后，都去总结项目过程，慢慢碰到钉子就会变少，当你意识的问题并处理了，下次可以以相同方式解决问题，效率就会提高。

4 结语
本文章以个人经历编写的，存在一定的偶然性与片面性。我从个人观点出发讨论技术工程师需要面对问题以及处理。因为每个人经历不一样，资历不一样，看问题点也不一样，我也相信应该有更好的理解或者更独特角度解读，欢迎一起交谈。