每个人的效率不同,一般公司内部会有个大概的平均效率吧。
不知道大家是如何评估开发时间的,app 是按功能点还是转化成每人时?网站开发呢?
tiny 大你这个站点web app都有,大概开发时间如何?
先谢谢各位赐教。
客观的排时间,就要留冗余. 否则就会死得很难看. 要面对,你不是答应了多久多久 就xx的指责. 即便如此,每次仍然会有问题. 只能说做重复的事 会准确一些. 可惜设计案每次都不一样. 表面看起来 没啥区别. 要考虑每个人生老病死的特殊状况. 团队冗余度不够的情况下, 也只能尴尬的去解释时间膨胀的原因了. 以前人多的时候, 还可以做一些储备. 现在人少了,新问题新需求基本都是高风险了. 如果能不断降低所谓新需求. 时间自然是可控了.如果真是纯粹的程序代码编写,应该还好估算. 掺杂着不明确的模糊的需求和设计就很坑爹了. 那个时间完全不可控.
6楼 @stros 首先需要一个基准. 人均的产出. 其实这个都是波动的不准确的 只能是尽量而已. .. 遇到新技术的话时间会额外多. 直到确定可控之后. 最好先不在计划内. 选择稳妥的方案先做.
可以试着让团队的人做一些小的任务.作为评估. 还能做一些技术积累. 然后就知道真实的产出了. 学tiny哥给同学们高压力.
另外一个情况是, 某君之前已经做过此类业务, 那么时间基本就可以大跨度的提升了. 但是也不能大意. 细碎多了 也是耗时间的. 想定时间合理,
有一些任务光看文档不行, 得交给有经验的. 但有些就是简单些, 交给新手也没问题. 合理分工的前提就是要因人而治. 尽量给同学们分配他们喜欢的事做. 效率会高,情绪也很High. 绑到项目上的需要争取原型和前置制作的时间.尽可能把技术问题都消化在这个阶段.
等问题变成落实做成什么样的时候, 那就可控得多了. 不过没经验的另一半,经常是看了原型产品后就改主意了.. 甚至是写着需求文档时 就把前几天说的给否定了. 所以也只能接受. 要紧的是, 一旦因此产生拖延, 程序很悲催的. 很容易就成了背黑锅的. 挺恶心.
stros , 帖子详细内容,发帖,回帖,改帖。这个该如何转化?随便说哪个功能转化成多少或者多少个功能够一天。
这个我只能说我的思路.比如这个很简单(其实认为他简单就已经错了) 拿Python的web举例子. 像发帖,回帖,改贴 逻辑代码简单. 烦的是样式(模板的事) 要做到who满意? 细节需要么: 比如支持语法高亮么? gavatar头像啥的? 而且发帖的这些事是需要一个基础的. 账号系统. 可大可小. 大体上简单Article系统应该很快, 全部做完的话 1-2周一个人工作 差不多了. 但比如我不会前端. 给我再多时间也不会达到那种who 满意. 希望你明白.
根据以往的经验。因为项目中很多小的模块都是以前做过的,会比较轻松估算出时间。如果没做过,做个简单的调研,根据学习能力或者以往攻克难题的时间来估算。最后还要留一点buffer。
执行过程中,严格监管进度。如果有人落后计划了,弄清楚原因。实在实在不行就得加班了。