看了《走出软件作坊》后，我最大的感受就是同样是初创公司我们虽然还有很多不足，制度很多方面都不完善，所以我们能做的就是，尽我们最大努力将事情做好，虽然这些制度表面看起来，都是公司问题，本质上都是人的问题，怎么用三五个人十来杆枪，在有限的资源下做无限可能的事，只有公司人员成长了，公司才会成长。所以本文，主要的讲述我在根据这本书的感悟，当中我所提到的方式或结论，只是个人观点，可能有失客观，毕竟我也是新人。

　　我的原则不是说问题就没法做，路是死的，人是活的。我提问题，只是想我们项目组更加专业优秀

　　新技术与项目关系

　　我认为的问题

　　在公司中，我喜欢新技术是众所周知的，而我也经常想在项目中实践我的新技术，但是新技术不等于好项目，首先新技术铺开需要几点条件。

　　1.项目是否都有这样的需求，没有新技术就不行。

　　2.新技术是否对项目有明显推动。

　　3.推广时机对不对，有些东西虽然很有帮助，但是当时却不是团队所有人都意识到的。

　　而我在项目中，渐渐发现我的做法违背这些原则，往往本来想做一些好东西共享给项目，但往往却事与愿违，结果往往造成新技术达不到明显的作用，还搞坏团队关系。

　　我有时就在想，我们应该站在项目角度上来看待这个新技术问题，其实我也常常听到新技术不能占项目的百分之几的云云，以前我也是简单看待这个问题，以为只是怕技术上无法实现，所以对新技术各种管制，其实新技术推广还要需要很多方面的影响。那么团队怎么管理新技术?

　　我想的理想解决办法

　　在书中也有对这方面的描述。我总结下来，解决方式主要就是开会讨论。但是开会也不是随便找几个人商量，也不是几个人摆下龙门阵，得有主题思想。找人需要主要的是下面几个问题。

　　1.相关人员需要对这项技术都有足够了解。

　　2.主要为有经验的老手。

　　3.得有个拍板的人

　　会议得有结论，会议主题主要评估一下内容

　　1.新技术比老技术的优缺点。(结论就是新技术是否存在价值)。

　　2.新技术对项目资源影响(结论就是是否对人，财，物，时间，先定性是好或者坏的影响，然后尽量量化分析)。

　　3.决策(结论就是做或不做，往往需要一个拍板的人)

　　如果最后决定要实施，也就是大多数人认为利大于弊时候(其实有时候是主要拍板人的意志)，也不能全部铺开，得先搞试点，验证开会所说的到达效果是不是属实。(我觉得这和邓爷爷搞改革开放一样，先开放几个地方，看看效果，大家都看到这个模式好，以后推进的阻力也就小了)

　　文档与项目关系

　　我们项目就是那么三四个人十来杆枪，前期也就是忙不过来，我们先说说文档的事情，我觉得我们项目上，一直对文档比较欠缺，大家用外国先进的开发理论来说项目怎么应该少写文档，一方面我赞同文档不一定马上写，但是出来混，迟早都是要换的，这些文档不是不重要，只是他现在的优先级比较低，后来看了下国家标准文档(GB8567-88)核心的多，快，好，省这些基本管理范围覆盖完了。现在的客户，你做事好不好，能力先不说，表面上浮的东西都不行，那映像差多了，以后我们欠下的文档在我们验收的时候的，肯定是要还的，这就是国情。外国东西是好，但是不符合国情。是不行的，你没环境用城市包围农村的战略来革命偏要硬上弓，最后结果就是反围剿失败，大伙一起战略转移吧。

　　文档是管理的基石(不是说没文档就不能管理了，只是说更专业更有说服力)

　　1.从汇报工作角度看

　　不论先进的敏捷式开发，还是老传统的管理思维，都有个基本管理过程组，启动->计划->实施->检查->结束，这一系列管理过程组，他依托的载体就是这些文档，为什么，你想想，给BOSS讲工作，本来管理就是摸不着的，任你说的天花乱坠，BOSS也最多信你2，3分，BOSS们都是以结果为导向的，怎么将无形的管理结果转化为看的见摸得着的东西，就是文档上的数据(造假数据问题不是我们这里讨论的问题，那是人品问题了)。你想想开会的时候，你就拍的脑袋说我们达到什么标准，又做了什么事。没具体数据，谁信啊。结局就像书里说的久而久之老总便不信任你了，渐渐的项目资源就要不到了。

　　2.从项目日常管理角度看

　　首先我们说说项目全生命周期吧，一个标准项目周期为(这里是理论上的)，定义阶段->开发阶段->实施阶段->收尾阶段，每个阶段也有相应的管理过程组和各个管理知识域，比如所有的管理基础中的范围管理吧，他输入是，可研报告，项目合同，项目章程，项目环境因数输出是项目范围说明书，WBS(工作分解表)，而我们项目往往都有个这样的问题：

　　客户说某某功能必须有，项目经理就和技术大牛商量这个怎么怎么做，经过一阵欢快的讨论后，项目经理说ok,就这样做，于是代码人员开始coding，做完很久以后，测试人员验收测试时大叫一声，“呀~~这是什么时候加的功能啊?”编码说“老早的事了，你问项目经理”，

　　项目经理一来说“是啊，早加了，不过我怎么觉得这里做的有点问题，”

　　编码人员：“当初你就是这样定的，你忘了?”

　　项目经理:“呀?为什么当时会这样定啊?”

　　代码人员：“xx 你xx。。。。。。。。。。。“

　　于是又是一阵讨论，最后这个功能就这样糊里糊涂给验收过去了。

　　这种问题为什么会出现呢?这就是范围管理没有落实，我们项目上经常说需求变化太大了，计划赶不上变化，所以这文档就算了吧，口头传达下这个指令，要知道人脑的记忆力是不敢恭维的(我就经常忘记自己写的代码)。关于变化问题，连教科书都说：“计划不变是相对的，变化是绝对的”，瀑布流式开发永远都是幻想。

　　遇到这样问题，按理做法是评估->更新WBS->实施->发布新版本的WBS,->测试人员编写测试用例。不管怎么着最后都要落实到文档上去，白字黑字，如果客户能签字最好，如果不行也要发封邮件知会一声。

　　3.从项目客户验收角度来看

　　在《走出作坊》书中看到这样情景，有时候项目关系人太多，需求你一个我一个，而这些关系人的需求甚至有时候都是相违背的，但是项目经理也全部照单全收，也没有文档，最后验收的时候，往往达不到所有关系人需求，而这时候提这些需求的关系人，往往可能时间久了忘了，或是根本就是挖个坑给你，这时候没有文档白纸黑字写在那，你纵有舌战群雄的本事，但是客户的口水也能把你淹死。但往往为了客户关系，项目经理不会去争辩，最后也只有哑巴吃黄连。

　　如果要实施文档，我们项目组怎么做?我的建议是

　　首先要做什么?

　　因为我们已经有很多债需要还，想一时半会解决这些问题都是不现实的，我认为我们应该为文档排个优先级。而项目需要哪些文档呢?

　　根据计算机软件产品开发文件编制指南《GB8567-88》，项目文档包含如下部分(这都只是参考，不一定全部按照执行)

　　1.操作手册

　　2.测试分析报告

　　3.测试计划

　　4.概要设计说明书

　　5.开发进度月报

　　6.可行性研究报告

　　7.模块开发卷宗

　　8.软件需求说明书

　　9.数据库设计说明书

　　10.数据要求说明书

　　11.文件给制实施规定实例

　　12.详细设计文档

　　13.项目开发计划

　　14.项目开发总结报告

　　15.用户手册

　　这些标准文档包含了项目生命周期所有的文档，晃眼一看，真是浩浩荡荡，但是我们项目就这么两三个人十多杆枪，这干脆都别开发了全部做文档了吧!当然这是不现实的，所以我们需要对这些文档分类(这在《走出作坊》书中也有说明)，既然我们无法做全全部文档，那我们就抓住关键的20%，也就是管理域当中的四个核心多，快，好，省(分别对应范围管理，进度管理，质量管理，成本管理)而这四个核心，以范围管理最为基础，所以我觉得我们应该这样做

　　怎么做?

　　第一步：将项目已有功能整理成范围管理文档，形成需求说明书和工作分解图(WBS)，以后如果有新的需求，就发布新的版本

　　第二步：根据需求说明书和WBS，完成测试用例与测试计划。

　　第三步：根据前两步的步骤，预估我们的进度，用前导图，甘特图等分析方法，做出项目的进度管理计划。

　　第四步：根据前三步方法的结果，做出成本管理计划，做到控制项目。

　　谁来做?

　　需求文档：售前人员，项目经理

　　测试文档：测试部

　　进度文档：项目经理

　　成本管理：项目经理

　　谁来监督?

　　计划做了，实施也做了，那么就该谁来检查了，在我们公司，我觉得这就是由我方boss，甲方老大，(理论上还有监理方)组成的项目的管理层，主要工作就是审核项目经理工作报告(各种文档)。

　　本文出自 “不怕错就怕不闯” 博客，请务必保留此出http://jacksongblack.blog.51cto.com/6378693/1334544