下面是小编为大家整理的小公司如何做好项目管理（范文推荐）,供大家参考。
小公司如何做好项目管理
1 需求调研
我觉得需求调研非常的重要，1 1 年前我还打算做一个在线教育服务平台，理念就是淘宝在网上卖商品，我在网上卖教育资源，我提供网上交易场所，签约的老师、学校以及培训机构提供可交易的服务，这种服务可以通过视频、音频、在线 线 PPT 、文本的形式展现。忙活了好一阵，发现这个市场早就有很多人做了，而且这个市场并不是很好做，首先在网上学习的人有几个? ? 并且先不说前期推广需要海量资金就是所需要的那么些高性能服务器丫也买不起! ! 这件事就此搁浅，结果信了马云的邪，2 2 年后你还想创业你在创业! ! 我觉得这就是典型的需求调研没做好，没有对用户需求做调查，没有考虑同行竞争，没有考虑可行性! ! 另外还要考虑括行业标准和法律规定，比如前些时候国家就出台了关于办视频网站的政策，我觉得你丫没有足够的背景就不要往火坑里跳楼。总之根据所做行业情况尽可能的把需求调研做全面，这样才可以保证项目首先是可以赚钱的。那么文档要写吗? ? 我觉得可以不要正式的文档，小公司的人手本来就不够用，要把主要文档化工作集中在重要的环节上，对于需求调研，本来就很杂乱，完全可以记在工作笔记上，放到需求分析的时候整理。
2 需求分析
为了得 到用户的金钱，我们总是在说，用户是上帝，用户永远是对的，尽管背地里在说客户端坏话：
“ 你丫钱给的倒不多，要求还真少，这需求根本不合理，是正常人的逻辑吗 ?” ，如果你想活下去，最终我们还是要想方设法满足用户的要求。用户是个外界因素，我们是无法控制的，那么我们
只有尽可能改进需求分析的方法来尽量减少不必要的麻烦。那么我觉得日本人做法倒是可以借鉴，在有条件的情况下派专人去现场，随时记录关键性的需求，即使不能去现场也尽可能的获取尽可能多大信息，不要指望开发后去获取什么有价值的东西。那么是否应该做个原型给客户看看? ? 我是觉得 这不大合适，因为如果项目周期短的话，等你做好原型，黄花菜都凉了。但我觉得等到需求做到差不多的时候可以做用户界面，所谓用户界面就是用户接口，是和用户打交道的地方，所谓一图解千言，有了界面用户会清楚自己所买的东西在未来会是个什么样的东西，再者开发几个有说明性都界面倒是不会暂用很多时间。等到需求确定下来后就要整理成文档了，这个是很重要的一步，是做设计时候的重要凭证和依据，这个文档就是用户规格说明书，所谓规格就是有规范的格式和内容。
3 3 需求评审
我们已经有了较正规的文档了，那么下一步就是召集所有开发人员开 会，最好有客户代表参加，尽管我是很厌烦开会，但该开的会还是要开到，因为之前我遇到这种情况，开发人员根据设计文档写代码，可是他并不知道自己在开发什么，站在自己的角度想一下，如果自己都不确定自己做的东西，即使有再完备的设计，也会对开发毫无兴趣，只会让自己觉得自己是个代码机器。所以所有人员参加需求评审是让大家知道自己在做一件有意义的事情，自己正在满足社会的需要，自己在为和谐社会做贡献，即使你从没那么想过，那你敢保证的你的潜意识没那么想过吗? ? 人是要有社会满足感的吧。另外开会前一定要准备关键有价值的议题，据我观察需求 评审会最容易扯到不着边的话题，所以主持人要控制话题，会议控制在 2 2- -3 3 个钟头，最好做成幸运 2 52 的形式，所有人员一定要互动起来，否则就变成了个人演讲。需求也做了，会也开了，那么要求客户签字吧。
4 需求管理
需求管理是在开发开始之后进行的，这也是另所有人头疼的一件事，之前做完一个项目后，客户经常打电话找我们，改过来改过去，后来我听到电话，血压都要升高 0 50 个百分点，后来索性就不接电话，客户就在网上找我，搞的我连Q QQ 都不敢登，但躲是躲不掉滴，客户直接打我手机，丫的真烦人，见过难缠的，没见过这么难缠的。后来 转念一想，难道这种情况真的不能避免吗? ? 至少是可以大幅度的缓解的吧。这就是我们需求管理中的变更管理没做好，改了哪些地方自己都忘记了，最后是跟着感觉走，拆东墙补西墙。在这里我建议要建立需求跟踪矩阵表，有了这个表我们至少可以对要修改的地方有了依据，迫使我们去调查到底是改什么地方，怎么改，最后改成了什么样。可能你会说客户需要大幅度修改原有计划，很难跟踪到具体某一项需求，那么我觉得这是由于前期的需求开发没有做好，在后期客户进行实质性的修改的几率是很小的，比如客户要求我们做个 A OA 系统，最后总不会要我们改成个门户网站吧， 在举个例子，在比如你开发一个 P ERP 系统，客户自己的业务流程不会轻易的改变吧，总不至于把盘点这个业务改成一个报表系统吧。如果真是这样，我们完全有理由告诉客户，你丫乖乖掏银子，我们再给你们开发 2 2 期工程，要改，没门 !
以上，我简单谈了一下项目管理中的需求开发和管理。在这里，我将以闲聊的方式与你讨论项目规划和项目监控。事实上，项目计划和项目监控是项目管理中的核心工作，也是很多开发人员最敏感的话题，因为这两件事与公司的领导和员工息息相关。
先说我以前的学校。我们学校过去有一片荒地。当时领导觉得学校要绿化， 就组织在荒地上植树。一年之内，任命了一位新校长。校长觉得学校应该以体育为主，决定建一个足
球场，于是把树移走，建了一个足球场。后来北京奥运会来了，他又开始种树，迎合绿色奥运的理念。这是一个典型的没有规划和监控的例子。结果，人和工人都受伤了。当然，对于学校来说，有国家财政和资本的支持，会有那么难，但是对于小公司做项目，估计很快就要牺牲了。
事实求是的说大多数小公司在这两个方面做得很少有令人的满意的，小公司的老板其实也会意识到公司在项目规划和监控方面做得不咋地，但很少能做到有效的改进，其实这个也是有很多方面的 原因的，以我自作多情的猜测主要有以下两个原因，对于小公司，尽管盈利不是很多，但基本还是可以撑下去的，老板会觉得管他乱不乱，公司总之每个月还是有盈利的，少就少点吧，多干几年自己的下半辈子基本有别墅有车了，所以比较保守，要是改革吧，万一鸡飞蛋打怎么办? ? 还是本分点好，小心使得万年船。其实是对项目规划和监控其实需要大量的成本，老板觉得钱应该花在刀刃上，搞这些东西就是在务虚。再者更恶劣的老板有病就乱烧香，就有想想借助 I CMMI 这个洋玩意治病的，其实很多老板都蛮喜欢I CMMI 的，I CMMI 就是假定人就是一个机器的部件，可以替 换可以不停的运转，总之管机器总比管人省心吧，结果是万分的矛盾，银子撒了一大把，收效却甚微，甚至比以前更乱，大家做的都不开心。与其听咨询师们拿什么高深的方法论来瞎掰，不如我们谈点实际的，想就以下议题来和各位消遣。
1 工作量估算
对于工作量估算很多项目经理( ( 老板) ) 喜欢用数学公式来计算，可能数学公式更加的客观和科学， ok, ，看看市面流行的计算方法吧，最常见的是基于代码行的数学模型，那么这里存在不少问题，工作量估算主要是为了在项目进行中进行有效的项目监控，那么软件开发尚未结束，谁知道最后的代码行有多大? ? 代码经常会被修改，那么修改的代码算不算? ? 如
果算，那么代码修改越多难道能说明工作量越大? ? 代码效率的区别也是很大的，假如一个 0 10 行代码可以实现的东西被写成0 50 行，难道能客观的反映工作量? ? 还有 2 2 种比较高级点的方法是基于功能点和 O COCOMO 的方法，那么我想问的是它们的公式中的系数该怎么定? ? 那么不少咨询师忽悠我说，根据自己的实际情况来定呗，那么我想问的是，算命是迷信，电脑意味着科学，那么用电脑算命算不算迷信? ? 所以我是主张这里还是要靠人的经验来估算，大家可以在项目周会上对工作量进行充分的估算，在估算时要同时考虑到项目执 行的难度，根据经验给出合理的评估。
2 任务分配
大多数的做法是将整个项目划分成一个个可以独立执行的原子任务，这些任务要划分优先级和难度，至少心理有个数，并且每项任务要制定负责人。那么问题就出在这个任务分配上了，软件开发是一项智力创造的活动，如果按 I CMMI 假设的那样，在分配任务时忽略人的因素是万万不可取的，我就有血的教训，不久之前做一个 y ruby 的项目，然后开始在公司内部随便抓了几个有点 y ruby 基础的人，也没太顾忌别人的想法。做着做着，觉得他们有点心在曹营心在汉，平时还是抱着本
thinking ia n java 看，做 y ruby 也是在敷衍了事，结果是代码质量不行，需要大规模的修改。当然按理说员工应该服从公司的安排，做一样就要做好一样，但员工也有员工的规划，你去叫他做他压根就不喜欢的事只能说明管理有问题。
另外还有一个普遍性的问题是能者多劳，有个朋友刚进公司动手能力很强，也非常的积极，每次做项目都分给他最难最累的任务，做着做着也就厌倦了，这时老板会忽悠你说，你能力强，要挑起公司的大梁，以后公司壮大了给你个什么职位，我觉得这就是在扯淡，这就是我经常见到的忽悠
式的管理，很多管理手段完全靠人情，很多人都是在 这种环境中被忽悠长大，到最后怎么样? ? 被忽悠了几年还不是另谋高就了，所以指望人情化管理的公司很难长大。我觉得该讲原则的地方就要讲原则，在任务分配上给能力强的分配少而精的任务，而且要考虑到员工自己的想法，有些人想做 a java 架构师，你叫他做 a oracle dba 就不合适，有些对 i ui 设计感兴趣，你叫他做系统分析员也不合适，有些人就喜欢搞技术，你硬要叫他做管理也是不合适。
3 进度管理
在做进度之前，一项最重要的任务是识别关键任务，很多进度表进行任务安排时将各项任务平均分的特点为觉得极不合适，有些任务比较难处 理，而且许多后续任务依赖于该项任务，那么这项任务就应该配备更精良的人手和充裕的时间，依我的经验 80% 的时间都是在处理这些 20% 的关键任务上。这里还有个比较重要的问题是时间安排，我听很多项目经理说时间安排要尽可能的紧，也就是比预计要靠前，这样员工才有紧迫感。我觉得这是不可取的，首先即使你按原计划进行，八成也是要要延期的，那么这就会导致项目严重延期，长此以往，项目延期成了家常便饭，不延期反而不正常，于是大家都成了老油条，那么进度表不就是废纸一张，毫无约束力而言吗! ! 我觉得根据实际情况指定个合理的进度表是比较重要的 ，或许你会说项目还是在延期，那我觉得是你项目估算没有做好，项目延期在 10% 左右比较正常，否则就可以调查是什么原因导致进度滞后，如果是客观原因，以后完全可以延长项目时间，总之一个合理的进度表比较重要。
4 项目奖金
这里牵扯到一个钱的问题，据我了解国内大多小公司很少有项目奖金这么一说，年底给点路费就不错了! ! 国内的大多
数项目经理更像是一个技术负责人，根本没有用钱的权利，我就曾像公司申请项目奖金，结果计划全盘泡汤，给的理由很荒唐，说项目奖金不好分配，给张三多一点吧，李四不爽，反之亦然。我心理暗自想：
“ 你 丫不想给就直说呗 !” ，这里会导致一个问题，就是 “ 项目经理 ” 凭什么约束成员，大锅饭的道理我也不想再解释了，总之结果就是 3 3 个月的项目就得做个 5 5 个月，其实老板的小算盘看似很精明，其实未见得，虽然项目奖金能省就省了，那么工作效率的下降所带来的成本的提高，孰轻孰重? ? 长远一点说，产品质量的下滑导致的项目维护的成本你计算过吗? ? 依我的经验，3 3 个月的有效工作时间其实也就是 1 1 个月，这已经不错了。不过项目奖金的分配确实是个难问题，但有没有项目奖金和分配合理与否是 是 2 2 码子事吧? ? 由于我也没有能耐申请到项目奖金所以也就没有深入研究这个问 题，只得望梅止渴，看看人家华为了，员工根据能力分等级，加上年限、加班、表现得出个权值来计算。总之现有鸡才能有蛋，这个问题需要更深入的讨论。
推荐访问:小公司如何做好项目管理 项目管理 小公司 如何做好
