IT售前人员如何写解决方案

您可以参考如下步骤进行：

1．需求分析

1．1．功能需求

1．2．性能需求

1．3．其他需求

2．网站目的及定位

2．1．建站目的

2．2．网站定位

3．网站设计

3．1．网站内容规划

3．2．建站内容及特性

4．网页设计

5．首页设计

5．1．导航设计

5．2．功能板块设计

5．3．商品搜索板块设计

5．4．商品分类板块设计

5．5．商品预览板块设计

5．6．动态新闻板块设计

5．7．热门搜索关键字

5．8．友情链接

5．9．客服

5．10．页脚

5．11．首页页面布局图

6．数据库的设计与建立

7．网站技术解决方案

7．1．技术方案

7．1．1．网页开发技术实施

7．2．网站安全性措施，防黑、防病毒方案

7．2．1．局域网安全措施

7．2．2．Internet互连安全措施

7．3．防火墙技术

7．4．反病毒技术

7．5．数据安全措施

7．6．技术支持和培训

7．6．1．技术支持

7．6．2．培训

8．网站维护

8．1．系统维护

8．2．数据维护

8．3．网页维护

8．4．其他

8．5．维护方案

9．网站测试

9．1．网站功能测试

9．2．网站性能测试

9．3．网站安全性测试

9．4．网站稳定性测试

9．5．浏览器兼容性测试

9．6．可用性/易用性测试

9．7．链接测试

9．8．代码合法性测试

9．9．程序代码合法性检查

9．10．显示代码合法性检查

9．11．测试工具

10．网站发布与推广

11．网站建设日程表

一般包含如下内容:

一确定网站的整体目标定位和市场定位；

1、相关行业的市场是怎样的,市场有什么样的特点，是否能够在互联网上开展公司业务。

2、市场主要竞争者分析，竞争对手上网情况及其网站规划、功能作用。

3、公司自身条件分析、公司概况、市场优势，可以利用网站提升哪些竞争力等等

二根据自身的需求和建站目的来配置自己的软硬件环境；

三网站的开发；

1、进行美术设计，创意网站风格进入网站整体排版规划；

2、数据库的功能设计

3、网站所要实现的主要功能：

①网站新闻发布系统（信息发布系统）是将网页上的某些需要经常变动的信息，类似新闻、新产品发布和业界动态等更新信息集中管理，并通过信息的某些共性进行分类，最后系统化、标准化发布到网站上的一种网站应用程序。网站信息通过一个 *** 作简单的界面加入数据库，然后通过已有的网页模板格式与审核流程发布到网站上。

②产品展示发布系统是将网页上的新闻、新产品发布和业界动态等更新信息进行集中管理，分类别系统化、标准化的发布到网站上的一种网站应用程序。前台用户可通过页面浏览查询，后台管理可以管理产品价格、简介、样图等多类信息。

③会员管理系统浏览者在线填写注册表，经系统审核后实时成为网站全员，页面填加登录验证功能，前台会员可自行维护个人注册信息，可对个人注册信息进行修改和删除，如遗忘密码可在线查询密码，后台设置会员管理界面，管理员可对会员信息进行分类查询（日期、姓名）、删除。

④留言板(在线答疑)供了一个公共的信息发布平台，适用于作为企业内部个人办公助手以及企业与企业之间进行信息交流；在线解决某些客户需求。

⑤BBSBBS（论坛系统）是网站中信息多、人气旺的地方，好的BBS可以吸引相当数量的访客，同时也担负着网站对外宣传、发布消息、收集客户反馈的重任，是网站、单位内联网必不可少的一部分。

⑥邮件列表使客户在其网站上建立邮件订阅功能，可以按照需求随时向订阅者发送新闻、杂志、公告等信息。并且能够提供管理界面有效地管理大量的邮件列表用户。

⑦广告订单广告订单系统是网站与其它网站建立合作关系所不可或缺的工具。主要用于接受客户的广告订单，投播客户的广告Banner、友情链接，并进行管理和统计。

⑧在线调查在线调查系统就是在网络上完成对某个（些）问题的调查，并且统计调查结果。适用于利用Internet,Intranet开展各种调查的用户。

⑨访问统计报告（计数器）对网站访问者的情况进行统计，有利于网站建设者掌握网站受欢迎的情况，及时调整网站信息及功能。以上所述功能均属现在主流网站基本功能，大部分程序源代码公开。

四网站维护

1、服务器及相关软硬件的维护，对可能出现的问题进行评估，制定响应时间。2、内容的更新、调整等。

3、制定相关网站维护的规定，将网站维护制度化、规范化。

五本人的一些介意与想法

1、将网站定义为一个以技术和产品定位的IT产品资讯网站，不要光顾把一些自己代理产品作为网站主打内容

2、将网站作的有自己的特色，比如：可在网站上做个“在线装机”栏等。

总结就是对一个时期的学习、工作或其完成情况进行一次全面系统的回顾和分析的书面材料，它有助于我们寻找工作和事物发展的规律，从而掌握并运用这些规律，为此要我们写一份总结。总结怎么写才不会千篇一律呢？以下是我收集整理的IT技术工作总结，仅供参考，欢迎大家阅读。

回顾20xx年，自己干了很多工作，涉及到的范围比较广，所做的工作带来的成果也不错，告别了20xx年的那种没有自信，总是被动的局面；业务上对发信息，资料，boss相关，语音这几个核心的业务模块更加熟悉；组织协调能力上得到提高，整体把握一块儿工作的进度，承受得住压力的能力逐步提升。工作方式上有所改善，由被动变成主动，由接收变成主动提出自己见解；知识体系得到补充完善，眼界由局部上升到更高一个层面，找到自己要发展的方向，阅读管理类和技术类的书籍给自己充电加油！20xx年，我在期待，期待更大的进步，期待更多更强的成就感。

一、主要工作业绩

（一）工作职责、主要工作及成果

1、hbjxt发信息系统、河北后台搭建移植

工作职责：部门模块参与人

hbjxt系统搭建过程中前期我主要负责的是发信息模块，后期转到新后台的搭建移植工作上。

a、发信息存储过程的移植

b、0元3元产品的并行

c、信息回执的添加

d、学校相关查询，用户相关查询，教师相关查询，信息相关查询功能移植

e、河北应用报表开发

在这个工作的过程中我最大的收获是对数据库简单知识的掌握和发信息相关业务的熟悉。以前对数据库的学习就到书写sql语句的层面上，目前对存储过程，函数，调度，触发器，表分区等常用的简单知识有了使用和了解。对于核心业务发信息也告别了一头雾水。

2、语音平台接手，为解决串号问题的改造

工作职责：平台负责人

a、日常的维护统计

b、语音新需求的开发

c、语音优化建议的处理

d、语音串号问题的

在语音web页面方面要发展成一个能提出自己见解能拍板的员工，目前尚未完全达到这个目标，不过日常的维护和遇到的问题大部分可以跟踪解决。

3、长短信页面负责人

工作职责：页面负责人

a、学校长短信的设置和取消

b、家长长短息接收的管理

c、老师长短息的设置选择

d、发信息类里面对于设置长信息和文件发送等逻辑的修改。

长短信的主要负责方是数据库组，中间组织了几次会议，都是权威人物，从大家的发言角度和发言内容里可以学到好多东西，先是需求的讨论确定，开发方案提出几种，大家一起讨论，最后让领导审核，每一次的会议组织都会有新的收获。是一次很好的推进工作案例。

4、新版短信模板

工作职责：部分模块参与人

a、发信息页面的改版

b、信息收藏夹的导入导出

c、jxlx下总导航和左边登陆框的调整。

我参与的阶段有：用例的审核，表结构设计的讨论，开发。

在这个工作中的收获是数据库表的设计，主要是按位存储的优点，合理的利用存储过程来定时的分析和生成数据，excel表格的上传下载相关知识。

5、语音外呼系统

工作职责：整体负责人

a、组织需求的讨论确定原型

b、拿出设计方案组织审核

c、参与后续开发

d、系统的跟踪和维护

这是我第一次以项目负责人的身份在公司出现，感觉很惊喜，也很有压力，一直都是在接收安排好的工作，这次领导告诉我，我要把握项目的进度，要去和需求人沟通给系统一个合适的定位，把合适的工作分给合适的人，要设计能满足需求，要保证项目保质保量的完成。当然这些工作我一个人是做不下来的，一是我经验不够，二是我一个人没有那么多的时间和精力，这时候就体现出来如何利用大家的智慧了。这个团队的一个特点是一个没有经验的负责人带着几个充满智慧的队友，刚开始在工作分配上很不合理，我把很多的工作揽到自己这里，但是这样我会很累，大家的智慧不能及时的融进来，还会打击积极性，在主管的指导下及时对工作安排分工进行了调整，让大家都积极的参与进来。有了前面的教训，在后期的开发中进展的很顺利，大家积极的讨论拿方案，对自己负责模块都尽职尽责，从中收获很多。

语音外呼项目的推动中，收获可以从两个方面来总结，一个是经验的积累，通过这个工作，经历了一个项目负责人的过程，此时经历就是收获，设计方案的一次次被推翻，就是一次次的进步，从沟通到设计再到开发，去组织去推动，也逐步的流畅，和大家的合作，借用别人智慧的能力也稍有提高。另一个是信心的增强，刚开始对需求的混乱和对系统不清晰的定位让我对这个工作无从下手，对它的思考时易时难，对设计更是心里没底儿，设计好了对开发又不自信，需要的知识点还很多，虽然前期是这样思考的，但是随着设计的明朗化和大家智慧的迸发，感觉越来越顺利，信心提高了很多。所以一个项目负责人不一定要是一个样样精通的人，但是一定要是一个能把大家智慧凝聚到一起的有思想有自信的人。以后我继续向大家学习！

6、资料迁移

工作职责：整体负责人

a、收集需求人，使用人的意见整理文档，弄清楚要解决的问题，和造成问题的原因

b、给参与人员分工梳理现有流程

c、组织技术内部对此熟悉的同事讨论，铲出一份需求设计文档，之后又进行审核

d、和需求人，使用人碰面沟通，对设计文档中涉及的流程进行了二次审核

e、页面开发和测试

f、功能模块维护和数据跟踪

带来的成果：在移动进行大规模的ecid重整时期，资料迁移功能发挥了很重要的作用，解决了博客博客圈的匹配，校讯通积分影响问题，客服的资料处理流程效率也得到了大大的提高。

资料迁移整体上考验的是对业务的熟悉和对需求的梳理沟通。我的总结感受：对于请教的问题，别人并没有责任一定要参与，即使参与了也不能把自己的疑惑全部抛给大家，应该做好前备工作，把能梳理的都梳理通，真正想不通的给几个选项，尽可能的节省大家时间，缩短这个环节在整体上大家就有精力给与更多的指导和建议。另外还要写好文档，一份好的文档可以给沟通带来好的影响，如果自己都稀里糊涂文档的逻辑性不强，让别人看着更不感兴趣，虽然沟通是双方的，但是如果想在沟通中掌握主动权，必须比别人多想点，多做点。

7、资料录入助手

工作职责：整体负责人（但是到最后没有用）

a、沟通确定需求

b、参与代码书写以及后期意见搜集

资料录入给我感触很大，我面对的问题有两个：一是自己对技术水平不达标，书到用书方恨少啊，打击了自信；二是时间比较紧急，还和几个经理直接沟通需求，有恐惧心理，状态相当不好；到最后还是按时完成了，虽然让大家并不是特别满意，在没有征求对方意见的情况下我自己简化了需求，但是感悟甚多；我的感悟：一是要增加自己的求知欲，提高技术水平，增强自信心；二是要学从大局考虑事情，多项紧急工作并行的时候也要有个轻重缓急，做好分配；三是会做人会做事会说话很重要。

8、学生综合素质测评系统

工作职责：整体负责人

a、参与需求的讨论和原型确定

b、系统的设计

c、组织并参与开发

该系统的特点：使用对象是一个学校，核心内容是对学生进行综合素质的评价，项目时间和紧迫，所以选择了一切从简，组织结构和权限使用的都是校讯通系统内的，老师管理员的账号使用的也是xxt的，家长的账号是学生的学号。

9、日常维护，优化建议

工作职责：模块参与人

a、语音平台，hbjxt有关信息的数据统计工作以及日常投诉维护

b、有关语音，tj平台，短信后台，策划后台，hbjxt后台的优化，报表新功能，30tomcat错误日志等的维护开发

c、需求的沟通和讨论

（二）工作及学习经验及收获

1、对发信息，资料，boss相关，语音这几个核心的基础业务模块更加熟悉，这些都是在工作中进行的积累，这些方面出现问题，可以更快更准确的定位出错的地方。

2、组织协调能力提高，这些是担当项目负责人锻炼的结果，平时负责的工作不再是具体的开发，而是负责把大家召集起来，整体把握一个事情的进度，这样的话就在无形中锻炼组织协调的能力，承受得住压力。

3、看了一些管理类的书籍，在做人做事儿做工作的方式上有所提升，不让自己的想法行为那么极端。

4、技术知识框架更加完善，毕竟看的多了，遇到的问题多了，思考的也就多了，逐步提升中……

（三）主动发现并跟进解决的问题（非任务类的，自己主动发现工作或项目中的问题，并思考和跟进解决的）

1、资料迁移上线后，关于sign_falg的变更，在走路的时候突然意识到迁移之后发给移动的sign_falg和connector中的没有同步，虽然当时问题还没有暴露，时间久了就会出现问题了，马上给领导请示让数据库组协助我排查数据，最后通过全量核对把已经不一致的资料纠正，同时修改程序的漏洞。

2、100数据库存储过程proc_person_count有效学生数，禁用学生数，有效班级数的计算错误，修改上传！

此过程是在20xx年12月18日开始运行，每天晚上00：00执行，作用是计算有效学生数，所有学生数，家长总数，教师总数，拥有联通号码的教师总数等一些数据，数据是以学校为单位

发现的问题：有效学生数，禁用学生数，有效班级数的计算错误

错误原因：河北的规则和河南的差异所致！

河南：有效学生：第一联系人激活的

禁用学生：第一联系人禁用的

有效班级：有有效学生的

河北：有效学生：两个联系人至少有一个激活的（排除网站用户）

禁用学生：至少一个禁用的，两个联系人不存在激活的（排除网站用户）

有效班级：和河南一致，但是有效学生统计错了，这个也就错了

3、100数据库存储过程proc_num_of_class执行报错！因为调度的问题引起，另外计算数据规则有问题！

此过程是在20xx年12月18日开始运行，每天晚上00：00执行，作用是计算有效学生数，所有学生数，家长总数数据，数据是以班级为单位

发现的问题：存储过程执行报错！计算数据规则有问题！问题同上！

错误原因：存储过程中定义了一个临时变量num1，number（2）类型！但是执行的时候存进去的数据是三位数，故报错！存储过程中用这个变量是判断当天的数据时候已经存进num_of_class表中，按照正常情况num1是0才对，不会报错，跟踪原因是因为proc_num_of_class一天执行了两次，晚上00：00和中午12：00，当中午12：00执行的时候数据已经生成，并且数据超过了number（2）所容纳的最大值！故报错！

至于为什么这个过程一天执行两次，请教数据库组同事未果，因为从调度语句上看频率是一天，每晚00：00执行！

解决办法：原调度删除，重新添加调度！执行时间放在00：01

4、个人话务量统计跟踪数据时候发现异常，一个人的话务量比所有人加一起都高

排查生成个人话务量统计的sql语句，在语音重要的表中加看个call_id，把电话的保存表和通话表精确的关联起来了。上线以前所有的数据此字段都是0，目前外呼的此字段值也是0，所有要把等于0的全排出掉！防止异常数据！

（四）进步及亮点（主要的2—3个）

1、对业务的熟练，当做的东西需要和系统内融合借鉴的时候，这个优点显得尤为重要。对做好工作更有把握，更有自信

这点的进步源于工作中对业务逻辑的梳理和积累。有些新工作的开展必须把现有的业务逻辑梳理清楚。

2、组织协调能力提高，整体把握一块儿工作的进度，承受得住压力的能力逐步提升。

这点的进步源于当了几次项目负责人。不管项目大小，是负责人就要负责工作的安排，人员的协调。

3、做人做事儿做工作的方式上有所改变，不让自己的想法行为那么极端。

有效的沟通往往能更快的推动工作，有效就要求是合理的沟通方式，大家都喜欢听好听的，都喜欢愉快的沟通氛围，就要尽量的去营造这种氛围，减少撕破脸的场合，看了一些管理类的书籍，有些还是很有道理的，可以逐步的在和别人沟通中派上用场。

二、工作中遇到的问题或困惑及解决办法

工作中由于大组的工作方向而定，如果一个月里很多时候都是在排查，配合的工作，这些很繁琐，没有什么技术含量但是需要全面细心，如果接二连三的都是类似的就很疲惫烦躁，困惑。

解决办法：加强学习，多看些书充充电，让自己能感觉到还在进步，不是在机械重复的工作，月度绩效中会流露出我的想法，让领导了解。

三、对公司、部门、小组的建议

希望部门能在大组的整体工作上可以均衡，让人员和工作量可以协调，不至于有的太忙没有时间学习，有的太闲只能学习，总结一下主要是以下几点：

1、多少人干多少的活。

2、工作的技术含量上均衡一下，干维护如果一直查漏补缺，会烦躁

3、部门需要重视基础业务和维护

1解决方案难写在哪里？很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。作为一个公认的方案打手，意思是写方案就象打字员一样。 因为你不敢让你的同事知道你只能用很少的一点时间写方案，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。写方案不难，知道怎么写才难。有结构就有思路，有思路就有方案。另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。基本上原因可以归为四类：11 第一种是没有体系一旦用户要求提供关于PDM的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。因为这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。12 第二种是没有思路有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就速手无策了。这种情况从根本上讲还是写方案者不熟悉企业业务造成的，写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。所以一个人要写好方案，还需要了解下游客户的业务，了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户关注重难点问题，自然可以比较好的确定方案的个性化内容思路。解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。13 第三种是没有素材一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。14 第四种是没有层次很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。结果拍胸脯容易，写方案难，自己写不出来只好求公司，公司没有安排专人了解情况，只好按模板制作一个，用户一看几个供应商内容都差不多，觉得不好，又总结出一些个性化要求，于是大家有开始折腾第二轮方案。其实方案编制在不同阶段有不同策略，不要轻易提供方案。刚开始接触是可以提供项目合作建议书，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。想急就又能解决问题的事情，本来就是一般人做不来的。方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。21 第一个容易犯的错误：只有论点，没有论证不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，有个金字塔式的写做原理，也就是说文章一定是有结构的。所以真正好的方案，不一定厚，但能看出你用心，你认真。现在的解决方案一个不好的倾向是"长、厚、全"，看起来面面俱到，其实对决策者没有帮助。所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。通观这个方案并没有研究为什么企业会产生这么多问题？问题是这些问题是什么产生的？为什么出这么多问题？而是不断说"我能！我能！选我，选我！"。如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。不好的解决方案最大的问题就象写一篇议论文，能够发现问题(这个也是模板化的，可惜中国企业大部分没有意识到自己很多问题并不少见，总以为自己是特殊的一类企业)，提出答案(搞信息化)，但没有论证(为什么搞信息化和企业管理进步有联系呢？)。没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。看到方案时候，其实很多用户下不决心，他会感觉每家都差不多。如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。但对内容认可程度并不高，实际上没看懂。22 第二个容易犯的错误：业务解决方案成为功能列表解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是4P销售人员，还缺少SPIN(顾问式)销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案了。)评论(0)

以上就是关于IT部门成立计划书全部的内容，包括:IT部门成立计划书、IT技术工作总结、IT售前人员如何写解决方案等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！