好的估算最重要的一点是只来自于可靠的需求定义，和确定的功能结构。

如果进度估算所需考虑的因素里包括了不确定的业务需求。功能列表，和复杂的政治因素我们就很难做出准确的预估。

1. 时间预估的准确度与需求的确定程度成正比。需求和功能列表变动风险越大。时间预估的准确度就越低。
2. 做出估算前要把自己的所有疑惑解决掉。对将要设计的功能的疑虑越多，时间预估的准确度越低。
3. 不要因为其他方面的压力，主观缩短自己的预估时间，例如政治压力，或者是项目发布时间的压力。
4. 时间预估要参考以前的合作经验。比如这个产品经理需求变动的概率有多大等等……
5. 灵活掌握时间预估中的变量，把握好时间冗余。例如：从开发需要demo的时间倒推你可能有更多的时间花在设计上，或者可以考虑应用更完善的ucd方法或流程做一些用户调研的工作。

时间估算可以参照PERT技术：

PERT全称计划评审技术（Program Evaluation and Review Techniques）。

标准公式是：（最佳估算值+4 x最可能估算值+最差估算值）/6=估算结果。

然而，对于如何计算最佳的加权估算值（weighted estimate），有不计其数的变形和理论。

有朋友向我抱怨自己的设计方案受到开发人员的质疑:“我要用新窗口的方式代替现在的弹出层方式，都已经和产品需求方达成一致了，开发说：我不接受！…………”

“不接受 ”这种态度。否定了设计师的工作价值但又不提供理由。需要设计师自己想办法证明自己方案的伟大光荣正确，说服开发来实现设计方案。虽然摆事实讲道理是一种 解决方案，但是如果项目组的每个角色在相互不信任的环境中都需要解释一下自己作出某个选择的理由。那将大大降低组织系统的执行效率。

此例中如果弹出层还是新窗口这类基础问题，都需要向每个项目成员说明理由，那么可以推断来自各方面的可能的质疑将让我们疲于应付，这就是所谓的沟通成本远远超出设计成本。严重的时候甚至会影响项目进度。有没有什么方法能规避或者是减少这种冲突呢？

首先我们分析一下此类冲突的特点：

1．冲突产生的时机，大多存在于项目从需求方向执行方推进时，冲突双方对某问题的解决有不同的看法，而这两种看法没有明显的优劣之分。彼此不能说服对方，问题的决策方不明确，这时候也最容易演变为相互说服的耗费大量时间和资源的拉锯战。

2、冲突产生的环节，角色职责交叉的中间地带和模糊地带。

怎样减少这种冲突呢？规范项目流程是一种刚性的方法，流程可以一定程度上起到明确职责分工的作用，明确各个角色对不同问题的决策优先权，但并不能清 晰的划分出每个问题的职责分界线。而这个不能明确划分界限的模糊地带又是最容易发生冲突的地方。而且流程规范也存在粒度问题，如果规范太宽松起不到规范的 作用。太严密又会僵化，繁琐的流程导致效率低下。

因此在流程规范触及不到的领域就需要另外一种规则来减少冲突，这种规则必然不是像流程规范一样的刚性规定,但又必须有一定程度的约束力。这是一种什么东西呢？是伦理，在万恶的旧社会叫“三纲五常，三从四德”。

下面我将试图证明通过伦理学方法减少冲突的可能性，为什么选择伦理学？

首先我们看一下伦理学的功能：伦理在一定程度上起到了调节社会成员之间相互关系的规则的作用，类似于约定俗成的交通秩序，引申为人在社会上为人处世 的规则。它试图从理论层面建构一种指导行为的法则体系，即“我们应该怎样处理此类处境”，“我们为什么/依据什么这样处理”。并且对其进行严格的评判。

伦理这种“约定俗称”和“指导法则”的感性特征使他可以渗透到流程规范触及不到的模糊地带。他的出发点就是调节成员间的相互关系，而且它通过公众评判产生约束力（例如贞节牌坊）。因此它有可能为我们解决冲突提供一种思路。

当然我不可能像先贤们那样写道德经，只能通过自己的项目合作经验，提炼一些浅薄的观点，欢迎拍砖。

“尊重”是目前我能想到的最重要的一条项目开发伦理。下面我将尝试向大家解释尊重伦理的合理性和形成这种伦理的一些必要条件。

为什么要建立尊重伦理？

在某项目中，设计师对产品经理的产品方向提出质疑认为功能设计不合理，并通过用户调研手段发掘出了真正的用户需求。但产品最终并没有体现这些需求，设计师是应该 “点到即止”还是为了用户的利益 “奋起反抗”。

根据尊重原则，我们应该选择第一种做法。

因为一旦我们为了满足某些用户需求质疑产品经理在产品方向上的决策权，就会破坏尊重职业分工的伦理，在这种伦理被破坏的情况下每个项目成员的决策就都有可能受到其他项目组成员的反复质疑。系统的整体执行效率必然大打折扣。

反之，如果我们尊重产品经理的最终决策权（虽然不一定信服），虽然这个产品不能满足一部分用户需求。但是尊重伦理保证了系统的执行效率。单个产品的成败，和系统的整体强健高效相比显得微不足道。

那是不是意味着尊重伦理的这种“容错”特性会纵容系统产出低质量产品呢？

从上面提到的例子来看：

产品经理的能力问题仍然要靠产品经理所属的组织系统去解决，进化或淘汰的力量均源于产品经理自身的组织。其它角色出于专业的局限性，无法对该角色进行有效的教育和促进。并且职责分明的情况下，产品一旦出现问题，系统也能迅速识别薄弱环节进行调整。

尊重伦理在团队中如何形成？

一方面 要求角色有能力证明自身决策的权威性和正确性

其实很多质疑者的质疑习惯源于以往的质疑成果的激励。质疑者大多在之前有过成功质疑的经验，并且认为自己的质疑使产品更加完善。这种成功质疑的对象 必然是那些没有能力证明自己决策的正确性和必然性的不成熟的角色。如果质疑者的每次质疑都被成功说服。那她的质疑习惯就会被尊重习惯和信任习惯所取代。

对与设计师来说，就是自己的每一个设计决策都要禁得起质疑。能在每一次受到质疑的时候给出充足的理由。在经过多次合作后，其他成员自然会建立起对你 的信任和尊重。质疑声会逐渐消失。最理想的情况是设计团队的大多数成员都具有这种能力，那整个部门都将收到足够的尊重，即使是部门中少数不成熟的成员（这 里的不成熟是沟通能力，不是指设计能力）也可以享受这种尊重成果并尽快成熟起来。

另一方面：依靠所有成员对尊重伦理的认同。

所有伦理的产生都源于，利他利己原则，利他是为了利己。就像红灯的时候让别人先走。是为了自己在绿灯的时候不会受阻一样。尊重伦理也是同样的原理，通过案例教育使成员认识到尊重原则的重要性，尊重别人是为了让自己的决策更受尊重。

尊重伦理的基础：

相互尊重建立在职责分明的基础上，只有在职责分明的情况下才能识别哪个角色拥有优先决策权。如果角色之间存在职责模糊的地带，就需要遵循能力尊重原 则，设计师深入理解用户行为的能力使他对产品细节有优先决策权。产品经理对市场的把握能力，使他在产品方向上有优先决策权。如果职责分工模糊，设计师参与 产品策略，开发参与产品设计。不但会影响适当的人作出正确的决策，当产品出问题时，系统也无法识别出错环节，不利于系统的进化。

什么时候可以突破尊重伦理（推倒贞洁牌坊）？？

虽然贞节牌坊制造了“和谐”的社会风气，但也束缚了广大妇女同志追求性福的脚步。严重的甚至有可能对“偷情”的小寡妇造成人身伤害，因此有必要的时 候我们必须要推翻它，以我们的“快速拍”产品为例。产品经理主观上希望通过降低新用户的注册门槛，来增加购买成功率，但经调查发现，大部分用户在支付宝付 款阶段依然无法越过门槛，而且技术实现上，系统不允许用户以非会员的身份购买宝贝……。这种情况下，所谓的快速拍就快不起来，而且有可能在购物关键流程上 使迷惑用户（因为快速拍界面根据cookie判断是否出现，因此可能会时有时无）我们就要尽力屏蔽这种需求。

由于对伦理学的方法,以及从设计师的角度来考虑整个项目开发的伦理具有一定的局限性，所以希望大家对我的看法多提批评和意见。也希望大家能提供其他自己认为重要的开发伦理。

第一步：明确目标
前期准备工作：
    1. 目的：为什么要进行沟通？有没有必要沟通？
   2. 对象：与谁沟通
   3. 时间：具体沟通时间，时长
   4. 标准：希望了解到什么，期待得到什么结果
   5. 资源：有哪些资源，有哪些条件。

第二步：假设归类
主要求对任务进行问题分解沟通
    1. 充分沟通，不断的进行提问和回答来穷尽问题
    2. 通过问题不断进行归类，突出问题重点。
注：好记性不如烂笔头。

第三步：明晰关键
主要是找到关健问题，并对问题的根源进行深入分析
    几个原则
    1. 抓住问题的关健
    2. 重点突出VS面面俱到
   3. 断其一指VS伤其十指
   4. 以目标问题为主纬度，要综合考虑其它方面
   5. 可以用不断试错的判断来分析