给软件开发经理的建议

 

Advice for Software Development Managers

© Gerald M. Weinberg, 2004 www.geraldmweinberg.com

给软件开发经理的建议


Software Development Magazine recently interviewed Jerry. Here are some of his answers.

软件研发杂志最近采访了Jerry。以下是部分访谈录。


Q: What’s the most important piece of management-related advice anyone has ever given you?

问:你得到的最重要的一条关于管理的建议是什么?

GW: If you blame your employees, you're a bad manager. You hired them, accepted them, supervised them, and directed their training. You’re responsible. If you don't like what's happening, look to your own behavior. But, if there's credit to be given, it's theirs.

温伯格:如果你抱怨你的员工,那么你是一个不善于管理的经理。你雇佣了他们,接受了他们,监督了他们,并指导他们的培训。你是有责任的。如果你不喜欢他们的表现,审视一下你自己的行为。如果项目成功的话,荣誉是他们的。


Q: What about when a manager has been hired into a group where some or all employees were already hired by someone else?

问:另外一种情况是,公司直接引入一位经理管理一个团队,而这个团队的成员已经存在,并不是由这位经理亲自雇佣的,这种情况怎么办?

GW: You don't take a management job passively. Before you accept the position, you interview everyone in your group, and you get them to sign on with you, or you sign them off -- or you don't take the position. I don't know why managers don't understand that. They take on new assignments like high school kids on their first blind date.

温伯格:你并不是被动的承担了这份管理工作。在你接受这个职务之前,你需要与这个团队的每一位成员进行面谈,让他们签约受雇于你,或者解聘他们——再或者,你放弃这个职位。我不知道为什么许多管理者都不理解这个道理。他们接受新任务,就像高中生盲目地去赴他们的第一次约会。


Q: What if an employee begins to exhibit bad behavior after he or she has been hired -- behavior that wasn't apparent in the interview phase?

问:如果员工在他/她受雇后,表现出了在面试阶段并不明显的不好的行为,怎么办?

GW: Well, that happens, and that's what managers get paid for handling. It can be a setback, but it's your job to take care of it and get the job done. Unfortunately, not many technical managers have any preparation for this, something I've been trying to remedy for years -- so in a sense, I'm to blame, because I've succeeded in only a few cases. Hey, if everything went smoothly all the time, you wouldn't need managers.

温伯格:这种事情时有发生,这也是任何一位管理者拿了薪水要处理的事情。坏事可能会成为好事,你有责任认真处理此事。不幸的是,并没有多少技术管理者对此有所准备,让坏事成为好事,这也是我多年来希望能够做到的事情——因此,从某种意义上而言,应该被抱怨的是我,因为我仅仅在不多的几个案例上获得了成功。毕竟,如果每一件事情一直都进展顺利,就不需要什么管理者了。


Q: If you were to publish a third edition of The Psychology of Computer Programming, what new insights would it include? (Dorset House Publishing released a Silver Anniversary Edition in 1998.)

问:如果你准备出版《程序开发心理学》的第三版,书中会考虑增加哪些新的观点?(Dorset House出版社1998年出版了该书的银年纪念版,该书的中译本也于2003年出版。)

GW: I might add something about how to make yourself so valuable that your work will never be outsourced -- something about the arrogance and overconfidence that has led to the loss of lots of software development jobs, not just to outsourcing, but to development work that's just not being done because the odds of success are so poor.

温伯格:我补充的内容将会提高你的价值,以保证你的工作不会被外包出去,否则的话,不仅很多工作会被外包出去(没你的份),而且你正在进行的开发工作也会失去,因为(如果自负和过度自信的话,)成功的几率实在是太低了。


Q: Is this bad behavior coming from the developers themselves, or do you mean to say the entire industry is to blame for not staying on top of innovation?

问:这种不好的行为是源于开发人员本身,还是您认为整个产业都未能站在革新之巅?

GW: It starts with the developers, and managers, too. But the overall result is, as you suggest, the entire industry getting too involved in navel-watching and competitiveness over the wrong values. For a long time, customers had nowhere else to go for service and had to put up with whatever we gave them. Now they have choices, and they're getting even.

温伯格:始于开发人员,也始于管理者。但是整体的结果,正如你提到的,整个产业都没有找对方向,在一些错误的地方去钻牛角尖。很长时间以来,客户没有办法获得其他服务,因为他们不得不要接受我们为他们提供的服务。现在,他们有了选择,他们也在获得公正。


Q: In Are Your Lights On? (also available from Dorset House), you note that people like to complain. How do good managers draw the line between harmless venting and disruptive pessimism, if such a line needs to be drawn?

问:在《你的灯亮着吗?》一书中,您指出,人们喜欢抱怨。优秀的管理者如何区分无害的情绪发泄和具有破坏性的悲观主义,如果需要划分这种界限的话?

GW: "Drawing the line" is probably not the most useful metaphor. The approach I like most is to listen to the complaint for a reasonable amount of time, then say, "And what do you propose to do about this?" Depending on the reaction you get, take it from there.

温伯格:“划分界限”也许并不是最有用比喻说法。我最喜欢的方法是在合理的时间内聆听他们的抱怨,然后对他们说,“那么你打算怎么办?”根据你得到的反馈,可以做出一些推断。


Q: You once said, "If you can’t manage yourself, you have no business managing others." Could you elaborate on that? What does it mean to manage one's self?

问:您曾经说过,“如果你不能管理你自己,你就用不着去管理其他人。”您能解释一下这句话吗?管理你自己是指?

GW: Well, perhaps you can look at Kipling's famous poem,"If." It starts:

If you can keep your head when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can wait and not be tired by waiting,
Or, being lied about, don't deal in lies,
Or, being hated, don't give way to hating,
And yet don't look too good, nor talk too wise;

Most of this poem is still pretty good advice about what it means to manage yourself (except, unlike in Kipling's day, it now applies to women, too).

温伯格:哦,也许你可以看一下吉卜林的著名诗歌“如果”。诗中是这样写的:

如果在众人六神无主之时,
你能镇定自若而不是人云亦云;
如果在被众人猜忌怀疑之日,
你能自信如常而不去妄加辩论; [i]

这首诗里面的大部分都可以帮助你理解什么是“管理你自己”(但不像吉卜林时代,这首诗现在也针对女人。)


Q: In your opinion, why do so many software projects go over budget or fail to meet their original requirements?

问:在您看来,为什么那么多软件项目最后超出预算,或者不能达到最初的要求?

GW: There's no single reason, but here are probably the top three:

1. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power.

2. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have).

3. Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong -- and something ALWAYS goes wrong. In 50 years, I've never seen a project where something didn't go wrong. When it does, the project’s success is determined by the leaders' ability to manage themselves emotionally.

温伯格:原因不是单一的,下面列出了最重要的三条原因:

1.最初的预算、计划和要求是完全不切合实际的,因为人们不能把事实真相告诉控制项目的人。

2.最初的预算、计划和要求是完全不切合实际的,因为人们不能理解和承认他们自身的局限(我们都会有自身的局限)。

3.即便在很少时候,人们跨过了最初的两个障碍,当项目推进过程中出了问题(问题总是会出现),他们就会情绪失控。50年来,我从来没有遇到过一个没有出过问题的项目。如果出现了问题,项目领导者管理他们自己情绪的能力,将决定项目最终是否能够取得成功。


Q: If you were to find yourself on a development team, reporting to a project manager, what qualities would you want that manager to have?

问:如果你在一个开发团队,需要对项目经理负责,你希望你的项目经理具有哪些品质?

GW: I'd want that manager to be a congruent, adult human being, capable of learning from others and his or her own mistakes. A good place to start honing these attributes is the AYE Conference.

温伯格:我希望这位经理言行一致、成熟,能够向他人学习,从他/她的错误中吸取教训。开始学习这些优良品质的一个好去处,就是AYE会议。



 

版权声明:

 

本文出处:http://www.ayeconference.com 9/13/04

原作者:Gerald M. Weinberg

WeinbergCN翻译整理(Shiningxyy翻译,Yuanfeng审校)

 

未经许可,不得商业使用。

 

 



诗歌全文:

《如果……》

如果在众人六神无主之时,
你能镇定自若而不是人云亦云;
如果在被众人猜忌怀疑之日,
你能自信如常而不去妄加辩论;
如果你有梦想又能不迷失自我,
如果你有神思,又不至走火入魔;
如果你在成功之中能不得意忘形,
而在灾难之后也勇于咀嚼苦果;
如果听到自己说出的奥妙,
被无赖歪曲成面目全非的魔术而不怨艾;
如果你辛苦劳作,已是功成名就,
还是冒险一搏,哪怕功名成乌有,
即使惨遭失败,也要从头开始;
如果你跟村夫交谈而不离谦恭之态,
和王侯散步而不露谄媚之颜;
如果他人的爱憎左右不了你的正气;
如果你与任何人为伍都能卓然独立,
那么你的修养就会如天地般博大——
而你,就是真正的男子汉了。
我的朋友!

‘If’……

If you can keep your head when all about you
Are loosing theirs, and blaming it on you,
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can wait and not be tired by waiting
Or being lied about, dont deal in lies,
Or being hated dont give way to hating,
And yet dont look too good, nor talk too wise;

If you can dreamand not make dreams your master;
If you can think and not make thoughts your aim;
If you can meet both triumph and disaster
And treat those two imposters just the same;
If you can bear to hear the truth youve spoken
Twisted by knaves to make a trap for fools,
Or watch the things you gave your life to, broken,
And stop and build em up again with worn out tools;

If you can make one heap of all your winnings
And risk it on one turn of pitch and toss,
And lose, and start again at your beginnings
And never breathe a word about your loss;
If you can force your heart and nerve and sinew
To serve your turn long after they are gone
And so hold on when there is nothing in you
Except the will which says to them; HOLD ON

If you can talk with crowds and keep your virtue,
Or walk with kingsnor loose the common touch,
If neither foes nor loving friends can hurt you,
If all men count with you, but none too much;
If you can fill the unforgiving minute
With sixty seconds worth of distance run,
Yours is the earth and all that is in it,
Andwhat is moreyoull be a man, my son!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录   译者序   第2版前言   第1版前言   第0章不可知和不可说   0.1和解析体验相关的问题   0.1.1解析模式的冲突   0.1.2检测解析模式   0.1.3思考不准确的思想   0.2沟通的不可能性   0.2.1内部重新组织   0.2.2触及共享体验   0.2.3管理不完美的沟通   0.3聆听的三个层次   0.3.1三个层次和方法集   0.3.2三个层次与本书   0.3.3守-破-离   0.4那么,明天我做什么   第0A章不可知和不可说:演进   0A.1沟通和共享的体验   0A.2守-破-离   第1章创造和沟通的合作博弈   1.1软件和诗歌   1.2软件与博弈   1.2.1博弈的类型   1.2.2软件与攀岩   1.2.3创造和沟通的博弈   1.2.4软件与工程化   1.2.5软件与模型构建   1.3再论合作博弈   1.3.1程序员成为沟通专家   1.3.2更快地博弈   1.3.3标识物和道具   1.3.4减少回报   1.3.5对于首要目标的充分度   1.3.6对于积淀的充分度   1.3.7博弈中的博弈   1.3.8开放源码开发   1.4这对我意味着什么   第1A章创造和沟通的合作博弈:演进   1A.1沼泽游戏   1A.2合作中的竞争   1A.3其他领域的合作博弈   1A.4软件工程的重建   1A.4.1这一词汇从哪里来   1A.4.2我们从哪里走错了   1A.4.3重建软件工程   1A.4.4技艺   1A.4.5合作博弈   1A.4.6精益制造   1A.4.7重建后的软件工程   1A.4.8其他工程化中的协作   第2章个人   2.1人是古怪的   2.1.1寻找特征函数   2.1.2古怪性格的元素   2.1.3不可避免的多样性   2.1.4技术的作用   2.1.5相互冲突的共同点   2.2克服失败模式   2.2.1犯错误   2.2.2宁可失败也要选择保守   2.2.3创新而不研究   2.2.4不能始终如一的习惯动物   2.2.5使用纪律和容忍来应对   2.3以一些更好的方式工作   2.3.1具体化   2.3.2实物   2.3.3在某些东西的基础上进行修改   2.3.4观察和聆听   2.3.5支持专注和沟通   2.3.6工作分配要与个性相匹配   2.3.7天赋   2.3.8奖励要能保留乐趣   2.3.9组合奖励   2.3.10反馈   2.4利用成功模式   2.4.1善于四处寻找   2.4.2人们学习   2.4.3可塑性   2.4.4贡献和采取主动   2.4.5组合成功模式   2.4.6英雄也是普通人   2.5明天我该做什么   第2A章个人:演进   2A.1策略平衡   第3章团队的沟通与合作   3.1信息的对流   3.1.1延迟和机会损失成本   3.1.2尔格-秒   3.1.3渗透式沟通   3.1.4穿堂风   3.1.5信息辐射源   3.1.6热空气理论的应用   3.2跨越沟通的鸿沟   3.2.1沟通的形态   3.2.2去掉某些形态所产生的影响   3.2.3利用各种形态   3.2.4黏度与跨越空间的鸿沟   3.3团队就是集体   3.3.1友善和冲突   3.3.2工作时间的公民意识   3.3.3敌意的XP与友善的XP   3.3.4使用胜利来建立“团队”   3.3.5团队文化与亚文化   3.4团队就是生态系统   3.5我明天该做什么   第3A章团队:演进   3A.1一个修订后的办公室布局样本   第4章方法集   4.1一个交付软件的生态系统   4.2方法集中的概念   4.2.1结构术语   4.2.2范围   4.2.3概念术语   4.2.4发布一个方法集   4.3方法集的设计原则   4.3.1常见设计错误   4.3.2在方法集上成功的项目   4.3.3与作者的相关性   4.3.4七条原则   4.4细看XP   4.4.1XP简介   4.4.2剖析XP   4.4.3调整XP   4.5到底为什么使用方法集   4.5.1方法集解决什么问题   4.5.2如何评估一个方法集   4.6明天我应该做什么   第4A章方法集:演进   4A.1方法集与策略   4A.2组织级的方法集   4A.3过程就是循环   4A.4更简单地描述方法集   第5章敏捷与自适应   5.1轻但足够   5.1.1刚好足够   5.1.2对于编制文档的建议   5.2敏捷   5.2.1最佳击球点   5.2.2虚拟团队的麻烦   5.3变得自适应   5.3.1不厌其烦地进行反思   5.3.2方法集成长技术   5.3.3反思研讨会技术   5.4明天我该做什么   第5A章敏捷与自适应:演进   5A.1对于寓意的误解   5A.1.1迭代必须简短   5A.1.2敏捷团队必须驻扎在一起   5A.1.3敏捷团队不需要计划   5A.1.4架构已死;重构是你全部所需要的   5A.1.5我们不需要什么经理   5A.1.6敏捷开发在纪律上要求很低   5A.1.7敏捷只适合最优秀的开发人员   5A.1.8敏捷是既老又新的、失败的、没有尝试过的   5A.2敏捷方法集的演进   5A.2.1XP第2版   5A.2.2Scrum   5A.2.3实用主义和无名的   5A.2.4可预测、计划驱动和其他中心调整   5A.2.5约束理论   5A.2.6精益开发   5A.3新的方法集话题   5A.3.1敏捷项目管理   5A.3.2测试   5A.3.3用户体验设计   5A.3.4规划管控、Burn图和系统工程   5A.3.5用例和用户故事   5A.4经久不绝的问题   5A.4.1最佳击球点和下降   5A.4.2固定价格、固定范围的合同   5A.4.3敏捷、CMMI和ISO9001   5A.4.4何时停止建模   5A.4.5高科技/高接触的工具箱   5A.4.6敏捷的中心   5A.4.7你有多敏捷   5A.4.8引入敏捷   5A.5软件开发之外的敏捷   5A.5.1项目组合管理   5A.5.2客户关系   5A.5.3合同   5A.5.4将变更引入组织   5A.5.5程序员读哈佛商业周刊   5A.5.6建造房屋   5A.5.7机场建设   5A.5.8图书出版   5A.5.9会议组织和敏捷模型的限制   第6章Crystal方法集   6.1对Crystal家族塑形   6.1.1核心Crystal元素   6.2CrystalClear   6.2.1CrystalClear的简要描述   6.2.2CrystalClear的反思   6.3CrystalOrange   6.3.1CrystalOrange的简要描述   6.3.2CrystalOrange的反思   6.4CrystalOrangeWeb   6.4.1CrystalOrangeWeb的简要描述   6.4.2CrystalOrangeWeb的反思   6.5明天我该做什么   第6A章Crystal方法集:演进   6A.1Crystal基因代码   6A.1.1合作博弈的理念   6A.1.2方法集的重点   6A.1.3方法集设计原则   6A.1.4高度成功的项目的7个特性   6A.1.5技术与选择   6A.1.6样本方法集设计   6A.2CrystalClear   6A.3把CrystalClear扩展到Yellow   附录A敏捷软件开发宣言   附录Aa敏捷软件开发宣言和相互依赖声明   附录BNaur、Ehn、宫本武藏   附录BaNaur、Ehn、宫本武藏:演进   附录C后记   参考文献
XXX航空移动化应用平台项目 1 投标书 13 2 规格偏离表 13 3 资格证明文件 13 3.1法人营业执照(三证合一) 13 3.2法定代表人授权书 13 3.3 投标人的资信证明 13 3.4 招标文件要求的其他资格证明文件 15 3.4.1投标单位资质证书及项目人员资格证书 15 3.4.1.1 CMMI等级登记证书 15 3.4.1.2 ISO9001质量管理体系认证证书 15 3.4.1.3 软件企业认证证书 15 3.4.1.4 计算机软件著作权登记书-SDK 15 3.4.1.5计算机软件著作权登记书-MAS 15 .4.1.6计算机软件著作权登记书-MMS 16 3.4.1.7计算机软件著作权登记书-EMM 16 3.4.1.8计算机软件著作权登记书-MDM 16 3.4.1.9 项目人员证书 16 3.4.2投标单位近3年内获国家及地方政府荣誉证书 18 3.4.2.1 2015年度中国移动互联网行业领军企业奖 18 3.4.2.2 2014-2015年度云计算应用优秀实践单位奖 18 3.4.2.3 2014年度中国最具影响力品牌奖 19 3.4.2.4 2013年度最佳技术服务提供商 19 3.4.2.5 2013年度中国移动应用平台最具影响力奖 19 3.4.2.6 2014移动生产力十大优秀案例奖 19 3.4.3投标单位综合情况审查表 19 3.4.4拟派项目经理资格审查表 20 3.4.5承担本项目主要技术人员和售后服务人员表 20 3.4.6最近两年主要开发实施同类型企业相同或类似系统的开发案例 21 3.4.6.1案例合同首尾页 21 3.4.6.2 系统开发主界面截图 22 4 项目解决方案 26 4.1 项目解决方案内容 26 4.1.1 系统总体目标、设计架构、系统详细设计方案 27 4.1.1.1 设计原则 27 1. 统一设计原则 27 2. 稳定性原则 27 3. 统一设计原则 27 4. 稳定性原则 27 5. 先进性原则 27 6. 高可靠/高安全性原则 27 7. 开放性原则 28 8. 适用性原则 28 9. 可扩展性原则 28 10. 操作/维护的易用性原则 28 11. 高可靠/高安全性原则 28 4.1.1.2 架构设计 29 4.1.1.2.1. 系统架构设计 29 4.1.1.2.2. 业务系统架构设计 31 4.1.1.2.3. 业务处理架构 32 4.1.1.2.4. 网络拓扑图 33 4.1.1.3 技术路线 35 4.1.1.3.1 统一的移动构建平台 35 4.1.1.3.2 Hybrid移动开发引擎 35 4.1.1.3.3 面向服务的SOA接口集成 35 4.1.1.3.4 高并发处理机制 36 4.1.1.3.5 高效的内存数据库 36 4.1.1.3.6 兼容多种集成模式 36 4.1.1.3.7 开放式的框架设计 36 4.1.1.3.8 数据库选型 36 4.1.1.4 应用工具 37 4.1.1.4.1. 开发工具 37 4.1.1.4.2. 分析设计工具 38 4.1.1.4.3. 项目管理辅助工具 38 4.1.1.4.4. 测试工具 39 4.1.1.4.5. 统计工具 40 4.1.1.4.6. 开发语言 42 4.1.1.4.7. 辅助软件工具及其效果 44 4.1.1.5 移动平台建设方案 45 4.1.1.5.1. 移动业务整合平台(APPCAN MAS) 45 4.1.1.5.2. 移动业务开发平台(APPCAN SDK) 53 1. 音频对象API 55 2. 电话对象API 55 3. 照相机对象API 55 4. 剪贴板对象API 55 5. 日期控件API 55 6. 联系人对象API 55 7. 数据库对象API 55 8. 设备信息对象API 55 9. 下载对象API 55 10. 邮件对象API 55 11. 文件管理对象API 55 12. 图片浏览对象API 56 13. Jabber对象API 56 14. 位置服务对象API 56 15. 日志log输出对象API 56 16. 彩信对象API 56 17. 支付宝API 56 18. 二维码扫描对象API 56 19. 传感器对象API 56 20. 短信对象API 57 21. Socket对象API 57 22. 上传对象API 57 23. 视频对象API 57 24. widget对象API 57 25. 平台对象API 57 26. 多窗口机制API 57 27. 跨域访问对象API 57 28. zip压缩解压缩API 57 29. 百度广告推广接口 57 30. 百度地图接口 57 31. 百度统计接口 58 32. 数据统计分析自定义事件接口 58 33. 微博分享接口 58 34. 自定义编辑框接口 58 35. 游戏引擎接口 58 (1) 插件扩展 58 AppCan IDE 启动画面 62 AppCan IDE 代码编辑界面 63 AppCan IDE模拟器与调试器 63 AppCan IDE 本地打包界面 64 AppCan UI框架控件 65 AppCan Player示意图 66 AppCan模拟器 67 Mac Mini服务器 68 AppCan SDK套装管理后台-项目列表 69 AppCan SDK套装管理后台-项目管理 69 AppCan SDK套装管理后台-引擎升级 70 4.1.1.5.3. 移动业务管理平台(APPCAN EMM) 71 4.1.1.6 前端应用建设方案 78 4.1.1.6.1. 机票预订 78 4.1.1.6.2. 订单管理 82 4.1.1.6.3. 航班动态 86 4.1.1.6.4. XXX商店 90 4.1.1.6.5. 会员注册\登录 93 4.1.1.6.6. 常用乘机人管理 95 4.1.1.6.7. 机票验真 97 4.1.1.6.8. 促销专区 98 4.1.1.6.9. 更多服务 99 4.1.1.6.10. 主页 103 1、 功能性:主页面集成APP中所有功能模块,用户可应用功能模块快速使用需求功能。 103 2、 经济性与宣传性:通过轮播图、广告、促销信息、资讯等展示形式满足XXX航空的宣传需求与广告需求,达到增加收益的目的。 103 3、 美观性:页面设计根据XXX航空整体UI设计思想为依据进行设计,使用户一目了然具备XXX航空的代表性和与其他航空公司的差异化,在此基础上进行深入设计,如根据季节设计清爽的界面、根据时下热播电影设计主题界面等。 103 4.1.1.7 后台管理系统建设方案 104 4.1.1.6.1. 移动平台业务管理系统 105 (1) 应用趋势统计 110 4.1.1.6.2. 移动平台会员管理中心 123 4.1.1.8 非功能性方案 126 4.1.1.7.1. 跨平台解决方案 126 AppCan应用引擎构成图 126 4.1.1.7.2. 消息推送解决方案 127 4.1.1.7.3. 消息/数据可靠性和即时性解决方案 129 4.1.1.7.4. 大数据推送解决方案 129 4.1.1.7.5. 用户操作行为分析解决方案 130 HTML5中国统计分析案例图 132 4.1.1.7.6. 业务系统整合解决方案 132 4.1.1.7.7. 大并发时保证后台业务系统可用性解决方案 136 4.1.1.7.8. 性能解决方案 137 4.1.1.7.9. 接口解决方案 139 4.1.1.7.10. 易用性解决方案 139 4.1.2 软件及硬件配置方案 141 1. 硬件配置 141 2. 软件配置 142 (1) 软件安装配置 142 (2) 软件版本要求 142 4.1.3 项目开发组组成及各成员职责分配方案 144 4.1.3.1. 项目工作方法 144 4.1.3.2. 项目组织结构 145 1. 项目实施领导小组 145 2. 项目经理 146 3. SQA组 146 4. 产品设计组 146 5. UI设计组 146 6. 手机端开发组 147 7. 后台系统开发组 147 8. 测试验收组 147 9. 角色和责任 147 4.1.3.3. 关键人员简历 150 4.1.4 项目管理方案 150 4.1.4.1. 项目例会 150 4.1.4.1.1. 项目协调会 150 4.1.4.1.2. 项目启动会 150 4.1.4.1.3. 现场安装前的工程协调会 150 4.1.4.1.4. 试运行前的工程协调会 151 4.1.4.2. 工作文档评审 151 4.1.4.2.1. 设计评审时机 151 4.1.4.2.2. 设计评审的形式 152 4.1.4.2.3. 设计评审的准备 153 4.1.4.2.4. 设计评审的实施 153 4.1.4.2.5. 对发现问题的处理和跟踪措施 153 4.1.4.2.6. 质量记录的控制 154 4.1.4.3. 项目风险控制 154 4.1.4.3.1. 管理风险 154 4.1.4.3.2. 技术风险 155 4.1.4.3.3. 人员风险 155 4.1.4.4. 项目质量管理 156 5.1.4.4.1. 质量管理过程 156 5.1.4.4.2. 质量管理组织 156 SQA组需参与的关键评审工作任务表 157 4.1.4.5. 变更管理 158 4.1.4.5.1. 需求分级管理 158 4.1.4.5.2. 全生命周期变更管理 159 4.1.4.5.3. 需求变更管理原则 160 4.1.4.5.4. 需求变更应对方法 161 4.1.5 项目实施方案 163 4.1.5.1. 实施计划日程表 165 4.1.5.2. 实施计划表 166 4.1.5.3. 阶段工作及成果 168 4.1.5.4. 项目进度保障措施与办法 170 1. 定义项目成功的标准 170 2. 识别项目的驱动、约束和自由程度 171 3. 定义产品发布标准 171 4. 沟通承诺 171 5. 计划中,在质量控制活动后应该有修改工作 171 6. 为过程改进安排时间 172 7. 管理项目的风险 172 8. 根据工作计划而不是日历来作估计 172 9. 不要为人员安排超过他们80%的时间 172 10. 记录你的估算和你是如何达到估算的 173 11. 记录估算并且使用估算工具 173 12. 遵守学习曲线 173 13. 考虑意外缓冲 173 14. 录实际情况与估算情况 173 15. 只有当任务100%完成时,才认为该任务完成 174 16. 公开、公正地跟踪项目状态 174 4.1.6 质量控制、质量保证方案 175 4.1.6.1. 项目质量管理的关键 175 4.1.6.2. 本项目质量保证措施 175 4.1.6.3. IT项目质量管理的目标和质量控制 177 4.1.7 系统安全性方案 179 4.1.7.1. 安全性设计原则 179 (9) 系统对内网服务及对外网服务功能要求独立发布,并提供安全、可靠的权限控制。 179 4.1.7.2. 服务器安全 179 4.1.7.3. 移动应用安全 179 4.1.7.4. 终端认证 180 4.1.7.5. 终端授权 181 4.1.7.6. 终端证书 181 4.1.7.7. 本地安全存储 181 4.1.7.8. 数据传输安全 181 4.1.7.9. 数据库安全机制 182 4.1.7.10. 容错机制 182 4.1.7.11. 数据同步 183 4.1.7.12. 服务器集群和负载均衡 183 4.1.7.13. 防火墙 184 4.1.8 项目交付定义 185 4.1.9 项目验收方案 186 4.1.9.1. 验收方案 186 1. 验收目的 186 2. 验收对象 186 3. 项目验收的前提条件 186 (1) 所有建设项目按照合同要求全部建成,并满足使用要求; 186 4. 验收方法 187 5. 验收步骤 187 6. 验收程序 188 7. 验收依据 189 8. 验收内容和标准 190 9. 验收结论 191 10. 项目交接 192 4.1.9.2. 测试方案 193 4.1.9.2.1. 测试内容设计 193 4.1.9.2.2. 测试阶段规划 198 V模型图 198 4.1.9.2.3. 测试工作流程 201 4.1.9.2.4. 测试结果评价与测试工具 208 (1) 项目汇报文件 210 (2) 测试方案 210 4.1.9.2.5. 测试人员名单 211 4.1.10 本期项目完成交付后,技术服务计划、维护、承诺及费用 212 4.1.10.1. 概述 212 4.1.10.2. 服务内容 213 1. 咨询服务 213 2. 应用系统的故障响应 213 3. 应用系统辅助操作 213 4. 应用系统的维护服务 213 5. 交流和培训 213 6. 应用系统业务调整 214 7. 应用系统软件升级 214 4.1.10.3. 支持机构 214 1. 咨询服务组 214 2. 咨询服务专家组 214 4.1.10.4. 支持方式 215 1. 现场维护 215 2. 热线电话咨询 215 3. 咨询服务网站 215 (1) 远程登录诊断维护 215 4.1.11 人员培训计划、技术转移方案 216 4.1.11.1. 培训方案 216 4.1.11.1.1. 培训对象和内容 216 4.1.11.1.2. 培训目的 217 4.1.11.1.3. 培训原则与培训质量保证体系 218 (1) 培训的师资力量 219 4.1.11.1.4. 培训方式 220 4.1.11.1.5. 培训大纲 220 4.1.11.1.6. 培训组织及技术力量安排 222 4.1.11.1.7. 培训组织方案 223 4.1.11.2. 技术转移方案 225 4.1.12 预期系统性能状况,后续升级扩展方案和计划建议 227 4.1.12.1. 移动端响应标准 227 4.1.12.2. 系统响应标准 227 4.1.12.3. 优化办法 227 4.1.12.4. 系统批处理效率 228 4.1.12.5. 并发用户下的系统性能 228 4.1.13 其他资料 229 4.1.13.1. 典型案例 229

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值