招工做的网站,wordpress网站百度收录首页,织梦装修公司网站模板,网页ui设计的排版据《创世纪》记载#xff0c;巴比伦塔是人类继诺亚方舟之后的第二大工程壮举#xff0c;但巴比伦塔同时也是第一个彻底失败的工程。
巴比伦塔的管理教训
这个项目具备了几乎所有成功的先决条件#xff1a; 有清晰的目标#xff0c;尽管目标理想化到了近乎不可实现的地步巴比伦塔是人类继诺亚方舟之后的第二大工程壮举但巴比伦塔同时也是第一个彻底失败的工程。
巴比伦塔的管理教训
这个项目具备了几乎所有成功的先决条件 有清晰的目标尽管目标理想化到了近乎不可实现的地步 人力资源非常充足 材料资源丰富如美索不达米亚地区的泥土和柏油沥青 时间上也没有明显的限制 技术方面同样不成问题金字塔和锥形结构本身具备良好的稳定性能够有效分散压力砖石建筑技术经过了深入研究。
然而项目在触及这些基本限制之前就已经宣告失败。
究其原因项目欠缺的是两个至关重要的因素有效的沟通与合理的组织。缺乏沟通意味着无法有效地协作一旦合作受阻工程便停滞不前。从历史记载中可以推断沟通不足导致了大量的争论、沮丧情绪以及集体间的猜疑。很快原本团结的部落开始分化成员们宁愿选择孤立也不愿意继续无休止的争执。
大型编程项目中的交流
如今类似的问题依然存在。由于团队内部缺乏有效的沟通导致了进度延误、功能不合理和系统缺陷频出。各个小组在工作中逐渐调整了自己的程序功能、规模和速度这些调整或明或暗地改变了输入输出约定。
例如负责程序覆盖功能的团队发现该功能使用率低于是降低了其执行速度。然而这一变动直接影响到了正在设计依赖该功能的监控程序的其他同事。因此这类变更需要从系统整体的角度来评估并且应该公开透明地发布变更信息。
团队应如何加强彼此间的沟通需通过一切可能的渠道进行会议、电话、工作手册等。现如今我们有了更方便的文字处理和文档协作工具但保持文档的更新和有效获取仍然很重要。
项目工作手册
项目工作手册并非单一文档而是对一系列必需产出的文档进行组织的结构涵盖了目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录等内容。良好的文档结构不仅便于追踪设计思路还有助于未来产品的文档编制。合理设计工作手册确保文档有序且信息更新及时便于检索。
项目工作手册的另一个重要作用在于控制信息发布确保信息准确传达至需要的人手中。通过编号备忘录和树状索引结构可以提高信息检索效率。随着项目规模的扩大文档管理难度呈指数级上升。采用活页夹和计算机编辑系统可以帮助实时更新文档通过标记变更内容和附带变更摘要来减少理解障碍。
当文档量庞大时使用微缩胶片可以有效减少存储空间并简化归档工作。然而微缩胶片不便标注与批注作为补充手段较为合适。现代技术中直接访问文件并记录修订日期和变更标识是可行的选择用户可通过显示终端查阅更新维护变更小结以便随时查看。
工作手册的本质并未改变仍是项目文档的集合但分发机制和查询方法的改进有助于提升工作效率。精确完整的接口定义能进一步优化文档管理有助于预防和纠正接口错误。
大型编程项目的组织架构
团队组织的目的是减少不必要交流和合作的数量因此良好的团队组织是解决上述交流问题的关键措施。如果项目有 n 个工作人员则有n^2 - n/ 2 个相互交流的口子有将近 2^n个必须合作的潜在团队。
减少沟通障碍的方法是通过人力分工和职能专业化。当实行分工和职能专业化时树状管理结构所需的详细沟通就会减少。实际上树状结构反映了权力和责任的分配但沟通结构更加网状不受此限制。
考虑一个树状编程团队及其有效运作所需的要素 任务 产品负责人 技术主管或架构师 时间表 人力分工 接口定义。
其中产品负责人和技术主管的角色尤其重要。产品负责人负责团队构建、资源配置和进度管理主要与外部沟通技术主管则专注于设计和技术问题解决确保设计的一致性和完整性主要在团队内部沟通。
这两种角色需要不同的技能组合。在小型团队中一人身兼多职较为常见但在大型项目中这几乎不可能实现因为同时具备管理和技术能力的人才稀缺且每个角色都需要全职投入。
另一种模式是产品负责人作为领导者技术主管作为助手。此模式要求产品负责人支持技术主管的技术决策并在团队中建立技术主管的权威。第三种模式是技术主管作为领导者产品负责人作为助手这种模式在大型项目中较为有效。
巴比伦塔可能是最早的工程失败案例之一但它不是最后一个。沟通和由此产生的组织是成功的关键管理者必须重视沟通和组织技能的培养正如重视软件技术的发展一样。
