谁该阅读本文？
1.刚刚毕业，和几个志同道合的朋友一起，找到一个门铺，为了一个软件而不知白天黑夜，我把这个叫做“工作室式”。
2.终于公司注册了，有了自己的办公室，还招聘了不少员工，算上自己少说也有十来号人吧，我把这个叫做“作坊式”。

以上就是中国目前最常见的两种公司类型。确切的说，前者并不是一个公司，但这里为方便讨论就姑且将其归类于一种公司。前者还处于初生牛犊的时期，主要是靠创业者自己支持公司的运作，所有问题都必须由创业者自己解决。后者的情况是：员工发现问题，创业者解决问题。作为这两种公司的领头人，都可以很好的看一下本篇文章。

上篇：问题的提出
一、由谁来实施管理？
对于“工作室式”公司，当然是由创业者自己来进行管理了。当多个好手聚集在一起时，必须确立明确的责任分工，因为大家大都是以技术出生，因为共同的兴趣爱好（大多是对程序的执著）走到一起，当涉及到具体的项目时，都希望能够发挥自己的编码特长，为软件注入最大的动力。于是矛盾冲突必然在所难免，因为你我都是程序高手，为什么要你写，我不写呢？另一个矛盾冲突的产生发生在项目进行过程中，当涉及到核心代码部分时，或许每个人都有自己的高级算法，但彼此之间又无法达到共识时，心里的疙瘩就产生了。所以，务必在公司成立之初就明确个人职责。当某人在项目中途遇到困难时，其他人可以暂时停止自己的工作来帮助他，但困难解决后最好是各咎其位。

另外，“工作室”式公司的日常开销是个比较敏感的话题，因为是朋友式的公司，所以有时候是大家自己出钱买一些东西，或者自己出的一些硬件设备，这些都应该作出明确记录，某某人在什么时间买了什么东西，是公司支出还是自己支出，可以设计一个好的表格进行登记。要知道，“工作室”式公司的日常开销是投资者最为关心的一个话题。

程序员此时的工作量最为繁重和重大，因为是公司的头号产品或者主打产品，他的好坏与其日后的生存息息相关。如果说他平时写的程序体现了他的编码水平，则此时他写的程序则体现了公司的生命存活力。这种情况下，他的首要工作是写程序，第二是作好程序文档的编写，包括核心算法的书面陈述，产品的特殊特点，大的版本变动，遇到的问题及解决方法，第三是听取项目管理人员的市场信息。但千万要注意的是，永远不要让你的软件与市场最新产品同步，要不然，你的程序永远也写不完。关键是要有自己的特色，等到第一个版本发布后，再在以后的版本中添加新特点。我们可以追随潮流，但不要让潮流牵着我们的鼻子走。

综上所述，“工作室式”公司的项目管理应该有专人来执行。
对于“作坊式”公司，项目的管理可以是两种人，一是创业者自己，二是项目组长或者项目经理（更大规模的“作坊式”公司）。当公司发展到一定规模，通常是十个人左右，此时公司招聘了更多的程序员进行编码工作，创业者自己负责项目的管理。此时创业者的任务是管理项目和负责核心代码的处理。因为是过来人，所以对这个软件的开发过程非常了解，其中涉及到哪些问题（比如需要查找一些资料），人手的安排（当时自己因为这个而分心），费用的解决（当初因为没有打印机而无法进行打印功能测试）等等。虽然此时我们想到的最多的是采取软件过程，但众多新招聘的毕业生连公司环境都需要熟悉，软件过程又何从说起呢？

进行项目管理的第二种人是公司招聘进来的项目经理，或者公司内部提拔上来的项目组长，本文中我把二者归为同一种人。虽然相比第一种人多了一个上级：总经理，但除了担当更多的责任和风险外，对自己手上的项目的管理和第二种人一样。

所以，“作坊式”公司的项目管理由项目组长或者项目经理来进行。虽然这一段有可能是废话，但我还是要把他拿出来，因为二者放在一起有很多共性和普遍性。

下篇：问题的解决
有因必有果，万物都是相生相克的，问题总有他的解决方法。上篇我们分析了常见的一些问题，下面我们就从三个方面来阐述如何解决这些问题。

一、项目的确立
对于“工作室式”公司，项目的确立可以说是最简单也最复杂的。首先，因为共同的兴趣爱好走在了一起，例如，大家都是研究Linux防病毒技术的，所以第一个项目很自然的就产生了，制作中国乃至世界上第一个Linux下的杀毒软件。如果就公司以后的开发方向产生了分歧，势必造成散伙等严重后果。可能的话，发展方向的不一致，可以使公司向多元化方向发展，成立不同的开发部门，各人负责一个产品，这是最好的解决方法。但此时考虑的因素更复杂。不确切的说，是把多个“工作室”组合在一起形成一个大工作室。所以对“工作室式”公司项目的确立主要在于彼此之间的共识。俗话说，志同道合，志趣相同，但道路可以不同。所以志同加道合可以说是“工作室”式公司耐以生存的根本。

对于“作坊式”公司，大多都有自己的市场部门，或者从销售伙伴那里得来的最重要的市场信息，而市场又决定了一切，销售曲线在一定程度上代表了软件的生命力强弱。根据市场做软件，是项目确立的第一种方法。但做过市场的人可能会说，千万不要玩弄市场，你永远跟不上市场的脚步。在今天，竞争的激烈让你手忙脚乱，在明天，前沿技术让你目不暇接。如果项目只是对以前产品的升级，则项目的确立主要由市场反映和技术的更新来确立。这里我们只讨论这种情况，不讨论一个前所未有的项目的管理。

由市场反映确立项目：为什么有很多老总喜欢下到一线，到商场里去聆听销售人员反馈或者直接和用户联系呢？说穿了就那句话：用户就是上帝。用户的需求代表了产品的发展方向，用户的批评说明软件存在的Bug，用户的表扬证明了软件的优点。如果用户说，你们的杀毒软件非常好，只是界面太专业，帮助文件里说了一大堆专业术语，我看不大明白！这就产生了两点商机，一是可以把帮助说明文档做成多媒体演示的形式，同时可以把程序界面做的漂亮些，制作更加人性化的界面，提高软件的亲和力等等，删除软件中不必要的向导，去掉作用不大的提示文字等等，主要对软件界面进行改造。这些可以成为新产品的特点进行宣传。二是可以制作产品的多媒体演示产品，不仅让用户可以用你的软件消灭病毒，还可以从你的产品中学习到新知识，了解病毒，并化被动为主动，主动到你的站点上更新病毒库等等。这顺便还减轻了售后服务的工作量，而你只需要制作一个多媒体演示文档即可，可谓一劳用益。用户的表扬必须成为后续产品发扬光大的地方，如果用户最喜欢的功能在新版本里不见了，失望的感觉相信每个人都深有体会。我们必须对其进行巩固和增强。了解同类产品的优缺点是提高自己最好的办法。要想有市场，就得比别人好，不好的东西是没有人要的。因此，根据市场去向来确立项目是个非常好的方法。

存在的风险：因为市场大，所以才会形成大家一哄而上的情形，因而市场上同类产品鱼目混杂，好的也被差的挤坏了。但千帆同进，百舸争流，在市场竞争规律的操作下，是金子总会发光的。

上面所说的可能有些跑题了，但这正是我们容易忽视的，即项目管理人员必须在心中有市场的前提下进行管理。我接管的大多都是一些多媒体项目，涉及到程序界面的非常多，因此，程序员有可能偷懒或者疏忽而对产品造成负面影响。因为用户在使用你的产品时根本不会想到其中包含了多少程序员多少的血汗，他要的是功能。软件的界面，这个第一印象对用户来说至关重要。

二、任务分配
对于“工作室式”公司的任务分配一般都是通过小组协商确立的。大家是根据自己的个人特色进行任务安排。擅长编码的进行程序编写，擅长人际交流的进行市场调研。如果都是进行程序的编写，则一定要对程序进行模块化的分割，每个人负责一个模块，完成一个功能。印度人的程序写出来都一样，那是因为他们的整体工作做的好，但试想一下，这样的人在公司里有什么竞争力呢？因为谁都可以替代你。我就不信印度人都可以写出一样的高级加密算法来。“工作室式”公司需要的是大家各显身手，每个人都使出自己的看家本领。如果大家的代码风格不一致，则彼此之间的沟通尤为主要。

对于“作坊式”公司，任务的分配大多都是项目组长决定的。首先根据以往经验将新项目划分为几个模块，或者几个阶段。确立具体的人手，将项目模块“包干到户”。这里有一种很有鼓舞性的做法就是根据以前的工作表现，提拨某人担任主要部分的工作，或者参与核心代码的开发工作，这对提高他的个人水平是很有帮助的。如果工作涉及到多个部门，则事先的程序蓝图显得至关重要，或者说是流程图，注意，这不是程序运行的流程图，而是开发进行的流程图。开始需要什么，如程序初始界面，中途需要什么，如新开发出来的加密算法，最后需要什么，如软件的电子文档等，这些东西应该出现在开发过程中的哪个环节，是否能够与现有模块完全兼容等等。所以分配任务不仅包括分配到每个人的任务，还包括分配给每个部门的任务。

三、项目持续时间
时间对于“工作室式”公司来说是个比较头痛的问题，因为大家都是加班加点的工作，很有可能因为一个问题而困上好几星期。如果是进行版本的升级，因为前任工作做的好，只需要对某个动态库进行一下升级，则这种情况就比较好办了。软件的发行都是在软件诞生以后才对外宣布的，换句话说，这个功能可能就是上一版本已经开发出来但没有加进去的，此时想发行新版本是为了添加另一个新功能，所以哪怕这个功能开发遇到钉子，也可以用上一个功能来补充，这对于发行新版本来说是最保险的做法了。最危险的做法就是：在想到一个新功能后就立即对外宣布我的产品在下一个版本里会有这个功能。

对于“作坊式”公司，项目的持续时间一般都和上一个项目一样。我现在接手的都是多媒体教学软件的制作，因为技术成熟，开发模式一样，主要变化在于教学的软件本身不一样，所以开发时间几乎是固定的。

这另当别论，对于今天开发杀毒软件，明天开发翻译软件，这样的项目时间就没有办法算了。

四、管理方法
上面说了那么多，间接的已经体现出了项目执行过程中的问题，也间接的对问题进行了解答。对于“工作室”式公司，可以简单总结为：分工明确，各尽其责。管理人员一定要注意编写相关文档，最好就是养成“写日记”的习惯。简单的只要记录下开始时间、结束时间、任务、执行人、棘手问题、解决方法、备注即可。因为大家都是在给自己干，所以责任心肯定是有的了，不怕有谁会偷懒或者抱无所谓态度。

对于“作坊式”公司，项目管理人员的工作就是监督项目进度和质量。如果开发人员对每天记录自己的工作感到很反感的话，可以采取分阶段或时间的上交自己的工作时间表。例如，在10号到15号一直在编写加密部分，从16号到18号完成了界面的设计，这些工作必须写下来。一可以成为审核他工作成绩的根据，二可以根据他的工作去安排其他人的工作。利用项目管理软件如Microsoft Peoject，你可以很清楚的看到当前项目进展到了什么地方，在哪里耽误了太长时间，是谁影响了总体进度等等。

上面是采取的第一步措施，即要求员工报告自己的工作进程，第二步措施就是召开小组会议。找个时间，不一定是固定的，可以在午间休息时，可以在大家都比较烦的时候，也可以是在周末下班前一两个小时，让大家聚集在一起，谈谈自己最近的工作情况，遇到的问题等，提出来让大家一起来解决。不仅有利于开拓思路，还可以增加团队的凝聚力，增加项目管理人员的亲和力，减少管理摩擦系数。会议过程中可以对大家宣布当前项目进行到了哪一步，让大家都知道项目的进程，让大家朝着预定目标进行。如果是因为员工偷懒延迟了进程，则可以当面提出，让大家知道他。如果是因为技术问题耽误了，则可以先让大家讨论解决方法，此时只是试探性的解决这个问题，不要让这个成为会议的重点。会议的目的是针对项目，不是针对技术，技术已经在会议上提出了，解决方法也就很明了了，一是让大家会后集体解决。二就是管理人员找他谈话，征询是否需要增加人手等。中国是世界上开会最多的国家，但绝对不能不开会。

第三步措施就是质量监督。如果公司有专门的测试部门，则对阶段的开发模块进行检测至关重要。仔细阅读错误检测报告，日后向下发放。发生的错误要让大家都知道。好处是，第一，对已有的错误可以避免再犯，对未知的错误可以根据已知错误进行简单推测，例如他的错误发生在数据运算部分，则其他人在开发类似模块时就会尤为注重一些，因为前车之鉴。第二就是避免将错误代入下一个阶段。微软有一句话就是永远不要等到在最后集中排除错误，必须发现错误后立即将其改正。因为你的错误可能会牵扯到其他模块，牵一发而动全身，对项目来说是致命的，有时几乎是整个项目重头再来。检测错误的开发文档可以包括以下内容：检测时间、检测人、错误出现地方（如“在工资总结窗口中单击了确定按钮后”）、错误（操作系统）提示文字和下面由项目管理人员填写的内容：所属模块、开发人、其他用到的地方等，接着再把这篇文档交给该模块的开发人员，让他填写以下内容：出错原因、解决方法、解决时间、改动后其他地方的变化等。如果其他地方也牵涉到了这个模块，则再交给其他模块的人。填写完相关内容后，最后一个人再交给管理人员，最后管理人员将其交给检测人员。这样，整个过程一环扣一环，谁都不敢在软件质量上开玩笑。但质量的检测一定要分阶段进行，千万不要让你的程序员疲惫于整天修改各种各样的错误。要知道，世界上没有绝对运行无误的程序。

第四步措施就是项目总结大会。等到整个项目完成后，召集大家坐在一起，管理人员进行总的发言。告诉大家整个项目是怎么进行的，中间遇到了什么问题，是怎么解决的，告诉大家相关的开发文档放在了什么地方（也可以打印出来人手一份），大家可以从中吸取到什么经验教训，开发中谁出了最大的力气，什么阶段是项目的一个历程碑，下一个项目的人手变动、本项目的员工奖励等等，这些都可以在会议上公布出来。也可以让大家自由发言。我们现在从各种报刊杂志上经常可以看到，某某成功的程序员在被采访起当初的开发时总是非常激动的。让大家畅谈自己最为得意的地方，可以提高员工的士气，如果员工辛辛苦苦做了那么多工作而没有人知道，他的积极性会很受打击或者会逐渐萎缩。

在《程序员》杂志上看到了非常多非常好的文章，谈到了诸如软件工程、CMM之类的话题，但对于绝大多数刚刚起步的公司来说，这些话题还是远了一些。很多公司还处在徘徊阶段，作为一家公司的小元老之一，我对还不明白软件工程的公司持有自己的见解。本文从大众的角度对项目管理进行了分析，希望对大家有所帮助。

本文发表于
《程序员》杂志第12期
《程序春秋》杂志第12期

对不起，网上下载的，作者是谁我还没有看见，等我看了实体书后，补上，好文章呀