读《人月神话》有感：可以的话，下次做系统项目，我希望能……

目录：

       写在开头的“我的罗哩罗嗦”

       第一批可以时刻自我提醒的要点

       觉得有必要还得花时间先弄清楚的（或者说是进一步了解。因为第六感告诉我这是能帮我解决目前比较实际也是很有必要的情况，但是我还没发觉到。）

       可以的话，下次做系统项目前，我希望能……

       我目前的做法、尝试

 

• 写在开头的“我的罗哩罗嗦”

    一次偶然机会，接触到了《人月神话-32周年中文纪念版》这本书。

    最近，我也决定开始将自己的时间放在“书”上，也开始读了一两本。

 

    最近，公司的项目开始放缓下来，有些也开始处于版本收尾阶段。可能是因为公司也处于开始的发展阶段，而我参与开发和负责的呢，总感觉好多东西都没有得到有效的管理和控制，效率很是问题，隐患相当严重。至少，我不想后面我所参与的都还是这种节奏和情况，于公于私，都是相对不妥的！我必须在这上面——不求有所作为——至少有所动作。

 

    碰到了这本书，看到介绍说“一本在软件领域绝无仅有，32年后依旧畅销不衰的传奇经典！软件开发人员、软件项目经理、系统分析师必读的一本书！”外加出版社名称，所以，我选择了至少“过一遍”吧。说实在，怎么会叫“人月神话”这么让人看不懂的字眼？我也是刚开始也是一头雾水。一句话，至少过了再说！

 

    对我这种“生手”来说，看哪本项目开发管理的书籍都是差不多的。所以，看这本书的时候，虽然很多时候都若有感悟，毕竟里面确实是指出了我当前碰到的问题，也是被我忽略、无能为力、无可奈何的情况；但更多的是迷迷糊糊。

 

    最后，冲着里面一个章节“《人月神话》的观点：是与非？”，我就省下翻第二遍的功夫。直接琢磨、领悟。并想想我能开始有何动作。

 

•     第一批可以时刻自我提醒的要点（鉴于书中一些问题的解决方式对于我来讲还是“言之过早”，所以有些我只写“问题想法”要点，没写“办法”要点。）

    所有的编程人员都是乐观主义者：“一切都将运行良好”。

 

    人月是危险和带有欺骗性的神话。因为它暗示人员数量和时间是可以互相替换的。

 

    Brooks法则：向进度落后的项目增加人手，只会使进度更加落后。

 

    “概念完整性是系统设计中最重要的考虑因素。”

 

    结构师+开发人员

    结构师负责产品所有方面的概念完整性。

    每个部分拥有自己的结构师，他必须就体系结构向主结构师汇报。

    结构师的用户图像会有意或者无意地影响每个结构决策，因此有必要使设计队伍共享一幅相同的用户图像。这需要把用户群的属性记录下来，包括：

          · 他们是谁；

          · 他们需要什么；

          · 他们认为自己需要什么；

          · 他们想要的是什么。

   为用户群的属性（一种频率分布）明确地记载各种猜测。清晰和错误都比模糊不清好得多。

    

    巴比伦塔项目的失败是因为缺乏交流和交流的结果——组织。

 

   项目工作手册“不是独立的一片文档，它是对项目必须产生的一系列文档进行组织的一种结构。”

 

   “项目所有文档都必须是该（工作手册）结构的一部分。”

 

   团队组织的目标是为了减少必要的交流和协作量。

 

  每个子项目具有两个领导角色——产品负责人、技术主管或结构师。这两个角色的职能有很大的区别，需要不同的技能。

 

   对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。

 

  因此，即使是小心项目，项目经理也应该在项目早期对上述的一系列文档进行规范化。

 

  项目经理的主要日常工作是沟通，而不是做出决定。文档使各项计划和决策在整个团队范围内得到交流。

 

  在编写任何代码之前，规格说明必须提交给外部测试小组，以更详细地检查说明的完整性和明确性。开发人员自己无法完成这项工作。

 

  开发大量的辅助调试平台和测试代码是很值得的，代码量甚至可能会有测试对象的一半。

 

  必须有人对变更和版本进行控制和文档化，团队成员应使用开发库的各种受控拷贝来工作。

 

  “项目是怎样被延迟了整整一年时间的？……一次一天。”

 

   一天一天的进度落后比起重大灾难更难以识别，更不容易防范和更加难以弥补。

 

•    觉得有必要还得花时间先弄清楚的（或者说是进一步了解。因为第六感告诉我这是能帮我解决目前比较实际也是很有必要的情况，但是我还没发觉到。）

   增量开发模型更佳——渐进地精华

    

  人就是一切（或者说，几乎是一切）

 

• 可以的话，下次做系统项目前，我希望……

   能跟别人交流下别人的项目手册是怎么弄的，包括组织、使用场景；

   能有个地方可以体现多了什么可以用的技术点突破；

   能有个地方可以看出，新开发出来的功能点，多了哪些文件名、改了哪些文件、参考网站地址、目前的限制和仍需完善的地方；不需要以后还得非问不可才知道。最怕到时候连当初开发的人都回答得模模糊糊，一句“真的太久了。”；

   能有个地方可以时刻及时反应做了哪些开发要点要求（如文件夹命名），任务调整分配（尤其是某些技术点只是口头上说让谁去弄，往往就是问的人都忘记，应的人也没弄、没跟进。）；

   

• 我目前的做法、尝试

    场景：

    任务：旧项目新版本开放

    团队：小团队开发。由于某种原因，项目经理不和开发人员一起，一般一个星期才能碰头。平时都是QQ、Q群交流。参与业务讨论的还有市场人员（经理级别）。开放人员中有熟悉旧项目业务和程序。

    目前情况：

 

    1  项目经理发了份更改文档，即对旧有项目的更改要求。开发任务人员分配由开发人员中一个熟悉旧项目的人带头。

    2 每天有项目进度工作报告登记，即哪个开发人员在某个项目上今天做了什么事情、可供测试内容、需协助内容、明天计划做的事情。是测试人员维护登记的一份Excel，每天都有邮件。

       每天每个人都会向部分人员——老板当然是必须的哈——发工作报告邮件。

    3 每天该项目的开发人员都会开个小会。

   我的身份：在该项目上，我充当一名开发人员

   我的想法和做法：

   由于第一次开会，在讨论项目经理发的那份“更改要求”文档时候，发现指派任务和一些即时想起来的要求等没有进行正式笔录（即归为文档、方便查看沟通的意识）的情况，察觉到到时候铁定是在某个人在开发完正在做的任务后，还来问“还有什么要做”，而被问的人还得想什么做了没有诸如此类的，于是在第二天早上在经理写的文档的基础上，以括号、标注、其他颜色、粗体、文档结构目录等方式进行重新排版，添加指派人员。更重要的，是在里面加多一栏：开会记录。以时间倒叙方式进行组织！

   这么做不为别的，就是为了什么都是有依有据，什么都是可以查。当然，我先写一点点要点，然后，就一个传一个让他们确认和修改。就这么个过程，一大堆东西都暴露出来。“哦哦，是，还得弄这个。”“不是，应该得……”其实，就算是我也一样。哪怕还没过去24小时。其实，大伙也愿意配合。只是，就是可能都觉得不需要那么麻烦，每个人都记自己的，然后就没人肯来做这第一步。

   发现大伙在补充登记的时候，同时在讨论确定，这个不是很好的过程嘛。这个也是在统一概念、及时沟通的问题。我在里面也对一些更改要求提出自己的“重新定义”。都让大伙看。不要觉得“这个就不用记啦”之类的。我也跟大伙提了建议，把新开发出来的功能，里面多了什么文件、jar包、插件js，至少都列一下名字。毕竟现在也没什么其他专门的文档组织管理，那就在这里面先写着给大伙知道。当然，我自己先身体力行。

   目前，文档以svn的方式进行维护。而我，在这份文档上面的身份对应，就是一个维护协调者。毕竟项目不是我负责的，我没必要也不合适抢这个头衔。日报里面也就写着：“协助维护。建议由谁谁谁负责确定该文档的正确性。”因为，我更在意的，是想懂怎么维护好一个项目，保证它整个生命周期该有的质量。因为，在某个项目中，我个人感觉已经消耗了相当低效率的1年多的时间。这段时间内，虽然说我进行了一些规范化的尝试。但是，因为自己瞎折腾，所以效率不高，纯属吃力不讨好的事情。

    而现在，我真的对项目管理不规范有了后天的恐惧！所以，“责任感=勇气！“哪怕对着老板，我只要保证不喧宾夺主，不争功的前提下，有问题我就提！提了看不出有何反应我就写日报邮件，加强显示。然后在问之前提的那些现在是什么情况。当然，懂得提，也得有自己的Double方案（如果没有就给个想法呗，让大伙集思广益！）。别给人只会提问题，不会帮忙解决问题的印象。不过，这里我想说的是，问题提了出来，就是积极的问题。总有时候它会变成任务的方式被拿来做单独解决的。但若不提，就是我的责任过失！

   题外话，我会学着调整自己说话、沟通的方式。我会继续看书。但是，如果我会怕老板会因为我”敢说敢提“而反感还是表示有意见的而当心混不下去的话，那就只能证明，我已经跟错老板了。毕竟小公司就是要看老板的。还好，目前，没看出我是跟错人。不过嘛，要是薪水能再多点就更好了哈~目前只能说，先不想这些。