任务的分解与程序员自身价值提升是否是浪费时间

最近做项目的小感悟--

任务本身按照熟悉度分为:
熟悉领域 :
    增删改查列表 这种东西时间基本是线性的,因为有东西可以参考,特别是后台的相关东西, 多张表的关联查询 js树状展现 这种有点曲折的可能多耗点时间,但还是可控
特点:完全可控,适合新人来做 

较熟悉领域:
    前端的业务拆分   考虑一些性能的问题 特殊展现效果 需要使用一些新的技术,但是难度较小,有很多人用到过,只需要查询相关资料就能用起来
特点:
时间不稳定 但可以给出最差解决时间 只要在最糟糕的解决时间前解决就ok  时间浪费存在


不熟悉领域:
    资料全是E文,又没有大量的实践资料可以查阅,完全自己干,难度较大
特点:
时间不可控,跟踪检测粒度调整大(五天时间四天的积累最后一天解决问题) 风险比较高


程序员自身发展的问题:
    完成任务过程中会举一反三的去查找一些资料,用不到但作为提升来说是很好的,虽然会时间损耗,但是从项目整体考虑
整个过程虽然比最佳完成时间多了一些,但是解决问题的能力也提升了, 最终反映一定的积累后解决类似问题的速度也有大的提升 从整个项目周期来说是值得的

    程序员满意度也有一定的提升,感觉到能学到东西,至于说学到手就跳槽了,这个没学到东西的人也会跳,他任务你这学不到东西,如果能力跟工资不匹配了,调整工资本身也是应该的

任务分解
    需要机能：知识体系梳理
              逻辑思维的清晰
              作业背景的熟知
              表达的简洁透彻

    带来的好处：作为作业风险，问题量化监管的前提。
                作业分解并分类，比较容易屏蔽作业内容频繁切换的情况发生。
                支持作业进度量化管理

程序员自我素质提升
    素质提升属于综合话题，并不是仅围绕技术。
    组员的素质提升能提高团队的运作。

    你培养了你的组员，能营造一个成长的环境本来就成功了。
    不该考虑你的合作者的去留，如果合作者的离开能获得更大价值，你应该祝福他。

    如果你的组员都十分优秀，那么这个团队肯定不长远了，月满则亏。
    一个聪明 + 九个傻子才能成功。
    聪明人多了，团队就缺少了包容。