下面是小编给大家带来关于软件项目团队建设的“三个中心”，本文共8篇，一起来看看吧，希望对您有所帮助。
篇1：软件项目团队建设的“三个中心”
要以客户需求，以客户操作使用的方便性作为指导产品开发、项目实施的原则，一切工作都要贯彻此原则。
以客户为中心，不是被动消极的接受客户的意见，盲从客户。而是积极主动地引导客户，和客户达成共识。这需要处处想在客户的前面，真正的替客户着想，从客户的角度出发考虑问题。
有三个方法可以和客户达成共识：
1、通过多种途径深刻理解客户的业务，抽象成清晰、简单、客户易于接受的思路。
2、在细处多替客户着想，争取在某些方面超出客户的预期。通过这种方法，才能使客户容忍那些达不到的需求。这有些和顾客买东西类似，客户可能会认同他比较关心的几个产品功能，忽略他不怎么关心、他认为不重要的几个产品功能，而决定购买此产品。
3、如果条件允许，不要局限于一个项目的用户需求，要延伸到普遍的此类用户的业务需求，抽象出其共性。
什么样的产品对公司而言才是好的产品？这个问题仁者见仁，智者见智。我认为能使公司赢利的产品才是好的产品，能使公司赢利的产品有如下特点：
1、花费最少的成本取得最大的收益，能让客户比较顺利的付款，
2、能带来公司短期赢利，又可减少长期成本（对小型公司而言）。赢利可分为短期赢利和长期赢利。对大型的软件公司，如Mircosoft、IBM可能追求公司稳定长期的赢利；对新组建的公司，可能在前期会以短期收益为主。当然在产品研发、项目实施过程中，要逐步抽象出一些可以复用的功能模块和产品，比如底层开发平台、底层开发构件、项目实施经验等，以减少公司的长期成本，这种认识能促成公司项目和产品研发的良性发展。
这是最主要的一点。软件项目中最主要的是人才、是团队合作精神。如果项目团队成员相信他们是世界上最好的，在某种程度上，他们的确会成为最好的。这并没有想象中那么困难。
在项目团队中，如果有一位成员悲观、自卑，这会具有极强的感染力，甚至会影响到整个部门直不起腰。要使团队的每一个成员都挺直腰杆，就必须让他们自尊、自信。只有自尊、自信，才能自强！
孙子兵法云：“欲得其中，必求其上；欲得其上，必求上上”，否则不可能顺利达到目的。
要相信我们的团队是最好的团队！
篇2：如何建设软件项目团队的一些问答
Q: 啥子是Programmer manager
A：program manager的program不是程序啦，。。一般管一个business domain的end to end solution. 在甲方的话，一般还会分成几个team，下面的service manager管operation和client management，还有initiative manager管一堆project manager来deliver project。
Q: 请教一下，从带10-20人到带更多的人，最需要注意的是什么？
A：
请教不敢，我就是完全失败的一个典型，呵呵，经验教训可以简单说说。
我自己的经验，其实技术团队的管理， 真正质变的大概是从超过25-30人起， 道理很简单。 一个人可以直接充分管理的人大概就是4-5个为佳， 25个以内，分组就可以，超过25/30个以后就必须分3层，管理成本就开始剧烈增加，啥问题都出来了。
二层结构的时候，下面人有问题容易及时修补，对小组leader的协调能力要求不高，只要负责即可，这种情况下基本没有多少管理成本。但是到了三层结构以后对第二层的人要求比较高，如果没有合适的第二层人员，就基本是个乱摊子。老大这时候主要的工作，其实就是应该在人数超过50之前，尽可能快的培养出适合第二层次的负责人，而不是急着做大导致整天忙着救火。另外分层架构的一个必然问题就是容易产生帮派和分离势力，不注意这方面出现的内耗杀伤力极大。所以对下属马仔头目的监控会耗费你比较多的精力，而且同时还要充分考虑到如何让这些小流氓敏感脆弱的心理感觉到尊重。
我自己感觉50个人左右时是个大坎，如果可以突破就可以顺利向三层的 组织结构发展，可以过度到100人以上，我们那时候的问题就是老板其实并没有意思到管理成本这个问题，错误的以为可以通过规模追求效益。在基本能突破50个人这个坎的时候，老板被上年的产值弄混了头，盲目发起了一场新战役，又空降了一个一心想做大事的牛人，两人一合作，就一起over了。我们当时的架构，老板热衷于搞大合并，把几个事业部合并了弄个大部门，把一些马仔头目拆分的乱七八糟的，说是充分利用资源，打破部门间的壁垒（扁平化管理？)，然后又乱七八糟塞了一大堆人进来，原来的三层结构彻底打破，结果变成无人负责制。
软件项目的团队规模，个人还是觉得越小越好，可能的情况下尽可能走小而精的道路，在培养了团队成员的默契和一些共同的文化认同以后，再逐步拆分扩充，要比一开始就上大摊子有效的多。 我们之前成功的一个项目，最初的预算是60人，我采取的做法现在看起来非常明智，首先只找了1，2个核心的程序员和少数的普通程序员，通过结对开发的方式让他们彼此熟悉和磨合，在这个过程中完成基本的核心开发，在2个月以后再补充第二批程序员，把原来人分拆重新结对。通过这种方式逐步过度到20-30的团队。 再往后考虑到个人能力和管理成本的问题，就拒绝再加入了，最后以项目规划的1半左右的资源就完成了开发工作。而且这期间培养了不少人，大部分人后来又补充到其他项目，逐步建立了整个部门技术团队。这种逐步圈地的做法比较稳妥，也容易培养团队之间的信任文化，那时候整个工作气氛还是蛮好的，我们是公司最少加班的团队，但是是公司开发效率最高的团队。而其他几个规模只有一半，一开始就砸进几十个人的项目，都是问题多多那种。
100个人以上的团队，我只见过，没管过，，基本上我觉得战斗力要比50人甚至30人低，吵架pk聊天时间多过做事时间，别相信啥1+1>2 。最近听朋友说XXX为了保证销售额，把销售人员增加了1倍，销售人员任务降低一半，这种规模游戏也就是骗领导有用吧，地球人都知道，横竖能干活的就是那么几个人。
对一个leader来说，我自己的感觉就是4，5个人的时候啥都可以不管，自己把活干大头就好了，要有nb的小弟就扔给她做。 10来个人的时候，就要注意大家吃喝玩乐心情愉快，因为到了这个规模，基本上靠个别牛人发飙已经不可能搞定工作了，需要你去努力拍下属的马匹投其所好，让他们赏脸做事，而且一定要有风险控制机制，关键工作岗位一定要有backup。规模再往上走，自觉往后面站，基本上你工作的中心就是要培养一批打手让他们自己折腾自己。
P：
非常喜欢5-10人的小团队，我上一个项目就是了，4个dev，两个是senior两个junior，另外4个tester，关系好打理，每个人知道自己在团队里的职责和位置。虽然个体能力不突出，但团队战斗力强。跟我们同期的另外一个20人的队，有3个牛得不得了的人，manager和leader之间谁都不服谁，最后项目交付了，但一大堆bug。
Q： 受教了，多谢分享！
一个问题就是：在2个月以后，团队开始扩充时，如果仍然采用结对的方式，而不是传统的分组（几个人一个小组，然后选拔组长），如何保证队伍具有非常一致的目标和想法，如何保证团结？
A：
软件工程里面有个著名的brook定理，大意就是向一个进度落后的项目加人，只会让这个项目更加落后，引申开来就是应该避免在项目的中后期大幅度加人。 这里面的主要的原因有几点。
1. 新人加入团队以后需要获取团队成员的信任和尊重，这需要比较多的沟通和交流成本，软件开发说到底是一种群体活动。
2. 新人要理解，认同团队的文化，也需要很大的成本
3. 新人需要对项目进行学习和了解，过程会拖累其他开发人员
4. 新人太多，有可能会彻底摧毁原来团队已经建立的平衡结构，比如团队文化， 团队间的角色定位。
5. 管理者会因此大幅度的增加管理成本，另外，管理者很可能并未做好管理这样团队的准备，有可能会因为不合适的行为和决定导致团队崩溃
6. 人员增加以后，彼此之间的交流沟通成本会大幅度增加，超出一般人的想象，
因此一般正确的做法是避免在项目中后期加人，虽然这么显然简单的道理大部分老板都不相信。
所以表面上看，逐步圈地的做法是违反brook定理的。但实际情况，恰恰因为结对工作在很大程度上克服了上述的问题，所以你要是理解了结对的收益，就可以明白为什么结对可以保证“队伍具有非常一致的目标和想法，保证团结”
1. 结对可以让新人之间加快了解过程，尽快的融入团队， 不使用结对的方式，一个新人可能需要1，2周才能和团队相处融洽， 使用结对的方式以后，1，2天就可以很熟悉。
2.结对降低了新人的学习成本，在结对过程中，原团队的成员采取人盯人的方式尽快的将技能和团队文化传递给新人，而新人一开始就可以上手工作（即便是菜鸟，在结对过程中也可以通过质疑和提问对老人提供帮助和监督，而出于维护个人的自尊，团队成员一般都会急于向新人推销，证明自己），更有成就感和归宿感。对团队也就更容易认同。
3. 结对是分而治之的，有助于避免新人因为陌生环境产生分离感，建立自己的帮派。 有助于强制性的向新人灌输团队的目标，保证团队的团结。习惯了结对的工作模式以后，程序员之间必须强制性的进行沟通和交流，也可以避免产生帮派和内耗。
4.作为boss更关心的一点就是，通过结对这种方式，可以获得足够的backup，可以避免因为人员流动给项目带来毁灭性的风险。因此可以大幅度的降低管理成本。我们项目中期流失了近三分之一的人，进度没有受到任何影响，所以前期boss极力反对做pp，后期大力支持。我们自己有过一个大致统计，正常情况下离职一个人，要损失至少半年的人工。
通过结对这种方式，互相之间建立了沟通和信任机制，再划分如果有目的的小团队，就比较自然，另外在不同的小团队之间交换结对伙伴也可以做激励和监督作用。而一次性投入的建设新团队，碰到的问题会更多。
这个项目其实失败的一个地方就是中期迫于人员流动而放弃了结对，最后导致帮派和内耗，纠正过来化了血本，否则还能做的更好。人员流失有一部分是因为个人当时管理经验不足，对问题的解决欠妥，还有一个原因是原材料不合适，老板在团队组建之初盲目的招来了一些并不适合的人（后来碰到一个老板，居然跟我提招10留1的理论，Orz），也为后来的内耗埋下了隐患。这也算是一个经验，团队成员的选择leader一定要过问，对于那些性格比较偏激，难以控制的人应该尽量回避，绝不可以因为资源紧迫就充数。
按：pp的工作方式，对团队成员性格有一定要求。
Q：
任何团队的组织划分，一定不是用技术最好的人来做leader。对技术好的人要进行压制。不管有多出色，都要尽力扶持听话的人。
找技术好的人是对的，但是他技术好，你技术不好，就面临挑战了。何况技术好，不听话的，到哪里都是干活的命，没有人会重视他们的。
A：
你老外说话也不真见外，按你这样管， 几天大家就造反了。
软件团队和一般的团队区别非常大， 对软件团队来说，最好的管理模式就是不管理， 让大家自己发挥，做好足够的引导工作就好。小团队leader身先士卒起个带头示范左右，大团队， leader要躲在后面做好后援当保姆。 技术好的人的做leader是非常自然的，不懂技术的人做负责人倒是比较容易引起问题，技术人员都比较骄傲，除非是个美女mm带头，那还可以忍忍。 不是说不懂技术的人做不好pm，但是没有技术背景的人天然就和技术人员有鸿沟，技术人员背后搞的小九九，花样那个多，所以没有技术背景，管理成本会比较高。
有个老外专门写了本书论证为啥技术好的人就该做leader， 你可以找找看。
按：管理层对技术人员的不尊重和粗暴压制， 才是技术人员不听话的一个重要原因。Q：
说起来， 管理无所谓，只要肯听话的，这个是永远的原则。
听话的，能力也强的--这当然最好的，但是一般听话的能力都比较一般。要是能力强，不听话，最好不要，这样的人， 很容易出问题。
A：
软件开发和普通的项目是有根本的差别的，软件本质还是个体的脑力劳动， 所以软件的生产力完全取决于个人的能力和工作态度。 2个程序员之间工作效率的差别可以轻易超过10倍， 所以你找找再多听话的人又有什么用？
能力的问题可以举个真实例子： 某500强企业开发的一个业务系统， 投入近20个人， 历时2年至今还不能上线。而同样的东西，在另外一个团队只是2个人一个月的工作量而已。第二个团队的平均人工是要低于第一个团队的。
态度的问题也可以举个真实例子： 某公司开发的一个应用系统，4个人组成的验收团队测试了5个月只找到40个的缺陷， 系统提交客户以后，客户方自己组织测试，3天内就发现了40个以上的重要缺陷。
任何一个公司，都必须有听话（执行者）和不听话的人（创造者和破坏者）的存在，否则这个公司就离死不远了。 管理要的不是简单的听话与否，管理者关心的应该是可控和有效性。
Q：
为了达到目标，有效性就是听话，完成任务达到目标可控性，也就是要听话。
A：
算了，让我去死吧。
按：管理人员和技术人员的沟通真是鸡同鸭讲，呵呵。
来自：如何建设软件团队的一些问答
篇3：软件项目管理制度建设
软件项目管理制度建设
背景知识编辑
软件项目管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期，软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。
1995年，据统计，美国共取消了810亿美元的商业软件项目，其中31%的项目未做完就被取消，53%的软件项目进度通常要延长50%的时间，只有9%的软件项目能够及时交付并且费用也控制在预算之内。
软件项目管理和其他的项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。这样庞大的系统如果没有很好的管理，其软件质量是难以想象的。
软件项目管理的内容主要包括如下几个方面：人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。
这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化;软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面;软件项目计划主要包括工作量、成本、开发时间的估计，并根据估计值制定和调整项目组的工作;风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防;质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划，有组织的活动;软件过程能力评估是对软件开发能力的高低进行衡量;软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣，下面就详细的对这两方面展开讨论。
开发计划编辑
软件项目计划是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。
软件项目管理过程从项目计划活动开始，而第一项计划活动就是估算：需要多长时间、需要多少工作量、以及需要多少人员。此外，我们还必须估算所需要的资源(硬件及软件)和可能涉及到的风险。
为了估算软件项目的工作量和完成期限，首先需要预测软件规模。度量软件规模的常用方法有直接的方法――LOC(代码行)，间接的方法――FP(功能点)。这两种方法各有优缺点，应该根据软件项目的特点选择适用的软件规模度量方法。
根据项目的规模可以估算出完成项目所需的工作量，我们可以使用一种或多种技术进行估算，这些技术主要分为两大类：分解和经验建模。分解技术需要划分出主要的软件功能，接着估算实现每一个功能所需的程序规模或人月数。经验技术的使用是根据经验导出的公式来预测工作量和时间。可以使用自动工具来实现某一特定的经验模型。
精确的项目估算一般至少会用到上述技术中的两种。通过比较和协调使用不同技术导出的估算值，我们可能得到更精确的估算。软件项目估算永远不会是一门精确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。
当对软件项目给予较高期望时，一般都会进行风险分析。在标识、分析和管理风险上花费的时间和人力可以从多个方面得到回报：更加平稳的项目进展过程;更高的跟踪和控制项目的能力;由于在问题发生之前已经做了周密计划而产生的信心。
对于一个项目管理者，他的目标是定义所有的项目任务，识别出关键任务，跟踪关键任务的进展情况，以保证能够及时发现拖延进度的情况。为此，项目管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。
常用的制定进度计划的.工具主要有Gantt图和工程网络两种。Gantt图具有悠久历史、直观简明、容易学习、容易绘制等优点，但是，它不能明显地表示各项任务彼此间的依赖关系，也不能明显地表示关键路径和关键任务，进度计划中的关键部分不明确。因此，在管理大型软件项目时，仅用Gantt图是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。
工程网络不仅能描绘任务分解情况及每项作业的开始时间和结束时间，而且还能清楚地表示各个作业彼此间的依赖关系。从工程网络图中容易识别出关键路径和关键任务。因此，工程网络图是制定进度计划的强有力的工具。通常，联合使用Gantt图和工程网络这两种工具来制定和管理进度计划，使它们互相补充、取长补短。
进度安排是软件项目计划的首要任务，而项目计划则是软件项目管理的首要组成部分。与估算方法和风险分析相结合，进度安排将为项目管理者建立起一张计划图。
项目控制编辑
对于软件开发项目而言，控制是十分重要的管理活动。下面介绍软件工程控制活动中的质量保证和配置管理。其实上面所提到的风险分析也可以算是软件工程控制活动的一类。而进度跟踪则起到连接软件项目计划和控制的作用。
软件质量保证(SQA，Software Quality Assurance)是在软件过程中的每一步都进行的“保护性活动”。SQA主要有基于非执行的测试(也称为评审)、基于执行的测试(即通常所说的测试)和程序正确性证明。
软件评审是最为重要的SQA活动之一。它的作用是，在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。审查过程不仅步数比走审多，而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大数是规格说明错误或设计错误，而正式的技术评审发现这两类错误的有效性高达75%，因此是非常有效的软件质量保证方法。
软件配置管理(SCM，Software configuration management)是应用于整个软件过程中的保护性活动，它是在软件整个生命周期内管理变化的一组活动。
软件配置由一组相互关联的对象组成，这些对象也称为软件配置项，它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外，用于开发软件的开发环境也可置于配置控制之下。
一旦一个配置对象已被开发出来并且通过了评审，它就变成了基线。对基线对象的修改导致建立该对象的版本。版本控制是用于管理这些对象而使用的一组规程和工具。
变更控制是一种规程活动，它能够在对配置对象进行修改时保证质量和一致性。配置审计是一项软件质量保证活动，它有助于确保在进行修改时仍然保持质量。状态报告向需要知道关于变化的信息的人，提供有关每项变化的信息。
组织模式编辑
软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。如果是订单开发，则成立软件项目组即可;如果是产品开发，需成立软件项目组和产品项目(负责市场调研和销售)，组成软件产品项目组。公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。
3.1、项目管理委员会项目管理委员会是公司项目管理的最高决策机构，一般由公司总经理、副总经理组成。主要职责如下：
(1)依照项目管理相关制度管理项目;
(2)监督项目管理相关制度的执行;
(3)对项目立项、项目撤消进行决策;
(4)任命项目管理小组组长、项目评审委员会主任、项目组组长.
3.2、项目管理小组项目管理小组对项目管理委员会负责，一般由公司管理人员组成。主要职责如下：
(1)草拟项目管理的各项制度;
(2)组织项目阶段评审;
(3)保存项目过程中的相关文件和数据;
(4)为优化项目管理提出建议。
3.3、项目评审小组项目评审小组对项目管理委员会负责，可下设开发评审小组和产品评审小组，一般由公司技术专家和市场专家组成。主要职责如下：
(1)对项目可行性报告进行评审;
(2)对市场计划和阶段报告进行评审;
(3)对开发计划和阶段报告进行评审;
(4)项目结束时，对项目总结报告进行评审。
3.4、软件产品项目组软件产品项目组对项目管理委员会负责，可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是：根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。
项目管理编辑
从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。根据公司实际情况，公司在进行软件项目管理时，重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。在20世纪80年代初，著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则，同样，在进行软件项目管理时，也应该遵循这七条原则。它们是：
(1)用分阶段的生命周期计划严格管理;
(2)坚持进行阶段评审;
(3)实行严格的产品控制;
(4)采用现代程序设计技术;
(5)结果应能够清楚地审查;
(6)开发小组地人员应该少而精;
(7)承认不断改进软件工程实践的必要性。
上一篇：社区家长学校管理制度 下一篇：没有了篇4：维护中心团队建设心得体会
维护中心团队建设心得体会
一、以关爱，扎实开展团队建设
维护中心通过晨会和周例会认真向员工宣传和宣贯团队建设的重要些性，营造浓厚的建设氛围，使员工的责任感不断增强，同时让员工深刻认识到，要做好维护工作，单靠个人的`力量是不够的，必须发挥集体的力量，靠集体的智慧和力量才能做好工作，完成任务，取得优异成绩。为此，我维护中心按省传中心23条验收标准的要求，扎实开展团队建设，认真做好各项工作，确保维护中心成为坚强团队。
二、以信任，让员工自觉投入建设工作
维护中心从开展团队建设活动之初，全体员工按照建设要求每天坚持穿外勤服，按照安全生产要求做好工作。还通过“小纸条”，把备选口号写在小纸条上，让员工选出自己喜爱的口号，以此表示对员工的信任，鼓舞员工士气，振作员工精神，激励员工更加刻苦勤奋、认真努力工作。
三、以激励，建设坚强团队
虽然我维护中心在今年1月、2月发生过二级干线故障，但中心经理依然鼓励员工不能泄气，激励员工继续把团队建设工作做好，争取做出工作成绩，把维护中心建设成为坚强团队。
四、以服务，提升团队凝聚力
维护中心以服务提升团队凝聚力，在做好服务工作的同时，切实加强对员工的思想工作，开展一系列政治思想教育工作，使每个员工树立正确的世界观、人生观和价值观，提高思想政治觉悟，热爱企业，热爱工作岗位，做到心往一处想，劲往一处使，增强执行力，提高工作效率，确保完成各项维护任务。
维护中心在加强团队建设中，真抓实干，扎实推进，取得了一定成绩，但是与省传中心的要求和其他兄弟先进团队相比，还是存在一定的不足与差距，需要在今后的工作中切实加以改进和提高。为此，维护中心要继续加强学习，深化管理，努力实践，按省传中心加强团队建设的要求，采取更加有力的措施，促进团队建设，争取把我维护中心建成坚强团队，为做好各项维护工作打下坚实的基础。
篇5：软件项目建设活动方案
一、广泛收集体系运行情况，不断完善体系文件;根据当前实施的体系程序，尽可能的与各部门进行沟通，把真实实际的工作内容写进体系文件中，必须做到与管理手册和作业文件的描述相一致，与各部门的工作职责相一致，一个要素可能要由多项职能来落实，每项职能又要由若干个活动来保证，因此，每个程序文件都应经过细致策划和编写。这是20--年首要工作重点之一。原来的体系文件覆盖到部门级，对下一层部门没有制定实际的管理内容，对全员参与体系的建设存在严重的不足。计划明年2月开始到3月底完成体系文件的重新编制。
二、积极开展各部门对质量，环境，职业健康体系的正确认识;当前公司存在一种意识误区，包括中高层管理人员认为只要体系得到认证就完成了体系工作的任务，其实体系是个管理平台，体系只是提出了一个标准，这标准也是现代企业必须建立的，然后有各个职能部门围绕标准展开的一系列活动，如果思路不明确，行为就必然产生偏差，这和建立体系是背道而驰的，所以对各部门对体系的认识和理解就要靠培训来实现。培训的计划按照不同阶段针对不同的培训对象和培训内容采取各种培训方式，注重实际操作的培训，为使培训起到具体的指导作用，培训分层、分部门进行，责任部门对实际应用展开，让各部门和不同工作人员得到工作上的提升，并通过已经编制文件书指导各部门贯标工作的开展。让原来只有基本的作业指导文件有一个可以量化的，可以实际应用的作业指导，此项工作根据实际部门需求作出具体计划时间安排。
三、深入部门调查研究，做好内审工作，为体系的执行得到有力的保障，体系是在不断改进和完善过程中的，体系推动部门通过各种检查、内部审核、了解体系的运行情况，积极收集各执行部门对体系运行的意见和建议，有针对性地对文件进行修改，可提高文件的适用性和可操作性。内部审核是全面的体系检查，内部审核的效果对体系改进有很重要的作用，所以重视内审员在部门中起的作用，对存在的问题进行限期整改，通过内部审核推动体系的发展和完善，让体系起到实用性，符合性，此项将每月展开。
四、对体系的执行实行考核制度，没有一个强制执行的制度，的管理体系也是无效的，所以要想让三个体系得到真正的落实和执行，体系办公室必须具有相应的权利，这需要公司授权去执行，和综合办公室共同配合对部门绩效考核。公司只有坚持掌握了建立体系的基本原则，明确了运行体系的主要目的是为了搞好企业的质量管理，安全生产、环境管理，提高整体管理水平，做到领导重视、全员参与，通过不断的持续改进，一定能使三个管理体系在企业内发挥相当大的作用。
篇6：软件项目建设活动方案
一、现状分析：
从本月22日上班到现在已有一周的工作时长，就目前来看，我个人还处于对公司以及公司产品的认识阶段，对公司以及公司产品还不够深入的了解。从近期与客户交流情况分析，我个人存在以下几方面的不足(肯定不只这些，我水平有限只能发现以下缺点，如领导发现我的缺点还望指点，我会悉心听取教诲并努力该改正)：
1、我对公司以及公司产品没有深入了解，对产品的操作流程以及报价还不是很清楚。
2、我对怎样挖掘潜在客户还没有的方法，还处于摸索阶段。
3、我对网站评估的相关工具，如百度指数、百度收容量，网站综合排名等工具还不是很熟悉，对怎样去评价一个网站是否属于网络营销型网站还不是很了解。
4、我对判别一个网站是属于哪一种类型欠缺了解。
5、我对客户提出的问题有时不能给予及时的回复，原因是自己对某些问题根本就不了解。
6、我对房地产行业缺乏了解，知识面不广。
7、我对百度推广方面的认识还够，缺乏相应的学习。
8、我跟客户的交流技巧还有待改善。
二、针对目前的现状，特制定近期工作计划：
1、争取用3-5天的时间，全面、具体、详细地了解公司及公司产品。
2、多看看对手怎么做，通过对比学习，从而提高自己。
4、多学习网络营销方面的知识，提升为客户服务的质量。
5、每天完成加q群、百度hi群(房地产相关方面的群)的任务数量，想尽一切办法提高加群的进入度。
6、不断摸索与客户的交流技巧，不断提高客户的成交量。
7、每天挖掘至少20个潜在客户。
8、定期/不定期的联系有意向的客户，回访已成交的客户。
9、每天工作后及时进行自我总结。
软件项目建设活动方案
篇7：项目团队建设要求有哪些？
项目团队建设要求有哪些？
1 项目组织应树立项目团队意识，并满足下列要求：
1 围绕项目目标而形成和谐一致、高效运行的项目团队，
2 建立协同工作的管理机制和工作模式，
3 建立畅通的信息沟通渠道和各方共享的信息工作平台，保证信息准确、及时和有效地传递。
2 项目团队应有明确的目标、合理的运行程序和完善的工作制度。
3 项目经理应对项目团队建设负责，培育团队精神，定期评估团队运作绩效，有效发挥和调动各成员的工作积极性和责任感。
4 项目经理应通过表彰奖励、学习交流等多种方式和谐团队氛围，统一团队思想，营造集体观念，处理管理冲突，提高项目运作效率。
5 项目团队建设应注重管理绩效，有效发挥个体成员的积极性，并充分利用成员集体的协作成果。
篇8：软件项目团队有效性五原则
对于软件项目团队，人员的技巧和经验可能对生产率产生高达10倍的影响，在《人月神话》中曾提到对于一个100人的团队，最好是只保留25个经验丰富的项 目经理进行开发，而解散其它成员。当实际上一个软件团队不可能要求每个人都经验丰富，经过充分的培训和智商奇高，都是牛人的团队往往更容易出现混乱。因此 需要谨慎实施只雇佣优秀开发人员的想法，一个更好的方式是多考虑如何去建设一个有战斗力的团队或者是如何真正去保证团队的有效性。
平衡和工作匹配是软件项目团队的重要方面。只要失去了平衡，团队就会变得脆弱。正如一个成功的橄榄球队，进攻，防守，教练，替补，传球等各种角色和活动都 不可少，伟大的球队需要在每个位置都有关键球员，但是球队中不可能每个人都是球星。因此球员应该更多关注如何赢得比赛胜利，而不是单纯的个人荣誉。
团队合作远比个人总和重要，因此项目经理需要真正做到人尽其材，每个人才都能够真正找到适合自己的位置，这样人才的配置才能达到一个平衡状态。对于如何为软件项目提供人员时候，波姆提出以下五项原则:
1.顶尖人才原则-使用更好和更少的人员
对大多数项目都有一个自然合适的团队规模，偏差太大都不利于发挥团队的能动性。另外团队中不可避免的有辅助性工作要做，必须要为软件项目团队配置如《人月 神话》外科手术队伍中谈及的一些秘书和辅助人员，但是我们需要搞清楚的是核心团队的人数要尽可能的少，以保证高度的概念完整性。
2.工作匹配原则-把任务分给技能和动力都匹配的人
对软件团队，辨别难以琢磨的个人技能并做到最优分配是相当困难的，而且项目经理的个人主观意愿也可能使分配复杂化。在软件项目团队中最胜任编码的程序员总 是希望能够得到提升上升为设计师和经理，由于帕金森定律导致的金字塔上升现象在软件项目团队更加明显，
我们不能承认编码工作的重要性，也不能给高效编码人 员更高的薪水，好的编码人员都在朝上走，在用的编码人员都很难是经验丰富的高效率人员。人才不能发挥所长，对工程师和管理者来讲是一个双重的打击。
3.职业发展原则-帮助员工的自我实现并取得好成绩
新员工刚进入团队中的时候职业发展原则是很有效的，可以帮助员工技能的完善和自我价值实现。当对于老员工和技能达到一定层次的员工，这点上往往是困难的， 组织或团队不可能一直产生很多新的东西或应用新的技术，团队中也不可能一直都存在职业发展的机会。在组织中，组织的培训受益最大的往往是中等或中等以下的 员工，而团队的培训往往更是战术性的，关注的是结束后就能马上应用的内容，而不会太多关注和培训业界新的知识和技术。
4.群组平衡原则-选择与其他人互为补充和协调一致的人员
在软件项目中我们不仅仅是关注项目的进度，质量，范围和成本四要素的平衡。还需要关注人员角色分工的平衡，冒险和保守的平衡，外部和内部的平衡，纪律和灵活性间的平衡等等。任何一个方面失去平衡，项目都可能处于危险中。
5.逐步淘汰原则-一个不称职的人留在组织内对谁都没有好处
不称职可以给你提供寻找更好员工或四使用更少员工的理由，不称职会阻碍其它组员自我实现能力，并且在某些方面会破坏团队内的平衡，给团队其它成员造成不称职也可以在团队中生存和获取报酬的负面影响。
软件开发是一项集体运动，项目经理必须培养一种团队合作，而不是单纯的追求个人成功的氛围。群组平衡和工作匹配应该是最主要的目标，因为顶尖人才原则和逐 步淘汰原则必须在群组平衡的前提下实施。另外职业发展原则不可以过分强调，因为过分强调这一原则而忽视了团队成功的个人或组织在竞争激励的市场上不会长久。
来自：blog.vsharing.com/sharptoolbox/A641577.html
文档为doc格式
