如果是平台开发的话，基本上都是拍脑袋，因为需求随时可能变、架构完全是摸索、大坑完全不可知。

如果是应用开发的话，出了概要需求之后，简单估一个时间，然后X2或者X3。

【 在 xeagle (静下心来编程) 的大作中提到: 】
: 标  题: 开发之前你们都是怎么预估开发时间的?
: 发信站: 水木社区 (Mon Aug 30 18:18:22 2021), 站内
:
: 开发之前产品经理要每个功能的具体开发时间. 你们都是用什么方法估计的, 还是直接拍脑袋?
: 如果这个模块我不太熟悉, 感觉很难给出个时间. 即使模块熟悉, 如果功能复杂的话, 也无法给出个准确的估计, 只能拍脑袋随便说一个.
:
: 看一本书上给出的估计方法貌似比较科学, 比如3天完成的概率是80%, 6天完成的概率是20%. 但这么跟产品经理报时间的话, 估计人家不干.
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 123.125.37.*]
--
FROM 123.103.9.*

有很多办法，比如敏捷是一种，瀑布是一种，但总归要把大任务拆解成子任务
拆解之后还可以用乐观、悲观、最可能时间去估算
另外还可以试着用用wbs、甘特图之类的工具，可以去分析项目之间的依赖等

【 在 xeagle (静下心来编程) 的大作中提到: 】
: 开发之前产品经理要每个功能的具体开发时间. 你们都是用什么方法估计的, 还是直接拍脑袋?
: 如果这个模块我不太熟悉, 感觉很难给出个时间. 即使模块熟悉, 如果功能复杂的话, 也无法给出个准确的估计, 只能拍脑袋随便说一个.
: 看一本书上给出的估计方法貌似比较科学, 比如3天完成的概率是80%, 6天完成的概率是20%. 但这么跟产品经理报时间的话, 估计人家不干.
: ...................
--
FROM 103.107.216.233

【 在 liu487639 的大作中提到: 】
: 老司机了，也比较专业。
: 最主要的是拆解，拆解成每个能把控的子任务，再留一定的时间用于自测、code review以及部署时间，*2 *10太扯了，自己作为技术人员不臊嘛


说到点了，没拆解清楚估算个球啊，先把不掌握的技术尽量都搞明白分析清楚再估，否则不叫估算，叫虾它马顺嘴胡勒勒，要么给自己挖坑，要么给公司挖坑。

如果没拆解清楚*2也是常见的，*10也完全有可能发生。
--
FROM 123.127.240.*

先做一两天，然后估算个时间，乘3报上去。

【 在 xeagle 的大作中提到: 】
: 开发之前产品经理要每个功能的具体开发时间. 你们都是用什么方法估计的, 还是直接拍脑袋?
: 如果这个模块我不太熟悉, 感觉很难给出个时间. 即使模块熟悉, 如果功能复杂的话, 也无法给出个准确的估计, 只能拍脑袋随便说一个.
: 看一本书上给出的估计方法貌似比较科学, 比如3天完成的概率是80%, 6天完成的概率是20%. 但这么跟产品经理报时间的话, 估计人家不干.
--
FROM 27.154.195.*

现在都互联网百万年薪了，怎么还在用这种古老瀑布模型不用敏捷开发？

【 在 xeagle 的大作中提到: 】
: 开发之前产品经理要每个功能的具体开发时间. 你们都是用什么方法估计的, 还是直接拍脑袋?
: 如果这个模块我不太熟悉, 感觉很难给出个时间. 即使模块熟悉, 如果功能复杂的话, 也无法给出个准确的估计, 只能拍脑袋随便说一个.
: 看一本书上给出的估计方法貌似比较科学, 比如3天完成的概率是80%, 6天完成的概率是20%. 但这么跟产品经理报时间的话, 估计人家不干.
--
FROM 49.185.17.*