1,265
社区成员
发帖
与我相关
我的任务
分享国内小型软件公司的项目管理
现在，无论大学生，硕士研究生还是博士研究生，还是企业的开发，管理人员，都在学软件工程，可是，照我看来，书上说的那一套好像都是针对于大公司开发大型软件的，在那些小公司，也就是一共不到30个人，开发员就那么几个人的公司，根本行不通，特别是产品开发。比如，在软件工程中，大家都知道代码编写只是很小的一部分工作，可在我所参与做过的几个产品，大部分时间都在写代码，产品的成败基本上取决于开发人员的素质和水平。再说，在小软件公司，高水平的程序员很少，大家的能力相差很大，二公司有没有实力去聘用更多的能干的程序员，所以导致产品的开发周期经常远远超出预期。在我看来，这些小公司也根本不可能真正按软件工程的方法来进行产品开发。
大家有什么样的看法，请各抒己见！
大家有什么样的看法，请各抒己见！
...全文
请发表友善的回复…
发表回复
ProjectCrazy 2003-03-07
- 打赏
- 举报
大家讨论很全面了，我还想就谈论比较少的地方作点补充：
首先我们必须认可，不论软件企业大小，编程序决不是软件开发的全部， <软件开发离不开科学的管理方式>，其次再给点补充建议：
1 寻找合适契机，得到高层领导的支持，执行人员的认可。
我想每个公司的情况不同，问题的解决方案自然不同！对于一个公司无论大小都有他的经营理念。不同的时期侧重面也不同。所以要先分清形式。。。
我公司正在开发一个软件产品，为了抢占市场先机，在开发的时候采用“个人英雄”+“自觉”式方法，目前占领了相当一部分的市场，达到了预期目的。客户是不关心代码的，但自己知道有多烂。蒙混过关死路一条，现在我们一方面维护现有产品的稳定性（修改bug）保证现有客户的服务，一方面开始进入开发整理阶段。在此时提出软件过程化管理是比较合适的，一方面满足老板的赢利目的，让老板懂得继续这样的开发后果是什么。一方面给哥们们一个调整喘息的时间。没有人跳出来反对。
2 找合适的人员
目前中国软件行业缺少的并不是会coding的人，而是真正的高级人才，好的项目经理，好的系统分析员，好的系统架构师，设计人员，以及好的管理规范。如果泛泛的把这些角色分配下去，但每个角色不能起到应有的作用，才叫多此一举！！！
3 前两点是前提条件，否则勿谈！
4 对小公司角色可适当合并。。。。降低成本
小企业人员少，可以把多角色分配给一个人，每个人要能搞清楚什么时候扮演什么角色。
===============================================================================
我想一个真正的软件人是不应该拒绝软件工程的，尤其当我们逐渐体会到他的精华（同样看一篇文章能体会到其精华的人并不多呦！），希望所有的软件人都能正视这点。让我们目光放大，放远，中国软件企业产业化不靠它靠什么？也许实施的过程会有挫折，就让我们作先行者，尽自己努力为软件产业作点什么，即使没能改变什么，没关系，自有后来人。。。
首先我们必须认可，不论软件企业大小，编程序决不是软件开发的全部， <软件开发离不开科学的管理方式>，其次再给点补充建议：
1 寻找合适契机，得到高层领导的支持，执行人员的认可。
我想每个公司的情况不同，问题的解决方案自然不同！对于一个公司无论大小都有他的经营理念。不同的时期侧重面也不同。所以要先分清形式。。。
我公司正在开发一个软件产品，为了抢占市场先机，在开发的时候采用“个人英雄”+“自觉”式方法，目前占领了相当一部分的市场，达到了预期目的。客户是不关心代码的，但自己知道有多烂。蒙混过关死路一条，现在我们一方面维护现有产品的稳定性（修改bug）保证现有客户的服务，一方面开始进入开发整理阶段。在此时提出软件过程化管理是比较合适的，一方面满足老板的赢利目的，让老板懂得继续这样的开发后果是什么。一方面给哥们们一个调整喘息的时间。没有人跳出来反对。
2 找合适的人员
目前中国软件行业缺少的并不是会coding的人，而是真正的高级人才，好的项目经理，好的系统分析员，好的系统架构师，设计人员，以及好的管理规范。如果泛泛的把这些角色分配下去，但每个角色不能起到应有的作用，才叫多此一举！！！
3 前两点是前提条件，否则勿谈！
4 对小公司角色可适当合并。。。。降低成本
小企业人员少，可以把多角色分配给一个人，每个人要能搞清楚什么时候扮演什么角色。
===============================================================================
我想一个真正的软件人是不应该拒绝软件工程的，尤其当我们逐渐体会到他的精华（同样看一篇文章能体会到其精华的人并不多呦！），希望所有的软件人都能正视这点。让我们目光放大，放远，中国软件企业产业化不靠它靠什么？也许实施的过程会有挫折，就让我们作先行者，尽自己努力为软件产业作点什么，即使没能改变什么，没关系，自有后来人。。。
snla 2003-03-06
- 打赏
- 举报
只要你不生搬硬套，把软件工程的理论真正的融入现实的项目当中，你会受益匪浅的！
如果你说软件工程不适合小公司，那么我只能抱歉的说，你还没理解和认识软件工程！
如果你说软件工程不适合小公司，那么我只能抱歉的说，你还没理解和认识软件工程！
flykarl 2003-03-06
- 打赏
- 举报
软件工程是个好东西，但是在小公司很难实现。
zhf_karen 2003-03-05
- 打赏
- 举报
软件工程和项目管理并不是仅仅针对大型软件公司的.为什么会导致你所说的情况?项目管理无用,软件工程无用.虽然我承认一点,目前的项目管理过程不是面向结果的管理方式,是一种面向过程的管理,认为如果软件开发过程达到了这些点,就能保证软件的成功.这在逻辑上是不通的,但是实施下来的确是有效果的.
我不赞成用户看到你很郁闷,因为这除非由于行业特征导致的用户忠诚度极高,不然基本属于做一个项目死一个客户的结果.客户需要的是满意的结果,你通过对用户的投诉分析,可以得到一些结果.
别去一味追求软件工程,大而全的项目管理,对过程定义做一些裁减,符合你的就是最好的.比如实施项目管理,你不想做风险分析,那么好,虽然我看来它非常非常重要.但是如果不符合你们的利益就可以不做(比如这个项目已经签署了合同,就是有风险也要做了,那么只要做风险预防就可以了),如果你要做概要设计,那么好,我们总应该知道如何的概要设计就应该算是合理的吧,不然就象很多人说的:我们这个项目很成功,很成功.但是谁知道呢?这就是规范和标准来确定的了.
有个数据,我们持续推进项目管理和软件工程,通过各种项目数据的采集,在一年时间中(不是今年的数据了),项目效率提高了1/3,项目成功比例提高了很多.软件工程不是做给别人看的,是适合自己的.在实施过程中,前期由于裁减过程不合理,降低工作效率是可以理解的,但是到后面,你会得到回报的.
我不想说什么没有短视之类的话,但是如果一直不去尝试,把目光仅仅集中在目前的得失,那么也许公司会永远在生于死之间挣扎.现在小的软件公司的境况我想不说大家也知道,为什么呢?有没有人想过为什么?我们不能活一天算一天吧,有个统计资料,有长期目标的人,成功(世俗意义上的成功)的机会比没有长期目标的人多30多倍,比长期目标模糊的人,多3-4倍.具体记不清楚了,大致的数据是如此.至少数量级没有错.还是把目光放远一点好.无论对于个人还是公司都是那样.
我不赞成用户看到你很郁闷,因为这除非由于行业特征导致的用户忠诚度极高,不然基本属于做一个项目死一个客户的结果.客户需要的是满意的结果,你通过对用户的投诉分析,可以得到一些结果.
别去一味追求软件工程,大而全的项目管理,对过程定义做一些裁减,符合你的就是最好的.比如实施项目管理,你不想做风险分析,那么好,虽然我看来它非常非常重要.但是如果不符合你们的利益就可以不做(比如这个项目已经签署了合同,就是有风险也要做了,那么只要做风险预防就可以了),如果你要做概要设计,那么好,我们总应该知道如何的概要设计就应该算是合理的吧,不然就象很多人说的:我们这个项目很成功,很成功.但是谁知道呢?这就是规范和标准来确定的了.
有个数据,我们持续推进项目管理和软件工程,通过各种项目数据的采集,在一年时间中(不是今年的数据了),项目效率提高了1/3,项目成功比例提高了很多.软件工程不是做给别人看的,是适合自己的.在实施过程中,前期由于裁减过程不合理,降低工作效率是可以理解的,但是到后面,你会得到回报的.
我不想说什么没有短视之类的话,但是如果一直不去尝试,把目光仅仅集中在目前的得失,那么也许公司会永远在生于死之间挣扎.现在小的软件公司的境况我想不说大家也知道,为什么呢?有没有人想过为什么?我们不能活一天算一天吧,有个统计资料,有长期目标的人,成功(世俗意义上的成功)的机会比没有长期目标的人多30多倍,比长期目标模糊的人,多3-4倍.具体记不清楚了,大致的数据是如此.至少数量级没有错.还是把目光放远一点好.无论对于个人还是公司都是那样.
liulianxi 2003-03-05
- 打赏
- 举报
有一点无可否认，软件工程确实是有用的。但在小公司中实施可能会有个方面的压力，实施起来也应该有所裁减，大家有没有想过，对小公司应该做什么样的裁减呢？毕竟，我们中的大部分人都不是在大公司做大项目。
sun4flower 2003-03-04
- 打赏
- 举报
很好的贴子，先保存一下~~：）
keisar 2003-03-04
- 打赏
- 举报
实践出真知。
w102272 2003-03-04
- 打赏
- 举报
国内小型软件公司的项目管理应该怎么管？？？？？
很简单，尽量降低成本，提高效率，达到必要的质量和功能。
所谓必要的质量和功能，最好是用户看到你很郁闷，但是最终还是接受了的功能和质量。再说浅显一点，60分万岁知道了吧？
这才有钱赚，才能生存下来，没钱赚，公司都死了，项目只亏不赚，搞个鬼项目管理，软件工程，恐怕你明天就被一脚提出公司了。
公司为了什么存在？ 为了利润。中国现在这些软件公司，小公司谋生存，大公司谋的还是生存，不过大公司有关系，有资源，有钱，所以冲突不是那么明显，可以来点表明上象样子的软件工程方法罢了。
套用软件工程的公司都得死。应该用软件工程的理念在现实条件下作必要的调整，
如果和压缩成本，时间，赢利的目标冲突了就要毫不犹豫放弃。
在这种环境下，很多情况为了市场牺牲质量，牺牲严格的过程是必须的。
只是要明白事，有脑子，知道自己到底丢掉了什么，
否则说个不好听的，给你个土枪小刀，你还真可能杀几个人，给你个SU30，你连怎么进去都可能找不到门。
还有要注意分辨那些是真要给你SU30的，还是拿那个幌你眼睛的，这是朋友和骗子的区别。
这叫什么？ 叫市场导向，利益导向，不是技术导向。
你说中国的项目管理，软件工程是什么？
不是面向质量的软件工程，项目管理， 是面向利益的软件工程，项目管理。
你说这真是短视，缺乏长远眼光，不求上进？
拜托，你要先活下来，至少你的老板活的比你强，你先达到他的水平再坐而论道吧。
很简单，尽量降低成本，提高效率，达到必要的质量和功能。
所谓必要的质量和功能，最好是用户看到你很郁闷，但是最终还是接受了的功能和质量。再说浅显一点，60分万岁知道了吧？
这才有钱赚，才能生存下来，没钱赚，公司都死了，项目只亏不赚，搞个鬼项目管理，软件工程，恐怕你明天就被一脚提出公司了。
公司为了什么存在？ 为了利润。中国现在这些软件公司，小公司谋生存，大公司谋的还是生存，不过大公司有关系，有资源，有钱，所以冲突不是那么明显，可以来点表明上象样子的软件工程方法罢了。
套用软件工程的公司都得死。应该用软件工程的理念在现实条件下作必要的调整，
如果和压缩成本，时间，赢利的目标冲突了就要毫不犹豫放弃。
在这种环境下，很多情况为了市场牺牲质量，牺牲严格的过程是必须的。
只是要明白事，有脑子，知道自己到底丢掉了什么，
否则说个不好听的，给你个土枪小刀，你还真可能杀几个人，给你个SU30，你连怎么进去都可能找不到门。
还有要注意分辨那些是真要给你SU30的，还是拿那个幌你眼睛的，这是朋友和骗子的区别。
这叫什么？ 叫市场导向，利益导向，不是技术导向。
你说中国的项目管理，软件工程是什么？
不是面向质量的软件工程，项目管理， 是面向利益的软件工程，项目管理。
你说这真是短视，缺乏长远眼光，不求上进？
拜托，你要先活下来，至少你的老板活的比你强，你先达到他的水平再坐而论道吧。
w102272 2003-03-04
- 打赏
- 举报
来自用户的观点，
－－－“写报告、编程序和买设备”，
－－－“干什么都得赚,不能让这小子白拿钱”， 其实真是简单而直接，呵呵。
边 际 需 求 递 减 规 律
段 永 朝(计算机世界99/4）
--------------------------------------------------------------------------------
----系统分析、 系统设计与系统实现是计算机应用项目开发的“三部曲”，书上是这么说的。 国内目前系统分析级的人才奇缺，系统设计级的人才相比之下满大街当 然得是中关村的大街）都是，报纸上是这么说的。解决这个问题的办法大概只有一条，那就是快速培养系统分析师傅，因为这是关乎系统成败的关键，许多人都这么说。
----不 过“三部曲”的说法太专业，可以改写成：写报告、编程序和买设备。
----我认识的安利思就是系统分析级的人物，或者起码自认为是系统分析师傅，因为此公对软件工程的老方法、新概念烂熟于心，对可行性研究的五大步骤、市场行情、 技术动态无不通晓，更可贵的是，安师傅训练有素、勤于琢磨、待人诚恳、性情温和。
----一 日，安师傅带着笔记本电脑里386页熬夜的成果和一个Prototype，单刀赴会，打算给一家新开张的酒店一个漂亮的Total Solution（全面解决方案）。在酒店的小会议室里，安师傅鼓起三寸舌打开电脑，指东戳西地从大堂讲到厨房，从吧台讲到客房，又从后勤讲到账房，布线如何结构化，网络怎样“内特”化（ 注：Intranet 的汉语规范译名据说叫内特网），数据需要范式化，界面显得漂亮化 … …
----厄运往往从最简单的问题开始。趁小安子重启动该死的“晕倒死Windows”的空儿，店老板问起了“这玩意儿得花多少钱”的问题。这个问题是谈话主动权转移的标志。当系统分析师把一个系统在报告里解决得过于Total、过于完美的时候，分析师是老师，店老板是学生， 而且是一个喏喏连声、越听越糊涂、越听越哆嗦的学生；当说到这玩意能花多少钱，又能替老板省多少钱（省下的就是赚下的）的时候，就轮到师傅上火了。
----有这样的感觉大概不为过。因为分析师眼里的系统需求乃至对需求的分析，主要是建立在对业务的理解之上的；而老板眼里的系统需求要直截了当得多：这东西必须赚的比花的多，否则是宁可不用的。
----问题的焦点就在于“需求”究竟是什么。如果说需求是分析师试图建造的那个系统的逻辑前提的话，就只能写在纸上，因为这个“需求”其实是一个懂得电脑的人，虚构出来的需求；如果说需求是店老板希望能“赚多少”的话，这个需求肯定会让安师傅这样的高级人才感到“俗不可耐”，因为在安师傅看来，信息化带来的好处是不容质疑的，是“一言以蔽之”的，所以就只能说在嘴上了。
----从吃饭这样一个直观的事例说，需求似乎应该是“欲望”。如果没有欲望，可能就不会产生真实的需求。但吃饭的欲望并不能无止境地存在，一旦吃饱后，哪怕再多吃一口，满足的感觉就不是上升，而是开始下降了。
----因此这里有一个基本的错位：系统分析师用自己“解决的欲望”替换了老板“尝到甜头”的欲望，从书本上讲到的需求分析开始，从对业务的解构与建构，从组织形态、业务流程与关系、数据类型与存储处理交换，以及用户打算干什么等等开始，并且以此为假设，推导出了一个完整的报告来。这个虚构的需求不停地以把问题搞玄乎、使系统显露出超越店老板的控制能力为特征，所以非但没有“激活”真正的需求，还可能倒掉胃口，使其“晕倒而死”。
----店主的欲望其实一点也不复杂：对那些没有“上级主管部门”拨机器、配软件的店主来说，用电脑的目的就是为了管好钱袋子。只不过许多真实的故事表明，在“用户打算干什么”这点上，因为技术壁垒和心理“障碍”，用户的需求处于“尚未激活的边缘”，或者说处于“饥饿的边缘”。也就是说，许多店老板，并不清楚自己为什么要请一个安利思来，或者请一个Programmer，他的欲望是很直观的：干什么都得赚，不能赔；他的边际防线也很明白：不能让这小子白拿钱。
----这是个有趣的差异，如何弥补这两者之间的差异，恐怕是超出“三部曲”之外的故事了
－－－“写报告、编程序和买设备”，
－－－“干什么都得赚,不能让这小子白拿钱”， 其实真是简单而直接，呵呵。
边 际 需 求 递 减 规 律
段 永 朝(计算机世界99/4）
--------------------------------------------------------------------------------
----系统分析、 系统设计与系统实现是计算机应用项目开发的“三部曲”，书上是这么说的。 国内目前系统分析级的人才奇缺，系统设计级的人才相比之下满大街当 然得是中关村的大街）都是，报纸上是这么说的。解决这个问题的办法大概只有一条，那就是快速培养系统分析师傅，因为这是关乎系统成败的关键，许多人都这么说。
----不 过“三部曲”的说法太专业，可以改写成：写报告、编程序和买设备。
----我认识的安利思就是系统分析级的人物，或者起码自认为是系统分析师傅，因为此公对软件工程的老方法、新概念烂熟于心，对可行性研究的五大步骤、市场行情、 技术动态无不通晓，更可贵的是，安师傅训练有素、勤于琢磨、待人诚恳、性情温和。
----一 日，安师傅带着笔记本电脑里386页熬夜的成果和一个Prototype，单刀赴会，打算给一家新开张的酒店一个漂亮的Total Solution（全面解决方案）。在酒店的小会议室里，安师傅鼓起三寸舌打开电脑，指东戳西地从大堂讲到厨房，从吧台讲到客房，又从后勤讲到账房，布线如何结构化，网络怎样“内特”化（ 注：Intranet 的汉语规范译名据说叫内特网），数据需要范式化，界面显得漂亮化 … …
----厄运往往从最简单的问题开始。趁小安子重启动该死的“晕倒死Windows”的空儿，店老板问起了“这玩意儿得花多少钱”的问题。这个问题是谈话主动权转移的标志。当系统分析师把一个系统在报告里解决得过于Total、过于完美的时候，分析师是老师，店老板是学生， 而且是一个喏喏连声、越听越糊涂、越听越哆嗦的学生；当说到这玩意能花多少钱，又能替老板省多少钱（省下的就是赚下的）的时候，就轮到师傅上火了。
----有这样的感觉大概不为过。因为分析师眼里的系统需求乃至对需求的分析，主要是建立在对业务的理解之上的；而老板眼里的系统需求要直截了当得多：这东西必须赚的比花的多，否则是宁可不用的。
----问题的焦点就在于“需求”究竟是什么。如果说需求是分析师试图建造的那个系统的逻辑前提的话，就只能写在纸上，因为这个“需求”其实是一个懂得电脑的人，虚构出来的需求；如果说需求是店老板希望能“赚多少”的话，这个需求肯定会让安师傅这样的高级人才感到“俗不可耐”，因为在安师傅看来，信息化带来的好处是不容质疑的，是“一言以蔽之”的，所以就只能说在嘴上了。
----从吃饭这样一个直观的事例说，需求似乎应该是“欲望”。如果没有欲望，可能就不会产生真实的需求。但吃饭的欲望并不能无止境地存在，一旦吃饱后，哪怕再多吃一口，满足的感觉就不是上升，而是开始下降了。
----因此这里有一个基本的错位：系统分析师用自己“解决的欲望”替换了老板“尝到甜头”的欲望，从书本上讲到的需求分析开始，从对业务的解构与建构，从组织形态、业务流程与关系、数据类型与存储处理交换，以及用户打算干什么等等开始，并且以此为假设，推导出了一个完整的报告来。这个虚构的需求不停地以把问题搞玄乎、使系统显露出超越店老板的控制能力为特征，所以非但没有“激活”真正的需求，还可能倒掉胃口，使其“晕倒而死”。
----店主的欲望其实一点也不复杂：对那些没有“上级主管部门”拨机器、配软件的店主来说，用电脑的目的就是为了管好钱袋子。只不过许多真实的故事表明，在“用户打算干什么”这点上，因为技术壁垒和心理“障碍”，用户的需求处于“尚未激活的边缘”，或者说处于“饥饿的边缘”。也就是说，许多店老板，并不清楚自己为什么要请一个安利思来，或者请一个Programmer，他的欲望是很直观的：干什么都得赚，不能赔；他的边际防线也很明白：不能让这小子白拿钱。
----这是个有趣的差异，如何弥补这两者之间的差异，恐怕是超出“三部曲”之外的故事了
frank_lin 2003-03-04
- 打赏
- 举报
规定用求和法来确定应编制的文件，是一个不错的办法。具体如下：任务负责人可用这十二个因素对所要开发的程序进行衡量，确定每个因素的具体值。把这十二个因素的值相加，得到一个总和。然后由这个总和的值来确定应该编制的文件的种类。
duhui2001 2003-03-03
- 打赏
- 举报
其实，很多人之学到了软件开发的皮毛，说一只会编码，所以在小公司好像只是编程，其实编程只是很小的一部分，哎，大家都知道软件工程，可又有几个人领会到了他的精髓了呢，在一个工程中最累的应该是项目经理，可是他有权力，就把应该他做的交给了程序员，如果程序员做不好，反而说程序员没能力，其实，那是人的惰性在作怪。综上所术，会软件工程的不去按软件工程的方法办事，而做事的不会软件工程或没时间用软件工程的方法办事。
ADAI110 2003-03-03
- 打赏
- 举报
在实际工作中我觉得软件工程告诉我的多是开发中的注意事项，他只是一个指导而已，实际的工作中变数太多，只能随机应变了；
thesecondbull 2003-03-03
- 打赏
- 举报
没学过，软件工程学好了就可以当项目经理了吗？
janton 2003-03-03
- 打赏
- 举报
我有同感
Wally_wu 2003-03-03
- 打赏
- 举报
我觉得软件工程适用于任何规模的面向用户的软件。
wellhead 2003-03-03
- 打赏
- 举报
<<极限编程>>年过了没有? 这个主要就是针对小项目而言(当然也是对小公司来说),因此说呢小公司有小公司的方法,不要老是死搬书上的东东!
im_yh 2003-03-03
- 打赏
- 举报
每做完一个项目都要认真地总结,
再一个要准备一个笔记本随时记录心得体会:)
再一个要准备一个笔记本随时记录心得体会:)
im_yh 2003-03-03
- 打赏
- 举报
建议理论和实践相结合!:)
sx9401 2003-03-03
- 打赏
- 举报
gz
lizongqi 2003-03-03
- 打赏
- 举报
关键还是思想能融入到开发过程中
加载更多回复（22）
