团队沟通

转载自：https://www.cnblogs.com/zer0Black/p/11819696.html 我是如何失去团队掌控的？ 我是一个不合格的技术总监，在过去的快三个月里。我带着从40多个人的研发团队（包含需求、开发、测试）里抽调出20多个人去为公司开疆拓土。在这快三个月中，我们一起奋战奋斗拼搏。在过程中，我通宵时间超过半个月，干到凌晨4/5点的日子数不胜数，干到凌晨1/2点日子更是习以为常。整个团队绝大多数人近乎两个月没有周末，辛苦异常，是实实在在的高峰体验。但是三个月后，我带着失败和一身的惨痛教训回到公司。 我在这次的经历中感受到了我是怎么失去团队掌控力的。我所谓的团队掌控，不是说兄弟们不听安排，不按计划行事。而是我对整个开发团队、测试团队、需求团队都有了新的认识，重新认识了团队，重新认识了这二十多个人。因为对个人和团队的能力判断误差和对项目难度的判断失误，导致了这次惨痛的教训。 我把我所面临的的困境和遇到的问题分享给大家，也将把我所做的决策分享给大家，并把我所意识到的错误分享给大家。希望能给每个面临此种局面的同行进行提醒。 项目和团队背景 共计三个月内有四个项目，没有正式的项目经理，只有三个实习项目经理 三个实习项目经理中，一个带过一个小型持续性项目（前后端共3人）接近一年；一个带过小项目（4人）一个月；一个带过两个中小项目（7人），共计半年时间 开发同事都相对年轻

　　沟通与协调是进行各方面管理的纽带,是在人、思想和信息之间建立的联系。沟通管理是项目管理的九大知识体系之一，在项目整体管理中有着极其重要的意义和作用。沟通研究专家勒德洛（Ludlow,R.）曾经说过：“高级管理人员往往花费80%的时间以不同的形式进行沟通，普通管理者约花50%的时间用于传播信息。”提高沟通管理是提高项目管理的关键。因此研究软件项目管理中沟通管理，提高沟通水平，是十分必要的，也有着重要的现实意义。 　　一、软件项目管理中沟通管理存在的问题 　　（一）项目前期准备不足 　　在识别阶段,项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以至于无法得到完整需求或最终经权威用户代表确认的需求。加上项目干系人的要求包含明确的和隐含的,不同的干系人其愿望和追求的目标往往相差甚远,因此对项目干系人的愿望进行平衡可能是相当困难的事情。而且客户参与程度不高,客户方面的相关责任人不明确或对范围和要求责任心不强,提出的要求具有随意性,项目前期对需求的确认不够积极。博士论文，项目管理。有些时候项目交付时的系统与原来设计的系统有很大差异,这与项目团队对用户需求的挖掘不足有关,也就是说在项目前期没有与客户进行有效的沟通。 　　（二）重大决策过于仓促。 　　在时间的压力下,很容易做出仓促的决定。即管理学上的芝麻绿豆原理:就是对于重要的事情两三天就下决定了

技术Leader是互联网公司中，战斗在一线的技术领导者，技术Leader们能力的强弱，决定着公司整个技术团队的战斗力，结合我之前管理上百人技术团队的经验，谈谈我心目中优秀技术Leader五个方面的能力要求。 一、技术能力 系统设计和开发能力。技术Leader要熟悉业务领域内的系统架构和相关技术，能根据业务特性,合理进行分层设计,实现最高效率、低运维成本等等。 对于重要而复杂的系统，要求做好过载保护措施，以及资源的动态分配和优先级管理等。 技术运营。主动分析系统各项指标以及变化，通过监控数据和统计手段对系统性能情况、性能变动规律及原因、各项重要业务项数据变动情况，并做出对未来的资源规划等。 二、业务能力 业务知识。能够提出改善业务流程的合理化建议，并被客户接纳，不仅熟悉与自己领域相关的流程、专业知识，而且对公司主体业务领域业务知识也了解。 产品规划。对Team内的产品方向有总体把握能力，推动产品经理、业务做产品近期、远期的规划。 三、项目管理能力 敏捷开发。能够在团队内部主导和推动敏捷开发。 项目管理。能够独立负责中型项目的实施和运作，清楚了解项目的关键因素，在现实情况和有限条件下做好任务分解和进度安排。 针对计划合理地调配和充分利用现有资源，解决项目中大部分问题；在活动过程中充分预见可能的问题，并提前确定相应的防范应变措施；有风险管理意识，懂得如何识别和管理风险。 四、团队管理能力

Soft skills are always hard than hard skills. 软技能比硬技能难。 老板听说最近流行“微服务”，问架构师咱们的系统要不要来一套？老板又听说最近流行“中台系统”，问架构师咱们要不要搞起来？其实，这些问题不用老板问，关注技术发展趋势的架构师每当听到新的技术或解决方案，都会暗中思忖是否应用到系统中。然而，用或不用，总不能凭感觉吧。此时，如果你能灵活运用康威定律，那么做出的判断将更加完美。 康威定律 康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。 跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。 康威定律可谓软件架构设计中的第一定律，起初只是在杂志上的发表，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。 只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四个定律： 第一定律 组织沟通方式会通过系统设计表达出来。 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。 第三定律 线型系统和线型组织架构间有潜在的异质同态特性。 第四定律 大的系统组织总是比小系统更倾向于分解。 第一定律 Communication dictates

问题一： 第一章中陈述了软件工程的目标是创造足够好的软件 。那么，何种软件才是足够好的，是否有客观评价的标准，我们在开发过程中应以什么样的标准为参考？ 问题二： 第三章关于初级软件工程师的成长提到了五个方面的内容， 1.积累软件开发相关知识，提升技能技术，2.积累问题领域的知识和经验，3.对于通用的软件设计思想和软件工程思想的理解，4.提升职业技能，5.实际成果。 然而，作者又在49页的职业发展中提到了考级之路，两者在工程师的发展过程中，孰轻孰重？应以哪方面为主？两者之间又有怎样的关系？ 问题三： 第四五章中提到了两人合作以及团队模式的问题，面对一个软件项目如何选择团队模式，如果在开发过程中，团队里两两之间的磨合时间过长，导致开发速度缓慢，应如何应对？团队模式定下后，如果发现不合适，要不要及时更改，还是在观望一段时间？如何处理开发时间和团队磨合之间的矛盾？ 问题四： 第七章中讲了MSF的基本原则，不难发现，九条之中有三条和沟通有关，分别是第一条：推动信息共享与沟通，第八条：学习所有的经验和第九条：与客户合作。 然而，在实际的项目开发中，团队中人数越多，沟通所花费的时间成本越多，那么，最大的开发效率和人数有何种关系，是与人数正相关吗？如何达到开发效率的最优化？ 问题五： 书中第九章讲解了关于PM的相关知识，详细的阐述了PM的职责和能力要求，但在实际中

软件质量保障的体会 问题1答案 软件开发过程中的包含的风险控制，项目中间阶段的交付质量的代价，项目管理工具的因素，软件开发成本的控制，内部质量指标的完成情况。这些都是需要注意的！ 问题2答案 1、 计划： 项目范围、项目质量、项目时间、项目成本的确认。 项目过程/活动的标准化、规范化。 根据项目范围、质量、时间与成本的综合因素的考虑，进行项目的总体规划与阶段计划。 各项计划得到上级领导、客户方及项目组成员认可。 2、 组织： 组织项目所需的各项资源。 设置项目组中的各种角色，并分配好各角色的责任与权限。 定制项目组内外的沟通计划。（必要时可按配置管理要求写项目策划目录中的《项目沟通计划》） 安排组内需求分析师、客户联系人等角色与客户的沟通与交流。 处理项目组与其它项目干系人之间的关系。 处理项目组内各角色之间的关系、处理项目组内各成员之间的关系。 问题3答案 个人认为QA是必要的 QA是团队灵魂。 PS(没啥可说的了) 来源： https://www.cnblogs.com/papapa613/p/11580229.html

1. 推行技术平台化建设,树立全技术团队DevOps思维,推行自动化构建,测试和部署的流程.我们目前项目的构建和部署全是人工进行,容易出现错误或失误.一是降低出错机会二是提升效率. 2.提升团队内部的技术交流.比如定期(每两周/每月)内部技术分享会,让大家了解对方在做什么,是如何实现的.目的是在互相分享中增进了解,技术的交流传播,营造学习氛围,提升技术并形成一个良性互动的小生态圈. 3.研发团队按照产品进行划分.比如易考通产品,易找标产品,易采通产品以及网站产品库等. 目的是专业性进一步加强,有利于为不同产品客户提供针对性的设计和服务. 4.技术团队的人员结构配比,比如"老中青三结合". 老有一定的经验积累,可以起到言传作用.中执行力强,体现身教,青接受培养锻炼,目的是保持团队的稳定和传承有序,将成员流失风险控制到最低. 5.绩效考核,应该以正向激励为主,以引导和奖励为主,而尽量避免扣罚性质手段. 考核可以采用成果考核和过程考核两种方式:成果考核是针对项目的结果,进度,质量,成本等方面进行综合考量.这是对整个项目组的考核. 过程考核主要针对项目的执行计划进行考核.重点是项目各个节点进度是否在可控计划时间内,项目各个模块是否按期完成,项目成员是否履行了各自的职责.这是对项目成员个人的考核. 两者结合就实现了结果与过程的监控,同时也实现了团队和个人的绩效考核. 6

本人于2019年7月11入职于公司测试部，任职测试工程师，在这近两个月的工作中，熟悉并遵守公司的规章制度，熟悉了公司的产品，受益匪浅。我的工作职责主要是负责公司产品功能测试，自动化测试，性能测试等分配的测试任务。参与了云息迭代测试，玩赚答题王测试，云闪测试，公益中国测试，推荐系统测试并提供推荐结果报告，补全testcase并完善迭代内容的testcase 在未来的工作中，我希望能不断的锻炼自己的工作能力，提升自己的专业知识储备，也希望自己更好的融入团队，配合同事同事工作。 团队成员都很热情，很快的帮助我了解了公司的产品，了解了工作内容，在遇到问题时，与开发和产品沟通的都很顺畅。 在计算推荐系统线上结果时出现了问题，领导的指导起到了重要的作用，重新规划了计算公式得到正确结果。 在工作完成有瑕疵的时候，领导指出问题，并给予机会改正。 公司的企业文化，对员工的重视，对规范化管理的重视，让我看到了公司无比巨大的发展潜力，这样的工作环境使我以最快的速度适应这份工作，并且很努力的把工作做好。能够加入这个团队，是我莫大的荣幸。 来源： https://www.cnblogs.com/SealLiu/p/11423766.html

分工合理，责任明确 团队是由个人组成的，团队中的个人往往经历不同、背景不同、性格有差异、水平有高低。在团队形成后、正式开工前，首先应该进行合理分工，要结合每个人的特点和爱好，充分发挥出每个人的特长。因为如果工作不愉快、不顺手的话，效率自然低下。分工完成后，每个人对应的职责也就确定了。这时应该同每一位团队成员进行明确申明，最好以文字形式落实到个人并与日常绩效考核挂钩，以避免互相推诿、相互等待的情况出现。 制定高效的沟通机制 分工完成后团队即开始工作，此时必须保证信息在整个团队内的畅通，特别是互相之间有工作关联的同事，在发现问题时需要及时提出，以免造成不必要的工时浪费。 但软件开发本身是一种需要精力集中并且安静的工作，多次临时性的打断会造成开发思路的停滞，因此团队负责人最好能够每天在固定的时间段内组织大家进行沟 通，并了解工作的进度。而固定的时间也会让大家形成习惯，使效率得到提升。 发现团队瓶颈 大家往往会陷入一种误区，认为团队中每个员工效率发挥到极致的时候就是这个团队效率最高的时候。但经过企业管理实践不断的论证，这种想法其实是非常可怕的谬 论。正确的做法应该是将整个团队看成一个整体，再去谈效率问题。团队的分工协作就好比是生产的流水线，流水线的整体生产效率不取决于流水线上效率最高的环节，而取决于效率最低、速度最慢的环节。当流水线上某一环节出现故障而停滞时，整个流水线也就停滞了