首先这和你熬夜加班没有半毛线关系, 千万别自己感动自己.

但凡是互联网项目, 出现延期是常有的事情.

项目延期之后, 一般流程是领导开会, 大家讨论, 新一任背锅侠, 然后下一次还是老样子.

项目评审

项目初期, 评审是最重要的一个环节.

这个需求能不能做, 那个需求要怎么改, 最后给到手的任务预估一个开发时间.

初入开发的小白, 最好有同事帮衬点, 做不到的需求千万别接, 不然整个项目都要卡壳.

需求改不改关系不大, 有的实现方式很简单, 查一查资料就能快速上手, 有的实现很复杂, 没有谁会给你几天时间开发一个无关紧要的功能, 不如直接砍掉, 或者换一种简单的, 免得费心费力还不讨好.

最难的就是估算开发时间, 哪怕是一个有多年经验的老鸟, 也不敢说估算的很准, 不准确就意味着可能延期, 没有奖金还扣绩效.

所以尽可能的多估算一点时间, 因为老总和领导并不太在意你的开发难易程度, 他们只要结果顺利, 其他的自行想办法.

有时候, 感觉评审就像是讨价还价的菜市场, 刚刚手撕产品, 又得单挑Boss, 实在是弄得心力交瘁.

这个时候你别来提时间管理, 老板是看市场行情, 不是看工作卖力.

指定要在某个节日上线, 假如留给你的时间只有一个月, 实际项目开发要二个月以上.

评审的时候, 你按最低最低的时间甚至预计自己加班后的最低时间估算, 要二个月, 中间不生病, 不请假等等.

老板总会觉得这个模块不值得你估算的这个时间, 这边砍几天, 那边砍几天, 非要砍砍才满意.

若是砍不到节前一个月的时间, 口头上会临时加派人手, 实际上每个项目都会有临时需求, 别的都差人, 哪来的给你用.

改需求

刚刚评审完敲定了项目流程开发时间, 出了会议室还没有回到座位, 新的需求就来了.

本来时间就一半当成两半花, 结果左一个新需求, 右一个新需求, 三天一个大需求, 一天几个小需求, 搞得好像需求不需要时间似的.

没办法, 产品,Boss一家亲, 小小员工没有拒绝的权利.

如果说 Boss 定的时间, 你加班, 熬夜, 周末也不休息, 努力赶一赶工期, 只要和预期差别不是很大, 一般没什么问题, 最多就是没有加班费, 身体快挂了一样的累.

那产品需求就是枪林弹雨, 不定时的炸弹, 任你再多的时间都直接被打成筛子, 一个炸弹就让整个项目可能挂掉重来, 这种事情并不是没有过.

要知道, 改代码往往比新功能开发至少多花费几倍以上的时间, 越改越多 bug, 看似一个芝麻小的需求, 很可能就需要推倒整个模块.

人人都是产品经理, 可试问, 有几个产品懂技术?

那种 app 识别手机壳颜色的操作不在文章讨论范围 ……

开发联调

时间可以预估, 需求可以砍掉, 但是人才是最不稳定的因素.

产品 /UI和前端, 前端和后端, 前后端和测试, 就拿前端来说, 几乎和每个环节都要打交道.

一个项目由不同的人开发不同的模块, 开发过程中需要不断的沟通和协调, 才能顺利进行下去.

谁先谁后, 或者同步进行, 都有规律可循, 一旦中间环节掉链子, 空有大把的时间也只能卡壳.

正式开发的时候大家时间都很紧张, 能够愿意腾出时间沟通, 算是性格比较好, 技术品过得去的.

最常见的问题是

• API改了字段或者增删了接口, 既没有及时通知别人, 也不修改文档, 让别人莫名其妙的排查, 最终定位到他的时候, 才懒洋洋的说知道了.
• 测试包一直等待打包, 确实是人忙不过来, 还要一个一个手动打包, 或者有时候忘了, 等过一段时间问起, 才想起来, 又或者其他的, 优先级问题

记得有一次, 测试在禅道上提出一个 bug, 没有截图, 说明也很极简, 并不能很好的表达出问题所在.(注: 自己刚入公司)

这边尝试复现, 定位问题和排查, 因为流程复杂, 操作一遍需要一定长的时间, 最后去问测试的时候, 对方直接扔来一句 ” 你不会自己去看啊 ”.

流程里就规定要注明机型, 场景, 尽量有截图, 视频, 总有人不按规定, 这个 bug 定位只有他手上的测试机机型才有这个现象, 而他知道却没说明.

要明白, 主动过去不是意味着求帮助, 而是花费自己的时间尝试去和对方友好沟通, 去之前就完整的排查了一遍, 要是文案详细, 也没必要找测试.

类似于这种人, 工作不负责, 沟通不友好, 说不定还是个老油条, 对上面客气, 上面不动他, 对新人和同事不友好, 你不喜欢他也对他没什么影响, 活还是要继续干.

所以这种人, 建议直接拉入黑名单, 公事公办, 之后的 bug, 但凡不明确的一律踢回去.

虽然公司会议上和项目群里一直说后台 API 要自测, 测试反馈要详细, 其他怎样怎样, 可长期还是老样子, 这其实和一个公司的团队氛围, 管理能力, 息息相关.

人在职场, 除了本职能力以外, 最重要的就是沟通能力, 自己的沟通能力要强, 可别人愿不愿意配合就是另外一回事了.

技术问题

一个 bug 卡半天的也不是没有.

个人的技术能力也决定了开发效率, 只能说技术可以自我提升, 但是上面的种种非人力可以干扰.

其次加班的效率并不高, 常常三个小时不抵白天的半个小时, 而且一般都是解决一些临时需求和伪需求.

技术本身说难也不难, 说简单也不简单, 区别在于花多少时间学, 用什么方法学, 有没有兴趣之类.

技术是一个软实力, 无法可视化, 无法短时间提升, 也是一个综合能力, 不一定和本职技术有关.

开发效率往往可以从一些软件, 插件, 硬件, 工具, 方法和技巧上来做提升, 短时间几倍十几倍的提升.

如何提升工作效率, 是一个开发人员长时间要去思考的问题, 尤其是经常加班的前提下.