小公司如何做好项目管理.docx

《小公司如何做好项目管理.docx》由会员分享，可在线阅读，更多相关《小公司如何做好项目管理.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、小公司如何做好工程管理1需求调研我觉得需求调研非常的重要，1年前我还打算做一个在线 教育服务平台，理念就是淘宝在网上卖商品，我在网上卖教 育资源，我提供网上交易场所，签约的老师、学校以及培训 机构提供可交易的服务，这种服务可以通过视频、音频、在 线PPT、文本的形式展现。忙活了好一阵，发现这个市场早就 有很多人做了，而且这个市场并不是很好做，首先在网上学 习的人有几个?并且先不说前期推广需要海量资金就是所需要 的那么些高性能服务器丫也买不起!这件事就此搁浅，结果信 了马云的邪，2年后你还想创业你在创业!我觉得这就是典型 的需求调研没做好，没有对用户需求做调查，没有考虑同行 竞争，没有考虑可行性

2、!另外还要考虑括行业标准和法律规定，比方前些时候国家就出台了关于办视频网站的政策，我 做行业情况尽可能的把需求调研做全面，这样才可以保证项 目首先是可以赚钱的。那么文档要写吗？我觉得可以不要正式 的文档，小公司的人手本来就不够用，要把主要文档化工作 集中在重要的环节上，对于需求调研，本来就很杂乱，完全 可以记在工作笔记上，放到需求分析的时候整理。觉得你丫没有足够的背景就不要往火坑里跳楼。总之根据所2需求分析为了得到用户的金钱，我们总是在说，用户是上帝，用 户永远是对的，尽管背地里在说客户端坏话：“你丫钱给的 倒不多，要求还真少，这需求根本不合理，是正常人的逻辑 吗？” ,如果你想活下去，最终我

3、们还是要想方设法满足用户 的要求。用户是个外界因素，我们是无法控制的，那么我们 只有尽可能改进需求分析的方法来尽量减少不必要的麻烦。 那么我觉得日本人做法倒是可以借鉴，在有条件的情况下派 专人去现场，随时记录关键性的需求，即使不能去现场也尽 可能的获取尽可能多大信息，不要指望开发后去获取什么有 价值的东西。那么是否应该做个原型给客户看看?我是觉得这 不大合适，因为如果工程周期短的话，等你做好原型，黄花 菜都凉了。但我觉得等到需求做到差不多的时候可以做用户 界面，所谓用户界面就是用户接口，是和用户打交道的地 方，所谓一图解千言，有了界面用户会清楚自己所买的东西 在未来会是个什么样的东西，再者开发

4、几个有说明性都界面 倒是不会暂用很多时间。等到需求确定下来后就要整理成文 档了，这个是很重要的一步，是做设计时候的重要凭证和依 据，这个文档就是用户规格说明书，所谓规格就是有规范的 格式和内容。3需求评审我们已经有了较正规的文档了，那么下一步就是召集所 有开发人员开会，最好有客户代表参加，尽管我是很厌烦开 会，但该开的会还是要开到，因为之前我遇到这种情况，开 发人员根据设计文档写代码，可是他并不知道自己在开发什 么，站在自己的角度想一下，如果自己都不确定自己做的东 西，即使有再完备的设计，也会对开发毫无兴趣，只会让自 己觉得自己是个代码机器。所以所有人员参加需求评审是让 大家知道自己在做一件有

5、意义的事情，自己正在满足社会的 需要，自己在为和谐社会做贡献，即使你从没那么想过，那 你敢保证的你的潜意识没那么想过吗?人是要有社会满足感的 吧。另外开会前一定要准备关键有价值的议题，据我观察需 求评审会最容易扯到不着边的话题，所以主持人要控制话 题，会议控制在2-3个钟头，最好做成幸运52的形式，所有 人员一定要互动起来，否那么就变成了个人演讲。需求也做 了，会也开了，那么要求客户签字吧。4需求管理需求管理是在开发开始之后进行的，这也是另所有人头 疼的一件事，之前做完一个工程后，客户经常打 找我 们，改过来改过去，后来我听到 ，血压都要升高50个百 分点，后来索性就不接 ，客户就在网上找我，

6、搞的我连QQ都不敢登，但躲是躲不掉滴，客户直接打我手机，丫的真烦人，见过难缠的，没见过这么难缠的。后来转念一想，难 道这种情况真的不能防止吗？至少是可以大幅度的缓解的吧。这就是我们需求管理中的变更管理没做好，改了哪些地方自 己都忘记了，最后是跟着感觉走，拆东墙补西墙。在这里我 建议要建立需求跟踪矩阵表，有了这个表我们至少可以对要 修改的地方有了依据，迫使我们去调查到底是改什么地方, 怎么改，最后改成了什么样。可能你会说客户需要大幅度修 改原有计划，很难跟踪到具体某一项需求，那么我觉得这是 由于前期的需求开发没有做好，在后期客户进行实质性的修 改的几率是很小的，比方客户要求我们做个OA系统，最后

7、总 不会要我们改成个门户网站吧，在举个例子，在比方你开发 一个ERP系统，客户自己的业务流程不会轻易的改变吧，总 不至于把盘点这个业务改成一个报表系统吧。如果真是这 样，我们完全有理由告诉客户，你丫乖乖掏银子，我们再给 你们开发2期工程，要改，没门！以上，我简单谈了一下工程管理中的需求开发和管理。在 这里，我将以闲聊的方式与你讨论工程规划和工程监控。事 实上，工程计划和工程监控是工程管理中的核心工作，也是 很多开发人员最敏感的话题，因为这两件事与公司的领导和 员工息息相关。先说我以前的学校。我们学校过去有一片荒地。当时领导 觉得学校要绿化，就组织在荒地上植树。一年之内，任命了 一位新校长。校长

8、觉得学校应该以体育为主，决定建一个足球场，于是把树移走，建了一个足球场。后来北京奥运会来 了，他又开始种树，迎合绿色奥运的理念。这是一个典型的 没有规划和监控的例子。结果，人和工人都受伤了。当然， 对于学校来说，有国家财政和资本的支持，会有那么难，但 是对于小公司做工程，估计很快就要牺牲了。事实求是的说大多数小公司在这两个方面做得很少有令人的满意的，小公司的老板其实也会意识到公司在工程规划 和监控方面做得不咋地，但很少能做到有效的改进，其实这 个也是有很多方面的原因的，以我自作多情的猜想主要有以 下两个原因，对于小公司，尽管盈利不是很多，但基本还是 可以撑下去的，老板会觉得管他乱不乱，公司总之

9、每个月还 是有盈利的，少就少点吧，多干几年自己的下半辈子基本有 别墅有车了，所以比拟保守，要是改革吧，万一鸡飞蛋打怎 么办?还是本分点好，小心使得万年船。其实是对工程规划和 监控其实需要大量的本钱，老板觉得钱应该花在刀刃上，搞 这些东西就是在务虚。再者更恶劣的老板有病就乱烧香，就 有想想借助CMMI这个洋玩意治病的，其实很多老板都蛮喜欢 CMMI的，CMMI就是假定人就是一个机器的部件，可以替换可 以不停的运转，总之管机器总比管人省心吧，结果是万分的 矛盾，银子撒了一大把，收效却甚微，甚至比以前更乱，大 家做的都不开心。与其听咨询师们拿什么高深的方法论来瞎 哪，不如我们谈点实际的，想就以下议题

10、来和各位消遣。1工作量估算对于工作量估算很多工程经理（老板）喜欢用数学公式来计算，可能数学公式更加的客观和科学，ok,看看市面流行 的计算方法吧，最常见的是基于代码行的数学模型，那么这 里存在不少问题，工作量估算主要是为了在工程进行中进行 有效的工程监控，那么软件开发尚未结束，谁知道最后的代 码行有多大?代码经常会被修改，那么修改的代码算不算?如 果算，那么代码修改越多难道能说明工作量越大?代码效率的 区别也是很大的，假如一个10行代码可以实现的东西被写成 50行，难道能客观的反映工作量?还有2种比拟高级点的方法 是基于功能点和COCOMO的方法，那么我想问的是它们的公式 中的系数该怎么定?那

11、么不少咨询师忽悠我说，根据自己的实 际情况来定呗，那么我想问的是，算命是迷信，电脑意味着 科学，那么用电脑算命算不算迷信?所以我是主张这里还是要 靠人的经验来估算，大家可以在工程周会上对工作量进行充 分的估算，在估算时要同时考虑到工程执行的难度，根据经 验给出合理的评估。2任务分配大多数的做法是将整个工程划分成一个个可以独立执行 的原子任务，这些任务要划分优先级和难度，至少心理有个 数，并且每项任务要制定负责人。那么问题就出在这个任务 分配上了，软件开发是一项智力创造的活动，如果按CMMI假 设的那样，在分配任务时忽略人的因素是万万不可取的，我 就有血的教训，不久之前做一个ruby的工程，然后

12、开始在公 司内部随便抓了几个有点ruby基础的人，也没太顾忌别人的 想法。做着做着，觉得他们有点心在曹营心在汉，平时还是 抱着本thinking in java看，做ruby也是在敷衍了事，结 果是代码质量不行，需要大规模的修改。当然按理说员工应 该服从公司的安排，做一样就要做好一样，但员工也有员工 的规划，你去叫他做他压根就不喜欢的事只能说明管理有问 题。另外还有一个普遍性的问题是能者多劳，有个朋友刚进 公司动手能力很强，也非常的积极，每次做工程都分给他最 难最累的任务，做着做着也就厌倦了，这时老板会忽悠你 说，你能力强，要挑起公司的大梁，以后公司壮大了给你个 什么职位，我觉得这就是在扯淡，

13、这就是我经常见到的忽悠式的管理，很多管理手段完全靠人情，很多人都是在这种环 境中被忽悠长大，到最后怎么样?被忽悠了几年还不是另谋高 就了，所以指望人情化管理的公司很难长大。我觉得该讲原 那么的地方就要讲原那么，在任务分配上给能力强的分配少而精 的任务，而且要考虑到员工自己的想法，有些人想做java架 构师，你叫他做oracle dba就不合适，有些对ui设计感兴 趣，你叫他做系统分析员也不合适，有些人就喜欢搞技术， 你硬要叫他做管理也是不合适。3进度管理在做进度之前，一项最重要的任务是识别关键任务，很 多进度表进行任务安排时将各项任务平均分的特点为觉得极 不合适，有些任务比拟难处理，而且许多后

14、续任务依赖于该 项任务，那么这项任务就应该配备更精良的人手和充裕的时 间，依我的经验80%的时间都是在处理这些20%的关键任务 o这里还有个比拟重要的问题是时间安排，我听很多工程 经理说时间安排要尽可能的紧，也就是比预计要靠前，这样 员工才有紧迫感。我觉得这是不可取的，首先即使你按原计 划进行，八成也是要要延期的，那么这就会导致工程严重延 期，长此以往，工程延期成了家常便饭，不延期反而不正 常，于是大家都成了老油条，那么进度表不就是废纸一张， 毫无约束力而言吗！我觉得根据实际情况指定个合理的进度表 是比拟重要的，或许你会说工程还是在延期，那我觉得是你 工程估算没有做好，工程延期在10%左右比拟

15、正常，否那么就可 以调查是什么原因导致进度滞后，如果是客观原因，以后完 全可以延长工程时间，总之一个合理的进度表比拟重要。4工程奖金这里牵扯到一个钱的问题，据我了解这里牵扯到一个钱的问题，据我了解内大多小公司很少有工程奖金这么一说，年底给点路费就不错了！国内的大多数工程经理更像是一个技术负责人，根本没有用钱的权利, 我就曾像公司申请工程奖金，结果计划全盘泡汤，给的理由 很荒唐，说工程奖金不好分配，给张三多一点吧，李四不 爽，反之亦然。我心理暗自想：“你丫不想给就直说呗！ ”， 这里会导致一个问题，就是“工程经理”凭什么约束成员， 大锅饭的道理我也不想再解释了，总之结果就是3个月的项 目就得做个5个月，其实老板的小算盘看似很精明，其实未 见得，虽然工程奖金能省就省了，那么工作效率的下降所带 来的本钱的提高，孰轻孰重?长远一点说，产品质量的下滑导 致的工程维护的本钱你计算过吗?依我的经验，3个月的有效 工作时间其实也就是1个月，这已经不错了。不过工程奖金 的分配确实是个难问题，但有没有工程奖金和分配合理与否 是2码子事吧？由于我也没有能耐申请到工程奖金所以也就没 有深入研究这个问题，只得望梅止渴，看看人家华为了，员 工根据能力分等级，加上年限、加班、表现得出个权值来计 算。总之现有鸡才能有蛋，这个问题需要更深入的讨论。