四月读书笔记2

四月读书笔记2

关于进程管理和客户需求，进程管理只是项目管理中的一个方面，还有比进程管理失控更加可怕的，那便是未能准确地获取客户的需求，导致项目运行方向犹如救经引足，南辕北辙。

收集客户需求看似简单，然而实际情况千变万化不一而足，某些用户仅仅偶尔使用程序，有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。他们对于程序和项目的需求互不相同甚至彼此冲突，是否需要同等对待？每个用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很少的总结性内容，就像是描绘了树木，形容了树叶，但却没有一幅森林的图案。如何才能将零珠碎玉完整准确拼合，获取项目用户真正的意图，而不是管中窥豹，坐井观天。这就需要使用到有效的需求文档，囿于篇幅，这里不做详细展开，不过一个合格的需求文档，至少需要包括目的、环境、范围、实现功能和使用的算法、输入－输出格式、操作指令、选项、运行时间、精度和校验，最后需要包含验证的方式和程序。需求明确后，方能明确实现的方式，建立整个项目的实现方式和流程，拥有验证方式和程序，才能够知道项目是否走在预期的轨道上，而这一切的基础，都是建立在拥有详实明确的需求文档之上，否则将有大量的时间浪费在和用户反复确认需求，从而延缓整个项目的进程。正如全书第十六章“没有银弹”和第十七章“再论没有银弹”中所说，所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。而随着技术水平的发展，“次要任务”的比重正在日渐降低，确切的说，只要能够获得准确的客户需求，在现有的技术上，几乎不存在无法实现的功能，那么实际的工作中，为什么还会有那么多错误甚至于反人性的功能出现呢？这究竟是技术上的原因，还是需求获取和描述出现的问题呢？传统的零打碎敲意见簿式的获取客户意见和需求的方式，能够获取全面而准确的客户需求吗？无论从社会行为学还是数理统计学的角度来看，都要打上一个大大的问号。