《网易一千零一夜》读后感10篇

　　《网易一千零一夜》是一本由网易杭研项目管理部著作，电子工业出版社出版的平装图书，本书定价：46，页数：314，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

　　《网易一千零一夜》读后感(一)：强大的PMO

　　怀着对网易PMO前辈们的崇敬之情，认真研读了书中所有的案例和理论，认识了好几位长得又好看，理论和实践又扎实的小姐姐。他们真的非常棒，是我学习的榜样。

　　有几件事是我接下来做重点去学习的：

　　1、由于我并没有接触过软件开发的项目，所以对于敏捷项目管理还是门外汉，里面的一些站会，故事点，教练之类的东西还不是能特别理解到位。书中的内容都是根据我观察到我们公司内部的情况，进行联想后有一点点的理解。

　　2、工具jira，书中反复提到这个东西，作为项目管理应该是一个比较重要的工具，我也看到钉钉中有这个工具的集成，需要和技术同事进行一次调研，看看这个工具是否能具有更好的管理特性，并能普及使用。

　　3、wiki知识库，这东西我非常需要，好像我们公司的同事正在用，要好好学习一下。

　　对于书最后出现的二维码，不知道他们的生意做的如何，希望能做的非常好，这样这个行业才能不断的出现更好的理论和更广阔的空间。

　　小黑说，这本书就是要把网易的想法灌输给所有的公司，如果通过这本书可能还不够，例子很丰富，理论基础有些没有说清楚，还有一些奇技淫巧我看着也很不舒服。

　　有收获，谢谢。

　　《网易一千零一夜》读后感(二)：网易一千零一夜 感悟和笔记

　　收获蛮多的，学习到了许多的管理经验、方法、流程。记录如下：

　　不要凡事都恨不得事必躬亲

　　不要追在别人屁股后面做监工

　　言必行，行必果

　　做项目、懂业务、懂人

　　项目周期时间的估算方法：

　　1、自下而上的估算

　　2、专家判断，由专家判断评估，更准确。

　　尽量缩短迭代，尽快交付成果

　　建立通畅的反馈渠道

　　内部用户反馈

　　外部用户反馈

　　团队新老员工比例不应超过1：1，其中新员工包括正职/借调+实习生

　　研发规范执行到位的程度

　　研发效率/产能，不是团队负荷度，而是产能吞吐量

　　版本中是否出现过技术优化需求

　　线上事故频率及严重度、修复速度

　　ug Bash

　　持续代码继承工具：

　　（4）单元测试XUnit家族以及IBM的Rational Purify，Quantify，Pure Cover age等。

　　（5）静态代码分析工具，开源的有项PMD、CheckStyle、FindBugs、Splint；商业的有Klocwork、Coverity、Pc-lint等。

　　手上任何一件事情，都有头有尾，有始有终，懂得闭环。

　　WBS：工作分解结构（Work Breakdown Structure） 创建WBS：创建WBS是把项目 交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。

　　《网易一千零一夜》读后感(三)：困境源于内心

　　最近公司所有项目都在推进项目制中，自己负责的业务也刚刚开始，对于项目制度和项目经理大家各有说法，好坏目前下结论有点过早。有一点是肯定的，任何变化都会有阻碍和质疑。从自己角度，知道项目制度是需要推进的，但是我们到底需要什么样的项目管理制度呢？难道只是个甘特图和各种会议？如果这样的话，应该无法解决问题的。项目不同角色的痛点在哪里？这些痛点是否有优先级，是否都可以用项目管理制度解决？

　　正好老大扔过公司内部项目管理的新书来，利用周末一口气都读完了。

　　整书分了四部分，第一部分应该属于初级的东西，形式上的东西，但是对比我们目前很多项目，发现都在走书里说的坑，比如说把繁琐的会议当作项目管理，比如说单纯的推广流程和制度，而忘了项目管理的本质是为了解决问题和提高效率的，比如说项目经理一来了就开始排期排期，以及一堆高大上的工具和方法论，而忽略对项目目的和需求的斟酌……

　　后面的部分读下来，很多时候让我忘了这是本项目管理书籍，感觉一般产品经理、团队负责人、协调人都会遇到此类问题。我们很多的流程其实都是为了信息的传递和控制，而这个技巧不是工具或者制度可以解决的。

　　从自己的工作角度，也有一些启发，比如现在我们的闭环管理做的一般，关键功能或者新功能的数据反馈做的不够，包括需求变更的记录做的不是很好，等等。

　　困境源于内心，这句话说的特别好。