沟通管理

1. 概述 本文档是数通畅联针对IT人员的工作意识、产品学习及项目管理能力的综合性培训文档，目的在于帮助公司员工统一认知及快速了解数通畅联的产品知识。 2. 预期读者 数通畅联内部员工 IT工作者及爱好者 3. 培训内容 3.1 能力晋升说明 3.1.1 能力维度 短期靠聪明、中期靠能力、长远靠人品。 3.1.2 晋升方式 1) 人员分布 跳槽可解决当前的薪资问题，但是不能解决等级问题，而薪资最终由等级决定。 2) 职业生涯 固定在高富帅公司—骨干、老黄牛（弱风险、机会少） 固定在高增长公司—高管、合伙人（低风险、高回报） 弱理性、饮鸩止渴—择业、开饭店（低风险、低回报） 有目标、择机而动—创业、当老板（高风险、高回报） 3.2 工作方法说明 3.2.1 意识态度 拒绝把自己定位成“小弟” 要为自己的未来做谋划，不要认为在给别人打工，就算真的有人剥削你，也可认为在做投资； 尝试制定一些高远的目标 不谋全局者不足谋一域、不谋万世者不足谋一时；多尝试几次，能力就会有所提高； 积极地面对挑战和困难 很多难题都是一张纸，一捅就破，只是我们把它想像的很困难；勇于尝试突破、不要拖延； 用良好的心态体验职场 所做的一切都是有所回报的，职场上严重不公平的情况是很少见的，长远来看都是公平的，不要斤斤计较。 3.2.2 工作方法 明确目标、分解任务、复述事情、沟通确认； 换位思考、知己知彼、架构先行

在每个项目中，项目经理作为整个项目的管理者，一直处于中心地位，项目经理不仅要掌控整个项目的运作情况，还要对项目的验收及成本进行管控，而这些无不要求项目经理应具备较高的能力，这种能力不只是体现在技术上还体现在能力素养上。 笔者在沈阳数通畅联软件技术有限公司从业，也是一名项目经理，因为公司一直本着人人都是项目经理的培训理念，所以从入职起，在能力与技术方面一直按照项目经理的要求进行学习。至今为止，已经以项目经理的身份完成了许多项目，每经历一个项目都深有体会，今天在这里为大家总结下我认为作为一个项目经理应该具备的能力素质有哪些。 能力素质 计划先行 总体计划是在项目一开始就需要罗列出来的，并且随着项目的进展，不断地调整计划，在大方向没有错误的基础上，安排小事项的处理方式，充分认知自己本身拥有哪些可利用资源。有经验的项目经理会倒排计划，首先看如何验收和验收标准，然后决定工作计划。 如果一个项目项目开始了很久，还不明确如何验收，那么这个项目出问题的几率就非常大。要知道做项目的最终目的就是验收，项目经理的角色不是研究机构的技术人员，而是不断推进计划，使团队所有的辛苦劳动得到预期结果的掌舵者。 有效沟通 有效的沟通需要出色的表达能力，这种能力包括语言表达、文字表达和肢体表达等，但表达能力不完全等于有效沟通，细心、耐心，广博的学识、良好的倾听对沟通都非常重要。沟通是双向的事情

曾经有个笑话，说三个软件高级人材等待上帝安排工作，一个说自己擅长抽象思维，上帝说那就做系统分析师吧；一个说自己工作非常细心，上帝说那就做QA；最后一个说，我实在没有更多的才能，那就做项目经理吧。有句项目管理名言则是这个笑话的最好解释：对项目经理的知识要求是要有1英里宽，7英寸深。也就是说，各方面的综合能力是项目经理的首要技能。 项目管理引入中国好多年了，除了国外的PMP、IPMP认证体系，现在更是将之引入高等学位教育。除了最先应用项目管理的建筑行业，现在各行各业都非常重视行业内的项目管理，这些足以可以看到项目管理的蓬勃发展。但是软件项目失败案例还是比比皆是的今天，如何将项目管理与新理论和技术层出不穷的软件产业双剑合璧？项目管理理论是欧美国家伴随着生产管理起步的，虽然方法论是通用的，但是如何在软件开发中产生更大效益，需要更多的业界项目经理以及高层思索和总结。 一个成功的建筑行业项目经理也会是一个合格的IT项目经理吗？项目管理有之一个名言：一个成功的建筑行业项目经理也会是一个合格的IT项目经理。在欧美国家是适用的，这样跨行业的例子也非常多。但据我了解在大陆这样的例子还非常鲜见。尤其软件开发行业，就更没这种先例了，为什么在欧美或者印度模式中，都是行得通，在中国不行呢？欧美或者印度模式的项目经理负责制定开发计划、协调、以及填写各种项目输出表格或模版就够了

曾经有个笑话，说三个软件高级人材等待上帝安排工作，一个说自己擅长抽象思维，上帝说那就做系统分析师吧；一个说自己工作非常细心，上帝说那就做QA；最后一个说，我实在没有更多的才能，那就做项目经理吧。有句项目管理名言则是这个笑话的最好解释：对项目经理的知识要求是要有1英里宽，7英寸深。也就是说，各方面的综合能力是项目经理的首要技能。 项目管理引入中国好多年了，除了国外的PMP、IPMP认证体系，现在更是将之引入高等学位教育。除了最先应用项目管理的建筑行业，现在各行各业都非常重视行业内的项目管理，这些足以可以看到项目管理的蓬勃发展。但是软件项目失败案例还是比比皆是的今天，如何将项目管理与新理论和技术层出不穷的软件产业双剑合璧？项目管理理论是欧美国家伴随着生产管理起步的，虽然方法论是通用的，但是如何在软件开发中产生更大效益，需要更多的业界项目经理以及高层思索和总结。 一个成功的建筑行业项目经理也会是一个合格的IT项目经理吗？项目管理有之一个名言：一个成功的建筑行业项目经理也会是一个合格的IT项目经理。在欧美国家是适用的，这样跨行业的例子也非常多。但据我了解在大陆这样的例子还非常鲜见。尤其软件开发行业，就更没这种先例了，为什么在欧美或者印度模式中，都是行得通，在中国不行呢？欧美或者印度模式的项目经理负责制定开发计划、协调、以及填写各种项目输出表格或模版就够了

工作日的日常 起床，坐班车到公司，用阿里邮箱处理未读邮件，打开语雀，完成当天的工作计划和日课，接着按照工作计划的优先级处理事务，通过 Aone 管理任务进度，完成代码的 CR 和部署，不定时处理钉钉消息，通过阿里郎参加线上会议或到会议室参加线下会议，这是我工作日的一天。 由于日常就需要和多个园区、多个城市的同学进行沟通和交流，事实上除了和本团队的同学以外，一直都是远程办公的模式，但是真正在家远程办公，会不会产生新的问题呢？ 答案是肯定的。从团队和协作的角度思考，在这种状态下如何管理团队，如何跟踪项目的进度以及如何保障沟通的时效和准确性，都是绕不过的话题。从个人的角度考虑，如何提高自控力保障效率，如何管理自己的时间，如何高效利用工具完成协作，同样值得探讨。下面从这几方面分别聊聊。 沟通 首先要明确，沟通的目的是为了保证信息的对齐，避免出现大家齐头并进，却向着不同终点奔跑的情况。根据不同的沟通范围，又分为两种情况，团队内沟通和跨团队/跨地域的沟通。 团队内沟通 团队内沟通，很多时候在工位前后吼一嗓子就能解决，实在不济多走两步很快也能说清楚。通常会进行一些团队事务的同步，可能包括手头上在做什么事情，项目进展到什么程度了，遇到了一个难题寻求帮助，完成了技术设计期望大家评审等等。这部分信息的同步通常比较简单和快速，远程办公影响不会太大。 跨团队/跨地域沟通 对于像我们这样横向拆分

因为平时事情比较多没时间写总结，2月份没有上班，就想着总结一下这些年来我在项目中常用的管理的方法，希望有所启发。 一、项目经理的心态要调整 最近总有人在跟我抱怨说现在的项目越来越难开展，各式各样的不确定性，导致了项目不好干将会是一个常态，这是个不正常但是不得不承认的现状，所以你只有去接受这个事实。你接受了这个现实，好吧，这篇文章你才能继续看下去。 首先管理项目，这绝对不是说就是项目经理一个人的事情，这是很多项目经理接到项目后感觉到自己在跟周围世界一个人抗争的原因，领导只会给压力，项目组成员只关心自己的事情，不是强制加班那么到点就下班了。你作为一个项目经理总觉得自己很苦逼，但是可怜之人必有可恨之处，你要想想自己是否要改变自己。职场上有人常说，如果我改变不了环境，那么我只能适应环境，适者生存，弱肉强食。这句话说得对，也不全对。作为一名项目经理，如果在困难面前这么消极，缺乏格弊立新的勇气，说句实话您的性格确实不太适合担任项目经理。你不去做点什么，也许永远不会改变什么，只有去做了，可能还会有些转机。 团队，团队，我见过一天到晚把团队建设挂在嘴边，但是实际上骨子里非要按照自己的意愿行事的领导，如果有不同的意见想方设法要打压，甚至制造谣言想把项目组拆散，项目经理遣走。这么恶劣的环境，项目经理干还是不干？ 你要清楚，项目不是项目经理一个人的项目，也许你的老板不在乎你这一个项目

新冠肺炎疫情防控期间可以说是我国数字化时代最大规模的一次集体远程办公。对于IT互联网企业来说，远程办公并不陌生，但对于传统行业来说，远程办公面临着诸多问题及系列隐私数据安全隐患。 不管是远程办公还是传统的办公楼集群式办公都是基于人与人之间的沟通、基于文档获取与协作完成的。对于传统企业来说，远程办公难度更大，它对企业内部及内外部的沟通效率、文件快速获取能力、文档安全性的要求更加高。 本次疫情或将进一步加快线上办公对传统办公模式的替代，它让许多不愿改变的企业主动接受线上办公，当然也暴露出诸多问题。今天，我们就围绕上述的三大核心问题进行探讨，企业到底该如何应对? CORNERSTONE 又可以做些什么？ 一、企业内部及内外部沟通问题 企业内部及内外部的沟通问题牵动着文件获取速度及办公安全性的方方面面，可衍生出诸多问题。 当下，许多传统企业仍旧使用QQ、微信等聊天工具来传输文件，认为上手即用，不需培训，简单方便，实则百弊丛生。 1】通过聊天工具传输资料，不仅有文件大小限制，且一旦过期就被清理掉，易导致重要文件丢失。 2】修改文件版本众多，且多次传递，无法有效沉淀最终价值，效率也大大降低。 3】内外部沟通困难，效率低。通过各软件外发文件需添加好友或需客户下载软件，通过邮件则无法确保外发文件的安全性，特别是方案规划、方案报价等文件。 让沟通更高效：针对这些问题， CORNERSTONE

今天和测试部的头就产品出货的检测点争论了很久，有点吵的味道，但是不烦，感觉很爽，争论的过程很不错，最终的结果也很满意，就是得到一个比较稳妥的办法，大家也都认识到了彼此看待问题的不同，也都认识到出货检测点的重要性。 研发部在做一个很不容易的项目，说到不容易就是说项目没有什么技术上的挑战，而且时间紧，任务琐碎，而且客户很难缠，就是那种做过技术，现在不做了，而且自认为很厉害的那种人，配合起来很费劲，经典的话如下： “需求都在文档里边。” “要是我们，产品手册2个小时就能搞定。” “计划不用和我说，我比你们急。” “我是没时间，否则就自己做了。” “做好你分内的事，其它的事情不用你管。” 弄得人很心烦，但是也没办法，研发部的兄弟一个劲说没事，但是我听到感觉十分不爽，我应该做点什么呢？ 做好项目，这是份内的事，与他怎么说都没关系，这是天职。 根据用户的特点，考虑与他沟通的方式，找出他的本身需求，把握住。 适当的教育，不能惯着他，否则会出大乱子。 将实际情况主动向上级汇报，寻求帮助，否则说不定哪天他会找领导说事。 做好风险应对和突发需求，加快项目的实施进度。 软件研发真的是一个围绕沟通的游戏，吵的时候不一定烦，烦的时候不一定吵，良好的沟通才是最重要的，我也能更好的理解这句话“大多数的项目管理者都清楚去管理一个软件项目更多的时候不是在用科学的方法，而是随性。”。 来源： https://www

“知己知彼，百战不殆。” 孙子的这句名言，非常之有道理。 然而，历史上，想要征服项目，最后反被项目征服的项目经理，数以万计。 难道他们都不知道不明白这个道理吗？ 【知己知彼】 -------------------------------------------------------------------------- “知己知彼，百战不殆”这个道理，大家都知道。可做起事来该失败的还是会失败，这到底是怎么个道理，大家就不知道了。对此，老孙也一直百思不得其解。 对于项目经理而言，“知己”也就是接项目前要先了解自己这边儿有什么筹码；“知彼”也就是接项目前要先了解项目那边儿有什么玄虚。按说在项目管理中，对“知己知彼”这样理解应该说没有什么毛病了吧？！可是，如果道理就是如此简单，大家为什么还会失败呢？ 时间长了、经验多了，老孙终于悟出了其中奥妙，失败的关键其实就在于：人们不知道知己知彼是为了什么！换句话说，知己知彼后该做些什么，他们不知道，或者知道却没有做。那么，知己知彼是为了什么呢？知己知彼后该做些什么呢？ ——知己知彼是为了奠定格局，形成有利于自己的开局。 用围棋术语来讲，那就是进入一盘有布局优势的对局。对于项目经理来讲，奠定格局就意味着向公司提出尽可能有利于项目经理的条件。如果有一个公平秤。一头是项目，一头是项目团队。那我敢肯定项目那头要重的多。没有一个项目可以让你简简单单成功

可能造成需求不明确的原因有许多，有些需求在最后一刻之前都是无法明确的； 同样的，需求文档缺乏也是常见现象，但是缺乏的 原因却是多种多样 的。 首先，您 处于什么位置 ？您是项目在技术方面的主要负责人吗？还是重要模块的主要负责人？ 您在团队中的位置是第一个重要的要考虑的因素。如果您是 一个大团队的一员 ，并且其他团队成员有同样的困惑，我的建议是暂时 只能按照原来的节奏去展开工作 ，已经发生的问题不可能立刻得到解决，而大型团队一般进行的是较为大型的项目，手头的工作也不是说停下来就能停下来的。 如果您是 团队的重要成员 （即使不是首席技术负责人），负责许多重要模块的研发工作，那么我就要建议您好好的和项目经理坐下来交流一下，但是就我们的经验，直接点出“缺乏明确的需求”是不会有效的。我的建议是，如果您能 就已经完成的工作和项目经理展开讨论 ，用事实说明在项目中遇到的需求困难，以及这种困难已经造成的麻烦，那么 即使不能解决问题，至少大家能建立起一个达成共识的平台 ，不至于在讨论工作量及规模的问题时互相扯皮。 不同系统的 需求特征是不同 的，依据需要完成的 系统的不确定性 （应该从客户及用户对需求的理解程度、开发团队对需求的理解程度、市面上有无成熟的同类产品这三个角度分别去分析） 的大小 ，来确定需求是否有可能在开始时就被明确下来。假设您现在正在开发一个创新的产品或系统