标签：http 使用 strong art 问题 html 工作 ar
1. 自上向下式
这种方式是指，从项目的整体时间或者重大的里程碑来倒推各项子任务时间，用各项子任务的完成来支撑整个项目的整理时间。这种方式适用于，对项目完成时间要求很严格的项目，项目团队从结束时间开始倒退，划分重要的大里程碑时间，再在大里程碑中，划分小里程碑，任务包，小任务包。最底层的任务越小，估算越准确。
这种方式可能存在的问题是，如果老板说了这个项目6月1日要完成，但是说到小任务算下来，发现根本不够时间完成。做为项目经理的你打算怎么办？后面的故事应该会对你有所启发。
请记住这个时候千万不要想着去以次充好，蒙混过关，更不要企图压迫项目成员加班或者拼命，如果那样这个项目就已经输在起跑线上了。
2. 自下向上式
自下向上式与自上向下刚好相反，是指项目团队确定要完成的子工作包和工作包，先完成什么功能，然后完成什么功能，最后汇总确定里程碑的方式来安排日程。
这种方式看似时间比较宽松，但是实际上还是依赖于开发团队的工作经验，如果有工作包有遗漏或者估算不准，还是会导致项目时间安排不准。而且这种方式挺挑战项目经理的能力，为什么呢？如果你缺少相关的经验，原本一个5天就可以完成活，你的技术成员分析出来要10天，少了就干不了。你究竟决定为这个工作包准备几天呢？
3. 由内及外式
一种类似于头脑风暴的日程安排方式。操作起来很简单，项目组在一起用头脑风暴或者思维导图的方式，把与项目的所有的相关东西都放进去。大家分析出功能难易，时间长短，检验方法，再归纳出顺序和监控点，里程碑。
这个方式有一个关键，那就是整个项目组的全部成员，最好都要加入，只有这样才能确保，所有工作都不会被遗失，所有的分析面面俱到。但是这也是这种方式的局限性，在小项目中，这种方式可能比较可行，但是如果是一个非常大的项目，你打算一群人讨论三天三夜？而且讨论的时候，不可能涉及的每一个问题都是所有人成员、所有项目角色都关心的，况且每个人也不是100%的集中注意力在为你献计献策。
4. 哈德逊湾式
“哈德逊湾式启动”方式源自17世纪加拿大东北部的哈德逊湾公司。这家公司配备了运送皮毛的商船。为了确保商船不会忘记需要的东西，他们会在距离哈德逊湾几英里的地方先临时停留一段时间。由于离海湾并不远，商船可以确保他们不会忘记任何工具和给养——在离开文明世界进入茫茫大海之前。使用这样一种启动旅程的短时间方式，他们能明确知道自己能否可以安然过冬。
设想你所管理的项目对于你和团队来说，完全是从未经历过的。你也不知道所在的环境是不是支持可用的工具，从何入手估算项目工作也毫无头绪。不妨考虑使用短期迭代来开始工作，比如“哈德逊湾式启动（Hudson Bay Start）”。“哈德逊湾式启动”技术可以让项目团队先尝试在项目的实际环境中开展某些工作。项目经理应尽量缩短这个过程。（“Hello World”程序也许就够用了。）关键是要让团队了解到，在当前项目产品所在的领域中实际工作会是怎样的状况。
这种方式给人的感觉，就像眼前一片空白时，先尝试，走出几小步，然后体会一下，感觉一下，总结一下得失，再大踏步前进。挺像投石问路一说。这种方式，可以避免团队在错误方向上，越跑越远。还可以帮助团队简历自信。更重要的事，在一无所知的情况下，整个团队有了一些常尝试和更加深刻的理解，有利于推动项目的下一步进行。可以跟前面的方式结合一起使用。
5.短期迭代式
如果有人觉得，哈德逊湾式方式很保险，想在项目中一直循环的的时用这种方式，摸着石头过河，那么你的方式就叫短期迭代式了。
这种方式适合高研究型项目，高科技含量的项目，试想一般在老板等着出产品赚钱的情况下，项目经理上刀山，下火海都要冲，哪有时间等着你摸着石头慢慢迭代啊？所以这种方式适合高风险，高投入，高回报的三高项目。而且要求投资入性格好，脾气好，眼光好。而且实际操作时，迭代周期要短，能短期看到一些成效，还要特别注意迭代的总结和review，每次迭代都要有对项目产品，更深刻的理解，然后在迭代中不停的修正方向。
网络案例分享：给我一块石头
克里夫与团队一起，用一周时间制订出了项目日程。他们完成了"哈德逊湾式启动"，并且确定已经识别出了主要的技术风险。他将风险和日程安排告诉了他的上司诺姆。"你就不能再早点完成项目了么？"诺姆的一句话将克里夫送回了团队，步履蹒跚。克里夫与团队又花了一周时间修改时间表，得到另外一个日期。他走进诺姆的办公室，说道："如果你能在这里和这里为我提供更多的人手"，他指着几个里程碑，"我就能用一个月时间完成项目。"诺姆皱着眉头说道："还不够好。我需要这个项目早点儿结束。"克里夫叹了口气，又回到项目团队中去了。又过了一周，克里夫拿着另一个日程来找诺姆，"好吧，这就是我们力所能及的结果了"，克里夫说。诺姆几乎连看都没看，就说道："但是还是不够好。"
克里夫暴怒道："你到底想要什么？"
"给我一块石头"，这就是诺姆玩的游戏。不管你制订出什么样的日程，你的出资人总是希望项目能更早完成。你只会发现：出资人对你提出来的每一个截止日期都不会认同——你的日期总是离他们的期望值很遥远。当"他们"希望项目能更快交付，但是不告诉你何时需要或为什么的时候，就会玩"给我一块石头"游戏。如果他们告诉你期望截止日期，你就能告诉他们能完成哪些工作。如果他们告诉你原因，你和团队也许就能想出一些创造性的解决方案来满足他们的要求。讲求实效的项目经理自有应对之策，其中就有克里夫采取的谈判策略。可一旦谈判失败，或者看起来永远难以成功，不妨试试下面的方式。在试图取更多石头之前，先提几个问题：你喜欢短的日程，还是长的日程？是要更多的人，还是更少的人？要是少实现几个功能会如何？先知道什么是最重要的，这会帮项目经理产生更加合理的解决方案，多少也能为你的谈判做些准备。找出是什么原因促成了他们期望的截止日期。探寻出这个项目的战略原因，并搞清楚"成功"的真正含义。要让出资人明白你做出的选择以及背后的原因。也许出资人会有更容易操作、更快实现的好主意。为你提供的日期说明信心范围。很可能管理层不明白你的估算意味着什么，而且你也有可能不理解他们所要的东西。在提供日期时要说明发布条件，这样你就可以提一些问题，了解他们对于发布版本的质量和功能的要求。我们可以让这个功能的性能极其出色，但是就得先放下那个功能，这样做可以么？用户们可以接受带有更多缺陷的产品么？
在一个组织中，"给我一块石头"会反复发生。很多时候，每个项目都会发生这种状况。如果你总是碰到"给我一块石头"的问题，考虑采用下面的实践：
制订排好优先级的产品代办事项列表。逐个实现功能。如果能够让出资人了解更多的项目进程，他们就不会那么纠缠截止日期了。使用短小的时间盒（持续时间少于四周），这样出资人就可以看清项目进程。如果你每隔几周就能展示出项目的有价值的进展，截止日期就没那么重要了。你可以开始讨论何时实现哪个功能，他们对质量的要求又是什么。
即使项目经理自己努力做好估算、规划和日程安排工作，你遇到的出资人、管理层和团队成员还是有可能视日程安排为儿戏。项目经理要把这些人带回现实，不过首先要学会识别这些日程安排游戏。所有的出资人和管理层都会逼你在日程安排上做出一些让步。即使你制定的项目日程已经相当合理了，他们还是会玩这样的游戏。不过他们抗拒的方式很容易识别，很少脱离几种固定的模式。项目经理只要能够识别出他们所玩的游戏，就可以更容易地掌控项目，得到理所应当的产出。
项目经理的磨练（2） 科学的安排项目日程安排,布布扣,bubuko.com
标签：http 使用 strong art 问题 html 工作 ar
原文地址：http://www.cnblogs.com/root-wang/p/3873288.html
