前言

最近一直被软件开发的效率问题困扰，恰好偶然的机会，收到了InfoQ的推送，这里有一个写作的平台，可以发表自己的一些观点和看法。恰恰我最近也遇到了一本书，就叫这个名称《软件开发生产率改进》。所以我的打算就是把这些读书心得，结合自己的实践写在这里。有些疑问性的东西，也会写在这里，如果有可以探讨的人，就可以有更多的收获。有句话，叫你有一个思想，我有一个思想，当我们交换的时候，我们都有 了两个思想。这么双赢的事，要多做。



软件开发生产率的问题，有人叫研发效能提升，这个问题从软件开发这个职业存在开始，几乎一直被研究，好像是一个无限的话题，49年第一台计算机问世，到现在有半个世纪，大家依然在研究这个问题。在《软件开发生产率改进》这本书里，也提到了这个问题。



现在出现的现象是，现在的人在不断的挑战，每个人都以为找到了解决问题的银弹。出来的结果都是自己满意的，因为是按着自己的想法去做了，可是究竟是提高了效率，还是为了达到自己控制团队的欲望了，那就不得而知。X理论，是大家最爱采用的管理模型，更多的强调控制。但是软件研发这个行业，在大家都知道不适合这种理论的时候，可是依然存在说做不统一，说要鼓励创新，不要控制，要更多的交流，可是真正的做的时候，就不是这个样子，为什么会这样呢？



现在软件开发的过程模型有很多，敏捷、CMMI、瀑布、XP等等。可是这个软件开发过程，应该在什么场景下使用？与现在的情况是适应的么？在现实的工作中，要不要考量CEO的喜好？这都是生存问题了。



以上的问题，只是在我从业的过程中遇到的问题的冰山一角。相信绝大多数人都和我一样，从一个技术人员出身，学而优而仕，走上了管理岗位。有的是纯粹的管理岗位，恭喜你，离报废不远了，这个是我看了好多技术管理人员的文章得出来的结论，技术人员做管理，还是有60%以上的时间要用在技术上的，而且技术人员做管理，其实更多的是项目管理，做的也不专业。



现在让我迷惑的还是角色分工的问题，团队管理、项目管理、技术管理究竟是如何分工协作的？而技术经理这个角色应该做什么事情？何况以后要做到高级技术经理，又要做哪些事情？让人困惑的问题真是很多呀。



相信，如果罗列下去，问题还有好长好长一串。在此就不写了，想再多，也不如去实践。那就从我的读书笔记开始，一点一点的思考吧，相信随着认识的提升，会有那么一点点改善。而研发效率的提升，会伴随着我们这些技术人一生的，如果你还在软件工厂中做事，那么这就会永远陪伴你。因为，无论你多努力，永远也跟不上产品的节奏。一个想法变现，虽然有现代技术的支撑，还是太难了。而结果导向的人，永远觉得不够快，软件研发人员永远是会偷懒的，所以现在绝大多数的公司采用的还是X-理论来管理软件开发，并相信这是唯一正确的事情。具体怎么样，我也不清楚，那就从第一节开始吧。



团队管理

真正的开发工作是理解用户需求、制定和测试设计方案、纠正逻辑错误、协调相同任务上其他同事的工作以及编制文档。

其实，我们在一个软件的研发过程中，做了好多不应该去做的事，除了以上的真正的研发工作。想想都有哪些？可是为了完成以上工作，也要做许多的事情，理解用户需求，产品经理要去用户现场沟通，要画原型，考虑实现方案，因为产品设计出来的东西，技术人员不一定可以做出来。所以，产品需求的理解，本身就有一个过程，设计实现就要来往多次。即使这样，还会出来，产品的需求在迭代的先后顺序的问题。前面做的工作，在后面因为其他研发模块的需求，导致先前的工作需要大规模的变动，试问，这样的工作方式，研发效率能高么？所以，我觉得，正确的做法是，在需求不明确的情况下，尽量做简单，修改容易，快速上线，而不是按月上线，而是按小迭代上线。



在这里其实最好的是，明确了团队应该去做的最有价值的工作是什么。只要为这些服务的，就是没有问题的，应该提倡和鼓励。时间关系，今天开篇先写在这里。