在这种情况下,PM不加大力度去监控,不花更多的时间是检查,那肯定不行!项目管理者联盟
当PM不能将任务分配的时候,最好先不要将任务分配下去!磨刀不误砍柴工吗,最好先把工作理顺了,可以讨论,然后再将PM的要求清晰的传达给组员,当组员了解自己要做什么,知道要达到的要求后,PM也就知道了,至少在检查的时候,就可以有的放矢了!项目管理者联盟文章
交流的顺畅与否,其实可以明确一点,就是大家的相互关系的好坏!要是你的组员总是感觉被你训斥,你想让他来跟你交流?那不是“找骂”吗!交流应该随时随地的进行。我们的一些交流其实都很不到位。有很多两人交流中,谈着谈着声音就变大了,感觉像是在吵架。这种情况尤其容易出现在一个给另一个讲解的时候。交流如果充分的话,可以让你发现许多问题,在工作检查的时候,当两个人在激烈辩论后,其他人都会发现,原来还有这么我没有思考到的地方。项目经理博客
软件文档的必备要素项目管理者联盟
和大多数同行一样,我明白软件文档的重要性。不幸的是,在任务开始前我很少阅读文档。相反,我常常像视线不清的父母一样,在装配好他们孩子的自行车之后,还落下一两个零部件没装上。 如果我们明白文档的重要性,那为什么我们不更经常用它呢?然而,许多软件文档存在以下问题:项目管理者联盟文章
· 错误的语法和/或拼错的词语blog.mypm.net
· 不完整项目管理者联盟
· 过时或不准确项目管理者联盟
· 过于冗长training.mypm.net
· 未经解释的缩略语或专用术语training.mypm.net
· 查找信息困难
存在这些问题的主要原因是软件文档常常被退居次位。工程预算迫使我们优先考虑开发过程中的主要活动,也就是那些可以看得到利润的地方。编写文档需要成本,因而它常常成为一项主观上的活动,而且通常被认为没有重要作用,应该尽量避免。许多项目经理认为客户不需要文档,它只是用来装点门面的。 软件文档质量差的另外一个原因在于文档撰写者。许多应用程序开发经理认为软件文档的编写是软件开发过程的一个标准组成部分,因此要求开发人员在编码的过程中产出文档。项目管理者联盟
尽管这种做法在理论上行得通,但它没有考虑开发人员编写文档的能力。简单来说,技术人员是用来开发软件而不是编写文档的。为了解决这个问题,许多应用程序开发经理雇佣专业技术文档编写者或业务分析师,以期改进软件文档的质量。但这又遇到了另一个难题:专业编写者及业务分析师的技术水平有限。training.mypm.net
解决这个问题要考虑需要编写的文档以及文档的预期读者。一般的规则是,写文档需要团队协作,这样就允许开发人员和文档编写者利用彼此的长处,取长补短。例如,如果预期读者是系统设计师,开发人员需要提供技术细节,然后文档编写者按照正确语法组织和编辑内容。不考虑预期读者或专门编写者,软件文档的质量取决于其可用性,可从以下6个方面去评价其可用性:项目管理者联盟
· 应用性:文档是否提供相关信息?项目管理者联盟
· 及时性:信息是否及时?项目管理培训
· 准确性:信息是否正确?项目管理者联盟
· 完整性:文档是否足够详细而又不会太过拘泥细节?项目经理圈子
· 可得性:文档是否随时可得?项目管理者联盟
· 可用性:你能否很快凭直觉就找到所需信息?
软件文档的最主要目标是传达一个系统的技术要素和使用方法。第二个目标是提供软件开发过程中的需求,决策,行为,角色和责任的书面记录。只有实现了这两个目标,软件文档才真正提供了有意义的信息。talent.mypm.net
针对被开除人员的应急计划转自项目管理者联盟
在职员离开企业时限制风险的出现是你的责任。在职员因不和睦而离职时这个责任就更加紧迫。找出和分析你的组织由于前任职员不满而面临的风险,是你的系统每天所面对的整体风险的一个延伸。不幸的是,对于很多组织来说,全面的风险和漏洞分析通常会超出预算限制。然而,还是有一些常用的措施可以使用的。项目管理培训
首先要在全面地审计信息系统资产的基础上确定风险暴露和漏洞。然后,基于信息系统安全性的三个主要组成部分来分析这些资产弱点。信息系统安全性的三个主要组成部分是:blog.mypm.net
· 机密性:保证组织的信息资产不会被不恰当地泄露。club.mypm.net
本文为项目管理者联盟联盟会员原创文章,授权发布,非经同意不得转载!
|