软件团队开发与自主开发的优缺点对比
感谢下载!
欢迎您的下载，资料仅供参考
软件开发项目团队建设
软件开发项目团队建设 近20 年来，许多新一代的软件技术、过程和方法的发展异常迅速，但软件工业仍然是一个人力密集的过程，离工业化生产方式的差距相当遥远，软件开发人员的素质、技术、能力以及软件开发团队建设的好坏，对软件项目的成败有者举足轻重的作用。为了提高软件开发的效率，提高软件开发的质量，减少软件开发的成本，降低软件开发的风险，就必须加强软件开发人员的管理，建立高效的开发团队。 1 软件开发团队在软件开发中的重要性 软件企业与传统工业企业不同，与现代企业的其他行业也不同。其最主要特征就是，企业最主要的“资产”是一批掌握技术、熟悉业务、懂得管理的“人”。软件企业主要的成本是人的成本，软件企业主要的财富积累是知识和经验的积累。因此，软件企业的人力资源管理，是企业最主要的管理内容。软件项目组的管理过程，几乎全部是围绕“人”来进行的管理。而作为被管理对象的“人”本身管理的讨论，则越来越成为软件领域所要讨论的核心问题。软件项目队伍是项目的基本工作单元，队伍的作用非常重要，是顺利实施项目的基础平台，值得花时间研究，探讨与项目成败的关系，以便更好地组建队伍，最大限度地提高工作效率。软件项目管理的主体是软件开发团队。一个软件项目管理的好坏，很大程度就体现在软件开发团队的建设和管理上。软件开发团队是软件项目实施的基础，它直接影响和制约着软件项目管理的最终效果。软件开团队在软件开发中的作用越来越突出。团队管理非常重要，它是项目顺利进行的基础，对于一个球队来说，要大力培养他们的团队精神，要求队员深刻认识自己球队的特点，团队精神能使球队更具有竞争力，可以打败实力相同而没有团队精神的球队。同理，对于软件项目团队也一样，在开发复杂软件的时候，通常每个人开发不同的部分，运行这些软件的设备又可能
软件团队的如何建设和软件开发如何管理
在很多场合，我们都听到人们说“人才是最重要的资产”，我想，这不是一句空话。有了人才就有一切，这是一个真理。对于软件开发来说更是如此。当然，对人才的关注并不意味着要人才堆积甚至浪费，人才浪费反而会影响整个团队。 人才只是一个个的点，如果没有形成一个有效的团队，人才再多也毫无意义。软件开发是一个需要协同作战的工作，团队是软件开发工作的基本组织，因此形成一个有效的团队是软件组织成功的基础。 很多时候，团队作战听起来容易做起来难。有一次，我和一个大型软件企业的CTO聊起了软件组织的模式，他打了一个比方，说软件开发就象做外科手术，外科主任应该是技术最强的人，熟知每一项技术细节的人，所以软件组织的领导也应该是技术最全面，每个细节都精通的人。软件开发真的象医生看病做手术吗？我们来看看这里面有什么不同。医生通常面对的是一个病人，通常处理的是一个个案，当然一个复杂的手术也需要麻醉、影像、护士、助手的配合才能完成。一个软件项目呢？软件项目也有大小的区别，小的项目一个人处理所有环节，前端、业务逻辑、数据库；大的项目通常有一个团队共同完成，需求分析、结构设计、概要设计、详细设计、编码、测试，中间贯穿配置管理、流程管理等等，可由几人、几十人、几百人的团队共同完成。当领导几十人、几百人的团队的时候，项目的成功与否不光是领导者的技术能力所能够决定的了，更重要的是领导者的管理能力和领导能力决定的了。可见，不同软件企业的CTO对软件组织的模式认识也是不同的。 既然我们认识到了团队是一个软件组织的基本作战单位，那么我们应该怎样建立一个样团队呢？我们建立的团队应该包含哪些模块呢？我们可以从一下几个方面入手来对我们面对的问题先进行一个分析： 团队的技术要求是什么？ 团队要具有哪些功能模块？ 什么样的员工适合我们的团队？ 下面我们来分析一下以上3个问题。 团队的技术要求是什么？通常，我们需要分析一下我们工作的技术要求。我们可以把软件系统作一个简单的分类： 基础系统，如操作系统、数据库系统、服务器系统 专业系统，如人工智能、大型索引系统 应用系统，如BOSS、BI系统
高效研发团队建设的六个步骤
高效研发团队建设的六个步骤 对美国软件工程实施现状的调查结果表明，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。软件开发团队的建设和管理依然是软件项目管理中一个十分主要的问题。 软件项目管理的主体是软件开发团队。一个软件项目管理的好坏，很大程度就体现在软件开发团队的建设和管理上。软件开发团队是软件项目实施的基础，它直接影响和制约着软件项目管理的最终效果。 一个高效的软件开发团队是高质量软件项目或产品的保证。建设高效的软件开发团队，是实现软件项目管理目标的前提和保证。具体的建设措施有以下六点： 1、选拔或培养适合角色职责的人才 软件项目是由不同角色的人共同协作完成的，每种角色都必须有明确的职责定义，因此选拔和培养适合角色职责的人才是首要的因素。 软件项目开发经理要熟悉各种设计方法，愿意听取其他人的意见，并且要很客观地把自己的思想与其他人的意见相比。此外，还要掌握激发团队成员积极性的方法。 系统分析员要熟悉需要的设计方法，掌握系统分析和设计的原则，要拥有完成职责所需的技能和丰富经验。 选拔或培养适合角色职责的人才，特别是合适的软件开发经理是建设高效软件开发团队的最重要的因素。 2 、增强软件开发经理的领导才能 软件开发经理是项目的负责人，负责整个软件项目的组织、计划及实施的全过程，在项目管理过程中起着关键作用。 增强和发挥指导作用 软件开发经理必须以身作则，严格要求自己，起到榜样和示范作用；要明确具体的软件项目质量、范围、工期、成本等目标约束；明确各软件开发团队成员的角色和责任分工，充分发挥团队成员各自的作用。 充分发挥激励作用 在软件开发过程中，由于严格的目标约束及多变的外部环境，软件开发经理必须运用各种激励理论对软件开发团队的成员进行适时的激励，鼓励和激发团队成员的积极性、主动性，充分发挥团队成员的创造力。 灵活授权，及时决策
团队的软件项目管理和开发流程
团队的软件项目管理和开发流程 1目的 ●用于指导公司的技术中心软件开发工作 ●定义了各部门与技术部的协作接口和流程 ●定义了项目开发流程和管理办法 ●定义了任务开发流程和管理办法 2说明 2.1 范围 本文档只适用于技术中心针对网站及其相关的一般性开发工作。包括： ●网站维护性开发 ●项目开发 本文档不适用于网站运维护性的系统维护工作。不涉及： ●网站的网络安全、权限等 ●数据库的安全、备份等 ●系统环境等 凡网站运维性的系统维护工作请另参见《运维管理规范》文档。 2.2技术中心组织架构 技术中心组织架构图 技术中心组织架构说明 目前技术中心从处理的工作性质分为三大部分：运维、开发和测试。根据需求工作量的大和小，其中开发的工作又细分为两类： ●网站维护开发 ●网站项目开发 根据网站具体的开发工作内容不同，又可将维护开发组和项目开发组的人员细分前台开发人员和后台开发人员。 各小组的职责范围 ●运维组：处理系统维护性的工作，包括系统安装维护、网络安全、数据库调 优备份等。关于运维的工作本文档不再详细说明，请参见《运维管理规范》文档 ●维护开发组：处理网站的日常小问题的修改、新需求的增加（但工作量不大） 等维护性的开发。 ●项目开发组：处理新项目的开发。 ●测试组：负责对维护开发和项目开发进行测试。
●网站前台开发人员：负责对网站前台的功能进行开发。 ●网站后台开发人员：负责对网站后台的用户管理、权限管理、开发、出票等 后台的功能进行开发。 由于人力资源的限制，目前没有专职的网站维护开发和项目开发，在没有新项目时，所有人员都可安排参与网站维护开发的工作。当有新项目时再组建项目组。但有高优先级的维护工作要处理而又人手不够的情况下，项目组的人员必须优先处理网站维护紧急事件。 2.3项目与任务的定义 什么是开发类项目（项目） 满足以下任意一条件进行开发的项目均为开发类项目： ●以前从未开发过的系统； ●不存在或基本不存在可复用的技术、模块，或业务逻辑、体系结构等或者在原产品上 进行大的结构性调整。 ●在公司已有的成熟产品或可复用模块或技术基础上，根据业务需要和客户需求，新增 独立业务模块，且开发工作量超过1人月，如果是2至3人开发工作但超过2星期根据情况也可划为开发类项目。新彩种、新玩法、新产品的开发等都可以划为开发类项目。（此要求没有硬性要求，可以视情况而定。） 例如：网站二期项目、增加福彩七乐彩、增加快乐十分游戏、足彩单场项目、无线项目、安微客服项目等。 什么是维护类开发（任务） ●在现已运行的网站基础上，根据运营的需要或者市场规划的需要，提供补 丁、实现新的需求 ●工作量通过技术部经理评估小于1人月但超过1个小时的。 例如：页面的调整、促销专题页面，日常运营中发现网站的问题等。 3.需求管理 3.1需求来源 需求来源类型： ●技术部提出 ●运营部（包括客服组）提出 ●市场策划部提出 技术部需求
不同工作方式的优缺点
freelance advantages: you choose the job disadvantages: no job security teleworking advantages: organize your work time disadvantages: you need to be good at self-organisation job-sharing advantages: more free time disadvantages: need to coordinate with other person shift work advantages: gives you your days free disadvantages: tiring part-time advantages: more free time disadvantages: less money temping advantages: lots of variety
disadvantages: hard to progress your career consultancy advantages: well paid disadvantages: no job security flexitime advantages: good for work-life balance disadvantages: not good for people who like routine hot-desking advantages: saves the company money disadvantages: disruptive to employees
软件开发团队建设
如何建设优秀的软件开发团队 1.引言 软件开发人员的素质、技术、能力以及软件开发团队建设的好坏，对软件项目的成败有者举足轻重的作用。为了提高软件开发的效率，提高软件开发的质量，减少软件开发的成本，降低软件开发的风险，就必须加强软件开发人员的管理，建立高效的开发团队。 2.团队建设的重要性 软件项目管理的主体是软件开发团队，一个软件项目管理的好坏，很大程度就体现在软件开发团队的建设和管理上。软件开发团队是软件项目实施的基础，它直接影响和制约着软件项目管理的最终效果。建设高效的软件开发团队，是实现软件项目管理目标的前提和保证。 当需要开发复杂软件时，通常要求团队每个人开发不同的部分，运行这些软件的设备又可能来自不同的供应商，而事后将软件的不同模块集成在一起，带来的问题会更多。一个软件模块本身没有问题，但是合在一起却可能不能工作。所有这些都需要一个高效合作的团队来共同完成的，所以建立一支工作效率高的队伍非常重要。 3.优秀开发团队的建设 高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作基础之上的，成员共同迎接挑战，有效地计划、协调和管理各自的工作以至完成明确的目标，高效的开发团队具有如下特征： a)人才选拔与职责分配 软件项目是由不同角色的人共同协作完成的，每种角色都必须有明确的职责定义，因此选拔优秀的人才和分配其合适的职位是首要的因素。团队的能力受限于个人的能力，所以首先要保证优秀的人才资源，具有突出能力的个人往往能带动整个团队的快速发展和成长；然后就是职责的划分，俗话说“好钢是在刀刃上”，为团队成员分配合适的职位往往能起到事半功倍的作用，大大提高团队的开发效率。 b)清晰责任与共同目标 清晰明确的目标会激励团队成员把个人目标升华到群体目标，团队的成员愿意为团队目标做出承诺，共同努力实现目标。明确个人的责任之后，团队的每个成员都十分清楚团队要取得什么样的成就以及由此给团队、给个人带来的益处，他们能将个人目标与项目目标有效地结合起来，会积极地完成工作从而为团队带来高效率的开发，为设计出高质量的软件提供了重要的保证。 c)团队凝聚力 团队凝聚力是无形的精神力量，是将一个团队的成员紧密地联系在一起的看不见的纽带。一般情况下，高团队凝聚力会带来高团队绩效。团队凝聚力在外部表现为成员的团队荣誉感，而团队荣誉感主要来源于项目目标。因此，应当设立较高的项目目标，并使团队成员对项目目标形成统一和强烈的共识，激发成员的团队荣誉感。同时，引导团队成员个人目标与项目目标的统一，增大团队成员对项目团队的向心力，使项目团队走向高效。 d)融洽的关系和良好的沟通 团队成员之间高度信任、相互尊重，既关注工作本身，更珍惜彼此之间的友谊，能够共同营造和谐、宽松、友爱的工作环境，使成员在团队中有一种归属感与自豪感。团队要进行开放性的信息交流与沟通，承认彼此存在差异，鼓励不同的意见，并允许自由地表达出来面对冲突和问题。当遇到问题时能及时交流共同商讨解决问题的方案，并
企业四种组织形式的优缺点
企业四种组织形式的优缺点 作者：杨柳君 斯坦福大学的一个研究项目完美地解决了四种组织形式的问题，两位著名的组织学者詹姆斯－巴伦（James Baron）和迈克尔－汉纳（Michael Hannan）主持了SPEC（Stanford Project on Emerging Companies）。斯坦福大学SPEC研究项目报告给我们列出了“四种组织形式的优缺点”。 我最近在读中欧肖知兴老师的书，这个报告资料是我在他的书中看到的，在此向他表示敬意。 在斯坦福大学SPEC研究项目报告中，四种组织形式分别为： 科层型组织、明星型组织、专制型组织、投入型组织。 说点题外话，在肖老师的书中看到这个报告时，我对建模型的重要性，有了更深刻的认识。 平时工作、生活中，我们很多人喜欢“捣浆糊”，一件事情翻来覆去的讲，也没讲明白，下次遇到同类困惑时，还是缺乏严谨、周密的解决之道。一方面可能没这个能力提炼，一方面应该是没这个意识。 其实，正如我们所了解的，只有建模型，才能将复杂问题简单化，抓住事物的本质。 在实际工作中，我们的组织依据自己的战略或资源，匹配相应的组织形式。
然而，正如我们所了解的，每一种组织形式都有其优缺点，我们在享有他的优点时，也必须正视他的缺点。 当我们的企业以某一种组织形式运作时，总有一些员工放大该组织形式的缺点，牢*满腹，这样就无形中给我们的管理者带来了很多管理沟通的难题。 而很多似乎关于“沟通”的难题，其实并不是“沟通”的技术能解决的，不是关于“怎么有技巧的说话”的问题，要真正解决他，我们得在产生沟通障碍的本源上找症结。 很多时候，企业中存在的“沟通”障碍与沟通技巧关系并不大，但在实际工作中，我发现很多企业的管理者有可能没看清这个问题。 比如不同企业组织形式运作中自然生出的关于“优缺点”的问题，解决之道是对管理者进行企业组织形式模型的培训，让他们心中有一本清晰的账，清楚的知道各种组织形式的优缺点。 这样，当他们在面对员工对所在企业组织形式缺点的抱怨时，便能坦然的化解，不至于连自己都迷失了。 在斯坦福大学SPEC的报告中列出： 1、第一类－科层型组织： “‘科层型组织’的特点是：程序、规则，责任。 ‘科层型组织’的优点是：效率较高；不依赖于个人，规模可大可小；公
强势的软件研发团队组建
强势团队人员需求及描述 团队中包含：研发部经理（即技术总监）、leader、项目经理、项目助理、系统分析、框架设计、产品经理、高级软件工程师（主程）、初级软件工程师（辅程）、UI设计、美工、DBA测试工程师、实施工程师等，他们的大致职责描述如下。 1. 研发部经理（技术总监） 对系统方向和团队中一些决策性的事进行管理，包括日常事务，虽然他不需要编码，但能担 任技术总监，他经历了设计开发，产品的实施，并对系统的战略性发展都有相当的见解，对整个系统的所有流程都面面具道，不单单局限于技术层面，因为他需要主导整个团队运作。 可以跟客户交流需求、根据需求分派任务。 2. Leader 管理项目组成员、技术难点分析，编写详细设计文档，技能特色很突出，有创新能力，不是什么都是从网上拿下来一改就用的，其它方面都可以讲出一二，对行业内的动态都很关注，有一定的交际能力。可以跟客户交流需求。 3. 项目经理 项目经理负责分配资源，确定优先级，协调与客户和用户之间的交往。总而言之，就是尽量 使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完 整性和质量。懂开发，知识面广，针对项目，对系统进度的控制，风险评估进有把控，根据反馈的客户需求，分派具体工作内容，项目中日常事务调配，人员配置，具有一定的的沟通 能力。可以跟客户交流需求。 1
3.1 项目助理 对会议、文档、日常事务的跟踪进行管理，这不只是助理一职，这个职务在整个项目中，启着至关重要的位置，她贯穿于团队中每个职务之中，其它职务是针，她就是一根线，她可以对项目中每个人的工作进度监控、总结和传达任务。 4. 系统分析、框架设计 对系统进行构架设计、技术评估、开发环境，编写概要设计文档与设计规范文档，对各类技术点进行分析，要求技术全面，并掌握熟练，有丰富的项目经验，在各种环境下，给出最佳的解决方案。①业务分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何交互。通过描述一个或几个用例的需求状况以及其他支持软件的需求来获取系统功能某一部分的规约。还要负责用例包并维护该用例包的完整性。②构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口。因此，与其它角色相比，构架设计师的见解重在广度，而不是深度。 5. 产品经理 对系统功能需求分析、用户体验设计，编写需求文档，如果我们接到任务，我们的产品需要做哪些功能，产品经理必须给出需求，将功能项目实际的列举出来，不但要知道自己做什么样的东西，还要了解我们做出来怎么用，分析产品在实际运营中的一些需求，制定项目的功能开发阶段，现在一般的开发团队中还没有这个职位，其实这个职位对一个产品的好坏影响很大，我们在产品开发完成后，常常遇到一个问题，就是产品刚出来就感觉已经落后了。 6. 高级软件工程师(主程) 软件工程师负责完成设计师的设计意图，根据设计文档编写代码；根据设计文档编写单元测试代码，根据测试报告BUG己录修订BUG完成包或子系统的开发。熟练相关开发技术例如：JAVA, C#(.net) ，C++,C,汇编，3D方面等，负责项目的核心模块开发，编写模块设计文档，不需要培训就可以直接进入开发状态，是团队模块开发引领者和衔接者，一般经历过几个项目的人都可以担当。 7. 初级软件工程师(辅程) 懂java, C#(.net) ，C++，C能开发一些简单的模块，在技术上需要提高，现在大部程序员都喜欢写后台代码，逻辑思维强，写服务、API 代码比较好，做小型项目外包都没问题。 8. UI 设计、美工 界面设计人员通过以下方法来领导和协调Web 界面的原型设计和正式设计：获取对Web 界面的需求（包
软件开发团队管理手册
目录 1.前言 团队管理是项目管理工作的重要组成部分，是一种通过更好的团队合作来提升绩效的有效机制。本文档将对团队管理的过程作出明确的规定和说明。 2.目的 本过程的目的是通过更好的团队合作来提升绩效，加强团队成员之间的合作力度，更有效的管理和更好地作出决定，并提高生产率，从而获得更高的效率和更好的绩效。为软件项目团队的管理提供指导。 3.适用范围 适用于公司的所有的软件开发项目。 4.团队简介 团队是由员工和管理层组成的一个共同体，该共同体合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。 团队由目标(Purpose)、人(People)、团队的定位(Place)、权限(Power)、计划(Plan)等五要素构成。 4.1.团队和群体的区别 图团队和群体的比较 4.2.团队的类型 团队有以下几种不同的类型。 项目团队 项目团队是为某项具体任务而临时组成的团队。它通常是一个大项目团队的分队，为了完成某项具体任务而独立开展活动。项目团队的生命期取决于任 务的长短。 公司各个事业部独立承担且开发周期比较固定的项目都属于项目团队。例如：汽车回收系统项目，多面评价系统项目等。 部门团队 在部门内部长期从事某项工作的人组成了工作团队。工作团队使共同工作的员工之间配合得更加默契。对于工作团队来说，沟通和解决问题是关键任务。 公司各个事业部独立承担且开发周期比较长的项目都属于部门团队。 例如：水处理项目，证卷系统开发项目，铁路管理系统项目等。
跨部门团队 跨部门团队涉及几个部门的人员，它的目的是制订计划，完成一个项目或解决某个重要问题。公司各个事业部联合开发的项目都属于跨部门团队。例如： ERP系统开发项目等。 领导团队 领导团队由某位高层领导和他或她的直接下属组成。领导团队的工作是组织所有高层或中层领导参与项目决策和对项目实施提供资源支持。 公司领导直接负责和管理的项目属于领导团队。 例如：CMMI项目等。 4.3.过程总体概述 启动期动荡期规范期表现期调整期 5.过程活动描述 5.1.进入条件 根据项目需求,经过项目管理委员会审批,组建项目开发体制。 5.2.输入 立项书 项目开发体制图 5.3.启动期 即团队形成的初期。也是团队成员理解和接受他人，关注团队的时期。 5.3.1.启动期的特征 感受和想法激动, 骄傲, 害怕… 我们的任务是什么 ? 我们应该干什么 ? 可观 察到的行为表现 警惕,提防,焦虑，最低限度的沟通,缺乏自信团队需求了解目标、成员资格、角色、责任、工作任务、标准以及工作流程所需领导艺术--引导 引导 -- 确定目标, 明确任务,确定团队工作流程,时间,地点 5.3.2.团队组建初期的两个工作重点 形成团队内部的工作流程和管理框架。 建立和维护与客户的联系渠道。 项目团队组建初期的两个工作重点简单地说一个是对内，在内部建立什么样的体制；一个是对外，怎样跟客户保持联系。 (1)团队的内部体制需要考虑的问题： 团队的任务是什么？ 团队成员的需要有那些资质或资格？
关于软件团队建设
关于技术团队建设 通过最近几年的实践，对于软件开发的最小团队模式，有一些新的理解，和大家共享： ?很多团队，公司在成本压力下，总是希望寻求一个最经济有效的团队组合，这个是可以理解的，也是开发的初衷。 ?最小团队不是指单纯的减少人员，不是把一个需要5个人做的工作压缩为1个人做。 ?软件开发本身存在一个众所周知的弊病，就是只要存在一个能够编码的技术人员，那么软件就总是能够“做”的出来，这也给人一个假象，软件开发的最小团队就是一定数量的“码农”；这个在其他领域比如建筑和制造几乎是不可想象的，究其根源，是因为软件的质量标准过于的飘渺：我的意思是，最小团队绝不是几个“码农”。 ?人员可以合并，但角色不能合并；职能可以合并，但能力不能合并: 换言之,担什么角色就必须能做什么事情,就必须具备相应的能力. 总之,我对最小团队的看法,最小团队就是最少的角色,而这些角色不能再削减,但人员还是可以以兼任的 方式来合并角色,不过在兼任过程中要注意不能有名无实,同时需要具备胜任该角色的能力. 三要素 软件时开发的三个基本要素是：管理，业务和技术。 管理：除完全以单人方式进行的开发不在本文讨论的范围，2人以上就存在一定的团队管理，人员的协调，工作的安排，流程的部署，进度的监督等等，加上必然存在的客户管理，“鸟无头不飞”，说的就是管理者的必要性。 业务：很简单，软件做了半天是为什么而做，产生什么效益和结果，这个都需要业务来完成，业务来自于需求，深化为设计，由测试加以验证, 最后接受者是客户。 技术：更容易理解，没技术能叫软件开发？软件开发首先是技术活，但广义上来说，需求分析，系统设计和开发管理这些也都属于技术的范畴，只要需要方法论的地方就需要技术。 所以做软件先考虑其三大要素，是管理是否成熟，业务是否明确，技术是否过硬，就能知道软件是否能够顺利完成。 角色 下面我们从3个基本要素的基础上讨论下，探讨下我心目中的最少角色。 ?管理体系 n 项目经理：兼顾客户管理和团队管理2大职责，在小团队中，这两种管理几乎不可能再拆分。 ?业务体系
举例说明各种领导方式的优缺点
举例说明各种领导方式的优缺点，并结合实际谈谈怎么理解什么是领导？怎样进行领导？ 领导就是率领和引导，是一种个体引导群体达成共同目标的行为，是控制、指挥、协调多种工作和人际关系的行为系统。所谓领导(leadership)就是一种影响力，是对人们施加影响，从而使人们心甘情愿地为实现组织目标而努力的艺术过程。习近平主席对国家的领导是一种领导，学校校长对学校的领导也是一种领导，公司董事长对公司的领导也是领导…… 按照莱温的领导方式理论可以把领导者的领导方式分为三种：专制型、民主型和放任型。A.专制型领导：领导以力服人，即靠权力和强制命令让人服从。其特点是发号施令，要求 他人依从，为人教条且独断，主要依靠行政命令、纪律约束、训斥和惩罚，偶尔也有奖励。 岳明是一位空调销售公司的总经理。他刚接到有关公司销售状况的最新报告：销售额比去年同期下降了25％、利润下降了10％，而且顾客的投诉上升。更为糟糕的是，公司内部员工纷纷跳槽，甚至还有几名销售分店的经理提出辞呈。他立即召集各主管部门的负责人开会讨论解决该问题。会上，岳总说：“我认为，公司的销售额之所以下滑都是因为你们领导不得力。公司现在简直成了俱乐部。每次我从卖场走过时，我看到员工们都在各处站着，聊天的、煲电话煲的，无处不有，而对顾客却视而不见。他们关心的是多拿钱少干活。要知道，我们经营公司的目的是为了赚钱，赚不到钱，想多拿钱，门儿都没有。你们必须记住，现在我们迫切需要的是对员工的严密监督和控制。我认为现在有必要安装监听装置，监听他们在电话里谈些什么，并将对话记录下来，交给我处理。当员工没有履行职责时，你们要警告他们一次，如果不听的话，马上请他们走人……” 部门主管们对岳总的指示都表示赞同。惟有销售部经理李燕提出反对意见。她认为问题的关键不在于控制不够，而在于公司没有提供良好的机会让员工真正发挥潜力。她认为每个人都有一种希望展示自己的才干，为公司努力工作并做出贡献的愿望。所以解决问题的方式应该从和员工沟通入手，真正了解他们的需求，使工作安排富有挑战性，促使员工们以从事这一工作而引以自豪。同时在业务上给予指导，花大力气对员工进行专门培训。 然而，岳总并没有采纳李燕的意见，而是责令所有的部门主管在下星期的例
构建高效软件开发流程和团队
构建高效软件开发流程和团队 1.前言 (2) 2.项目计划 (2) 3.开发文档 (3) 4.编写代码 (4) 5.代码管理 (4) 6.测试 (4) 7.BUG管理 (5) 8.Code Freeze (6) 9.Tech Talk (6) 10.Code Review (6) 11.沟通与交流 (7) 12.后记 (7) 1.前言 本人曾就职于多家公司，但留给我印象最深刻、开发管理最规范的公司是I 公司。该公司总部位于美国硅谷，其开发的产品曾获得PC Magazine的最高五星级的优秀好评。现我根据在此公司中所感受到的经历及自身的一些感想写出来，希望能给大家和其它公司有所借鉴。 2.项目计划 在一个产品发布并使用之后，其中肯定有许多地方不如意和值得改进的地方。客户在使用的过程中会发现一些问题，提出更高的需求，市场也在发生变化，我们的竞争对手也在发展，新的技术不断地产生，这些因素推动着我们的产品不断地向前发展，使它的版本不停地往上增长。这些发展的需求不是一下子提出来的，在客户使用的过程中发现某些不如意不方便的地方，他们会向我们的技术支持人员提意见，而技术支持人员会把这些需求以BUG的形式存入BUG数据库中，其级别一般定义为下一个版本的Feature。有些上一个版本未解决的BUG也可能需要在本版本中来解决。因此当我们来开发下一个版本时，其许多特性已经存在
于BUG数据库中了。当然新版本的特性不是只从BUG中获得，管理层可能从市场的角度来提出新的特性以求领先竞争对手，开发人员本身也可提出某些要求来纳入新版本开发的计划中，如要求对某部分代码进行重构以使其结构更清晰更容易维护，执行效率更高。 每个人把同自己相关的功能模块收集起来，同时预估时间，其中主要包括写文档的时间、开发时间和单元测试的时间，一般要求精确到工作日。这些信息发送给组长，组长再把本小组人员的任务和预估时间发送给管理层，由管理层对此任务及进度进行评估审核，管理层会根据产品发布时间及客户需求、市场因素等方面作出选择，可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同预计的产品发布时间有较大冲突，而且此功能是本版本中必须得做的，则开发小组会被要求重新预估时间，加快开发速度来达到这个要求。 虽然这个开发进度时间是一个大概的估计时间，但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个Status Meeting（一般那时工作效率较低，适合开会），在此会议上我们会根据这个进度来review我们的工作，每个人手上的工作是否按照这个进度在走，是否有人延后了，是否block住别人的工作了。在此会议上每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个会议，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后，如果有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上，那也没有办法，只能修改原先的进度表，因为那是我们的估计与现实发生了偏差，我们必须使我们的进度表符合实际情况，这可以避免许多项目发生最后的20%的工作量会占据80%甚至一直拖后的情况。修改进度表的情况我们曾经发生过，有一次在按照原先的进度执行到将要完成的状态时突然接到通知由于市场及客户的原因要求加入另一项重大的功能，这个功能对我们程序的结构有非常大的影响，因此我们就要重新制定一个进度来满足需求。在这种情况下，产品原先的开发进度被打乱，发布时间也因此推迟。当然这种情况应当尽力避免，尤其在项目后期产生新的需求，若不得已也应重新规划进度，而不是仍旧依照原先的进度去执行，因为老的进度已不能反映现实的情况。 3.开发文档 在项目进度安排中我们已经把写文档的时间也规划进去了，这里虽然是写文档，其实是设计程序，整理一下思路与架构，磨刀不误砍柴工，这样在实际写代码时会流畅很多，节省时间，因此可以说真正有思想性的东西都在写文档这段时间内完成了。当然我们这里的文档格式不象ISO那样规定了条条框框，我们的文档格式相对自由，基本上能随意发挥，但对于几个主要点一般来说是需要说明的。要求写的文档能让他人比较容易地看明白，能把问题讲清楚，能反映你的设计思想。文档的数量也不多，开发文档有两类，一类是Function Spec，另一类是Design Document。 Function Spec中需要写明的是本模块完成的任务，解决什么问题，有什么作用，为什么要这些功能，此外我们还会添加进适用范围，有什么不足，注意点是什么，还有哪些地方在以后可以进行改进。在这个Function Spec中不涉及到任何非常详细的算法。此文档不光给开发人员看，还让QA及其他成员以及后来
软件开发管理团队
软件开发管理团队 分析国内外主要软件开发管理团队的现状。 很多国内搞计算机的专家都认为：国内的软件研发过程，个人色彩比较浓。过分地依靠个人无法形成产业规模，而没有规模就谈不上产业化了。我国软件产业的市场规模在世界软件市场中只占0．3％左右的份额；即使在国内市场上．中国公司开发的软件产品的占有率也只有大约30％，大部分市场仍然被国外公司所占据。中国的软件产业在世界市场上仍处于赶超阶段，我国大部分软件企业还大都面临着软件开发超期、超预算、软件产品的质量不能使最终用户满意等问题，如何缩小中国软件产业与其他国家的差距，实现跨越式发展已非常迫切地摆在学术界和产业界面前。软件产业属于完全基于知识的产业，因此，其产业内的人力资源(尤其是软件开发团队)状况成为该产业发展的关键要素。 国内团队的现状 但整体来看，目前我国软件产业总体规模仍然太小。2005年，我国软件产业占全球市场的份额仅为5.9%。而同年，美国、西欧、日本占全球市场的份额分别为39%、29.5%和10.4%。我国软件企业以中小企业为主，软件收入前100家企业销售收入平均仅为1亿多美元。软件企业多以从事定制项目和一般应用软件为主。对于大多数软件企业来说，没有一个良好的切入点，走独立发展的道路难度比较大。企业竞争力不强，无法形成产业的竞争性优势，导致我国软件产业在全球软件产业分工中定位不清 国外团队的现状： 20世纪90年代以来，世界软件产业获得了飞速发展。据IDC统计，全球软件业的年均增长率一直保持在15%～20%之间。目前，全球软件业已经开始进入成熟期。产业分工较为明确，产业成熟度较高，成本已成为企业竞争的首要因素。发达国家的软件企业从降低成本考虑，逐步集中力量发展核心业务；利用全球的人力资源，将大量非核心业务向发展中国家转移 软件行业团队管理（人力资源）管理的评价体系有哪些。 人力资源管理评价指标体系设计原则 共有以下三方面：第一，系统性原则。企业人力资源管理评价指标应从系统的角度出发，全面地、系统地反映企业人力资源管理系统中的各个子系统及其相互协调以及整体运作。第二，科学性原则。纳入企业人力资源管理评价的每一个指标都要有明确的内涵和科学的解释，要考虑指标选择、指标权重确定、数据选取时的可比性和计算方法的科学性。第三，目标一致性原则。目标一致性原则指的是在评价系统中，应在系统目标、评价指标和评价目的之间取得一致。第四，可操作性原则。指标的设计既要考虑有数据的支持、数据获取的难易程度和可靠性，又要考虑计算方法的简易性等。第五，可比性原则。评价指标要具有
ERP项目实施中的团队建设
ERP工程实施中的团队建设 有很多关心ERP或正准备实施ERP的朋友都会问这么一个问题：“到底怎样才能成功地实施ERP工程呢？其中有哪些关键要素呢？”这的确是一个很大的话题，可能三天三夜都细说不完。其中包括诸如工程“一把手”工程、高效先进的实施方法、明确的实施目标与范围、有效的计划控制与时间管理、不断进行阶段性工作总结、必要的风险控制与应急措施等等大家比较熟知的内容。但其实还有一点尤为重要，却也非常容易被忽视的一个因素就是人——工程的团队建设。我们知道，在一个企业中，参与到ERP工程实施的成员都是由各个相关部门的关键人员共同组成，而这样一支由不同业务部门、不同业务背景、不同素质的人共同搭建的临时队伍怎样才能在共同认同一个工程目标、一个工程的工作方式的前提下，按照紧迫的工程实施计划共同完成好艰巨的ERP建设任务呢？这也正是ERP工程的团队建设的重要性，它也将从很大程度决定工程实施在多大程度上的成功。 企业ERP系统是通过信息技术这一手段把优秀的、规范的管理固化下来，同时也通过信息技术的革新带动管理的进一步优化。在这其中，信息技术与企业管理是有机结合的，并相辅相成，进而达到合理配置企业资源、降低成本、提高生产效率，最终加强企业的核心竞争力，以实现利润最大化。那么ERP工程的实施必然会涉及到企业管理的方方面面，譬如：销售管理、财务核算管理、采购管理、存货管理、生产管理、人事管理、成本管理等等。而这些管理又是通过企业的各个组织单元或各个部门互相协同来完成的。即，企业实施ERP工程绝不是企业信息技术部门可以独立完成的，它必须是由企业实行各项管理职能的相关部门与企业IT部门共同来完成的。这也是为什么人们总是说“ERP工程是一把手工程，ERP工程需要企业各相关部门的共同参与”的缘由了。其实，说到底这就是一个围绕着人的话题。一切以人为本！ 考核与激励并存 一般而言，ERP工程实施的参与者，除了IT人员外，其他人员一定是自身的岗位工作与工程工作齐头并进的。于是关键问题就在于，如何保证这些人能对工程工作非常投入而且保证工程工作的顺利开展。这就必须要将其所担负的工程工作纳入到其绩效考核中去，让他意识到工程工作并不是可有可无的，是与其本职工作同等重要的。工程工作完成的好坏也是直接与其个人收益挂钩。但光有考核也是不行的，这样只会对实施者产生被动无奈甚至抱怨的感觉，如果工作量超负荷实施者很容易造成破罐破摔的心理。因此，还需要有激励的手段，如：高层领导直接关注、单独设立工程奖励基金、升职、延长带薪休假、给予培训深造的机会等等，这些手段的运用会很好地激发实施者的工作热情与上进心。这样，实施者就会从被动无奈中转变成主动投入，而且将会对工作发挥创造性作用，如果这方面进展得较为顺利，那么这支队伍已具备了一个良好的基础环境。 增强团队凝聚力与个人成就感 ERP工程组毕竟是一个临时搭建的组织，它只为工程目标而存在，因而不可能成为一个长期的部门，因此，参加ERP工程实施的人员对工程组明显缺乏归属感。又由于ERP工程的实施存在着许许多多“知与行”的矛盾，甚至有的工作将会反复，每个参与实施的人都可能随时遇到挫折，如果这样的情绪不及时进行调整，在队伍中弥漫，工程实施可以说是“风中之烛”，有随时熄灭的危险。如果发现这支队伍中有这样的问题，需要及时进行调整，沟通思想、组织活动，拉近人与人之间的距离。譬如说利用业余时间开个沟通会或者组织去户外进行集体游玩，
企业四种组织形式的优缺点
作者：杨柳君 斯坦福大学的一个研究项目完美地解决了四种组织形式的问题，两位著名的组织学者詹姆斯－巴伦（James Baron）和迈克尔－汉纳（Michael Hannan）主持了SPEC（Stanford Project on Emerging Companies）。 斯坦福大学SPEC研究项目报告给我们列出了“四种组织形式的优缺点”。我最近在读中欧肖知兴老师的书，这个报告资料是我在他的书中看到的，在此向他表示敬意。 在斯坦福大学SPEC研究项目报告中，四种组织形式分别为： 科层型组织、明星型组织、专制型组织、投入型组织。 说点题外话，在肖老师的书中看到这个报告时，我对建模型的重要性，有了更深刻的认识。 平时工作、生活中，我们很多人喜欢“捣浆糊”，一件事情翻来覆去的讲，也没讲明白，下次遇到同类困惑时，还是缺乏严谨、周密的解决之道。 一方面可能没这个能力提炼，一方面应该是没这个意识。 其实，正如我们所了解的，只有建模型，才能将复杂问题简单化，抓住事物的本质。 在实际工作中，我们的组织依据自己的战略或资源，匹配相应的组织形式。然而，正如我们所了解的，每一种组织形式都有其优缺点，我们在享有他的优点时，也必须正视他的缺点。 当我们的企业以某一种组织形式运作时，总有一些员工放大该组织形式的缺点，牢*满腹，这样就无形中给我们的管理者带来了很多管理沟通的难题。 而很多似乎关于“沟通”的难题，其实并不是“沟通”的技术能解决的，不是关于“怎么有技巧的说话”的问题，要真正解决他，我们得在产生沟通障碍的本源上找症结。 很多时候，企业中存在的“沟通”障碍与沟通技巧关系并不大，但在实际工作中，我发现很多企业的管理者有可能没看清这个问题。 比如不同企业组织形式运作中自然生出的关于“优缺点”的问题，解决之道是对管理者进行企业组织形式模型的培训，让他们心中有一本清晰的账，清楚的知道各种组织形式的优缺点。 这样，当他们在面对员工对所在企业组织形式缺点的抱怨时，便能坦然的化解，不至于连自己都迷失了。 在斯坦福大学SPEC的报告中列出： 1、第一类－科层型组织： “‘科层型组织’的特点是：程序、规则，责任。 ‘科层型组织’的优点是：效率较高；不依赖于个人，规模可大可小；公平；适合多种类型的公司。 ‘科层型组织’的缺点是：不灵活；管理费用大；不讨员工喜欢；不适应
强势的软件研发团队组建
一、强势团队人员需求及描述 团队中包含：研发部经理（即技术总监）、leader、项目经理、项目助理、系统分析、框架设计、产品经理、高级软件工程师（主程）、初级软件工程师（辅程）、UI设计、美工、 1.研发部经理（技术总监） 对系统方向和团队中一些决策性的事进行管理，包括日常事务，虽然他不需要编码，但能担任技术总监，他经历了设计开发，产品的实施，并对系统的战略性发展都有相当的见解，对整个系统的所有流程都面面具道，不单单局限于技术层面，因为他需要主导整个团队运作。可以跟客户交流需求、根据需求分派任务。 2.Leader 管理项目组成员、技术难点分析，编写详细设计文档，技能特色很突出，有创新能力，不是什么都是从网上拿下来一改就用的，其它方面都可以讲出一二，对行业内的动态都很关注，有一定的交际能力。可以跟客户交流需求。 3.项目经理 项目经理负责分配资源，确定优先级，协调与客户和用户之间的交往。总而言之，就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。懂开发，知识面广，针对项目，对系统进度的控制，风险评估进有把控，根据反馈的客户需求，分派具体工作内容，项目中日常事务调配，人员配置，具有一定的的沟通能力。可以跟客户交流需求。
3.1项目助理 对会议、文档、日常事务的跟踪进行管理，这不只是助理一职，这个职务在整个项目中，启着至关重要的位置，她贯穿于团队中每个职务之中，其它职务是针，她就是一根线，她可以对项目中每个人的工作进度监控、总结和传达任务。 4.系统分析、框架设计 对系统进行构架设计、技术评估、开发环境，编写概要设计文档与设计规范文档，对各类技术点进行分析，要求技术全面，并掌握熟练，有丰富的项目经验，在各种环境下，给出最佳的解决方案。①业务分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何交互。通过描述一个或几个用例的需求状况以及其他支持软件的需求来获取系统功能某一部分的规约。还要负责用例包并维护该用例包的完整性。②构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口。因此，与其它角色相比，构架设计师的见解重在广度，而不是深度。 5.产品经理 对系统功能需求分析、用户体验设计，编写需求文档，如果我们接到任务，我们的产品需要做哪些功能，产品经理必须给出需求，将功能项目实际的列举出来，不但要知道自己做什么样的东西，还要了解我们做出来怎么用，分析产品在实际运营中的一些需求，制定项目的功能开发阶段，现在一般的开发团队中还没有这个职位，其实这个职位对一个产品的好坏影响很大，我们在产品开发完成后，常常遇到一个问题，就是产品刚出来就感觉已经落后了。 6.高级软件工程师（主程） 软件工程师负责完成设计师的设计意图，根据设计文档编写代码；根据设计文档编写单元测试代码，根据测试报告BUG记录修订BUG，完成包或子系统的开发。熟练相关开发技术例如：JAVA, C#(.net)，C++,C,汇编，3D方面等，负责项目的核心模块开发，编写模块设计文档，不需要培训就可以直接进入开发状态，是团队模块开发引领者和衔接者，一般经历过几个项目的人都可以担当。 7.初级软件工程师(辅程) 懂java, C#(.net)，C++，C能开发一些简单的模块，在技术上需要提高，现在大部程序员都喜欢写后台代码，逻辑思维强，写服务、API代码比较好，做小型项目外包都没问题。