沟通管理

误区 之前我没有项目经验，在上一家公司的项目管理上，我只是照葫芦画瓢。 产品发起，整个项目没有项目经理这一说。或者说有，但却真的感受不到，一丁点也感受不到。 产品发起会议，或者开发发起会议。无论谁来发起会议，一般都会针对于某一具体需求或者某一具体实现方式。 没有具体的任务规划，任务拆得不够细致。这个和开发自身有关系。当然那时的公司确实没有一些指导性质的模板和导师。 任务分得不够细致，就会导致工期评估差距比较大。 各种O们的临时紧急需求，很多O没有技术背景和项目管理背景。很多时候提出的需求都是发生在项目开始过程中。 都是很急的需求，不得不重新估算时间和排期。开发为了避免延期风险，就是让产品排优先级，然后我们根据优先级估时。 直到有必要的需求都在这个迭代中计划上。 没人全局把控，产品从产品角度，开发从开发角度，业务从业务角度。始终没有一个最终的协调人。 产品在对各种O的对话中，气场和身份不足，导致需求基本是提出就会安排。即便是请出青岛总负责人出面沟通，最终的结果一般就是接受。 之前我们是青岛为开发，北京为产品、UI、前端、测试。异地沟通。电话会议是常有的事情，私下的临时沟通电话更是家常便饭。 信息同步、开会、理解程度 都会造成沟通上的成本增加。 紧急需求上线后，三个月没人反馈。问了才知道，财务提的需求他们没用过。 开会一般都会临时决定，发起人会准备资料

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

规划沟通管理： 输入：项目管理计划、干系人登记册、事业环境因素、组织过程资产 工具：沟通需求分析、沟通技术、沟通模板、沟通方法、会议 输出：沟通管理计划、项目文件更新 管理沟通： 钩工事组 技魔方信保 沟通二项组 输入：沟通管理计划、工作绩效报告、事业环境因素、组织过程资产 工具：沟通技术、沟通模板、沟通方法、信息管理系统、报告绩效 输出：项目沟通、项目管理计划更新、项目文件更新、组织过程资产更新 控制沟通：二项问工资 二项公变主 输入：项目管理计划、项目沟通、问题日志、工作绩效数据、组织过程资产 工具：信息管理系统、专家判断、会议 输出： 项目管理计划更新、项目文件更新、工作绩效信息、变更请求、组织过程资产 来源： https://www.cnblogs.com/ljh-zw/p/11790689.html

论题 论点 范围管理 制定范围计划、范围定义、创建WBS、范围确认、范围控制 进度管理 活动定义、活动排序、活动资源估算、活动历时估算、进度计划制定、进度控制 成本管理 成本估算、成本预算、成本控制 质量管理 质量规划、质量保证、质量控制 人力资源管理 人力资源计划编制、组建团队、团队建设、管理项目团队 沟通管理 沟通管理计划编制、信息发布、绩效报告、干系人管理 风险管理 制定风险管理计划、风险识别、风险定性分析、风险定量分析、风险应对计划、风险监控 来源： https://blog.csdn.net/baidu_18696283/article/details/102692937

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

了解康威定律吗 定律一：组织沟通方式会通过系统设计表达出来，就是说架构的布局和组织结构会有相似。 定律二：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。一口气吃不成胖子，先搞定能搞定的。 定律三：线型系统和线型组织架构间有潜在的异质同态特性。种瓜得瓜，做独立自治的子系统减少沟通成本。 定律四：大的系统组织总是比小系统更倾向于分解。合久必分，分而治之。 你认知的比较深刻是哪一条？ 定律二和定律四比较深刻。 开发中也经常碰到，产品经理的需求太复杂了？适当忽略一些细节，先抓主线。产品经理的需求太多了？放弃一些功能。 目前火热的微服务就符合这个定律，将大型系统拆分，更利于开发和管理。 这几个定律如何解释微服务的合理性 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理。 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计。 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效。 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的。 依据这个定律，让你去管理一个团队，你会怎么做 我们要用一切手段提升沟通效率，比如github，wiki

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

微服务架构实战160讲 其它学习课程目录： 从0开始学微服务 面试官绝杀：系统是如何支撑高并发的？ 分布式技术原理与算法解析 消息队列高手课 从0开始学架构 微服务 一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 结构图： 来源： https://www.cnblogs.com/it-chen/p/11637928.html

背景 给任务排优先级是解决做什么的问题。有效执行解决的是怎么做的问题。 项目执行的要点。 清晰的目标 现象 1.明确项目的初衷，但是没有设定可以衡量的目标。 2.在你的眼中目标很清晰，但是负责项目实施的员工并不知道从哪下手去执行； 3.两周能搞定的事情，员工却花了3周，就是说延期了； 4.项目交付时间到了，员工没完成，他们却觉得很无辜； 5. 项目如期发布了，但是效果不对； 分析 目标不够明确，至少没有具体到执行人员可以执行的程度； 上下级对目标的理解看似一致，实则有偏差，尤其是对进度，质量，效果； 目标发生变化，没有及时同步给相关人员； 总结： 目标不清晰的后果，必然导致员工在紧急程度，质量水平，效果上的执行跟预期偏离。 责任人明确 现象 项目涉及到的各个团队，是否都有一个明确的责任人？ 负责人和所有的项目组成员，是否都清除各方面的总负责人？ 项目是否有唯一的总负责人，总负责人是否有效？ 分析 各负责人对负责的理解不同；工程师认为的责任是承担分内的开发工作，而负责人是对项目所涉及到执行和协调问题都负责。 总负责人无效； 总结 总负责人的缺失或者无效 机制健全 现象 A不够主动 越好了及时通报，为啥有些人不通报； 流程都有，但是不按照流程来； 分析 过于依赖人的主动性，缺乏基本的流程和机制； 有机质，但是没有人监督执行； 机制有人监督执行，但是大家不愿意去执行； 总结

项目管理九大知识体系——沟通管理 Posted on 2007-07-13 15:32 放飞梦想 阅读(99) 评论(0) 编辑 收藏 网摘 所属分类: IT知识点滴收藏 回想一下你所经历的项目，有没有出现过以下这样的情况： 客户 在检查项目阶段成果时，指出曾经要求的某个产品特性没有包含在其中，并且抱怨说早就以口头的方式反映给了项目组的成员，糟糕的是作为项目经理的你却一无所知，而那位成员解释说把这点忘记了；或者，你手下的程序员在设计评审时描述了他所负责的模块架构，然而软件开发出来后，你发现这和你所理解的结构大相径庭…… 可能你遇到的情况比上面谈到的还要复杂。问题到底出在哪儿呢？其实很简单，就两个字——沟通。以上这些问题都是由于沟通引起的，沟通途径不对导致信息没有到达目的地。“心有灵犀一点通”可能只是一种文学描绘出的美妙境界。在实际生活中，文化背景、工作背景、技术背景可以造成人们对同一事件理解方式偏差很大。 在项目中，沟通更是不可忽视。项目经理最重要的工作之一就是沟通，通常花在这方面的时间应该占到全部工作的75%～90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。 沟通 管理 的体系 一般而言，在一个比较完整的沟通管理体系中，应该包含以下几方面的内容：沟通计划编制、信息分发、绩效报告和管理收尾。沟通计划决定项目干系人的信息沟通需求：谁需要什么信息