第一次发非技术类的博客，最近对自己的工作中遇到的问题有一些思考，虽然都是蹩脚的文笔，但还是记录一下提醒自己，应该也没人会看。
吃一堑，长一智。
- 预留思考时间：根据任务的复杂程度，预留时间思考周期
- 新任务（未接触过）：思考时间0.5天-1天，快速调研、商讨任务时间周期；
- 旧任务（接触过）：思考0.5天，如需当场答复，周期应该在"预期时间上乘2倍"。
- 原因是任务永远比你想象的要麻烦得多，除非把多方面因素都考虑得到。
- 接到任务时需考虑什么？
- 是什么：
- 【目标是什么】任务的目标是什么，需要达到什么程度，什么预期？
- 【方法是什么】是否有现成的工具或现成的流程可借用？
- 【框架是什么】任务的思路框架是什么，不同阶段要做什么？
- 为什么：
- 【为什么要做】为什么做该任务，从公司利益上是否为绩效考核内容？
- 【为什么可做】该任务是否可给自己带来一些锻炼或/和能力提升？
- 【为什么能做】根据目前状况判断该任务是否可以承担，是否需要更多时间或者人员？
- 怎么做：
- 【多沟通】沟通时别人的一些建议要自己分辨，一些建议性的方法有的可行有的不可行。
- 【多阅读】多从相关的官方网站或权威的文献中找到问题解决办法
- 【多思考】拿到任务后，从多方面思考任务执行的框架、影响因素、提出质疑等
摘抄一篇公众号推文：《为什么实际开发时间总比估算的多很多？》
如何估计开发时间取决于你所参与的项目的规模，比如是一个小型项目、中型项目还是一个大型项目，或者仅仅是一个项目的某一部分。
-
估计小型项目的开发时间
- 根据定义，一个小型项目是一个软件工程师可以单独完成的项目。对项目进度的主要影响是这个软件工程师的能力和生产力。
- 人们在估计小型项目的进度时最常犯的一个最大的错误是，他们会把子任务的时间加到进度表中，而忘记了会议、电话、电子邮件和其他管理任务的时间。
- 忘记增加测试时间，以及发现和修复缺陷（和重新测试）的时间。
- 因为很难估计软件中存在多少缺陷，以及解决这些缺陷需要多少时间，所以大多数管理人员会将进度表中第一次估计的值扩大2~4倍。
-
估计中型项目和大型项目的开发时间
- 第一种估计大型项目进度的方法，是将其分解为一堆较小的项目，然后估计每个子项目的开发进度，再合并（汇总）起来进行总体估计。
- 这种估计方式会带来很多问题。第一个问题是，中型项目和大型项目会存在小型项目中不存在的问题。
- 估计中型项目和大型项目的进度会包括4个任务，即把项目分解成多个较小的项目，估计这些小项目的进度，增加集成测试和调试的时间（也就是让各个小项目结合到一起并且正常工作的时间），然后通过一个乘数因子得到最终的合计结果。
-
估计开发时间的问题：
- 该项目是在研发项目，通常没有办法预测研究阶段需要多长时间。
- 管理层已经预先制定了时间表。
- 这个团队以前做过类似的事情。
- 没有足够的时间和资金。
- 程序员会夸大他们的效率。
- 进度取决于额外的时间。
- 工程师就像搭积木一样。
- 对子项目的估计是不准确的。