it项目组成员岗位职责共5篇.docx
《it项目组成员岗位职责共5篇.docx》由会员分享，可在线阅读，更多相关《it项目组成员岗位职责共5篇.docx（14页珍藏版）》请在冰豆网上搜索。
it项目组成员岗位职责共5篇
it项目组成员岗位职责（共5篇）
第1篇：
项目组成员岗位职责
项目组成员岗位职责
1.项目负责人岗位职责
⑴组织审前调查，编制审计方案，进行人员分工和任务分配；⑵起草并向被审计单位（人）下达审计通知书；
⑶按照批准的审计方案组织项目实施，指导、检查项目成员的工作，复核审计证据，综合审计工作底稿，保证审计质量；
⑷负责与被审计单位（人）及与审计事项有关的其他单位的协调与沟通；⑸起草审计报告，向处领导报告工作，重大项目向处业务会报告工作；⑹负责与被审计单位（人）进行交流，征求对审计报告征求意见稿的意见，对被审计单位（人）提出的意见进行复核，提出是否修改审计报告的建议，向处领导报告，重要事项向处业务会报告；
⑺向被审计单位（人）下达学校领导批准的审计报告；⑻检查审计结论和审计决定的落实情况；⑼对审计资料进行整理、归档。
2.项目组其他成员岗位职责
⑴协助项目负责人做好审前调查和审计方案的制订；
⑵对审计思路、审计方法及审计中遇到问题的处理提出意见和建议；
⑶按期完成分工范围内的审计事项，取得审计证据，编制工作底稿，保证工作质量，接受项目负责人和相关领导的复核和检查；⑷协助项目负责人起草审计报告；
⑸协助项目负责人做好与被审计单位（人）的交流和审计报告征求意见稿的修订；⑹做好审计资料的整理和归档工作；⑺完成项目负责人交办的其他工作。
第2篇：
编辑组成员岗位职责
1.熟练掌握目前所有的排版软件，包括Word200
7、photoshopCorelDRAW等；2.负责所选文章的排版、初次校对、编辑等工作，对本版内容能有宏观把握。
3.按时完成组长分派的任务，并要保证质量。
第3篇：
it项目经理岗位职责岗位职责
it项目经理岗位职责-岗位职责
一、IT项目经理岗位职责
1.负责制定IT部门年度计划，并监督计划的实施情况;2.规划公司数据分析系统并组织实施;3.负责对信息管理系统的日常维护及数据安全，建立并完善相应的管理体系;4.负责公司ERP系统、定制软件系统等业务系统的实施和维护;5.负责对公司人员进行相关计算机知识的培训;6.负责公司IT设备的档案归档工作，做到IT资源的合理调配利用;7.负责监督与考核本部门员工的工作情况，it项目经理岗位职责。
职位要求：
1.本科以上学历，计算机相关专业毕业;2.具有项目经验的;3.对网络、硬件、软件和系统具有比较全面的了解和认识，熟练操作ERP4.具有较强的业务分析和系统分析能力;5.深入理解网络安全的知识和工具，具有丰富的网络安全经验;6.良好的沟通技巧，高度的责任心及独立解决问题的能力;二、工程项目经理岗位职责
1、接受总经理的领导，管理整个工程部的员工，岗位职责《it项目
——文章来源网，仅供分享学习参考经理岗位职责》（https:
//unjs）。
2、制定本部门的组织机构和管理运行模式，使其操作快捷合理，并能有效地保障酒店设备、设施安全经济地运行和建筑、装潢的完好。
3、总结和归纳运行和维修实践、制定和审定设备、设施及建筑装潢的预防性维修计划、更新改造计划且督促执行，保证酒店设施不断完善，始终处于正常、完好状态。
4、制定和审定员工培训计划，定期对员工进行业务技能、服务意识、基本素质的培训。
5、全面负责工程部的节支运行、跟踪、控制所有水、电、煤等的消耗并严格控制维修费用，保证酒店最大限度的节能、节支。
6、根据营业情况和气候及市场能源价格情况，提出节能运行的计划和运行维修费用预算。
7、负责协调和酒店相关的市政工程等业务部门的关系，以获得良好的外部环境。
8、主持部门工作例会，协调班组工作。
9、分析工程项目报价单，重大项目应组织人员讨论并现场检查施工质量与进度，对完工的项目组织人员进行评估和验收。
10、配合安消部搞好消防、安全工作。
——文章来源网，仅供分享学习参考
第4篇：
IT项目经理岗位职责
软件开发管理体会
从毕业至今，大小的项目做了一些，有不少成功的喜悦，也有很多失败的教训。
今年由于工作需要，我以软件项目负责人的身份参加了接入网统一网管系统开发的整个过程。
从中学到了不少知识，有许多体会,想将自己的感受写出来，与大家共勉。
软件项目管理是一个庞大而复杂的系统工程，当前业界对于软件开发流程有不少规范和定义，如CMM和xxxx。
在该管理体系的管理下是可以开发出高质量的软件产品。
但是由于该体系较适合于大型而且复杂项目的团队开发，真正实施尚需要时间和过程。
而我们当前执行的项目，一般只有10个人左右，要实施软件工程难度更大。
我认为：
虽然项目大小不一，但管理方法是相通的，要做好软件开发工作，就必须加强有效管理。
大家知道，“软件危机”起源于一些大型项目的不断延迟甚至失败。
与大项目相比，小项目具有以下特点:
·项目功能相对较少；
·开发人员较少；
·开发周期较短。
小项目看起来比较简单，比较容易成功，人们往往容易忽视小项目的管理，其实这是一种误解。
据我了解，小项目开发中容易出现以下问题：
:
1、开发之前没有认真地进行项目可行性和工作量的估计。
往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差距。
2、没有真正的设计过程。
开发人员少，不同人员的程序之间交互、接口相对少一些。
开发周期短往往是几个人从头到尾负责一个项目，几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档来规范各自职责和项目细节。
这种做法潜在的危险之一是有人可能会对所讨论的接口、结构理解有偏差，可能会造成以后的返工。
另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按时完成分工任务后，才发现各个模块组合起来却无法形成一个完整的系统。
其根源在于没有一个负责协调的人员不断监控整个开发过程。
第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，难以理解以前别人做好的代码，又要从头做起。
另外，没有文档的程序，日后维护和版本升级都比较困难。
3、不经过单元测试而直接进入系统测试。
造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。
例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。
但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。
针对以上问题，我认为在开发过程中必须处理好四个关键问题，严格把关，可以大大提高软件的质量。
这四个关键问题为：
人员、规范、测试、时间控制。
一、合理配置人员
首先软件开发是一项长期艰苦的工作，所以一个团结、协作的团体才能在规定的时间内完成一个质量上乘的软件项目。
团队中的每个人必须积极融入到整个集体中，不能互相推诿，更不能互相埋怨和指责，正确的态度是大家在充分信任的基础上团结协作，互相帮助，主动承担任务,利用集体的智慧获得成功。
整个团队就是一部机器，只有每一个齿轮都能正常运作，才能生产出优质的产品。
合理配备人员是成功完成软件开发项目的切实保证。
所谓合理配备人员应包括按不同阶段适时运用人员，恰当掌握用人标准。
一般来说，软件项目不同阶段、不同层次技术人员的参与情况是不一样的。
图一是典型的软件开发人员参与情况与实际人员需求差异曲线图。
如人员配置不当，很容易造成人力资源的浪费，并延误工期。
特别是采用恒定人员配备方案时，在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情况。
为开发人员创造出一个人尽其才的环境也是项目成功的重要环节，让他们能得心应手的施展自己的才华，特别在工作安排上要煞费苦心，针对每个人不同的特长，根据项目的具体环境和条件来合理安排人员在恰当的岗位上。
项目负责人是一个团队的核心，其综合素质直接影响项目的成败。
合格的项目负责人具有高超的领导才能和强烈的科技意识和较强的业务处理能力；具有敏锐的洞察力，能瞄准目标，实事求是，精心组织，坚决果断，灵活应变，享有信誉；善于制定计划，解决问题，沟通信息；具有良好的市场意识和交际能力。
当然同时满足这些条件比较困难，但是他应该具有实现这些素质的条件，并注重经验的积累、素质的提高、能力的培养。
并能从以下几方面严格要求和培养自己：
以身作则：
只有身先士卒，各方面以身作则，才能得到广大开发人员的认可和信任，才能树立较高的威信。
果断抉择：
负责人的重要任务是决策，特别是有多种选择的情况下，一个正确的选择往往事半功倍。
善于交际：
他必须积极对外联络，充分利用外部资源，例如其他部门做过类似项目者，可以向他们取经甚至直接获得源码。
这对一个项目争取时间，避免重复工作很重要。
善于协调：
协调几个人的工作比自己完成一段编码更重要。
由于协调不力，将影响开发。
所以项目负责人除完成自己的编程任务外，必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。
善于制定计划：
在开发前，可将明确的开发任务通过文档传递给每个开发人员，让大家都熟悉设计模型，都清楚自己所做的工作在整个系统中处于什么地位，这样有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。
沟通问题：
团队沟通不是技术问题，但却是一个最能影响工作效率的问题。
沟通及时、集思广益、步调一致，才能取得胜利。
二、严格执行软件开发规范
软件开发需要严格按照软件规范实施。
用手工作坊式的方式来开发软件，其结果必然失败。
从项目的用户需求分析、系统分析、编码、调试、测试、发布都需要一步一步完成，不能轻视或忽略任何一步骤。
前部分没有完成好，不要贸然进行下一步。
越是项目起步阶段，越是要注意按照规范进行。
如前所述，因为开发软件项目规模较小，很容易忽视规范化，而随心所欲，没有计划，想到哪做到哪，其最终的结果是失去控制。
其实项目小正是实现软件规范化管理的好时机，规模
小，涉及的管理方面有限，管理实施起来比较容易。
CMM等规范标准不是轻而易举就能实现的，但是可以借鉴它的思想和方法，先在小项目上实现规范化管理，培养人员的规范和意识，为以后实现大项目的CMM等规范打下良好的基础。
特别需要重视软件开发中文档管理。
那种认为只要产品做出来可以运行，何必花费许多精力去做文档的观点是错误的。
经过实践，我深刻体会到，没有文档会带来很多问题。
用文档去引导开发过程，抛弃随心所欲的开发模式。
就象工厂工人师傅按照图纸生产零件一样，否则很可能会得到次品甚至是废品，给后来开发者留下一堆没有意义的“垃圾”产品。
我认为文档应该是开发中阶段（ｍileStone）结束的标志，每个阶段后，都需要提交相应的文档，而且要确保文档的质量。
确保文档质量的最有效方法就是评审，提交文档后，项目负责人组织相关人员对该文档进行审核，在充分讨论的基础上进行文档的重新修改和审核直到满足项目要求。
文档应该是贯穿整个过程的主线，在不同的阶段，需要不停地对文档进行完善，使之真正成为全体项目人员的智慧结晶。
三、重视测试
测试是软件开发中容易忽视的问题，许多人认为开发的主要工作是编码，其实不然，在没有严格执行开发流程的开发活动中，测试可能是唯一能确保软件质量的方法和手段。
而越是松散的项目越轻视测试活动，它既没有固定的测试组织，又没有程序员间的交叉测试，更没有考虑过有效的测试流程和方法，他们的软件质量完全建立在对程序员能力信任的基础上，这是很不安全的。
测试是对软件产品质量的检验和评价。
它一方面检查软件中存在的质量问题，同时对产品质量进行客观的评价。
我们一般把发现的错误bug（我们也称为缺陷defect）按严重性分为四类：
死机（系统崩溃或挂起）、致命（使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的）、严重（系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：
显示不正确但输出正确）、一般（界面拼写错误或用户使用不方便）。
我们也把发现的错误按优先级分为三种：
高、中、低。
一般是某错误对用户接受或使用影响越大其优先级越高。
要完成严格的测试，就必须建立规范的系统测试流程，有专人负责执行，而且开发人员要积极配合，不要认为测试人员是在给自己找麻烦，测试人员查找的错误可能是程序员无法发现的错误。
一般的测试流程应该是：
1、项目组提交系统测试申请给测试中心指定帐号。
由专人检查文档格式和完备性。
2、检查合格后交给该产品对应方向的研究人员，评价其内容的有效性和真实性。
3、检查合格后由测试中心主任审查并通过，成立测试组，指定测试组长（可暂时没有组员）。
4、测试组长根据该产品的申请报告、测试设计和以往测试数据，制定测试方案。
5、测试中心主任审核通过测试方案后，根据测试方案指定测试组成员，并由支持组完成其他支持任务（如：
设备的配备、测试数据库的建立、网络权限的修改„„）。
6、测试期间测试组根据测试方案进行实际测试，记录并跟踪测试缺陷报告，填写测试记录。
测试组长与项目组（测试经理）经常沟通，并获取产品的更新版本。
同时，测试组长审查、修改并提交所有缺陷报告，保证随时掌握产品的质量情况，并监督测试进度。
7、产品进行到一定阶段后（标志是测试缺陷报告库中所有的报告处于归档状态），由项目组和测试组长共同决定产品进入稳定期测试。
稳定期测试版本之前的版本必须在显著位置标明为测试版字样。
8、稳定期测试期间所发现的缺陷报告也需要记录在测试缺陷报告库中，并在稳定期结束后由双方（有时可能也有市场方面的意见）共同决定对这些缺陷的处理方式。
如果需要改动产品，则重新开始稳定期，否则通过稳定期测试。
9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。
10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。
同时，将测试过程中对测试设计的改动纳入基线（是已经通过正式复审核批准的某规约或产品，是软件开发中的里程碑）。
最后，组长整理并在指定地点保存相关测试数据和测试样张。
11、测试中心解散测试小组。
另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试（如：
Y2K测试，病毒检查、裸机测试、加密检查、说明书检查„„），并要求写入测试方案中。
测试应该在现实的环境中进行。
所谓现实环境就是与用户实际使用的环境相同或相近，因为开发环境和用户使用环境有很大区别的，而开发的产品最终是要交给用户使用的。
如果没有办法模拟用户环境，则程序员可能必须自己开发一些模拟程序来模拟现实环境。
特别是与硬件配合的项目，因为在程序调试时硬件可能没有完全完成，这时就必须开发模拟硬件的程序，否则开发的进度可能无法保证。
四、时间控制
开发人员最担心“领导不断催促，可系统提交日期一拖再拖”，项目负责人对此一筹莫展，束手无策。
开发活动如同一个黑箱子，资金扔进去了，人员扔进去了，设备资源扔进去了，但不知道什么时候会出来结果，更没有把握出来的东西是否是用户所要的东西。
为避免人力、物力、财力浪费，要做好项目计划，进行有效的时间控制。
软件项目管理过程开始于项目的计划，在做项目计划时，第一项活动是估算。
现在已经使用的技术是时间和工作量的估算。
因为估算是其他项目计划活动的基石，而且项目计划又为软件工程过程提供了工作方向，所以我们不能没有计划就着手开发，否则就会陷入误区。
软件项目的进度安排主要是考虑软件交付用户使用的这一段开发时间的安排。
进度安排的准确程度可能比成本估计的准确程度更重要。
软件产品可以靠重新定价或者靠大量的销售来弥补成本的增加，但进度安排的落空会导致市场机会的丧失或者用户不满意，而且也会导致成本的增加。
因此在考虑进度安排时要把人员的工作量与花费的时间联系起来，合理分配工作量，利用进度安排的有效分析方法严密监视软件开发的进展情况，以使得软件开发的进度不至于被拖延。
在作进度安排时要考虑的一个主要问题是任务的并行性问题。
当参加项目的人数不止一人时，软件开发工作就会出现并行情况。
因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。
另外还应注意关键路径的任务，这样可以确定在进度安排中应保证的重点。
常用的进度安排方法有两种，即甘特图（GanttChart）法和工程网络法。
项目怎么样才能算做好了，也是各有各的看法，我对项目成功的定义为，“三赢”的项目，才算是真正成功的项目。
三赢包括，用户满意；公司满意；项目参与人员满意。
为用户服务、让用户满意：
用户指提供资金并且最终使用项目结果的所有人员，项目的开发过程和最终结果，要让用户认可、使用，并让用户说好。
此为一赢。
让公司满意：
项目开发要按时保质保量地完成，并为公司积累项目经验、知识储备，包括项目、人才、技术、市场等各方面的储备。
此为二赢。
让项目参与人员满意：
要让开发人员在项目中专注地完成任务，免受项目之外的因素干扰。
正常、优秀地完成项目，对开发人员本身也是一种巨大的鼓励。
还要让供应商深知其设备、软件的使用情况，让项目的成功成为供应商的成功，为下一次的更好合作打下基础。
初为开发负责人，需要不断积累经验，我书写此文目的在于抛砖引玉，争取和大家一同将我们的项目做得更完美。
欢迎各位指教。
第5篇：
IT项目经理岗位职责
一、项目经理岗位职责
1、项目经理为整个项目的第一责任人。
2、项目经理对《质量检查报告》中的所有细则负首要责任。
3、项目经理必须有效掌控项目开发的各个环节，协助、指导项目组成员的工作，及时发现并处理项目中存在的问题，并对项目组成员的工作进行合理的评价。
4、负责管理和控制项目全过程的质量、进度。
分析偏差，采取纠正措施。
如果发现项目实际进展显著偏离计划，则及时采取纠正措施。
5、根据项目规范建立项目组内部管理和沟通机制。
6、可根据需要调配组内人员等资源。
7、有权对项目组成员提出奖惩建议。
8、项目经理负责组织需求分析工作，并组织对需求文档和需求变更文档进行复审。
9、分配系统设计任务，包括体系结构设计、模块设计、用户界面设计、数据库设计等。
10、组织对体系结构设计、模块设计、用户界面设计、数据库设计进行评审。
11、负责组织项目开发小组会议并编写会议纪要。
开发小组会议每周至少举行一次（可与项目例会合并），对难点、疑点问题进行分析、解决，保证小组内成员充分沟通。
12、负责每周对开发人员的代码进行检查。
13、负责提交测试版本、搭建符合实际的集成测试环境，每个项目只能有一个测试环境，开发环境不可与测试环境混合。
14、所需提交文档：
立项后制定《项目计划》并保证该计划的合理性和现实性。
组织项目组内对《项目计划》进行评审，《项目计划》制定或变更后必须发邮件通知部门经理、测试部及项目相关人员。
每周五下班前提交项目的《项目周报》至TFS上项目相关目录。
协助设计人员编写《体系结构设计报告》、《模块设计报告》、《用户界面设计报告》、《数据库设计报告》
提交《内部验收表》。
项目成果交付用户前项目经理必须组织内部验收，并签字生效。
结项前向项目管理部门提交《结项申请书》。
负责组织开发设计人员、需求分析人员、测试人员，根据《用户需求说明书》提交各类技术文档，并保证该文档的及时有效性和准确性。
二、项目管理FAQ
1、项目计划如何编写？
项目计划按文档模板的提示完成各项内容，统一使用xxxx工具制定并跟踪。
2、项目计划编写好后怎么提交？
项目计划编写完毕后，需将初稿提交给项目管理部门进行初审，并由其组织项目管理部门成员及项目组成员进行开会评审。
3、怎样进行项目计划变更？
在项目过程中，需根据实际情况对《项目计划》进行变更，须提交项目管理部门进行评估，如对项目有重大影响，项目经理须填写《项目计划变更申请表》并提交项目管理部门进行审核。
4、需求分析文档编写有哪些要求？
项目的需求分析文档是开发的依据，在编写中每项功能的描述必须思路清晰，要求有输入、输出项和操作步骤、业务流程等信息，并能对功能画出示意图、流程图等。
需求分析文档编写完成后需将初稿提交项目管理部门进行初审，再由其组织项目组成员并邀请相关人员进行会议评审。
5、整个项目实施过程中，各类角色周期性需要提交什么文档？
项目经理：
每周五举行项目例会，并提交《项目周报》的“项目进度”部分。
开发人员：
每周五提交《项目周报》的“实际完成任务”和“问题汇总”。
测试员：
每周五提交《项目周报》的“质量保证报告”。
6、项目经理的主要任务是什么？
在立项申请评审会议中指定项目经理后，项目经理需提供项目组开发人员的建议名单，包括体系结构设计员、界面设计员、数据库设计员及模块设计员。
制定完《项目计划》后，项目经理应按《项目计划》要求制定《开发计划》。
项目经理负责对各系统设计员所提交的设计文档进行初审。
项目经理应经常对开发人员的模块设计或源码进行抽查，确保软件开发质量，并符合设计要求，并在每周五提交的《项目周报》中的“源码检查情况”记录相关信息。
7、如何使用Bug管理系统？
项目立项后，测试部将会在Bug管理系统创建该项目，并设置项目组成员及各成员的角色。
项目组内任何人发现项目缺陷都应该登录Bug管理系统中进行记录，若非项目组成员发现错误应及时反映给测试人员。
提交缺陷时，根据缺陷的严重性选择类别，并选择“严重级别”能让开发人员及时获取信息进行修改。
标题应该简要说明缺陷内容，以便进行相关查询和统计，不能以“错误”、“测试结果”等无意义的词作为标题。
8、怎样进行验收、升级、安装？
所有项目在提交客户前，必须通过测试部和项目经理组织的内部验收，并填写《内部验收表》。
内部验收通过后，项目经理制定《客户验收计划》并组织客户及项目相关人员进行验收，编写《客户验收报告》。
项目组/开发人员负责提供需要验收的软件和建立验收环境。
并编写安装、升级脚本。
安装、升级前应先在测试服务器上搭建与正式服务器相同的环境，执行安装、升级脚本，确保脚本执行无误，然后再验证程序的正确性。
测试服务器上安装、升级无误后，项目经理指定开发人员进行正式系统的安装、升级，安装、升级人员填写《升级（安装）记录表》。
9、如何结项？
所有交付给用户使用的系统，必须在交付验收的同时，提交经项目经理和质保员审核的操作手册、软件系统管理手册、系统安装、配置和维护手册等验收所需文档。
所有验收文档提交齐全后，由项目经理撰写《结项申请书》，申请结项。
《结项申请书》应附上经项目经理审核的项目竣工文档清单，并对项目进行全程回顾，总结项目中的经验教训，对项目组成员的工作质量、责任心和效率等进行评估。
项目管理部门对《结项申请书》进行评审，决定是否同意结项，并提交《结项评审报告》。
10、操作手册等验收文档由谁来写？
验收所需文档均由项目经理指定项目组内成员完成，项目经理和测试员负责审核。
11、结项后又有新需求或需求变更怎么办？
根据需要重新考虑立新项目。
12、对于细小需求频繁变更，时间要求又紧张的需求变更如何应变？
对于较小的需求变更，经过需求分析人员和开发人员的沟通，记录在需求文档的历史记录中，并由项目经理签字确认；重大需求的变更，则必须按照需求变更流程进行控制，提交《需求变更申请书》，并进行项目组内的需求评审。
如果质保员在测试时才发现需求有重大变更但未形成文档且未经评审，则严肃处理。
升级会员 