一周一本书-20-《软件方法》-潘加宇

如何做好一个软件？

一个软件要做的工作可以量化么？如果能量化，那有流程么？如果有流程，那有方法么？

大学学的是计算机，但是最不愿从事的行业就是软件。结果呢，出了校门现在，一干就是8年。我并不是在摆什么资质，因为我们应该清楚，一份工作你重复干了8年，你的经验并不是8年，而是一年而已。

《软件方法》讲的是用UML语言来辅助我们进行软件的从0到1的过程。这个过程的结果并不是最终运行在电脑屏幕上的那个界面，而是一堆图纸，可视化的图纸。

是的，确实是图纸。建筑行业有设计和施工图纸，电工行业有设计和实施图纸，城市规划有图纸··· ···任何你看得到的工程都有图纸，你要写的软件居然没有。

“图纸在我脑子里呢”，我也曾经说过。直到看到这本书。

这本书的直接受众应该有两类人：

1.程序员

这类人一般的工作思路就是提功能的人说要做什么，嗯嗯哦哦之后，迫不及待的打开编辑器开始写代码，调试，然后发现做完的东西，总是被告知要修改，没玩没了的改。

2.项目管理者

这类我们称之为“IT包工头”，他们既要跟客户聊需求，转头还要跟程序员转述。作为一个中间人，两边都要沟通，现实是两边都没沟通好。用户说的不就是这样的么？怎么做出来的东西就是不对呢！面对需求和变更，他们是最无奈的，因为他们面对的并不只是程序，而是公司的成本和效益。

我甚至推荐产品经理也来看看这本书，因为一个产品到底要满足谁的需求，提供什么样的功能是一开始就要想清楚的事情。精益思想的逐步迭代改进是没错，但是也要求你在产品之初，能想明白你产品到底能带来什么样实实在在的客户价值。

很庆幸能在工作的第8个年能看到这本书，更荣幸的是，和自己的团队在一起用了7个课时一起讨论学习，一起做作业。最让人兴奋的，是每一次在进行项目讨论的时候，我们都开始用《软件方法》中学到的知识，用新的方法在做我们每天都该去的的事情：内部沟通更加有条理了；需求变更更加谨慎了，和客户的沟通更加有效率了··· ···

这是不只是一本书的作用，更是不断打破自己习以为常的工作方式的决心。

希望大家一起加油！