异地软件开发项目管理问题 异地项目开发应该如何管理

队和北京的管理起来。初步想到以下几点（我们有一个公网的服务器）：在服务器上建立svn版本控制服务器，并且把svn和apache结合起来，让广州的同事可以通过c/s和b/s两种方式访问版本库；使用JSPWiki管理项目中的文档。 随后邮件列表中的其他人提出了很多有用的建议。ThoughtWorks的咨询师、CruiseControl开发者胡凯建议：至少[应该做到]：每天早上用电话Standup。让两方面都了解进度和困难。应该有一个搭好的演示环境，这样，每一两周广州的同事可以给北京的同事演示软件目前的特性。Wiki有专人负责收集大家的问题和保持与北京的联系，并且把答案及时的反馈回来。有Matrix帮助北京的同事分析目前项目的情况，Test Coverage, Iteration Point, build time……Korben Zhang指出，有效的版本控制和自动构建是分布式项目中重要的信息：异地开发沟通和交流自然受影响，在机器上聊天的方式，来交流系统没有构建成功作用比较弱。我想异地开发可以采用的方法可能有：语音、视频+白板版本控制定时自动构建监控报告 留学英国研究敏捷软件方法的杨昆博士还指出了分布式项目中背景信息传递的重要性：对于异地开发而言，除了传递正式信息，最重要的是传递背景信息（context），便于异地成员的理解。因此文本的沟通不能代替人际的沟通。每天的电话会议是个挺好的建议。如果条件允许，能视频是比较理想的。很多非言语的信息（表情，神态）可以传递。这些非言语的信息对于理解对方对一些事件的态度（如，强调/支持/反对等）的程度很有帮助。而且，混个脸熟，对增强团队成员之间的信任感也是有好处的。最不济，MSN等聊天工具还是必要的。因为，MSN是非正式的沟通工具。非正式的沟通在同地工作的团队中是随处可见的，是润滑剂。异地开发的不足，也在这个地方。不管采取啥策略，应该注意用比较低的成本，完成背景信息在团队中的传递。 为了降低成本、提高企业竞争力，现代软件开发中分布在多个地点（甚至多个国家）的项目越来越常见。但分布式项目的缺点是交流成本急剧上升，给管理带来更大的难度。行业领先的企业指出，采用敏捷方法可以有效应对分布式项目的挑战。微软MSDN指出，离岸软件开发完全可以受益于敏捷过程。ThoughtWorks也拥有实施分布式敏捷项目的成功案例。

如何与异地的开发人员沟通

如今产品经理与开发团队各处一方的情况很常见。除了印度软件外包业务，大型公司的分支机构之间，以及公司与被收购的子公司之间，都可能出现这种情况。

如果开发团队不在你身边，沟通和执行的难度将进一步放大。异地开发出现的问题常常导致团队士气低落，有人甚至公开质疑异地开发能否真正节约成本。

提高与异地开发团队之间的沟通效率，我有三条建议。

开发团队距离越远，语言、文化、时差带来的沟通难度越大，确定完善的产品说明文档就越重要。如果产品经理不确定开发什么样的产品（或者反复改变想法），异地开发团队只能疲于奔命，白费力气。这简直就是一场灾难，丝毫不亚于医生开错方子。如果你与开发团队相隔很远，无论是沟通产品文档的内容，还是讨论修改产品设计，一定要借助高保真原型进行交流。阅读文档毕竟不轻松，如果文档是非母语的，或者阐述不清楚，那沟通效率就更低了。

本地的开发团队很容易发现和解决各种冲突（比如，两个管理者给出相互抵触的指导意见）。异地开发团队则会发生很多意想不到的情况，往往过了好几个月才发现问题。这是因为异地开发人员不得不揣摩各种不同的意见（但经常揣摩错）。因此，必须有人在本地负责与异地团队的协调工作。这并不是说所有沟通工作都必须经过此人，而是应该明确异地开发团队只接受他的命令。这项工作可以由本地的项目经理、资深开发人员或者其他主管担任。

如今商业沟通手段很丰富，除了电子邮件和即时消息外，还有视频会议可供选择，此外，语音电话业务（VoIP）大大降低了国际长途通话费用支出。尽管如此，当面交流的优势依然不可替代。每个季度，产品经理至少应该前往异地与开发团队见一次面，与软件架构师、管理者当面交流。面对面交流有助于改善（合作）关系，提高沟通效率。此外，交换人员也是一种有效的沟通方式，可以让主程序员来本地与产品经理共同工作一段时间，或者让产品经理到异地工作一段时间。

按照我介绍的方法与优秀的开发团队合作是一种特别的享受。如果是与印度外包团队合作，那么由于时差的原因这种合作会让人觉得更加惬意。每天早晨上班时，对方的项目进展已经摆在面前。你可以用白天（对方的夜晚）检查、测试代码，反馈信息，显著缩短项目的循环周期。

请注意，如果是在异地开展与产品原型相关的工作，由于循环周期非常短（一天迭代好几次），你必须随时准备处理对方的问题，投入更多的精力。

解决异地开发问题的另一种方式是在异地聘请产品团队。这种趋势正在兴起，我相信这种模式会被更多的公司采用。你大可不必为此担心。我们曾经用了10年时间在异地培养专业的开发和测试人员，培养专业的产品经理和设计人员很可能还要再花10年时间。

产品经理最担心听到开发人员这样抱怨：不能再增加功能了！我们得停下来重写代码。代码库一团糟，就像纸糊的老虎，根本应付不了持续增加的用户。我们维护不下去了！

这一幕在很多公司上演过，现在依然在不断重演。1999年eBay遭遇这一幕时，公司濒临崩溃的情形超出所有人想象。Friendster几年前也 发生过这种情况，当时他们正在向MySpace开放社交网络用户。网景与微软展开浏览器大战时，也发生过类似的事情，最后的结果大家都知道。事实上，没几家公司能渡过难关。

一旦公司陷入这种困境，开发团队往往沦为替罪羊。经验告诉我，这类问题通常是由产品管理失误引发的。因为产品经理一直迫使开发团队满负荷工作，开发 尽可能多的功能。所有软件架构都存在功能极限，如果忽视产品的基础技术构架，一旦系统越过崩溃的临界点，就会造成无法挽回的结果。

在重写代码的过程中，用户无法看到产品的任何改进。你可能认为重写代码至多也就几个月，但是实际花费的时间无一例外要多得多。你只能坐在一旁，眼睁睁看着用户投奔竞争对手，而这个时候，竞争对手恰恰在不断地改进产品。

如果你还没有遇到这样的情形，未雨绸缪很有必要你需要预留一定的研发技术能力，在eBay被称为余量（headroom）。很多因产品迅速膨胀产生的问题都与扩展规模有关，余量意味着避免触及技术能力的上限，为用户数量的增长预留空间，为事务增长预留空间，为新增功能预留空间，保证产品的基础技 术构架能够满足团队的要求。

与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统性能，避免我们需要停下来重写代码的情形发生。

如果你的糟糕处境已经初现端倪，应该拿出至少20%的资源进行调整，而我担心有些团队连20%都不愿意拿出来。如果你已经身陷重写的困境，说明公司危在旦夕，这里给出一点建议供你参考。

第一步，针对开发团队确定的产品修改目标并制订切实可行的计划和时间表。通常，有经验的开发团队估计的开发时间八九不离十，但是重写代码是个例外，因为多数团队都没有重写代码的实际经验，估计往往过于乐观。你必须审时度势，仔细检查每处细节，确保计划切实可行。

第二步，只要有可能，最好把重写目标分成几大块，实现递增修改，让用户感受到产品的改进，哪怕会因此把9个月的工作时间延长至2年，也一定要采用这种方式。重写代码时，保证让用户看到功能的改进即使会占用少则25%，多则50%的开发资源对保持产品（尤其是互联网产品）的市场占有率至关重要。

第三步，由于开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，并确保产品定义的正确性。

eBay起死回生后，我们发誓绝不重蹈覆辙，马上开始新一轮的代码重写，把危机甩在身后。事实上，由于发展迅速，eBay已经重写了三次代码，最后一次采用了完全不同的编程语言和架构。开发团队花了几年时间，大规模地改写了几百万行代码，同时在不影响用户群的情况下，开发了大量新功能。这是我知道的最惊心动魄的中途重建网站的故事。

临渴掘井不如未雨绸缪，为防患于未然，别忘了预留20%的余量。

Java程序开发步骤？

一个完整的Java程序开发步骤主要包括：

1、项目启动

1)、项目组成立(公司成员、客户成员)

2)、制定项目预期目标

3)、制定项目计划周期

4)、建立好项目组成员沟通机制

2、需求调研

1)、创建调研计划、协调调研时间

2)、收集客户资料，获取客户需求

所有的资料都需要保留一份，资料中存疑的需要及时询问

3)、编写需求文档

重点描述出客户的业务流程和性能要求。

采用Word、Excel、Rose等形式。

4)、需求变更记录

5)、确定开发环境和运行环境

6)、扩展性要求

7)、与旧系统的接驳要求。

8)、估算出项目工作量

本阶段需要一套需求管理系统来进行需求的管理。

本阶段的需求文档也是用户测试的依据。

3、系统设计/详细设计

一个系统可以分为基础平台和应用模块两部分。

1)、选择基础平台，无论是采用第三方平台还是自行开发平台，都需要深入了解，查看是否符合要求。

2)、应用模块设计(针对业务流程)

3)、中间件的采用或自行开发，需要深入了解。

4)、用户界面的设计

如果用户界面设计完毕并确认，即可初步写出用户使用手册、管理员使用手册。

5)、变更记录

本阶段的系统设计是集成测试的依据。

4、程序开发

创建开发任务计划表、开发计划日程表

1)、优先编写测试用例

2)、按照编码规范编写代码

3)、按照文档注释规范注释

以上形成开发文档。

本阶段需要一套版本管理系统。

本阶段的测试用例也是单元测试的依据。

如果能做到，最好每日构建。

5、测试

本阶段需要一套Bug管理系统，形成需求、设计、开发、测试互动。

1)、编写测试计划和测试方案

2)、功能测试

单元测试、集成测试

3)、性能测试

集成测试、压力测试

如果能做到，最好能进行自动化测试。

如果能做到，做分析统计工作。

最后形成测试报告。

6、试用、培训、维护

本阶段需要解决：

1)、解决异地修改和公司修改的同步问题。

2)、用户测试中的Bug修改问题，按照级别分为

a)、程序Bug

b)、设计变更

c)、需求变更

尽量按照a b c的顺序来进行修改，尽量避免b、c级的修改。

最后形成安装手册、维护记录。

以上是Java项目开发过程中的基本步骤！

如何管理异地企业

你的情况是你自己公司开直营店，不需代理商或者加盟商。也是属于连锁专卖店的模式，只是自营而已。

这样确实有其优点：便于自己管理，统一执行公司标准；便于促销、终端陈列等形象统一。

我是从事家纺企业的渠道管理。我以家纺专卖店的管理角度给你分析下

你要开连锁店（自营店），要做好以下准备：

1、门店选址：

可以选址行业集中区域；或者目标客户群集中地，当然还要考虑交通、

朝阳或背阳等等问题。

2、专卖店的统一形象设计（CI标志），你公司目前规模不大的话，还不需要专门的设计部门，可以找设计公司，其中设计到每个细节，一份标准的店面设计图纸里面包括用什么材料，颜色，什么品牌，灯光效果，决定前看下空间效果图等等。

3、专卖店的终端管理，简单的说就是：人、财、物

人：

关于专卖店，选好店长是很重要，一般要选有经验而且人品，不错而且学历高中或以上要受过公司培训的店长。不知你那边的情况如何，一般情况下，店长可以公司派，当然当地能招牌到适合的店长最好，一般店员都是招牌当地人，因为语言沟通上有优势，营业员的稳定性比较重要，像我们这边一般都是找，30-40来岁已婚的妇女，她们的情况比较稳定，当然也不是绝对，看具体的人。如果当地招聘的话，一定要在营业前进行培训。专卖店员工要穿工作服，这对终端形象很重要；有人事变动，如店员离开，要提前一个月向公司回报。

财：一般是店长和副店长，副店长负责做账，店长负责其他事物，这里涉及到一个轮班问题，不管怎么样，一定要使店长或副店长其中一位在店。一般是每天选个营业空段，把营业款存进公司帐户，我这边的公司直营店和公司的主要联系是电话和传真机，你那边最好就用电脑操作，报货下单都方便。一般是一个星期把账目传给公司。一个季度盘点一次或者促销完毕盘点一次，这根据你们那边的具体情况而定。因为，专卖店有统一的销售单，这销售单就是公司以后对账的根据。副店长必须每天把账务做完。（副店长轮休或有事有时是店长兼做账）

PS：销售单写错或者其他任何原因都是不能撕掉的，这也是财务常识。销售单上注明：顾客持卡或其他原因所以打折。一般店里的店员的伙食都是她们自己出的，对于店里的一些生活易耗品费用：可以给一个标准，一个月限额多少。有电脑的话，最好做完手工帐再在电脑上做账，平时可以每天传一份给公司，财务可以一个月来一次，既是查账又可以结算工资，我这边的奖金提成是一个季度算一次的。

3、物：就是每天营业前要把店内清洁下，使终端形象好点。

收货：一般是店长负责制，对完货，客户联上：确认签字；有什么缺失或者损坏及时向公司回报。

一般促销活动前要盘点，促销完后要盘点，还有季度盘点，根据实际情况而定。当然还有一些客户的退货（质量问题）等一些条则的指定。

由于时间有限，简单分析到此，有问题可以联系我：QQ：358644982

可以给你提供一些连锁经营的资料和经验分享。

软件开发的项目经理的日常工作是什么？

搜集了一篇软件开发中项目管理的文章，看看

当项目繁多的时候，需要规范，并且定义到细节，只有这样，才能支持大规模的开发。

PM非常重要，PM的能力将直接导致项目最后的质量。

本文是根据公司当前的现状而描述的，并不一定普遍适用－－合适的，就是最好的。

项目经理职责：

1、 基本职责就是确保项目目标的实现，领导项目团队准时、优质地完成全部工作。

2、 与客户沟通，了解项目的整体需求。并与客户保持一定的联系，即时反馈阶段性的成果，和即时更改客户提出的合理需求。

3、 制定项目开发计划文档，量化任务，并合理分配给相应的人员。

4、 跟踪项目的进度，协调项目组成员之间的合作。

5、 监督产生项目进展各阶段的文档，并与QA即时沟通，保证文档的完整和规范。

6、 开发过程中的需求变更，项目经理需要跟客户了解需求，在无法判断新的需求对项目的整理影响程度的情况下，需同项目组成员商量，最后决定是否接收客户的需求，然后再跟客户协商。确定要变更需求的情况下，需产生需求变更文档，更改开发计划，通知QA。

7、 项目提交测试后，项目经理需了解测试结果，根据测试的bug的严重程度来重新更改开发计划。

8、 向上汇报。向上级汇报项目的进展情况，需求变更等所有项目信息。

9、 项目完成的时候需要项目总结，产生项目总结文档。

项目经理权利：

1、 开发指挥权。项目开发人员的分配和调整。

2、 技术决策权。主要是审查和批准重大技术措施和技术方案，以防决策失误，造成重大损失。

3、 申请协作权。项目发展出现不能解决的问题的时候，可以向上级申请协作。

4、 考核成员权。考核项目组成员，视觉和测试组只考核组长。

必备流程：

1． 每天下午5:00――6:00，项目经理召集该项目的相关人员（包括开发人员、美工等）作项目每日总结，内容包括：

（1） 了解每个成员的工作进度情况。

（2） 了解成员在工作中遇到的困难，并寻找资源解决。

（3） 成员之间的配合是否协调一致（比如，需要提交的物件没有按时提交或遗忘等）。

（4） 如有需要，根据当前的进展情况调整项目计划。

（5） 安排每个成员第二天的工作。

（6） 如果考虑到项目当前的进展状态可能会导致项目延期，则项目经理有权安排项目组加班，以保证工期。

2． 如果项目经理接收到新的需求，则项目经理应该在下午的项目每日总结会上提出，并分配安排工作。除非新来的需求特别紧急或影响到项目组当前正在进行的任务，需要召集项目组成员紧急讨论外，否则不应打断项目组的当前工作。

如果新的需求是在每天下班后接收的，则项目经理应在第二天早上召集项目组成员讨论并安排任务

手机软件开发管理过程中，如何采用敏捷开发模式

1 传统的瀑布模式软件开发不能满足正规公司的软件开发要求

1-1 手机软件公司大，小之分

目前手机软件公司应该说一个参差不齐，

（2）一般公司做法，有一定规模的公司，在软件开发过程中，引入了项目管理思想按照传统的瀑布方式的软件开发模式在做软件管理，按照软件需求分析，软件概要设计，软件详细设计，编码，集成，软件测试，软件发布流程在做项目计划，项目管理按照这个项目计划进行软件开发控制，软件项目管理仅仅是强调了软件开发计划和软件开发控制，对于整个软件实施构思，已经如何实施才能达到项目要求，指导比较少？

针对于目前手机软件需求变化极快的情况，此开发模式在多项目情况下，软件需求确定，软件开发计划确认，软件开发反馈以及沟通，分工在实际实施过程中，都会往往应为一些软件需求变更导致项目交付有问题！

（3）软件成熟度较好的手机软件开发公司，引入了PM，按照CMM流程重视软件开发过程控制以及软件开发技术积累，同时为了能适应手机软件开发需求变化比较快的特点，不采用传统瀑布模式软件开发，引入了敏捷开发模式，在软件实践过程中，引入了FDD,ASD,XP的敏捷开发模式，在软件开发过程中，强调以构架为中心，以需求为驱动的迭代开发模式，通过构架，确保软件的可扩展性和接口合理性，强调接口设计，方便于迭代和合作开发；通过需求驱动，把每一个需求功能，作为一个user 测试点独立开发，先进行每一个user feature 验证，然后集成，通过每一个user feature的验证中，引入客户参与以及反馈确认，从而控制开发过程质量以及需求匹配程度，减少软件开发偏差！

1-2 采用敏捷开发好处

引入敏捷开发，通过需求阶段，需求管理敏捷，在需求管理过程中，以客户为中心；

软件构架，采用敏捷分析，客户，测试，研发共同参与，让虽有参与，可以尽快获得客户反馈，以便于保证工作正确性；

敏捷开发，强调接口，合作，迭代集成，迭代测试；

敏捷测试：尽快确认研发是否适合需求，并且反馈；

如果整个团队内部都已经能熟练的实施后，可以考虑实行分布式的敏捷开发；即机制外包开发或者异地机构开发管理；

分布式敏捷：

快速达成共识---沟通以及反馈确认通畅---敏捷开发

2-1 敏捷开发工具

CC,SVN--软件配置工具；

CQ,BUGFREE---测试管理工具

开发论坛：WIKI；技术共享，目标共享，计划共享，接口共享网络工具：沟通工具

软件项目负责人工作中的一个管理类问题~

哥们你是第一次做这个活吗，很多这样的项目都是回扣不到位，上层出问题了，有问题肯定是前期没有做好，既然没有做好就要忽悠甲方啊，忽悠成功就可以了，比饿哦与压力

哦，这个咋说呢~呵呵，可能每个情况有不同吧~不过算你回答的正确，给你满分吧，哈哈

我们公司是模具制造企业，想上一套项目进度管理软件，请问有什么公司的软件比较适合我们，我们是小型的

简众ERP,中小型企业管理专家！

感兴趣的话可以试用一下我们的ERP

先试用，后收费

绝对个性化定制，可以二次开发

软件价钱合理， 维护成本低

感兴趣的话可以站内联系我

转载请注明出处51数据库 » 异地软件开发项目管理问题 异地项目开发应该如何管理