阅读 77

从前端开发流程谈团队体验优化

有槽点的地方就可提升。

日常工作中,相信大家跟同事相处都很和谐、很融洽,除了偶尔“忍无可忍”…但在茶余饭后,你肯定有不少关于某人的槽点拿来跟大家聊,要么响应慢,要么输出的东西你用起来不舒服,要么对你“过于关照”,等等,你会发现其他人也有类似的感受,既然有吐槽,就必然存在问题,本文发表一些个人愚见,聊聊这些问题。

提需求

需求从哪儿来?

  • 产品规划——基于部门的阶段性目标制定;
  • 产品优化——使用体验欠佳,功能或者页面调整;
  • 前期遗漏——前期考虑不周就发布上线,不得不提额外的需求去弥补;
  • 领导建议——高层领导在使用过程中察觉到问题;
  • 运营反馈——运营活动、abTest,试验性取舍;
  • 客户反馈——客服渠道或者亲友、同事、社交软件收集的问题。

以上基本能够涵盖大部分的需求来源,看起来都没有问题,但其实每个环节都或多或少有改善空间。

先聊聊大家熟知的事情。

改需求

有过项目经历的都知道,一个页面或者一个功能模块,一旦定稿,集中精力做的话,少则三四天,多则十天半月,即可初步开发完成,然后是兼容、适配、测试、灰度和发布,但往往稍具规模的团队都不会给你一个完整的时间很顺利地完成这个过程,而是多个需求并行开发,测试、修改穿插。

定稿之前,设计师有个初稿,中间稿,定稿,定稿1,定稿2,定稿3,打死不改终稿,打死不改终稿1…

而开发折腾的点在于,设计改了你要改,设计不需要改的时候,文案、逻辑、提示、公告等也需要你改。

这就造成了一种习以为常的亚健康状态——改需求。

由此带来的,是工期评估成为伪命题,你无法准确估算到底需要多久,时间长了产品觉得太慢,时间短了你压力大,有种说法是“从后向前推”,即上线时间确定,不论耽误了多少时间,都要赶在预定上线时间之前完成,所以还是会给一个时间,然后加班加点地去迎合,叫苦不迭。

显然,这不是某个环节的问题,而是团队运转的问题,分块来谈。

基建

只要稍具规模的,趋于稳定的团队,都会有个问题,平稳有余,激情不足,成员积极性不够,创造力不够,除了搬砖做需求、改bug,就是吹水、休闲娱乐。

这会造成两个问题:

其一、团队工作模式僵化,一成不变,哪怕有若干因素导致它是低效的、不舒服的,也没人提改善意见,即使提了,也很难被执行,除非团队leader重视起来,不断的进行监督和督促,甚至把它作为绩效考核的一部分;

其二、个人工作不断重复,知识和经验积累停滞,进入温室效应,止步不前。

员工的首要任务是完成分配的工作内容,公司的首要目标是产生效益,无可厚非。但员工同样是人,有性格、情感、爱好、长处,他们需要快乐、需要得到认可,需要体现价值,而作为占了日常时间至少70%的工作来说,有必要把这些提供给他们,怎么提供?

团建、聚会

脱离工作的严肃感甚至压迫感,把大家更生活和个性的一面展示出来,让彼此在轻松的氛围中更熟悉,拉近距离。

薪资、头衔

涨薪、发奖金,或者职级提升,优秀员工评定,这是每个人都乐于得到的,代表领导对自己工作的肯定。

学习、会议

不论哪个行业,都在发展和更新换代,很多东西需要学习,技术尤甚,且变化多端,所以,不论是开工作会议汇报总结,还是开分享会交流学习,都能够给大家有益的刺激,增添更多动力,也能把学到的新东西及时用于工作当中解决问题。

人尽其用

每个人都是不同的,同一件事,不能指望每个人都做,或者做得同样好。

我们的目标不是同质化,而是善于发现他们的闪光点,将其最大化。

有人乐于研究工具,就让他去研究,帮助大家提升效率;有人对框架/库感兴趣,就让他去学习和掌握,进而尝试接入项目;有人擅长整理文档,就把整理汇总的工作给他。

各人的精力都是有限的,由我这几年的经验来看,更建议发展自己成为专才,而不是通才,更何况,举目望去,专才都凤毛菱角,就不必贪心了。

当然,这并不代表和其他事情绝缘,我们可以共享他人的成果,也应该跟团队其他成员分享自己的成果,互相学习,互帮互助。

每个职场人的追求,不外乎去一个有温度、有前景的公司,发挥自己的专长,做一些有意义的事,并得到相应的成长和回报。

当人和人之间的关系更好,个人素质更高,不但可以在不断讨论、摸索中优化工作方法,还能增强团队凝聚力,增加成员的参与感和荣誉感,不论团队取得了什么成绩,他都会觉得,那当中有他一部分贡献在,而不只是沾了光的旁观者。

个人

产品经理

说到产品经理,在团队中是什么角色?提需求,写需求文档,跟各个环节的执行者沟通。

他们不是领导,胜似领导,说话的风格通常是这样:

命令式——“X同学,这个需求你做一下。”
商量式——“X同学,这个事比较紧急,看能不能优先?”
渴求式——“帮帮忙,马上要上线了,这个问题解决一下好不好?”

不论什么方式,结果就是,设计怎么做,开发做什么,源头都来自产品。

故而,产品的眼界,决策力,对需求的判断、整理和规划能力就显得尤为重要,否则整条线都跟着折腾,要么方向错了,开发到中途放弃/夭折,要么逻辑没有理清楚,各种的修改和增减,本可以两天弄完,拖到一周,本可以下班之前弄完,加班到半夜。

另外,由于产品经理工作的特殊性,需要跟各环节沟通,高效沟通就成了关键,怎么算高效——我说的你懂,你知道怎么说我能懂。而且最好一次把事情讲清楚,避免“我以为你知道,原来你不知道”、“上次跟你说的时候说漏了”等情况出现。

如何改善?一方面靠产品自身素质和意识的提升,如何列需求,怎样整理问题,然后,跟业务相关的跨领域知识稍懂一些,比如设计,是单屏还是多页,想要什么颜色,放在什么位置,想以什么样的形式突出,给用户什么感觉,等等,并不涉及很具体的专业知识,只是站在一个用户习惯和交互需要,较准确地跟设计师传达信息,设计师就能有针对性地做出接近理想的效果,降低返工率。

当然,还有另一方面,后面会提。

设计、开发

设计和开发在跟产品沟通的时候有个共同点,专业领域的东西产品不一定懂,但相比之下,设计的东西更好懂,说到底它是人的视觉感受,可以用自然语言表达出来——“颜色淡一些”,“那块突出一些”,“这里加一根线”等等。

难的是开发和产品的沟通,涉及较多细节。比如说:

  • 什么是块,什么是条。
  • 需要做的是一个页面,还是在现有页面里添加一个组件。
  • 点击的是整个条,还是一个箭头。
  • 有没有可能空、超出、报错。

这几个看似较简单,但有时反复跟产品确认还是会出现认知偏差。等做完了,他又说“哦,原来你说的是这个意思啊”,这就比较尴尬,而且会让人心里很没底。

更纠结的是开发复杂度的认知,本来简单的,他觉得复杂,当他拿来一个看似简单,其实挺多工作量的需求,说“这个需求很简单,给你两个小时就能做完了吧”,实际的改动可能很复杂。

这就涉及刚刚没说的另一方面,除了产品在不断的合作当中了解专业概念、习惯之外,设计和开发也需要把自己专业的东西更通俗和直观地表达出来,把他们不了解的开发理念、习惯做法告诉他们,双方达成大致的共识,时间长了,就会更懂对方。

进步

进步不分工种,不分级别,你更优秀,能做的事情更多,解决的问题也更多,而不是碰到问题总爱说“这个好像搞不了”,你不解决,他不解决,问题就一直存在,成为团队长期的包袱。

当习惯了“知难而退”,你会默认自己的工作就是那样——重复、琐碎、无趣,没有上升空间。没有一份工作是专为你提供学习和进步机会的,有时瓶颈不是来自外界,恰恰是我们自己。

项管

我本人所在的团队经历过一次变化,在那之前是没有项目管理者的,有需求产品经理直接找leader,leader看开发的排期情况安排,这样就有一些问题,提需求的时间不确定,大小不确定,随时可能来需求,leader疲于沟通和协调,开发时间线也是乱的,工期难以评估,交付压力大。

后来来了个专门负责排期的人,每周安排固定时段开排期会,就有了改观,一周的需求在两三个小时内安排完毕,设计和开发随即和产品经理沟通需求,评估开发量和工期,虽然不是每次都能严格按照规定进行,但总体好了不少。

项管的工作就是协调人力、时间,跟进项目进度,保障在预定时间完成上线。在多人团队中,项管的方法和效果直接决定了开发节奏和体验,很重要。

链条

我们都有这样的经验,领导谈工作喜欢看结果,因为无限顾及细节,结果好了,才算成绩。

结果不是某个人,某个环节能够成就的。

从开发角度,我们已经做了很多探索和努力,从三驾马车裸奔,到层出不穷的工具、框架、库、处理器、压缩、合并、预加载、缓存…看似挖无可挖,还有PWA、Serverless、Flutter,优秀而又有追求的开发者们一直在向前逼近,似乎要把挡在面前的障碍全部扫清。但团队是一个整体,一个链条,不宜割裂看待。你把代码写好了,高度还原,可维护,又健壮,突然说要改,列一二十条,不要疯么;你绞尽脑汁将代码压缩精简了20k,不知道谁上传了一张80k的图片,努力几近白费;你在做着这个需求,忽然有另一个需求插进来,眼瞅着要耽误工期了,不急么。所有这些,都需要每个环节的妥当安排,配合默契,才能灵活应变。

人的状态对了,节奏对了,氛围好了,利于个人出成绩,也利于团队出业绩,是件双赢的事情。

寥寥数语,权当茶后闲聊,时间原因不是很全面,如有冒犯,还请包含。

读者朋友有何高见,欢迎交流。

原文链接:ideazhao.com/2020/02/17/…



关注下面的标签,发现更多相似文章
评论