对于那些不熟悉软件开发的人来说，一个项目同时具有
产品经理和
项目经理可能看起来很奇怪。 区别在于，第一个负责确定产品，第二个负责项目的状态并在交付日期有风险时向有关方面报告。
项目经理倾向于通过标准化和周期性流程来确保截止日期的可预测性。 这些过程专注于状态报告以跟踪进度。 人们普遍认为，您越密切地监视过程，项目进度将变得越可预测，并且按时交付项目的可能性就越大。
项目经理的诅咒是他们从团队那里得到的估计时间的质量。 这些估算值可以有很大差异。 它们通常因人而异，可能需要每日更新。 估算中的这种旋转最终可能使无法确定项目的时间，但是预计经理会确定日期。 当最终错过这些最后期限时，经理必须找到一种方法来说明为什么错过了最后期限，而不必让最后的员工直接为错过的最后期限负责。 这方面的外交不足常常导致工作人员指责项目经理“将他们扔到火车上”，而不管他们先前评估的准确性如何。
以下是项目经理中有问题的性格：
会议策划人
项目经理认为，项目的所有问题都是由于缺乏沟通和协调引起的，因此将有大量的会议作为解决方案。
- 可以变异为统计数据
- 与产品经理（例如专利作者）一起使用时有危险
- 校正的可能性： 高
- 项目危险： 低
问题
从理论上讲，人们聚集在会议上讨论各种方案并做出决定。 实际上，这种情况很少发生。 会议计划者不了解这种现象，因此尝试尽可能多地与尽可能多的人安排会议。 他真诚地相信，这将改善团队中的协作：在他的脑海中，牢固地传达了沟通不足以使项目成功的想法。
这种类型的经理加剧了绝大多数会议固有的三个主要问题：
- 通常，参加者的选择不善，结果有些人会听取他们不感兴趣的信息，并对与他们无关的问题发表意见。
- 会议的组织通常也做得不好，这常常导致与会议目的无关的混乱的辩论，反过来又没有任何实际的结论。
- 项目不是在会议上完成的，而是在工作场所完成的。 如果您驱使员工参加会议而不是工作，他们会花费宝贵的时间。
解决方案
会议计划者不会对项目构成严重威胁，因为员工通常不会参加会影响其生产率的会议。 因此，尽管正在进行会议，工作仍在继续。
该项目经理可以通过简单的说明来解决：
- 对他们通常召开的所有会议类型进行分类：状态报告，项目审阅，日程安排等。
- 确定可以通过其他方式（例如通过电子邮件，跟踪工具，非正式对话）实现这些会议的结果（如果有）。
- 对于强制性会议，请确定应举行会议的频率以及应由谁参加。
- 分块安排会议，以避免因上下文切换而分散注意力。
- 在一周中的某些天没有会议。
- 整个星期都免于集会（您会被它所爱）。
- 至少提前一周安排每次会议，并发布议程和会议之前需要考虑的任何材料。
- 在会议开始时，请检查会议议程，目标并帮助实现这些目标。
- 立即结束会议：如果达到最初的目标，则不要继续。
需要开会才能完成项目，但最重要的是：
- 使每次会议都尽可能有效。
- 最小化对性能的负面影响。
一旦会议筹办者了解了这一点，他的行为就会立即变得更好。
统计员
一个项目经理，仅参与创建列表和检查项目，无论其内容如何。
问题
完成任何项目都需要两个基本步骤：
- 列出待办事项。
- 标记列表中的项目。
统计类型的项目经理得出的结论是，维护此列表是他的全部工作职责。 他不担心清单上有什么。 仅凭它具有分数并且以可预测的速度对其进行检查的事实。 统计人员不会评估列表中的项目，也没有提供任何关键方法，而是依靠其他项目，告诉他们项目的内容和截止日期。
这样的经理最担心的是项目管理软件可以完成他的工作。 因此，变得不必要。 通常会为此类计划中的牵头项目提供统计信息，他非常谨慎地保持最新信息。 该项目本身可能是一片废墟，团队可能会发布完全错误的产品，且会延迟数月且质量很差，但到目前为止，所有内容均已正确记录，统计数据并未发现任何问题。
幸运的是，如果统计学家仅维护列表并删除项目，则如果他不考虑自己对真实情况的无知，则对项目没有任何危害。 主要的问题是统计数据可能会迅速转变为更糟的情况。
解决方案
统计数据很难确定，因为他对细节的关注植根于自然，很可能来自童年。 如果有人认为列表很重要，那么您说完这些话后，他不会突然改变自己的心态。 此外，列表确实很重要，但它们只是一张地图，而不是风景。 列表的这种混淆是重要的，但不是最重要的，这使统计数据特别难以修复。
统计数据缺乏的一项关键技能是与人合作的能力。 经理与清单互动，而不是与人互动。 邀请他们与生活中的人们谈论他们在做什么以及为什么这样做，而不仅仅是索要物品清单。 但是，在执行不佳的情况下，统计信息可能会下滑到微观管理（请参阅
不安全的管理器）。
最后，要求写一篇关于项目状态的段落摘要，而不是将结果显示为项目列表。 这将使他们更全面地介绍该项目。
错误的
经理与项目的实际情况相去甚远，以至于他向有关方面提供虚假信息。
问题
经理的主要职责是报告项目的状态。 这被称为“设定期望”，“满足期望”是确定项目成功与否的标准。 优秀的项目经理会根据定量和定性数据以及自己的专业经验来设定期望。 另一方面，一个犯错的经理完全是基于他的直觉。
以下是关键短语，可让您识别云中的项目经理：
- “我感觉不好。”
- “我认为这时候我们不会及时到来。”
- “我认为我们一切都会好起来的。”
- “我看不到任何问题。”
- “这个决定使我感到困惑。”
注意“我”和“我们”的使用-这些都是很好的标记，表明经理的看法是基于主观印象，而不是基于收集和分析的数据。
重要的是要注意误导的经理，
悲观主义者和
乐观主义者之间的区别：
- 悲观主义者基于他对定量和定性信息的解释，认为该项目将失败。
- 乐观主义者基于对定量和定性信息的解释，认为该项目将成功。
- 错误的经理仅凭自己的感觉就对项目的成败提出了意见，这是完全不正确的。
这是少数几个可以自行破坏整个项目的人物之一。 如果这样的经理经常与利益相关者会面，则应提高警惕，因为可能发生以下情况：
- 经理告诉当局一切都丢失了，该项目将永远无法投产，结果该项目被取消。
- 经理说，一切都井井有条，一切都会按时进行，因此，如果当局迟到，当局将更加失望，这将导致该项目的取消。
解决方案
幸运的是，可以通过两个操作来固定这样的管理器：
- 问他为什么感到自己的感受。
- 向他展示与他的直觉相反的定量和定性数据。
为什么要问清楚他的感受？ 这将帮助他理解判断不是基于某种物质，而是基于主观评估，即基于感觉。 重要的是，他自己得出这个结论-不必说他有不良的直觉。 不断问“为什么会这样？”，直到取得突破为止。
经理一收到它，就向他展示有关该项目的扎实事实。 例如，如果他说“产品质量不好”，请想象一下一个图表，该图表显示了过去几个月中错误数量的稳定下降。 如果他说：“我们将准时准备好”，请提供未完成任务的列表以及通常的任务完成时间，事实恰恰相反。 在这个阶段，管理者的思想和逻辑占上风应该只是一个问题。 如果他仍然有幻想，请根据需要重复该过程多次。
悲观主义者
一位自信地说项目失败的经理，不可能说服他做相反的事情。
- 可能变异为错误
- 与警报器等测试器结合使用会很危险
- 校正的可能性： 否
- 项目危害： 极高
问题
从一侧可以将大多数软件开发项目称为失败：
- 预算过多。
- 超过最后期限。
- 缺少所有必要的功能。
- 性能，稳定性或可伸缩性问题。
- 大量的错误。
在现实世界中，这是可以预料的，有时甚至被视为不可避免的现实。 但是悲观主义者对项目提出了很高的要求，以至于项目无法满足，因此
他在项目真正失败之前
就宣布了自己的失败 。
悲观主义者很容易通过两个关键特征来识别：
- 他特别选择有关项目状态的负面指标，以便将重点放在负面方面，而忽略或贬低任何正面迹象。
- 他对自己的表演充满激情，表演常常充满情感戏剧性。
这样的立场可以使当局相信该项目是没有希望的，而且确实被取消了。
解决方案
悲观主义者的经理无法固定，因为他通常对自己的生活不满意，对工作，职业或公司本身不满意。 因此，它的负面影响与项目本身无关，而是一个个人问题。 您可以做的最好的事情就是提供心理咨询，而很少有公司这样做。 这通常导致不可避免的结果：经理要么离开，要么公司解雇他。
乐观主义者
不管有何相反的证据，都已经说服了项目成功的项目经理。
- 可能会变异为队长或犯错
- 与乐观的开发人员结合时会很危险
- 校正概率： 低
- 项目危害： 极高
问题
通常，人们喜欢与积极的人一起工作。 乐观经理的缺点是他积极的世界观
不能明确该项目的警告标志 。 他宁愿采取措施解决这些问题，也不愿忽略这些迹象，认为它们是不利于健康的负面因素，而宁愿只报告善举。 这会在团队成员之间建立一种自满或沮丧的文化，而老板却幻想一切都进行得很好。
在任何领导职位上，面对逆境的乐观情绪都是重要的优势。 要将乐观的经理与大胆的领导者区分开，请使用以下测试：
- 他对这个坏消息感到感激吗？
- 他多久做一次毫无根据的表扬？
- 无论团队的士气多么低落，他总是心情愉快吗？
- 即使有正当理由，他是否也会避免对抗？
- 人们似乎对他的喜爱远胜于项目的成功吗？
乐观的经理通常会导致项目失败，因为它会忽略可能导致失败的问题。 项目花费的时间越长，效果越差。
解决方案
乐观主义者容易与大胆的领导者混淆，这就是为什么很少识别他们，因此很少纠正他们的原因。 当乐观的面孔出现时，由于该项目已经失败，通常为时已晚。
组织努力培养勇敢的领导者。 因此，如果乐观的经理可以说服上级主管该项目由于其无法控制的原因而失败，则晋升的机会更高。
不管经理为何如此行事-为了个人职业发展，不想面对一个难受的真理或天真幼稚，对项目的损害都是相同的。 唯一的区别是他是被提拔还是被解雇。
队长
一个项目经理，他专注于让所有程序员满意，而不关注项目的成功。
问题
高昂的士气对任何项目都很重要：士气高时，开发人员通常更具创造力和生产力。 当项目进展不顺利时，士气自然会下降，直到情况改善为止。 这时，队长没有解决项目的问题，而是在提高士气。
球队的队长和
乐观主义者有着共同的积极态度，但是其表现形式却有着根本的不同：
- 乐观主义者无视项目面临的任何问题，并向当局报告了不正确的信息。
- 团队负责人仅根据士气来考虑项目的成功：士气低落是不成功的项目； 高昂的士气是一个成功的项目。 他会考虑客户和上级的利益，如果有的话。
队长很容易发现：
- 它自发地带有咖啡和甜甜圈等零食。
- 他认为，与每个员工私下进行对话很重要，以便“听到他们的需求”。
- 通常，她喜欢谈论个人事物，谈论工作以外的员工生活（认为这可能会引起不满）。
- 它发出积极的信件，在整个办公室内建立激励因素，通常过于积极。
- 他代表着最好的办公家具，最好的照明设备，并且通常是最好的工作环境。
- 积极应对恶劣的工作条件，例如员工缺乏职业发展，培训不足和加班工作。
- 与团队组织课外会议，与项目的重要阶段无关。
- 非常关心所有项目参与者都爱他。
这样的人似乎是理想的项目经理，但有两个原因值得关注：
- 所有这些事件只是暂时性地增加了士气，当人们记住项目的现实时，这种情绪很快就消失了。
- 他们没有消除道德低下的根本原因，而是倾向于短期激励措施。
因此，团队的负责人最终都是每个人都喜欢的，但实际上并没有完成项目经理的工作。
解决方案
主要问题是团队负责人通常没有太多的项目经理经验。 因此，解决方案是训练他。 幸运的是，项目经理有大量的培训资源。
为经理提供必要的工具，有必要鼓励他找出士气低落的根本原因，然后加以纠正。考虑到队长改善员工情绪的自然趋势，他一确定了解要寻找的东西，便会做出积极的尝试，以发现并纠正道德下降的根本原因。在这个阶段，您将获得一个动机非常强大的项目经理：首先，他将道德作为衡量项目中问题的一种方法，其次，他发现并解决了这些问题。由于他的动力来自同胞的同情心，因此道德低下的问题将很快被消除。顺便说一句，由于他们的性格对他人友善，因此不太可能“治愈”他们这一组成部分，并且他们的“更正”不应意味着消除了性格中积极的部分。最后，如果可以提高项目经理的水平，那么很难找到比团队负责人更好的投资选择。暴君
一位经理，以他们努力工作的动机来鄙视项目成员。
问题
软件开发项目通常涉及许多有个性的人，但是每个人都应该服从一个目标，并专注于项目的实施。因此，项目经理有权领导项目参与者以确保项目成功。暴君滥用这些权力，使用负面强化来取得结果。尽管可能不喜欢暴君，但老板们常常相信，他们的“坚毅”确实是项目成功的必要条件，特别是如果进度落后于计划。威胁和惩罚实际上是许多人格类型的诱因（请参见像士兵这样的开发人员），这有助于传播暴君。暴君的实际问题很难发现，但对项目造成极大的危害。暴君工作的时间越长，人才流失速度越剧烈。最后，一旦所有有能力的项目参与者被开除，就不可能邀请有才华和经验丰富的参与者参加该项目，因为潜在的员工将不愿与一个无能的团队一起工作（事实很容易在面试中弹出）。重要的是要注意，暴君通常是在最不适当的时候引入项目的：项目陷入困境。处于失败风险中的项目应该抛弃无能的团队成员，同时保持能力，但是暴君会产生完全相反的效果。解决方案
要纠正暴君，必须使他意识到这种行为会对项目产生负面影响。有两种一般方法：首先，提供反映其项目管理风格的定量数据：- 有多少有价值的员工离开了国家。
- 成功吸引人才。
- 发布了多少功能。
- 记录了多少个错误。
- 缺少多少个日期。
比较这些信息时，时间表特别有效。其次，让他们知道您在不久的将来会期望什么指标。他们很可能会表现出恼怒和绝望，因为他们不知道如何改善这些指标。但这是向他们提供有关如何成为更好的经理的建议和培训的理想机会。培训应包括以下内容：- 他们与员工的行为方式。
- 他们如何讨论项目的失败和成功。
- 如何识别和淘汰不称职的项目参与者。
- 如何吸引和留住有能力的参与者。
只要有合适的专家进行这种培训，就可以完全纠正经理暴君，因为一个人自然具有以下特征：- 人们不想成为卑鄙的人。
- 人们喜欢被爱。
- 人们喜欢有效。
最主要的是，尽管暴君在过去享有声誉，但团队还是采用了新的方法。例如，召开主题为“对不起”和“我变得更好了”的会议可以非常简单地解决该问题。迷恋过程
经理沉迷于流程，以至于忘记了他的任务-帮助项目取得成功。
- 可以变异为暴君
- 与独裁者型产品经理一起使用时有危险
- 校正的可能性：高
- 项目危险：低
问题
在任何培训课程结束时或在阅读有关管理的任何书籍时，每位经理都有被该过程困扰的风险。即使是最好的情况，也会发生这种情况，因此在更正它们时，耐心很重要。着迷的过程分为两大类：- 瀑布迷恋
- 痴迷于敏捷开发（Agile）
也许培训课程或书籍对这些过程的称呼有所不同，但是您可以通过应用以下测试轻松地将它们归入正确的类别：- 痴迷瀑布，相信所有问题都可以通过附加文档来解决，例如，“从现在开始，我们将为每个文档编写系统需求和业务需求。”
- 那些痴迷于敏捷开发的人认为，可以通过频繁的短期会议来解决所有问题，例如，“从现在开始，我们每天早上不超过15分钟就组织一次会议”。
任何经理的目标都是在预算范围内按时交付项目。我们使用的过程对此有所帮助。当项目经理沉迷时，他可以忽略主要目标，而将注意力集中在“流程是否正确？”这个问题上。损害其他公务。解决方案
无论您做什么，都不要试图抢劫他们或挑战他们。您正在与一个宗教狂热者而不是一个理性的人打交道。他说服自己，他的过程将“修复”该项目。如果他们认为该项目已“中断”，而您尝试说“这对我们没有帮助”，那么他们只会认为您是该项目中断的部分原因。解决这个沉迷的过程很容易：只要满足他所说的一切，轻轻提醒一下“转动一艘大船需要时间”和“罗马不是一天建成的”。关键是迫使他同意通过一系列小创新而不是重大改变来实施新流程。这将使他们从自己的经验中学习哪些方法有效，哪些无效。通过积累经验，他们将学习如何使流程适应当地情况。他们希望他们能理解：这个过程是达到目的的手段，而不是目的本身。不确定
一个项目经理，不断询问员工的当前状态，认为他们必须专注于完成任务。
问题
当经理坐在他的办公桌旁，远离从事项目工作的项目参与者时，他很容易感到一文不值。这使他们能够做自己认为必要和有用的一切必要的工作。对于一个不确定的经理来说，看起来最有效率的最明显方法是检查员工当前的工作。通常使用以下方法来实现：- 分发请求项目状态的电子邮件。
- 安排会议以讨论状态。
- 详细填写时间表的要求。
- 将松散的目标分解为小任务的要求。
- 组织自发的面对面会议，询问团队成员的状况。
一个不安全的经理被广泛称为另一个名字：微观经理。项目团队成员将他的项目管理方法解释为以下任何一项或全部：通常，员工会对不确定的项目经理产生深深的怨恨，因为他们认为：- 经理不信任他们的时间管理技能。
- 经理不相信他们对截止日期的评估。
- 经理不了解需要独自解决问题的能力。
- 经理除了询问和报告状态外无事可做。
这种看法在项目经理和开发人员之间造成了对抗，抑制了经理可以用来解决实际问题的有用沟通。开发人员没有与这样的经理进行合作和合作，而是避免与他进行任何其他联系，因为担心他们（再次）被要求获得身份。解决方案
不安全的经理非常普遍，这种行为被视为经理的主要工作。假设不可避免，大多数开发人员会形成一定的门槛，要求他们多久查询一次他们的当前状态。由于大多数人已经学会适应不断追求地位，因此不安全的经理不会给项目带来高风险，尽管它使团队无法进行原本可以进行的有用沟通。这样的经理出生是因为他的团队绩效不佳。因此，解决方案是将该经理放置在团队旁边。否则，通过直接询问每个开发人员的状态来克服这位经理。如果他们在附近，则经理可以通过窃听开发人员之间的对话来了解项目的当前状态。在这种模式下，经理是最有效的，因为他只需要在生产力真的很困难时进行干预。另请参阅：