[转]关于项目管理软件开发的一些思考

Posted 2020-10-15 你好，生活！

偶遇该文，里面的内容是在工作中时常念到的，转载收藏。

感谢原作者。

http://zhanjia.iteye.com/blog/1876344

---------------------------------------------------------------------------------------------------------------

    下面总结几个曾经思考或遇到过，觉得有必要梳理一下的观点：
 
做项目的公司
    很多做项目的公司，太过于注重速度而非效率，注重结果而非过程，注重功能点而非质量，以销售为主，看重利润，对投入资源方面特别吝啬。当然，公司为了生存，这些其实都可以理解。但就我个人感觉，很多公司在这方面做得太过了。他们可能从未真正想过，如何通过N多项目，慢慢积累起来，形成自己的核心产品，或者说形成自己的核心竞争力。你也许反对这种观点，是的，你说的这些老板经常站在上面喊话：你们要将这个项目做成公司的一个产品，然后进行推广，接更多的项目。下边在听的人早已习惯了老板的这番豪情壮语，听完了就当啥事都没发生过，继续干自己的活。
    有些老板因为站得太高，看不到下面的事儿，给下面的人的支持太少；有些老板因为不懂技术，一味的控制成本，生怕被下面的人耗光了。呵，老板通常都是比较抠门的。无论是哪种情况，这种公司很难形成一个好的产品，很难形成自己的核心竞争力。有些公司只能勉强过日子，活得也挺辛苦；但有些公司却真的发展壮大了起来，日子美滋滋的。当然，这跟中国的大环境有很大的关系，只要有权、钱或关系，公司就很难倒闭，不仅不会倒闭，日子还会越过越好。最广为人知的例子当属国企了，那真的是高成本、低效率，但国企依然很有钱途，你明白的。后面这类公司其实不在我讨论的范围之内。
    就像中国的应试教育一样，我们已经习惯了某种标准，进入了某个圈套，被某种规则所束缚了，很难或不愿意跳出那个框框。如果你跟公司提建议，改善这种做事的方式，公司会告诉你，如果不这样做公司就会生存不下去。真的是这样吗？我看是一厢情愿吧？我们应该多学学《重来：更为简单有效的商业思维》（Rework中文版）一书里面的一些观点，书里面的观点非常独特而富有说服力，是一本值得反复阅读体会的书籍。里面的观点告诉你，失败并非成功之母；要想让客户接受你的产品，首先得让你自己接受；计划就是瞎猜等等原先你并不知道，原先你认为是正确的，但它却告诉你是错的的一些独特观点。
 
    我自己没开过公司，所站的角度也不同，有些因素可能没考虑到。
 
项目管理
    什么是项目管理？说得简单通俗一点，就是利用各种手段与资源，在指定的预算与时间内完成项目。时间与预算基本是不变的，资源只能有限度的调配，但手段却有无数种，正所谓有100个项目经理就会有100种管理方式。
 
    抛开一切外在的因素，项目的成败，很大程度取决于项目经理的管理水平，以下是关于项目经理的几个问题：

    项目经理真的完全理解客户的需求吗？——正确理解需求，才能减少返工，项目进展会更快
    项目经理把需求完整的传递给项目组了吗？——吃苹果怕吃到半条虫，说话怕只说一半
    项目经理关心过某个功能模块的业务流程吗？——通常项目经理最了解业务流程，能够给项目成员们最好的业务指导
    项目经理登录过几次系统？用过哪些功能？这个丑陋的玩意儿真的是客户所期望的吗？——通常项目经理最了解客户的需求，这时项目经理就是最好的客户代表。可以从功能界面、业务流程、业务术语等检验系统是不是客户符合客户最初的期望，是否有需要改善的地方。
    项目经理，你有没有把客户后续的反馈意见传达给项目组了吗？——项目组的所有成员都应该知道客户的想法，而不仅仅是项目经理知道
    项目经理不正确的决策，导致项目加班加点，项目进度滞后——多征求项目组的意见，你的意见不一定是对的

    以上第3、4点，通常最直接的导致客户的不满。每当你给客户演示系统的时候，客户经常会对你提的一些问题：

    界面太丑
    界面的业务术语或操作提示完全是从技术人员的角度进行设计的，项目经理或分析人员到底有没有参与到这些业务流程的设计，对术语、提示进行梳理，并指导技术人员进行开发？——例如，有些技术人员在做异常提示的时候，把后台代码抛出的异常直接显示到页面了，这是非常低级的一种错误
    这个问题已经提了好多次了，我不知道为什么这么简单的问题你们就是不改？真受不了你们
    你们从来都不会主动去考虑这个事儿应该怎么做，如何改进，每次都要等到我主动提出的时候你们才会去做，最后做完了还有一堆问题，我真不知道你们想干什么？

 
简洁
    大道至简，大道理通常都是很简单的，简单到一两句话就可以说明白。同样，越是伟大的产品，其设计与使用会越简洁。比如苹果和Google的产品都极其简洁，但却不失其伟大之处，它们都有许多粉丝，都受到很高的评价；再如时下最流行的jQuery框架，语法也是非常简洁，但功能却很强大，而且很高效。
    同样，在做项目的时候，当你问客户希望系统的功能界面是什么样子的，客户常常会告诉你：简洁、大方。虽然这听起来很扯淡，似乎没有任何价值，问了等于白问，客户也许压根儿就没想过这事儿。但由此我们基本可以得出一个结论，简洁的确非常重要！
 
    在这个行业呆的时间越久，就越发觉简洁的重要性，但我发现身边好多人都没有注意到。
    软件的简洁性，不仅仅指系统功能界面及操作上的简洁，而是要保持软件工程的整个过程都尽可能的简洁。比如，做需求分析的时候，尽量考虑既能够满足用户的需求，又不会投入过多的资源，需求分析不一定要面面俱到。功能界面的设计要抓住用户关注的重点，如首页应该摆放什么内容，应该展现什么字段？我们经常忽略的一点是，未深入的考虑界面展现的内容对客户有什么作用，而是一味的往界面堆数据，结果给客户演示的时候，客户会问你，你有没有想过展现这个数据或者用这种实现方式有什么作用？业务流程的设计，尽量保持流程简单，清晰，易于实现。数据库的设计，尽量用最少的表，最少的字段来实现。当然有时需要考虑对数据的冗余，可能会增加表或字段，但这样通常可以减少表之间的关联性，提高处理性能，降低业务处理的复杂性，所以最终整个软件会变得更加简洁。代码上，对于同一功能的实现，也尽量用最少的代码、最简单的方式来实现，这样既减少了代码量，也使代码更清晰易懂，易于维护。
    我发现，保持软件的简洁性不仅能够减少不必要的投入、提高开发效率，而且能够提高产品的质量、更好的满足客户的需求。
    IT大佬苹果公司和Google公司的产品在简洁性上几乎体现得淋漓尽致。
 
程序员的代码不太靠谱
    在这里，我并不是想对所有程序员进行否定，只是想说明一种常见的现象。
 
    一个项目，从开始到结束，可能会经历各种各样的需求变更、功能修改或人员变动，从而项目本身潜在的问题也会越来越多。归纳起来有两大原因：

    代码测试不充分
    业务不理解

    先抛开测试团队与代码走查等因素，程序员首先必须对自己实现的代码负责。有些程序员，代码写完了，就不会再去看了，他们脑子里的概念是写完代码就是完成任务。有些程序员，测试自己实现的功能时，像是在走过场，跟没测试没太大区别。有些程序员，对业务不理解，但他就是不说，非得要写出不正确的代码；而有些程序员理解业务，但事实上他理解错了。
 
    我们可能经常会问程序员的问题：

    这个功能你完成了吗？——答：完成了
    做完之后你测试过吗？——答：测试过了，没问题
    对于这几种情况，你都测试过吗？——答：测试过了，都没问题
    要测试仔细一点，有问题尽早修改，不要到最后交付给客户时才发现问题——答：我都测试过了，肯定没问题

    这下可放心了，工作完成了，测试也没问题。可过几天给客户演示的时候，却突然冒出这样那样的问题，而且还不少，很多都是客户自己发现的。这是为什么呢？当然，软件的问题总会有，但有些确实是不应该出现的。
 
    每当我检查其他同事写的一些代码时，有些时候真的很无奈，甚至想不明白为什么会这么写，为什么会经常犯这样的错误？——真的是不看不知道，一看吓一跳！
 
    所以，有一位真正理解业务的技术人员，对代码进行检查很重要，特别是对核心代码、关键业务模块的实现流程的检查。
 
别再拍脑袋做事儿
    拍脑袋做事真的很危险：

    客户提的需求别拍脑袋答应，尽量快速评估一下再答复。如果无法现场确认，回公司讨论之后再给客户答复
    客户原来已经认可或正在使用的功能，别拍脑袋随便修改，即使你的很好想法，但在实施之前最好与客户沟通确认之后再做，自作聪明是需要付出代价的
    别拍脑袋写代码，先把思路理清楚，画个流程图或伪代码之后再动手也许会更好

 
不要浮躁
    关于浮躁，程序员们应该有比较深的体会。只要你摆正价值观，降低姿态，怀着热情去工作，浮躁自然就会不复存在，而且工作也会更开心了。
    在这方面建议看看罗浩的《野兽派游戏》、《降级论》两篇文章，相信里面的一些观点会与你产生共鸣，使你豁然开朗，从增加自己的自信，更坚定自己的目标。
 
注重反馈，提高服务
    最后再提一下，客户的反馈很重要，客户多次提到的问题要特别关注。提高服务意识，多与客户交流，及时反馈问题。