精华内容
下载资源
问答
  • 上阶段工作回顾
    千次阅读
    2020-07-21 12:01:24

    在结束项目时,项目经理需要回顾项目管理计划,确保所有项目工作都已完成以及项目目标均已实现。

    一、项目或阶段行政收尾所需的必要活动包括(但不限于):

    1. 为达到阶段或项目的完工或退出标准所必须的行动和活动,例如:

    2. 确保所有文件和可交付成果都已是最新版本,且所有问题都已得到解决;

    3. 确认可交付成果已交付给客户并已获得客户的正式验收;

    4. 确保所有成本都已记入项目成本账;

    5. 关闭项目账户;

    6. 重新分配人员;

    7. 处理多余的项目材料;

    8. 重新分配项目设施、设备和其他资源;

    9. 根据组织政策编制详尽的最终项目报告。

    二、为关闭项目合同协议或项目阶段合同协议所必须开展的活动,例如

    1. 确认卖方的工作已通过正式验收;

    2. 最终处置未决索赔;

    3. 更新记录以反映最后的结果;

    4. 存档相关信息供未来使用。

    三、为完成下列工作所必须开展的活动:

    1. 收集项目或阶段记录;

    2. 审计项目成败;

    3. 管理知识分享和传递;

    4. 总结经验教训;

    5. 存档项目信息以供组织未来使用。

    三、为向下一个阶段,或者向生产和(或)运营部门移交项目的产品、服务或成果所必须开展的行动和活动。
    四、收集关于改进或更新组织政策和程序的建议,并将它们发送给相应的组织部门。
    五、测量相关方的满意程度。
    如果项目在完工前就提前终止,结束项目或阶段过程还需要制定程序,来调查和记录提前终止的原因。为了实现上述目的,项目经理应该引导所有合适的相关方参与本过程。
     

     

    例: 在项目收尾时最后应该做的是?

    A、 完成经验总结

    B、 提供给客户所有相关的文档

    C、 更新档案

    D、 解散团队

    答案:D

    解析:本题中,四个选项都是项目收尾时应该做的工作,顺序是:B、A、C、D

    更多相关内容
  • 金融类的APP我们主要是突出理财产品作为主要的手段然后就是各类的理财项目的推荐根据具体的需求以及功能进行从到下的排列与组合这期我们主要教导如何制作banner以及金融界面的具体排版与分布;金融界面的二级界面...
  • 2020年8月17日医保谈判工作正式启动,2020年的国家医保目录调整全过程分为准备阶段、申报 阶段、专家评审、谈判和竞价、公布结果5个阶段。截至到2020年12月16日谈判和竞价阶段结束, 预示着今年谈判已经进入尾声。...
  • A:准备环节: 团队在回顾会前一天的站会上选出1名回顾...无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。 ...

    https://mp.weixin.qq.com/s/WNK6oKKdvo8a0pmjPlskxA

    A:准备环节:

     

    团队在回顾会前一天的站会上选出1名回顾会引导人,通常是轮流,团队初期由教练来进行引导。

     

    引导者准备道具和数据资料。

     

    B:开始

     

    一:宣读宗旨

     

    引导者宣读敏捷回顾会最高宗旨,团队自由选择跟读。

     

    如下:

    无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。

     

    我的观点:

    非常有必要且充满能量的一个环节,注意用标准的普通话,饱含坚定的意志去宣读这句话。可怕的是,这种能量可以传染,快速的复制到每个人的身上,这种仪式感可以让大家迅速进入状态。

     

    二:改进成果回顾

     

    对上个迭代制定的改进措施执行情况及取得的成果进行评价(匿名1-5分)

    引导者:“请大家对上一个迭代的回顾会所制定改进措施的执行情况进行评价,这是问卷网匿名评价,请大家扫码提交评价。”出示二维码。

     

    打分选项如下:

        1:好像没做什么改进

        2:有改进,但有较多不足

        3:改进措施对我的工作有帮助

        4:我在改进中受益,我认为改进有效

        5:我们明显受益,我会持续守护我们的改进成果

     

    展示评价结果平均分。并邀请大家进行1分钟发言,阐述自己的看法。

     

    我的观点:

    让大家对于上次迭代的改进情况进行一次主观的评价,检视一下上次的改进成果是否深入人心,承前启后。

     

    这个检视有两层含义:

     

    1:回忆一下我们都改进了些什么,大家看下我们都是怎么看待上次的改进,大家一起照照镜子,这次我们要如何做的更好?

    2:每个人的角度不同,也许自己从改进中受益,但却伤害了他人,集体的视角往往更加全面

     

    三:看图说话

     

    引导者同屏展示如下几个图,或者发到群里,团队自己看。

     

        1:燃尽图

     

     

     

     

        作为一个懒人,我就不解释什么是“燃尽图”了,不明白的小伙伴可以自行百度,GOOGLE,BING。我们有2个燃尽指标,1个是PBI,达到DOD。1个是SBI,达到DOD。但凡达到DOD大家就可以在看板上移动它。

     

     

        2:情绪彩虹

     

     

      “情绪彩虹”这个名字是我起的,源自于“情绪曲线”,“情绪测震仪”。玩法有点有区别。我来跟大家说道说道。

     

    首先,团队的每个人都会领取一只颜色别致彰显自己个性的白板笔,颜色自选,先来后到。

     

    然后,看板上找一块区域,纵轴标记出笑脸,一般,生气,3个表情,横轴标记迭代的天数。每天站会结束时,大家用自己的水笔,在看板上画出能体现出你此刻感觉的图形或者打点,此时不连线。

     

    如果遇到有事件影响了你,绿色代表技术类事件,黄色代表组织类事件,红色代表个人事件,撕下小报事贴,写上并贴在当天情绪点的最上方区域。变化并不可怕,可怕的是无视这些变化,把所有团队认为有影响的事情记录下来,会发现很多惊喜以及被忽略的一些重要事物之间的联系。

     

    最后,回顾会前,大家清理看板的时候,用标志自己颜色的水笔将自己画的图案连成一条线。

     

    团队连完线,远远看去,是不是感觉像大家一起画出一道属于团队的靓丽彩虹呢?

     

     

        3:团队时间表

     

     

    团队时间表,用来分析大家时间都花去了哪里,哪些地方坑,哪些地方比预想的情况要好,在回顾会之前,引导者会组织大家花几分钟时间清理看板,将看板上的报事贴撕下来进行整理,并形成这种可视数据,这样做可以尽可能的客观的了解每天时间的使用情况。

     

    这种时间数据建议按照事项或者工作项来统计,如果团队自组织不是很完善,千万不要统计到个人头上,避免内耗,大家需要时刻意识到我们是一个整体。

     

        4:缺陷趋势+看板自留地

     

     

    缺陷趋势用来警示团队,质量是我们的生命线。

     

    自留地可以有任何团队想要表达的内容,包括遗留问题等。

     

    上面左图所示是尚未上线前的某段时间缺陷的情况,统计的是导致集成构建失败以及自动化测试完成,进入手工测试阶段以后所发现的缺陷。右图是上线后近期一次回顾会展示的自留地。大家把生产问题支持所花费的时间,修改BUG,新增商户等需要消耗团队资源支撑的事情也做了记录。

     

    我告诉大家,这些时间趋势如果每个迭代在逐步变少,那么我们的债务就越少。如果在变大,那么我们的债务和利息就越多,大家自己看着办。

     

    5:用户评审感受

     

     

    用户评审感受纵轴是打分标准,横轴是迭代次数。

     

    在评审会的时候,用户给本次迭代评审展示的成果进行打分。迭代计划会的时候,我们会和最终用户爸爸/PO一起确认迭代计划。迭代结束时,团队会给用户爸爸展示我们迭代的成果,有时候是开发人员演示,有时候是测试人员演示,用户爸爸如果在现场,我们还会邀请用户爸爸现场体验新功能,演示结束之后,我们邀请用户爸爸给我们匿名(用户爸爸有可能是多人)打分。

     

    以下是评分标准

    1:真烂

    2:无言以对

    3:凑合

    4:满意

    5:特别棒

     

    (小贴士:正式功能上线之后,也可以参考此方法让用户对正式功能进行打分,我们现在有在做这样的实践,发现效果不错,用户的反馈持续变好,团队更加有信心)

     

    引导者将以上几个图展示完之后,会让团队团队,思考5分钟,并把自己的看法记在纸上,如果是新增加的图或者第一次看图,引导者会讲这个图怎么看,但是不评论图上的数据。

     

    然后我们进行轮流发言,每个人1分钟,讲自己的观点。“我的观点是,……完毕,下一个XXX”

     

    发言结束之后进入下一个环节

     

    我的观点:

    1:数据驱动和持续改进是一对好基友,但是切莫因为数据搜集,建模困难而不去做,刚开始尝试难免会有数据不准确,维度不丰富,反馈不客观等等的情况,只要继续尝试下去,逐渐丰富起来,相信大家一定会找到适合自己团队的数据。

     

    2:在这个环节,有个点比较让人容易忽视,就是团队的主观感受。

     

    绩效=能力*意愿。在这个环节,除了让大家从不同角度观察客观的业绩数据(跟能力相关)之外,还需要观察主观的情绪数据(跟意愿相关),对情绪变化明显的同学表示关心和好奇。很多团队在做数据驱动的时候,过于强调结果和客观的业绩数据,导致忽视了个人情绪和意愿反而会让组织变得僵化。

     

    四:聚焦问题

     

    这个环节我们主要通过共创的方式让大家结合之前对迭代看法的上下文,背对背思考之后提出需要聚焦问题。

     

    引导者:“通过刚才的发言,大家刚才分别阐述了对本次迭代的一些看法,我们都知道,回顾是为了聚焦问题,提出改进,下面让我们进行提问,格式是“如何……?”例如“如何提高自动化测试的覆盖率?”,围绕如何改进,大家每个人最多能提3个问题,请将问题写在报事贴上,1张报事贴,写1个问题,2分钟。”

     

    引导者也参与写,写完之后,大家进行交流讨论10分钟,重要的是,每个人提出的问题能让其他人听到,并且知道你为什么认为这个问题如此重要。

     

    我们的做法通常是3人一组,交流一轮,然后每组选择1个人留在那组,其他人换组再交流一轮。大家充分碰撞思路。

     

    思路碰撞完之后,给大家1分钟,做问题调整,再次列出你认为最重要的3个问题,如果依然跟之前写出的没有差异,那么可以不用做调整。

     

     

     

    最后大家一起把问题合并同类项。针对有争议的可以放在一边,一般来说大家的问题相似度会比较高。下图是我们有一次在星巴克做回顾贴出的问题。选择出最长的那一列,就是大家最关注的问题了。如果有2列都一样,那么则进行投票,每人1票,投票结果相同进行一轮交流,之后再投票。找出这个最关注的问题之后,就要进入下一个环节,改进措施。

     

    我的观点:

    团队共同认为什么问题是最重要的,就解决什么问题。每个迭代只聚焦1个问题,最重要的问题解决了,其他的问题可能会随之发生变化,也许就变得不再重要了。团队应该把当前的精力集中在解决大家共同认为的最重要的问题上。

     

    五:改进措施

     

    改进措施的形成原则,遵守“奥卡姆剃刀”,少即是多。所以我们团队约定,我们只针对最重要的问题,制定一条大家都认可的改进措施,所有人对这条改进措施负责。其余的好的改进措施和想法,也都列示出来,有想帮助大家做的更好的同学可以积极的践行。

     

    引导者:“既然我们大家共同找到了那个最重要的问题,接下来,大家一起来思考,我们如何能够有效解决这个问题。”

     

    具体行程改进项的方式和上一环节“聚焦问题”是一样的,找到聚焦的问题之后,大家集中精力,思考5-10分钟。列出1-3条改进的措施,要求简单有效即可。

     

    例如曾经有一次关于“如何提高工作计划的合理性”这个问题,团队有提出两种思路:

     

    一种是通过JIRA,建立一些数据模型,录入数据分析,生成报表,balabala。。。

     

    另外一种是直接采用SBI报事贴,直接把报事贴上的时间统计下来展示给大家,大家再来探寻。

     

    这样的情况下,我们通常会直接采用第二种方式,尽可能简单并且能产生效果的方式。

     

    我的观点:

    1:为了避免受害者情绪,只有大家自己认可的东西,大家内心才会接受,改进措施制定的前提条件是尊重团队的选择,如果大家都选择了复杂的,那么就用复杂的,下个迭代我们再来看这个改进的有效性如何。复杂的改进也未必不好,只要有效,并且大家认可就好。

     

    2:那么什么是有效呢?有效的改进是指客观上有衡量的标准,主观上感受也有改善,如果只是要求客观上的数据指标达到要求,主观上的感觉很糟糕,我们也不认为这个改进有效。

     

    六:我要点赞

     

    完成了行动项的输出,我们通常需要一些激励,以便面对接下来的困难。彼此感谢,彼此欣赏最为重要。

     

    点赞的规则是每个人只有一次机会点赞,必须说出为什么感谢那个人,点赞不能给自己,可以给团队任何人。然后记录这次迭代回顾点赞的数据,每个月团队内公布一次获赞的榜单。

     

    我的观点:

    点赞是给非常有必要的环节,可以提振团队士气,但是要注意,团队的安全感足够高的情况下,我建议跟我们一样,采用当场实名,“说出来”的方式点赞,这种“说出来”的方式不仅是对被赞赏人的肯定,更是自我的一种积极表达。

     

    我们希望在职场中要不吝赞美,好的情绪和能量可以扩大。

     

    反之,如果安全感不够,或者极度缺乏安全感,可以匿名的方式,例如用匿名投票,匿名卡片等等。

     

    七:回顾评价

     

    最后,引导者宣布回顾会结束,感谢大家参与,并邀请大家评价。

     

    引导者:“感谢大家参加这次回顾会,下面请在赞扬声中用你的反馈来帮助我进行持续改进,以便我以后更好的为大家服务。”出示反馈二维码。

     

    以下是回顾评价打分选项:

    1:并没有什么用

    2:希望有用吧

    3:找到了解决问题的方向

    4:感觉不错

    5:我觉得充满力量

     

    我的观点:

    追求透明,检视,调整是Scrum的核心支柱,可以通过大家的反馈帮助自己迅速提高引导技巧,收获认可,发现不足。团队就是教练的镜子,教练也是团队的镜子,同时教练也可以根据反馈来辅导引导者,共同成长。

     

    以上就是我的回顾会教练经验,另外,友情提示以下2个需要注意的地方。

    1:上述方法较多,不一定适合您现在的团队,如果觉得对您有帮助的话,请考虑酌情导入,我们形成上面的套路也是经过了一段时间的迭代。

    2:注意感受打分的极值(极值就是指打5分或1分的情况出现),虽然是匿名打分,但是极值依然重要,极值的出现可以辅助判断团队在某些方面感受强弱的明显信号。

     

    展开全文
  • 2019浅紫简约工作总结汇报通用PPT模板是一款用于本阶段工作回顾、本阶段指标分析、成功项目展示、下阶段工作计划展示...等场合的PPT,欢迎大家下载参考使用!该文档为2019浅紫简约工作总结汇报通用PPT模板,是一份很...
  • 1 项目实施阶段回顾;硬件/软件准备;-现有流程分析 将来流程定义 -项目范围调整 -组织机构定义 -数据准备启动 -系统原型搭建;现有业务流程调研报告 ?现有业务流程的了解和需求;原因 -业务操作的规范化,要求制定各...
  • 网易实习第一阶段简单回顾

    千次阅读 2016-08-20 11:56:58
    前几天顺哥面试的时候碰到HR明确说我转正答辩通过,趁此机会对这段时间的工作做个梳理。面试经历之前在已经在 Android实习生面试记录-蘑菇街、网易等 写了,结果就是网易发了offer,蘑菇街拿到终面机会但是我没去...

        前几天顺哥面试的时候碰到HR明确说我转正答辩通过,趁此机会对这段时间的工作做个梳理。面试经历之前在已经在 Android实习生面试记录-蘑菇街、网易等 写了,结果就是网易发了offer,蘑菇街拿到终面机会但是我没去面:5月4号入职网易,同时蘑菇街通知5月5号现场终面(第五面...)。那天上午办完入职手续后顺哥来接,正在电梯间接到蘑菇街HR电话确认是否能够去终面,根本不确定是否可以请假&感觉刚入职又去面试不大好就拒了。过了几个礼拜蘑菇街HR又给我打电话说北京有面试问我去不去,虽然感动但还是拒了。

    开始阶段

       入职第一天,领机器配环境,自由网络一切都很爽。完事后老大扔了一本Clean Code 给我看了两天,笔记: [读书笔记]Clean Code (1-8章)[读书笔记]Clean Code (8-完结)。之后就是熟悉工程源码看看git提交规范什么的,一周时间在周会的时候做了个汇报。项目还是蛮大的,当时住公司晚上待到九十点走也仅仅是看了个皮毛,深入细节的话一个礼拜还是不够的。汇报的时候也列出了我看源码的步骤还画了个大大的类图(第一次尝试

           

    开发阶段

    1. 企业云课堂

        了解了怎么提代码,怎么写代码以及熟悉了项目源码后,正好又要开始新的需求。顺哥分了点任务给我,叫我先做设计。这点是与我之前写代码是很不一样的,一种“野路子”碰上正规军的感觉。以前自己做项目,基本就是把功能确定在纸上大概画画UI,然后脑子稍微想想怎么实现哪些地方可以复用大概的架子是怎样的就开始写代码了。有时候遇到问题就边做变查,甚至半路发现之前没有考虑到的点但却发现一时半会解决不了可能就可耻地改需求了。反正是自己做的东西,既是运动员又是裁判员~_~  对于一些书上讲的UML不屑一顾,嫌麻烦。但现在不一样,我面对的是一个商业产品:需求是确定的,不能说改就改;你需要对你的每一行代码负责,保证产品完成的质量。就这样开始了第一次开发的设计。

        其实还好,这次做的是 网易云课堂企业版的第一个版本。企业版是针对企业的相对于线上的网易云课堂业务复杂度更小,好多东西都是可以复用的。因此也将相关的代码深入看了下,主要对比不同的地方,另外看当前的代码有哪些可以借鉴以及改进的点。照着这个思路做了自己的设计,在此期间@HY 同学也是提供了很大的帮助。设计的同时还要和后端沟通定接口。弄完后给顺哥看毫无悬念地——被打回来了。主要是UML详略不得当,一些关键的点没有体现出来。改过之后基本符合要求过了设计评审,然后还是在@HY的帮助下进行了项目排期。时间还算充裕,给了八天的时间,两天buffer。最后在规定时间内页完成了功能的开发,效果如下:


    接下来是提测,但是我要滚回去准备期末考试,也就是说人跑了,bug留下来了。

    回公司的时候也快要上线,我负责的那部分有两个bug,这两个bug倒不是代码逻辑不对,而是需求。

    1. 在无数据的情况下,显示的图标不对。这个是因为没有和策划确认明确需求,自己想当然了

    2. 遗漏了一个补充需求,这个锅我背一半 因为稿子上是没有明确在对应的页面标注的,而是写在最后面的补充说明里边。当然,这个以后也是特别要注意的

    2. 代码静态检查

        做完第一波需求后正好部门对代码质量提出了更高的要求,我们的提交的代码,每三个小时就会被程序自动检查一次,对于不合格的代码都会按照不同的严重级别进行标出。我的任务便是消灭严重级别较高的代码。所谓不合格代码基本是Clean Code,重构等书上讲的,细致到变量的命名不符合要求,if嵌套超过三层都会标出。工程量较大,着实 花了不少时间。不过这次也算对Clean Code的一个回顾吧。

    3. 企业版换肤

        做企业版1.0的时候视觉给的稿子将主色调从绿色改成了蓝色,由于我们两份代码是要共用,直接简单粗暴的改是不可取的。开始想了两个方案:

    1. 采用Google的主题切换 它要求我们不能使用硬编码,改动会比较大 另外如果我们后续想把它做成动态更换是受限    的:切换主题的时候由于需要重启当前Activity,会产生闪屏,这是不能容忍的。

    2. 遍历所有的View,对View的颜色进行动态改变。 这种方案不会造成闪屏,但是工作量大,侵入性太强。

       以上两种方案均被否决,第三种方案被提出: 插件化换肤

    PS:    左边是几个相关的概念: 插件化、组件化、动态加载

      右边是Android插件化的应用

     

    我们把图片/颜色 资源打包成一个插件Apk,然后用定义好的语法规则建立View和资源的对应关系生成一个配置文件。换肤的时候我们只需从插件中获取资源,然后将App中的View根据配置文件进行主题切换。这种方案有两个明显的优点:

    1. 侵入性小,基本不需要对原有的代码进行太多更改,一次部署完成之后,以后想换其他主题只需再打包个插件并对     配置文件进行简单修改即可

    2. 拓展性强,支持动态换肤,如果以后想直接从服务器下发资源进行换肤只需再整合下载模块即可

    方案敲定后,顺哥给了详细的设计,大概就像下面这样(仅是我修改并简化的粗略类图)


    后续的编码及部署也是花了不少功夫,完工效果如下



    总结 

    这三个多月的实习,自己在工作方式思考方式变化较大:

    1. 一切以事实说话,你需要拿出明确的理由说服他人

    2. 没有模棱两可,没有想当然,确认后再动手

    3. 设计要落实到纸上,而不是"应该是什么"

    4. 对设计模式有了不一样的见解,浅浅地开始不是为了"模式"而"模式"

    下面是自己对技术和产品的展望:

    1. 技术



    2. 产品


    ~~~~~~~~~~~~~~~~~~~ 这仅仅是个开始,第一阶段 ~~~~~~~~~~~~~~~~~~~~~

    出处: http://blog.csdn.net/mummyding/article/details/52260513

    GitHub地址: https://github.com/MummyDing/Leisure/



    展开全文
  • 01-3 项目上线回顾-主要工作准备;02-1 5月运行总结-整体汇报;02-2 5月运行总结-整体汇报;02-3 5月运行总结-期初数据;02-4 5月运行总结-核心业务;02-5 5月运行总结-财务核算;02-6 5月运行总结-智能工厂;03-1 6月工作...
  • 工作总结ppt模板,目录:前阶段工作回顾,取得成绩的原因和经验,不足之处及原因分析,当前形势分析,下一步工作计划,几何图形元素设计,简约扁平化风格,蓝灰配色,适合工作总结、工作汇报的通用ppt模板。
  • 六年安卓开发的技术回顾和展望

    万次阅读 多人点赞 2022-02-15 00:46:51
    快速迭代(这一点其实无论什么阶段) 提升质量(用户规模日活亿和日活一万,需要面对的挑战差异也是这个数量级) 第一点:快速迭代 虽然快速迭代是业务各个阶段都需要做到,但和从 0 到 1 相比,从 1 到 100 的...

    大家好,我是 shixin。

    一转眼,我从事安卓开发工作已经六年有余,对安卓开发甚至软件开发的价值,每年都有更进一步的认识。对未来的方向,也从刚入行的迷茫到现在逐渐清晰。我想是时候做一个回顾和展望了。

    这篇文章会先回顾我从入行至今的一些关键点,然后讲一下经过这些年,我对软件开发的认知变化,最后分享一下后面的规划。

    回顾

    人太容易在琐碎生活中迷失,我们总是需要记住自己从哪里来,才能清楚要到哪里去。

    入行至今的一些关键节点

    2014~2015:开始安卓开发之旅

    说起为什么做安卓开发,我很有感慨,差一点就“误入歧途”😄。

    当初在大学时,加入了西电金山俱乐部,俱乐部里有很多方向:后端、前端、安卓、Windows Phone 等。

     

    由于我当时使用的是三星 i917,WindowsPhone,所以就选了 WinPhone 方向。

    当时还是 iOS、安卓、WinPhone、塞班四足鼎立的时代,WinPhone 的磁贴式设计我非常喜欢,加上设备的流畅性、像素高,一度让我觉得它可能会统治移动市场。

    结果在学习不到 2 个月以后,我的 WinPhone 意外进水了!我当时非常难过,一方面是对手机坏了的伤痛,另一方面也是对无法继续做 WinPhone 开发很遗憾。对于当时的我来说,再换一台 WinPhone 过于昂贵,只好换一台更加便宜的安卓机,因此也就转向学习安卓开发。

    后面的故事大家都知道了,因为 WindowsPhone 缺乏良好的开发生态,支持应用很少,所以用户也少,用户少导致开发者更少,恶性循环,如今市场份额已经少的可怜。

    现在回想起来,对于这件事还很有感慨,有些事当时觉得是坏事,拉长时间线去看,未必是这样。

    当时还有一件目前看来非常重要的决定:开始写博客,记录自己的所学所得。

    在开发项目时,我经常需要去网上搜索解决方案,后来搜索的多了,觉得总不能一直都是索取,我也可以尝试去写一下。于是在 CSDN 注册了账号,并于 2014 年 10 月发布了我的第一篇原创文章

    后来工作学习里新学到什么知识,我都会尽可能地把它转换成别人看得懂的方式,写到播客里。这个不起眼的开始,让我逐渐有了解决问题后及时沉淀、分享的习惯,受益匪浅。

    2015~2017:明白项目迭代的全流程

    在学习安卓开发时,我先看了一本明日科技的《Android 从入门到精通》,然后看了些校内网的视频,逐渐可以做一些简单的应用。安卓开发所见即所得的特点,让我很快就可以得到正反馈。后来又去参加一些地方性的比赛,获得一些名次,让我逐渐加强了从事这个行业的信心。

    在 2015 年时,偶然参加了一家公司的招聘会,在面试时,面试官问了一些简单的 Java 、安卓和算法问题。其中印象最深的就是会不会使用四大组件和 ListView。在当时移动互联网市场飞速发展时,招聘要求就是这么低。以至于现在很多老安卓回忆起当初,都很有感慨:“当初会个 ListView 就能找工作了,现在都是八股文” 哈哈。

    到公司实习后,我感触很多,之前都是自己拍脑袋写一些简单的功能,没有开发规范、发布规范,也没有工程结构设计、系统设计,更没有考虑性能是否有问题。真正的去开发一个商业项目,让我发现自己不足的太多了。

    因此在完成工作的同时,我观察并记录了项目迭代的各个流程,同时对自己的技术点做查漏补缺,输出了一些 Java 源码分析、Android 进阶、设计模式文章,也是从那个时候开始,养成了定期复盘的习惯,每次我想回顾下过去,都会看看我的成长专栏

    2017~2020:提升复杂项目的架构能力和做事意识

    第一个项目中我基本掌握了从 0 到 1 开发一个安卓应用的流程,但对安卓项目架构还只停留在表面,没有足够实践。

    在 2017 年,我开始做喜马拉雅直播项目,由于喜马拉雅在当时已经有比较多年的技术积累,加上业务比较复杂,在架构设计、编译加速、快速迭代相关都做了比较多的工作,让我大饱眼福。

    同时直播业务本身也是比较复杂的,在一个页面里会集成 IM、推拉流等功能,同时还有大量的消息驱动 UI 刷新操作,要保证业务快速迭代,同时用户体验较好,需要下不少功夫。

    为了能够提升自己的技术,在这期间我学习了公司内外很多框架的源码,通过分析这些框架的优缺点、核心机制、架构层级、设计模式,对如何开发一个框架算是有了基本的认识,也输出了一些文章,比如 《Android 进阶之路:深入理解常用框架实现原理》

    有了这些知识,再去做复杂业务需求、基础框架抽取、内部 SDK 和优化,就容易多了。

    在开发一些需求或者遇到复杂的问题时,我会先想想,之前看的这些三方框架或者系统源码里有没有类似的问题,它们是怎么解决的?比如开发 PK 功能,这个需求的复杂性在于业务流程很多,分很多状态,咋一看好像很复杂,但如果了解了状态机模式,就会发现很简单。借用其他库的设计思路帮我解决了很多问题,这让我确信了学习优秀框架源码的价值

    除了技术上的提升,在这几年里,我的项目全局思考能力也提升很多。

    由于我性格外向,和各个职能的同学沟通交流比较顺畅,领导让我去做一个十人小组的敏捷组长,负责跟进需求的提出、开发、测试、上线、运营各个环节,保证项目及时交付并快速迭代。

    一开始我还有些不习惯,写代码时总是被不同的人打断,比如产品需求评审、测试 bug 反馈、运营反馈线上数据有问题等等,经常刚想清楚代码怎么写,正准备动手,就被叫去开会,回来后重新寻找思路。

    后来在和领导沟通、看一些书和分享后,逐渐对写代码和做事,有了不同的认识。代码只是中间产物,最终我们还是要拿到对用户有价值、给公司能带来收入的产品,要做到这个,眼里除了代码,还需要关注很多。

    2020~至今:深入底层技术

    在进入字节做基础技术后,我的眼界再一次被打开。

    字节有多款亿级用户的产品,复杂的业务常常会遇到各种意想不到的问题,这些问题需要深入底层,对安卓系统的整个架构都比较熟悉,才能够解决。

    上图是安卓系统架构图,之前我始终停留在一二层,在这一时期,终于有了纵深的实践经验。

    比如帮业务方解决一个内存问题,除了要了解内存指标监控方式,还要知道分析不同类型内存使用的工具及基本原理,最后知道是哪里出了问题后,还要想如何进行体系化的工具,降低学习成本,提升排查效率。

    问题驱动是非常好的学习方式。每次帮助业务解决一个新问题,我的知识库都会多一个点,这让我非常兴奋。之前不知道学来干什么的 Linux 编程、Android 虚拟机,终于在实际问题中明白了使用场景,学起来效率也高了很多。

    对软件开发的认识

    前面讲了个人的一些经历,包括我怎么入的行,做了什么项目,过程中有什么比较好的实践。下面讲一下我从这些具体的事里面,沉淀出哪些东西有价值的结论。

    主要聊下对这两点的认识:

    • 职业发展的不同阶段

    • 技术的价值

    职业发展的不同阶段

    第一点是对职业发展的认识。我们在工作时,要对自己做的事有一个清晰的认识,它大概属于哪一个阶段,怎样做可以更好。

    结合我这些年的工作内容、业内大佬所做的事情,我把软件开发者的职业发展分这几个阶段:

    1. 使用某个技术方向的一个点开发简单项目

    2. 使用某个技术方向的多个点及某条线,开发一个较为复杂的业务或系统

    3. 掌握某个方向的通用知识,有多个线的实践,可以从整体上认识和规划

    4. 不限于该方向,能从产品指标方面出发,提供全方位的技术支持业务角度,端到端关注指标

    第一个阶段就是使用某个技术方向的一个点完成业务需求。拿安卓开发者来说,比如使用 Android SDK 自定义布局,完成产品要求的界面功能。这个阶段比较简单,只要能够仔细学习官方文档或者看一些书即可胜任。拿后端来说,比如刚接手一个小项目,日常工作就是使用 Spring 等库开发简单的接口,不涉及到上下游通信、数据库优化等。

    第二个阶段,你做的项目更加复杂了,会涉及到一个技术方向的多个点,这时你需要能把这些点连起来,给出一个更体系化的解决方案。

    拿安卓开发者来说,比如在自定义布局时,发现界面很卡顿,要解决这个问题的话,你就要去了解这个自定义 View 的哪些代码流程影响了这个页面的刷新速度。这就相当于是从一个点到另一个点。怎么连起来呢?你需要去研究渲染的基本原理,分析卡顿的工具,找到导致卡顿的原因,进行优化。这个过程会对流畅性有整体的认识,能够对相关问题有比较全面的分析思路、解决手段,从而可以开发相关的分析工具或优化库。如果能达到这个程度,基本就算是一个高级工程师了,不只是做一个模块,还能够负责一个具体细分方向的工作。

    第三个阶段,掌握某个技术方向的通用知识,有多个线的实践,能够连线为面,同时给工作做中长期的技术规划。

    拿安卓开发来说,刚才提到你通过解决卡顿问题,在流畅性这方面有了比较多的实践;然后你又发现内存有问题,去了解了内存分配、回收原理,做出内存分析优化工具,这样就也有了内存的一个体系化的实践。再加一些其他的优化经验,比如启动速度、包大小等。把这些线连起来,就得到了一个性能监控平台,这就是有把多条线连成一个面。

    还有比如说你发现项目打包和发布过程中的一些痛点,并且能够做一些实践解决,最后如果能够把这些优化项连起来做一个统一的系统,给出完整的 DevOps 方案,提升开发、发布、运维的效率。能够把这个系统搭建起来,有比较深入的经验,那就可以成为“技术专家”了。

    再往上走就不只是做技术,而要更多思考业务。技术最终都是要为业务服务。职业发展的第四个阶段,就是不局限于某个技术方向,能够从产品的业务规划、业务指标出发,给产品提供技术支持。

    你首先要明白公司业务的核心指标是什么,比如说拿一个短视频应用来说,它核心指标除了常规的日活、用户量,还更关注视频的播放率、停留时长、页面渗透率等。了解这些指标以后,你要思考做什么可以有助于公司提升这些指标。结合业务指标反思当前的项目哪里存在优化空间。

    有了这个思路并且知道可以做什么以后,你可以做一个较为全面的规划,然后拉领导去讨论可行性。这时你不能再局限于某一端,不能说我只是个安卓开发,其他部分都找别人做。一般在项目的价值没有得到验证之前,领导不会轻易给你资源,因此第一个版本迭代肯定是要靠你自己,从前到后独立完成,做一个 MVP 版本,然后让领导认可了这个系统的价值,才有可能会分给你更多的资源做这件事。

    总结一下对职业发展的认识:第一阶段只做一些具体的点;第二阶段做多个点,需要能够连点成线;第三个阶段需要围绕这些线提炼出通用的知识,然后做到对业务/技术项目有整体的认识;第四阶段能够从业务指标出发,做出有价值的系统/平台。

    技术的价值

    说完职业发展的不同阶段,接下来聊下技术对业务的价值。

    技术是为业务服务的。根据业务的不同阶段,技术的价值也有所不同:

    1. 业务从 0 到 1 时,帮助业务快速确定模式

    2. 业务从 1 到 100 时,帮助业务快速扩大规模

    3. 最卓越的,用技术创新带动业务有新的发展 (Google、AWS、阿里云)

    业务从 0 到 1 时

    我一开始做的工作,业务就是处于确定模式期间。业务上反复试错,项目常常推倒重来,会让程序员觉得很有挫败感。

    这个阶段很多程序员都会发挥复制粘贴大法,产品经理说要新增一个功能,就复制一份代码稍微改一改。

    如果说目前就是在这种业务中,该怎么做呢?如果我回到当时那个情景,我可以做什么让公司业务变得更好呢?

    我总结了两点:在高效高质量完成业务的同时,思考如何让业务试错成本更低。

    如何让业务试错成本更低呢?大概可以有这些方式:

    • 提供可复用的框架

    • 提供便捷的数据反馈机制

    • 多了解一些竞品业务,在产品不确定的时候,给一些建议

    第一点:尽可能的抽象相似点,减少重复成本。

    如果产品每次都给你类似的需求,你可以考虑如何把这些重复需求抽象成一些可以复用的逻辑,做一个基本的框架,然后在下次开发的时候能够去直接用框架,而不是每次都从头开始。我平时工作也常常问自己“我现在做的事有哪些是重复的,哪些是可以下沉的”。

    就安卓开发来说,这个阶段,可以做好基础建设,提供插件化、热修复、动态化框架,帮助业务快速发版,自研还是第三方看公司财力。

    如果你说这些太复杂了我做不来,那就从更小的层面做起,比如某个功能原本需要多个接口多个界面,看能不能改成接口参数可配置,界面根据参数动态生成(也就是 DSL)。

    第二点:提供便捷的数据反馈机制

    在产品提需求时,你可以问问产品这个需求出于什么考虑,有没有数据支撑?比如说产品需求是某个按钮换个位置,那你要搞清楚,为什么要换,换完之后会导致页面打开率提升吗?要有这种数据驱动的理念。

    如果公司做决策时缺乏相应的数据,你可以主动地去提供这种数据反馈机制。比如说开发一个埋点平台、数据监控平台。尽可能地让业务有数据可看,能够数据驱动,而不是像无头苍蝇一样盲目尝试。

    如果无法做一个这么大的系统,那可以先从力所能及的做起,比如说战略上重视数据;做好数据埋点;思考做的功能,目前有哪些数据是核心的,这些数据有没有上报,不同版本的数据是升还是降等。

    好,这是第一个阶段,技术对业务价值就是帮助业务快速确定模式。第二个阶段就是业务快速扩大规模时,技术的核心价值是什么呢?

    业务从 1 到 100 时

    业务正在快速扩大规模时,需要把当前跑通的业务模式复制到更多的地方,同时能够服务更多的用户。这个阶段,技术能够提供的价值主要是两点。

    1. 快速迭代(这一点其实无论什么阶段)

    2. 提升质量(用户规模日活上亿和日活一万,需要面对的挑战差异也是这个数量级)

    第一点:快速迭代

    虽然快速迭代是业务各个阶段都需要做到,但和从 0 到 1 相比,从 1 到 100 的阶段会有更多的挑战,除了个人速度,更要关注团队的速度。

    团队的速度如何提升?可以参考后端的单体到微服务、前端的单仓到多仓的演变过程及原因。

    这个阶段主要有这几点问题:

    1. 多人协作代码冲突

    2. 发布速度慢

    3. 出问题影响大,不好定位

    具体到安卓项目,几百人开发和三两个人开发的,复杂度也是几百倍。我们可以做的是:

    1. 下沉基础组件,定义组件规范,收敛核心流程

    2. 拆分业务模块,设计业务模板,单独维护迭代

    3. 探索适合业务的新方式:跨端(RN Flutter KotlinMultiplatform)、动态化、多端逻辑一致(C/C++ Rust)

    第二点:提升质量

    和日活几万的项目相比,日活千万甚至上亿的产品,需要应对的质量问题更加显著。在这个阶段,我们不仅要满足于实现功能,还要能够写的好,更要能够了解底层原理,才能应对这样大的业务量。

    有了大规模的用户后,你会遇到很多奇怪的问题,不能疲于每天去解决一样重复的问题,那你就需要从这些问题中找到一些共通的点,然后提炼出来,输出工具、解决方案甚至平台。

    这就需要你从问题中磨练本领,站在更高的层面思考自己该具体的能力、思路和工具。

    在解决问题的时候,除了当下这个问题,更需要做的是把这个问题解构、归类,抽象出不同问题的相似和差异,得出问题分析流程图。

    同样是分析内存泄漏,有的人可能只知道使用 Leakcanary,但你还可以思考的更深入,比如:

    • 先定义问题。什么是泄露?

    • 泄露是申请了没有释放或者创建了没有回收

    • 内存泄露怎么分析?

    • 找到创建和销毁的点

    • 在创建的时候保存记录,销毁的时候删除这个记录,最终剩下来的就是泄露的

    有了基础的逻辑,就可以把它套用到各种问题上:

    • Native 内存泄漏:在 Native 内存分配和释放 API,做记录

    • 图片使用不当:在图片创建、释放的 API 里做记录

    • 线程过多:在线程创建、释放的 API 里做记录

    在遇到一个新问题时,发现和之前解决过的有点像,但又不知道哪里像。怎么办?回头去思考新旧的两个问题,它们的本质是什么?有什么相似的分析思路?

    这个思考训练的目的,就是提升举一反三的能力。大规模应用可能各种问题,需要你一方面提升技术,另一方面分析问题的思路和能力上也要提升,不能看着一个问题就是一个问题,要做到看到一个问题,想到一类问题。

    展望(后面的规划)

    技术上达到一专多能,软实力上持续提升。 

    硬实力

    专业

    如果你是安卓开发,最好在某个有细分领域很擅长,比如音视频、跨端、动态化、性能优化。

    我目前主要是做优化,后面需要继续补充的知识:

    • Linux 内核原理

    • Android 虚拟机原理

    • 项目从开发、编译、发布、数据分析各个流程的效率提升方式

    多能

    前面提到职业发展的第四个阶段:

    不限于该方向,能从产品指标方面出发,提供全方位的技术支持

    我希望可以具备独立完成一个系统从前到后的能力。

    目前已有的经验:

    • 使用 TypeScript + React + Electron 开发桌面端软件

    • 使用 SpringMVC 开发简单的内部系统

    后面需要加强的点:

    • 熟练掌握前端的 js、打包、优化等知识

    • 后端技术达到中级

    还有这些点需要长期关注:

    • Flutter 更新频繁,有一些尝试效果还不错,一套代码多端运行,节省开发成本

    • 掌握 DevOps 理念及实践

    最终目的:

    • 具备独立完成一个有价值的系统的能力

    • 具备对研发整个流程的完善、优化能力

    软实力

    除了技术规划,我也有很多软实力需要继续提升,今年主要想提升的就是同频对话的能力。

    什么是同频对话?

    同频对话就是根据听众的角色和他的思考角度去转换你的表达内容。

    比如说我们在和领导汇报的时候,你要去讲你做的一个系统,你就要从他角度去表达。他可能关注的是整体流程、系统的难点、瓶颈在哪里,带来的收益是什么。那你就不能只讲某个模块的细节,而要从更高的层面去思考和表达。

    为什么要提升呢?

    随着工作年限的增加,市场对我们的要求是越来越高的,除了写代码,对表达能力的要求也是越来越高的。

    一开始刚入行,你就是做一个执行者,只要多动耳朵、眼睛、手,实现别人要求你做的功能。

    后来你的能力逐渐提升以后,有机会设计一个模块的时候,你就需要多动脑力去思考,去复设计这个系统的输入输出、内部数据流转等。

    再往后走的话,你可能会有一些资源,那就需要能把你的想法完整地表达出来,让别人帮你去贯彻落地。这其实是一种比较难得的能力。我今年计划通过多分享、多与不同的人交流等方式,提升自己的这种能力,争取做到满意的程度。

    结束语

    好了,这篇文章就到这里了,这就是我这六年的技术回顾和展望,感谢你的阅读❤️。

    人生的多重境界:看山是山、看水是水;看山不是山、看水不是水;看山还是山、看水还是水。

    我想,我对软件开发,还没有达到第三层,相信用不了多久,就会有不同的观点冒出来。

    但,怕什么真理无穷,进一寸有一寸的欢喜!

    如果给你什么启发,欢迎留言交流,共同进步✋!

    展开全文
  • 一年工作回顾及总结

    千次阅读 2012-10-15 17:30:03
    去年7月4号入职到现在已经有一年零2个月了,一直想写下一年工作回顾及总结,但是每次打开文档时总是以各种理由推后,一来是想写的太多但是又不知从哪里写起,二来是总想把自己的一年工作经历写的真实好看一点,以...
  • 系列文章目录 一篇文章看懂PMP的2021新考纲重点(建议收藏) 项目发展史/项目定义/项目集/项目组合/十五至尊图 ...这里我们可以看到,一个冲刺是可以跟工作分解结构WBS挂钩的,但是概念和叫法都是不一样
  • 项目回顾案例

    千次阅读 2015-09-09 11:10:07
    截止到8月中旬结束,投入的开发人员、测试人员、管理人员达到60多人,2015年8月31日,由咨询顾问作为主持人带领该团队的10多名核心人员,对整个项目进行了系统回顾总结,整个回顾总结的过程如下: 1 咨询顾问花了1...
  • 精品文档助力人生欢迎关注小编 电子商务年终工作总结范例 电子商务年终工作总结范例 是事后对某一阶段的学习工作或其完成情况加以回顾和分析的一种书面材料它能使我们及时找出错误并改正让我们抽出时间写写总结吧你...
  • 大家好我是*我自1986年参加工作后先后担任过初中语文生物数学计算机应用基础等学科的教学1988年恢复专业技术...阶段的学习专业为计算机应用与管理到现在为止我在教育岗位已经21年了回顾过去的1年为了把今后的工作做的
  • 软件工程师年终工作总结最新 软件工程师年终工作总结 总结在一个时期一个年度一个阶段对学习和工作生活等情况加以回顾和分析的一种书面材料他能够提升我们的书面表达能力快快来写一份总结吧但是总结有什么要求呢以下...
  • 工作总结ppt | 工作总结怎么写 | 工作总结开头 | 工作总结结尾 | 工作总结报告 总结是对自身社会实践进行回顾的产物它以自身工作实践为材料是回顾过去对前一段时间里的工作进行反思但目的还是为了做好下一阶段工作...
  • 2014年终总结回顾与2015年工作总结

    千次阅读 热门讨论 2016-02-16 12:56:57
    2016已经开工,开工之前先来对2015年的工作做一个总结。是我们跑的太慢,还是时间跑的太快,是我们跑偏了方向,还是时间在跳跃性的向前,让时间把我们落的太远太远!这一年在做的事情还是花时间去赚钱,依然没有学会...
  • 回顾15个月的工作经历

    千次阅读 2014-11-22 22:09:15
    我把我至今的工作经历分为如下两个阶段,分别对应在百度和现在在阿里这两个时间段。 第一个阶段,学习工具 自打毕业给自己定下往分布式这块发展后,我看到了许许多多的系统和工具,那些东西对当时的我来说是"不可...
  • 程序员如何提高工作效率?如何更好获得领导的认可?要从写使用手册,低级程序员,中级...PDCA工作方法是将工作任务分为四个阶段,即Plan(计划)、Do(执行)、Check(检查) 和 Act(改进)。要求把各项工作按照作出计划、计
  • 最新2020年网络工程师工作总结范文 今年十月份祥子要回学校进行软件工程硕士的论文答辩了如果能够顺利通过算是又完成了一个努力的阶段网络工程师的努力过程回顾这十几年来的网络工程师工作经历印记还很清晰仿佛就象...
  • 2015年选择回到贵州工作,《再见北理工》留恋不舍;2016年成为一名大学青年教师,《教书路开启,爱情味初尝》;2017年又借调到省发改委忙碌,留下《人生百味,有你真好》;2018年数不清的加班,尝不尽的酸甜,完成了...
  • 工作复盘的重要性

    千次阅读 2021-03-07 23:24:06
    同样对于工作也是一样的,一直以身体的忙碌去掩盖思维的懒惰并不是有效的工作方式,最快最有效的学习/工作的方式是对自己的问题进行总结思考,遇见哪些问题,如何解决,还有没有更好的办法。 联想总裁柳传志将...
  • 回顾检视会有助于团队不断提高,不论是采用敏捷方法还是传统方法的... 预设会议基调能帮助团队成员关注手现有的工作,这一步向团队重申召开此次回顾检视会议的目标,这样可营造一种便于讨论问题的和谐气氛。 ...
  • 原来是昨天,有两个年轻人,三十多岁,一个体重,九十多公斤,一个体重八十多公斤,他们说,唉…有一个说是我快要找工作了,但是自己太菜了,你能不能帮忙写篇文章帮助治疗一下我的菜鸡病(emmm...似乎有点跑题了,...
  • 事物飞速发展之时,往往需要你停下脚步,回顾自己所处的位置,否则你会很容易陷入对细节的兴奋之中。构成人工智能基础的数据科技正以不同的方式向前发展,而且速度飞快。因此,在你改变职业之前,或者决定使用人工...
  • 只不过为了保证在各种异常场景下,TCC都能够正常的工作,会添加不少异常处理手段。 为了把两个阶段的行为梳理清楚,绘制了下面的流程图作为总结。 涉及到的具体细节,可以结合前面的讨论进行回顾。 一阶段 - TRY 二...
  • 一个产品经理的工作经历与总结

    万次阅读 多人点赞 2018-10-31 22:39:29
    细细回顾了一下,工作内容大致可以分为以下几个部分: 1.需求收集、管理、分析、筛选、立项 需求主要分为外部需求和内部需求,外部需求来源主要是通过 数据采购商(客户)反馈 、 客户访谈 、 市场调研 等途径...
  • 摘要:有些团队践行敏捷一段时间后,感觉回顾会议(Retrospective Meeting)时间太长,动辄2-3个小时,而且会议走形式,会后无效果,那么如何才能让回顾会议有...所以回顾的目的是为帮助团队定期改善工作,发现障碍
  • 其中许多工作都与GCN相关(比如之前解读过的IGCN),这是一篇被ICLR2017会议录用的频谱图卷积工作,非常经典。而GCN又来源于对ChebNet的进一步简化与近似,他们都属于在频域定义的图卷积网络。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 71,422
精华内容 28,568
关键字:

上阶段工作回顾