l公司的入职培训分6个课程，为期三天，分别为：企业介绍c软件项目管理c软件质量管理c项目团队协作i体系介绍c公司管理制度。
第一课：企业介绍，由行政部经理主讲，无非是企业发展历程c部门机构c公司价值观c愿景c文化c高管介绍等内容。短短几年，就杀入了营业额数亿俱乐部，够吓人的。当然这个数字的背后依赖于什么，大家心知肚明。同时入围深圳软件百强企业，什么双软c高新技术认证更是不在话下了。无非是培养新员工的自豪感和归属c认同感。
第二课：软件项目管理，由研发部的高级项目经理主讲，这个课题内容范畴有点大，大学软件工程专业课就有所涉及，但讲师结合项目实际讲解得更为实用，从需求c设计c开发c测试c上线部署c运维全程讲解了各阶段的文档输出，其中涉及项目计划c度量c配置c监控c评审c风险c产品集成等诸多内容。
软件仅仅是编码吗？我想不仅仅是外行人，很多行内人的理解恐怕也仅仅停留于此。第一次在系统工程的层面去理解软件，改变了我狭隘的认知。
软件开发的真实目的是什么？客户要的不是代码，而是利用这些代码的辅助来实现其商业目的。需求分析需要关注和收集什么？仅仅是客户提什么就实现什么吗？对于开发人员来说，只有编码唯一一项工作吗？一个软件的全生命周期里，交付运维后的生命存续通常占据了整个生命周期的90以上，交付上线项目即告完成了吗？在决定项目成败的前几大风险因素是什么？据统计倒还不是技术类风险，依次为：需求不明确c需求变更c分析不完善(客户/范围风险)，其次是人员流动(内部风险)c质量控制(质量风险)c进度延迟(进度风险)，最后才是技术c外部环境风险，前2者导致项目失败的情况占据了90以上。一个项目组成员如何搭配，是人越多越好吗？项目监控仅仅是上线前才关注的事情吗？客户需要对整个项目做哪些阶段确认？这种知识和经验的受益在学校是无论如何也学不到的。
第三课：软件质量管理，由质量管理部的经理主讲。她首先询问我们：“到底什么是产品质量？”符合用户需求c0缺陷c可靠耐用c用户满意大家的回答不一而同。工业化生产有质检环节，是保证产品质量的最后一关，那软件产品本身呢？是软件就会有bug，仅仅依赖于交付前的测试？软件质量与系统分析/设计/开发人员都无关吗？我们到底又如何去理解和保障软件质量？
她首先列举了几位大师的观点，对我的认知是为之一震的：
1质量就是符合要求的，而不是最好的；
2质量系统的用来预防的，而不是用来检验的；
3质量的标准是零缺陷，而不是差不多就好；
4质量是设计出来的，而不是检查出来的。
以此为论，软件产品的质量是要从源头需求调研c软件设计抓起，是需要全角色成员的参与，而不能完全依靠测试人员。对于需求分析阶段，需要尽可能地明确系统设计目标，充分准确把握客户需求并确认，尤其是潜在需求c非功能性要求；在系统设计阶段，除需要设计出满足范围内需求的全部功能外，还必须考虑系统的扩展c容错和可靠性，而不是勉强能用；对于开发阶段，开发人员绝不能仅满足于实现功能运行无误就行，还必须考虑极端情况下的输入项验证c对高访问量c高并发情况下的支撑c良好的ui交互c用户的操作习惯c极端异常操作下的各类容错处理等等，并且开发人员对自己开发的程序必须要进行单元测试，不仅仅是ui上的鼠标点几下操作，连代码内部细节通过肉眼都要进行审查和优化，注释和文档与编码工作一样重要；在系统测试阶段，除了常规的集成测试(综合测试)c系统测试(业务测试)之外，还要加入边界c压力等测试。没有一个独立强大的第三方测试部门，又如何在最后一关保证软件的质量？
我见过国内的很多中小型软件公司，没有独立的测试部门，甚至专业测试人员1个都没有，最多也仅安排一个行政或美工c文员兼任，这种流水线所交付的软件，能达到软件产品的基本质量要求吗？我深度怀疑。更有甚者一个项目在客户环境里运行了1一2年，用户和数据量急剧膨胀，需求变更和追加源源不断，运维和开发部门最后发现，无论如何修复和重构更改，项目都难以为继，工作量越来越大，感觉还不如推倒重写，陷入两难境地。或者运维阶段后续的二次开发，接手者发现项目毫无注释和文档，交接往往没有或很短暂，维护起来异常痛苦，这些情况在国内绝对不是个例。系统分析c设计的缺陷一大堆，项目经理心知肚明也无可奈何，都是在为前期的短视c成本压缩买单吧。
短期见效c控制成本c重技术轻管理c重编码轻测试，这也就是国内很多it软件公司的通病症结所在，需要引起我们的重新反思。
第四课：项目团队协作，由一个项目管理部的领导主讲。讲师首先播放了一部影片，源自港片的一个片段：描述了团队小组的3个成员，借助相互紧密默契的配合，成功突破写字楼的安检防护系统，窃取到一机密设备，并成功逃脱完成任务的故事。这类故事我们在影视作品里已经看了很多了，并无新奇，如《碟中碟》系列c《加里森敢死队》c《速度与激情》c《十八罗汉》等等，远的如《西游记》c《水浒》，近的如当时热播的《越狱》其实都属于此类题材。
《越狱》在作品中就将团队协作诠释得很完美和有趣了：一伙未经训练c临时拼凑c甚至还相互间隙敌视的狱友，借助利益交换达成合作意向，在共同目标的驱使下，突然变得默契异常。他们没有选择，内心其实非常清楚：通往自由的希望之路只有一条，要么拼尽全力依赖团队突围出去，要么就在监狱里度过后半生，或无法如期见到自己的亲人。icr一无疑是这个团队的天才领袖。
一个很简单的问题摆在我们面前：不依赖于团队协作，在这个世界上，很多目标我们能通过单枪匹马达成吗？很多人都知道团队合作的重要性，但在实践中又往往抛于脑后，触及不到其本质。
历经蒸汽c电气c信息技术三次工业革命，人类进入高度精细化分工和自动化时代，如今代表万物互联c智能化的第四次工业革命业已到来。个c十来个人组成的项目团队司空见惯，在华为，还存在上千人规模的大项目团队协同开发，工厂流水线的各部门对协调能力尚且要求很高，更何况知识密集型的软件行业？稍微大一点的项目，在系统分析c设计c开发c测试阶段就存在着明确的分工，所以说，在软件行业，团队协作的重要性是毋庸置疑的。团队精神，在日后我自己作为面试官或项目管理者，被当做一项必备的职业素质来看待。
在国内十几年的教育系统里，是没有关于团队协作相关课程的，实践更无从谈起。我接触过很多刚迈入社会的高校毕业生，人占其位，只顾其职，或以自我为中心，或埋头闷干，连基本的团队沟通协同能力都没有。在it 业内传统的价值理念里，技术至上论风靡一时，即一个技术人员倘若自我感觉良好自认技术大牛的话，他的目光是空无旁人的，甚至不知团队协作为何物，我行我素，对同事的意见c项目经理的建议置若罔闻，遇到对技术持不同观点的讨论时，习惯于排斥一切他议，以自我观点自居，患有很强的心理强迫症。团队成员拥有不同的声音是正常现象，但一味固执己见导致团队内耗或远离目标，则是一个问题。对此类人员，其实我认为他作为一个技术工程师至少是不合格的，他们都忘记了几个重要的问题：
1软件的最终目标，不是炫弄多牛b的技术，而是帮助客户实现其商业价值；
2技术是实现项目目标的重要因素，但记住，很多时候不是影响项目成败的最关键因素，因为在更迭如此之快c知识爆炸的今天，技术方案的选择是如此之多，方法总是比问题多。讨论到底用哪一种技术方案解决问题不重要，争执本身毫无意义，明智做出决策去解决问题本身才是最重要的。理解了这一点，你就会知道自己的位置，和应该怎么做。
在我的职业生涯里，看到很多项目组为一个技术问题争执不休，甚至还相互斗气，项目经理亦难断方案，项目进度一拖再拖，成员之间的关系氛围也变得糟糕，实在是觉得可笑可悲。这样的项目团队倒不如静下来作自我检讨：我们团队存在的意义到底是什么？还有没有存在下去的必要？
人在一起是团伙，心在一起是团队。团队是什么？它必定不是乌合之众，按照我的理解，通俗点说就是一群人通过知识c技能的协调配合工作，解决特定的问题或达成共同的目标。
团队的要素或特征在于：
1有共同的目标，无法达成一致的目标时，团队的存在毫无意义；
2由人组成，且有明确的权限和分工，缺一不可；
3依赖于成员间的信任c良好沟通c互助协作才能达成目标；
4拥有应变c自我学习进化能力；
5需要内外环境的支持；
项目管理的本质也就很好理解，即在一定时间内，组织团队完成特定的目标。团队组织无处不在，学校的班级c军队c体育团体c社团组织个企业乃至一个家庭，广义上都可以理解为一个团队，只是有些团队临时拼凑，目标多元化针对性不太强而已。在自然生态里，狼群便是典型的群体动物，具备很强的团队合作精神，以至于借助团队力量能够以弱胜强，无往不胜，为华为老总任正所非所津津乐道，借引为企业管理精髓。
越是高目标c专业性越强c人员越精干的队伍，对团队精神的要求越高，可理解为一部精干强悍的机器在高速运转，任何一个部件出现问题，极有可能出现系统故障甚至瘫痪罢工，从而无法完成目标，如特战部队。管理中有一个有意思的现象，暂且称之为11理论，即团队成员的能量可以11一2，也可以大于2，或小于2。当一个团队在沟通c协作出现问题的时候，很可能会出现内耗，导致团队受挫。所以我尤其强调，在软件项目组这样的专业团队里，团队合作精神是成员的必备素质，默契的配合比锋芒毕露重要，记住。一旦发现某个成员个性太强我行我素c目无团队不愿纠正的时候，我是倾向于立即换人。
作为技术工程师，我认为必须改变以往的固有认知，除了提高自身的专业技术水平外，还应将团队精神植入内心，有所深悟，作为必备的职业素养去修炼。
具体应该修炼什么？我个人认为，团队精神包括如下几个要素：目标c信任c沟通c分享c互助c自我学习。
1目标：团队以实现特定目标或完成一定任务为第一要务，作为成员所有人必须首先清楚共同的目标，将之作为行动使命，如果对团队目标不清晰或理解不一致，势必导致配合的偏差。完成目标比个人的个性张扬或主见伸张更重要，记住。
2信任：成员之间必须保证100的相互信任，尤其是对团队管理者的信任，适当抛弃个人成见，坦诚相待，乐于奉献，而不是心怀猜疑c拉帮结派c处处索取。
3沟通：这点毋庸多叙，没有沟通或沟通不畅的团队只不过是一盘散沙，在对手面前不堪一击。具体在项目管理里，对需求c设计文档必须先保证充分的理解，再去编码，不清楚之处必须及时与分析c设计人员沟通，测试是对开发成果的纠正和反馈，不要对测试心怀抵触，出现bug是正常现象，及时和测试人员保持沟通。开发工程师遇到技术问题自己尝试解决无果后，及时寻求团队成员协助，仍无法解决则必须向技术经理或项目经理反馈，因为一个问题的受阻势必影响项目进度，这不是一个人要面对的问题，记住。项目周c月c阶段c总体计划c项目周报c工作日志c例会也是沟通的一部分，作为项目经理，应该定期召开项目例会(通常是周例会)，及时了解项目进度，倾听问题反馈，并做阶段总结，评估风险，及时调整下一阶段计划。
4分享：这恐怕是这几项里最难达成的要素。众所周知的原因，技术人员大多有保守个人所掌握的技术c不愿分享的心理倾向，我见过有的工程师甚至将自己的技术包裹起来，即使项目组成员向其请教，也一口回绝。在我看来，这种人的路是窄的，他忽视了禅宗里的一个基本常识：好的东西只有拿出来与他人分享，你才能获得更多，记住。这个世界上，没有一个人能解决眼前的所有问题，掌握所有的门类知识或经验。互助就是一种分享，培训本身就是分享的最好方式。如果是他人公司的核心商业机密，出于保密无法共享倒可以理解，除此之外，很多东西与他人分享何乐不为？无论是知识c技能还是经验c快乐，能促进团队成员间的信任感，提高效率，更重要的是，他人也同样愿意与你分享，这是人感恩回馈的本能。分享极大地促进相互进步，形成知识互补，互联网的精髓也不在于此吗？久而久之使团队演化为学习型组织，拥有强大的知识经验库和创新能力，这样的团队才是最为可怕的！
5互助：重要性不必多言，作为团队成员，只需牢记一点：一个人不管有多牛b，缺少了团队协同，连存在的意义都没有。团队每个成员都不可或缺，很多时候人类是依赖于彼此才能抵达目标，只有分工的不同，不存在等级尊卑，指挥协调决策也仅仅是项目管理者的职责。在艰巨的任务面前，所有人都只有一个命运，互助是双向的，个人的得失显得微不足道。在很多影视作品中，特战部队往往深入敌后，深处危险的境地，任何成员稍有闪失，便随时可能将整个团队葬命敌手，导致任务失败。团队就是一个整体，精密运作如机器，没有零件间的协作立即瘫痪。有机会可以参与一些户外拓展运动，对互助协作会有更深的体会。
6自我学习：外部环境是不断变化的，唯以应变面对万变。在特种作战的影视作品中，会看到计划好的方案，到了敌后环境突然发生了巨大变化：人质转移了，或情报有误敌人力量增强了，或遭突然伏击，这些都无疑考验着团队的应变能力。软件项目亦是如此，客户需求的变更c团队成员流动c代码质量低下c某些政策的改变c甚至客户高层的人事变动皆为外部变化，都需要项目经理及时采取策略应变，团队成员亦不必为变化感到惶恐，不变是理想的，变化是永恒的，注意系统设计c开发的扩展性和容错行，减少耦合，尽量避免硬编码，同时还需不断地学习新技术。一个项目不能替客户解决所有的问题，项目经理还需注意控制项目的应用边界，明确上线标准，和客户协调项目开发的分阶段性等等。
最佳实践：因职业上的原因，研发技术人员大多偏内向c低调c表达能力偏弱，作为项目经理，绝不是个高高在上的管理者，除了对项目的全程跟踪，还有义务调节团队氛围c释放激励，促进成员间的磨合沟通。如为项目组成员争取活动经费，周末组织轻松快乐的业余活动(如打球c爬山ck歌等)，会议中适当加入幽默调侃，公开鼓励表现好的成员，记住：鼓励永远比抱怨有用。此外，借助中午一起聚餐是个简单有效的方法，让团队成员有更多的机会交流沟通，增强凝聚力。时间允许情况下不要忘了培训，让所有成员有机会参与主讲能增加团队的归属和认同感。
团队需要磨合，组织参与野外拓展c户外团体运动是强烈推荐的方法。工作作风严谨但氛围可以快乐，业余生活更要传递轻松快乐，以调节工作上的压力，自由和快乐是人的本能追求，不是吗？适当调节团队的性别比例，避免阳气过重，如测试和美工优先考虑女性，技术过关前提下亦可考虑女工程师，关注人性，道法自然，天人合一，有什么比快乐工作效率更高呢？
团队协作很有意思，很大程度上考研着项目经理的管理才能，当团队迸发出惊人能量，抵达目标的那一刻，是人生非常值得怀念的美好时光，这种成就感比个人单枪匹马的成功要大得多。
笔趣阁读书免费小说阅读_www.biqugedu.com