当前位置: MXJAVA > 编程开发 > 文章正文

　　公司想要发展，必须要有业务和市场。但这些条件并不是与生俱来的，而是要靠一点一滴的积累和改进逐渐形成的。对于刚刚成立的小公司，第一单业务是没有能力挑选的，即使不赚钱。有些公司因为第一单业务而逐步走向辉煌，也有一些公司却是相返，甚至破产。公司要发展，只能踏踏实实地做好项目，建立良好的口碑。若只是想赚点钱，并不打算发展的话，那么做不好项目也是不行的。

　　我入行５年，做过的大小项目不下１５个，有些项目只要一两个月，有些则要一年多。其中好做的项目少之又少。何谓好做的项目呢？不要太大，不要太复杂，不要加班，不要……这样的项目往往没多少钱赚。对于客户来说，他们希望做成的软件质量要好，价钱要少，开发周期要短等，这些条件加起来，一个原本好做的项目就变成了不好做的了。

　　把不好做的项目做好是对每个公司能力的检验。公司的企业文化、管理水平、员工能力、稳定性、积极性、态度、以及技术力量是决定项目能否做好的关键因素。国内的公司大多都有企业文化，这些所谓的企业文化严格的讲并不是真正意义上的企业文化。仅仅是拿来吹嘘，给别人看的。真正的企业文化是需要积累的、全体员工认同的、具有企业自身特色的。管理水平高低是企业成功与否的关键，好的企业拥有一批忠诚的且认同企业的中层，他们是企业的中流砥柱，企业的发展依赖于他们。员工能力、稳定性等都是需要企业不断改进和积累的体现。蒙牛的牛根生曾经讲过一句话：“财聚人散，人聚财散”。我认同这个观点，但不完全认同。没有企业文化，管理水平低下，发再多的钱，也没有凝聚力，也不会长久。话题扯远了。

　　那么怎样才算做好项目呢？先让我们思考一下，项目的好坏谁说了算？自然是客户。如果他对你们的评价很好，你的老板喜在表面乐在里心。不过我敢保证，大多数老板想到的第一件事并不是你们辛苦了，该给你加多少奖金，而是客户能否给他下一单生意，怎样能在这个客户身上赚更多的钱。当然，如果你的老板对你很满意的话，加薪日就不远了。所以，要想加薪，就得让你的老板对你满意，要想让老板对你满意，就必需让客户满意。毕竟客户说好才是真的好。那么怎样才能让客户满意呢？首先我们必需清楚客户要什么？（这个问题似乎很白痴，但就是有很多公司不清楚。）答案当然是最终的软件产品。他希望最终产品无bug，界面美观，操作简单，功能强大，运算速度快，安装简单……看，客户就这么一个简单的要求，他只想要个好的软件而已。对于专业软件开发的我们来说，这不正是要做的事情吗？

　　在继续下面的话题前，先问一个问题。想要看日出，需要向东走，那么往西走会不会看到？也许你很努力，也许你很有毅力，也许你会不断地向西走，但结果却是否定的。这就说明，即使我们很专业，即使我们很敬业，即使我们很有责任心，即使我们很努力，但结果并不见得一定会好，除非方向正确。你认同吗？

　　回忆一下你以前做项目的过程。和现在一样你是一个项目经理。你很出色，并且公司领导对你非常信任，于是，把对公司有着重大意义的项目交给你来负责。对于公司的信任，你非常感激，你开始比以前更加的努力。不过你只是个项目经理，没有三头六臂，不能无时无刻地检查需求，也不可能一个个地研究UML图和ER图，更不可能一行行地检查代码以及测试用例。你所能做的就是要求各小组组长，根据你的进度安排，提交各种报告。定期召开周例会、评审会、里程碑会，填写各种跟踪报告等等。看起来，你比以前更严格了。也许你也只能通过这一系列的活动来判断项目进展是否顺利。也或许你并不愿意这样做。你知道，这个项目对于公司和你有多么重大的意义，你也知道，这个项目不好做，时间有多么紧迫。你更清楚开发人员都非常忙，有一部分已经开始加班了。当然你也很忙，除了制作各种文档、报告、检查各小组提交的报告外还要时常与客户联系，沟通。有时，你不得不因为参加公司一个无聊的会议而放下手头的工作。然后和你的开发人员一起加班到很晚。当然你也可以选择不这么做，但安排在你身边QA（质量保证）人员总是盯着你，稍有不对，便向高级经理汇报。

　　你手下的组长们都很出色，他们都是精英。但他们跟你一样，都在忙着制作文档，维护文档。还不得不因为规定的会议和必须的会前准备占去大半的时间。他们的重心几乎放在文档上面，要知道，他们可是技术精英，并不擅长写那些被规定好了格式的文档。他们拿手的，恰恰是解决软件开发过程中的实际问题。如果没有那些烦人的文档和会议，他们就可以一显身手。需求组长会指导分析人员如何更好地分析用户需求。设计组长会和设计人员一起搭建项目架构、数据库以及业务流程。编码组长可能会和编码人员一起解决技术难题，检查他们的代码，和他们一起重构。测试组长有充足的时间准备集成测试用例，压力测试及业务逻辑点等等。由于大部分时间放在了文档上，项目中的技术难点，没有时间去解决，组员没有经验，写了个算法似乎解决了问题，但谁知道又会跳出多少臭虫。接下来问题越来越多，时间也越来越紧。文档越来越完善，但项目却越做越乱。不知趣的客户偶尔也会提出需求变更，遇到较大的需求变更时，你不得不召开需求变更分析会议，集中了项目组精英，大家一起讨论可行性（这种讨论结果似乎都一样）。接下来，写需求变更报告，审批，维护计划，变更文档。眼看着离客户验收的日子不远了，实质的开发却还差很远。于是你决定，全员统一加班。这也许就是传说中的最后一道防线吧。终于，在经过无数的日夜，过程的无数次迭代后，你们严格按照模型定义的那样，做出了一堆专业的文档，完成了每个PA要做的工作。QA人员很轻松地完成了本职工作，对你们的工作给予了肯定。你的队员们有了黑眼圈，疲惫不堪。眼看着客户就要来验收了，此时你的测试组长向你报告，又发现几个bug。客户验收前发现bug是很要命的事，你条件反射地找来编码组长，而他却不得不找模块的编码者来解决。仔细研究后，给你的回答是，需要时间。此刻你终于明白，这些专业的文档并不能替代实质的软件拿给客户演示。当你将这些漂亮的文档交到客户手中时，他们却皱着眉头观看着软件的演示。再后来，你的老板叫你去了他的办公室。

　　你和你的团队在总结会上对造成项目质量低下的原因进行了讨论。大家一致认为没用的文档太多，开会太频繁，过程过于复杂等等原因是导致项目组反映迟钝，质量低下的主要原因。要知道，除了加工资，很多时候，全员没有这么统一过。你向高级经理提交了团队的意见，得到答复却恰恰相反。高级经理认为，项目失败的原因在于文档做的不够细，由其是计划阶段没有识别出存在的风险以及风险规避措施做的不好，导致风险发生。计划中的风险缓解方案不够细，导致风险发生后，没有及时得到缓解。作为项目经理的你，除了认真的思过，没有更好的办法。

　　经过这个项目后，你对文档的作用产生的怀疑，但你的上司却要求你必需做好各种文档。那么公司为何总是强调文档要详尽呢？后来的一个项目中，你终于明白了这一点。项目进行到一半，项目骨干向你提出离职请求。你立刻意识到严重性，于是赶紧向高级经理报告。高级经理并不紧张，因为他一直都有看你的报告，也会从QA那里得到项目的情况。他从容地重新给你分配了一名精英，精英通过骨干留下的详尽文档，很快就融入了项目组。你开始明白，详尽的文档可以很好地弥补人员离职或其它原因带来的损失。你也明白了人员提出离职，高级经理却依然那么从容的原因。不过你并不认同公司的做法，你认为公司应将精力放在为员工创造更好的条件，在能力所及的范围内尽量满足员工的需要，和如何留住员工。而不是放在员工离职后怎样才能让项目顺利进行上面。要知道公司越是如此，员工也就越发想离开这家公司。你开始怀疑公司的经营理念，怀疑公司对员工的态度。你不再向以前那样拼命，项目的质量也开始打折扣，同样，老板的脸色也越来越难看。再后来，你辞职了。高级经理依然那么从容。

　　上面的两个例子，在国内的公司中是普遍存在的。项目好坏起决定性因素不是文档，而是程序。把精力全部都放在对项目毫无用处的文档上面，却忽略了最重要的东西，最终不会换来好的结果。为何不换个思维，将代码看作文档？将繁琐的过程变得简单，让项目组学会快速反映的能力？

　　好公司+好管理+好员工+好方法＝好项目。

　　每个公司都声称以人为本，员工就是公司的最大财富。来个不恰当的比喻，对于贫穷的人来说，每花一毛钱都要掂量掂量，但对于富有的人来说，几万几十万也是个小数目。钱用的好，会为你赢得更多的财富，若用不好，会带来更大的损失。到那时上面的公式就应成了

　　烂公司+烂管理+没员工（或没能力的员工）＝？