团队合作中一起共事的那些头痛事

本文探讨了团队合作中常见的头痛问题,如交互设计师与产品经理、视觉设计师、开发工程师之间的冲突,并提供了有效的应对策略。从积极参与决策、提高沟通效率、明确岗位职责等多个角度出发,旨在促进团队间的和谐合作。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

团队合作中一起共事的那些头痛事




  其实合作也很简单,多积极参与一下上游的决策,知根知底;多耐心向下游讲解一下那些只存在于自己脑子中的主观想法,倾听一下他们的建议和疑惑。多往彼此那边靠一靠,心就能挨得近一点。




  面对交互设计师的痛苦:




  1. 不主动帮忙提供解决方案,而是先PK需求。




  怎么办好呢:交互认清自己和岗位定义,采取积极配合的态度,多提建设性的意见;同时在需求构思阶段产品最好能拉上交互一起讨论,同时为需求寻求客观的用户数据支持。




  2. 闷头画稿不沟通,画出一套自己满意的稿,却和自己预期相差很大。




  怎么办好呢:建议交互画粗糙纸面稿,经频繁沟通讨论,再绘制精细纸面稿。再次确认沟通后,才用软件绘制精细线框图。逐渐细化,把矛盾逐批解决,不至于积累到最后爆发。




  针对交付衔接:




  1. 各个角色在交付文档后,承接人的理解会走形。




  怎么办好呢:各种交付物在交接时要由负责人在交付评审会上逐条讲解,以实现充分理解。交付物只是用来备案的,不是用来沟通的。




  2. 对上游的交付物和交付时间有疑问,不直接询问相关责任人,而是先来询问产品,再由产品转告。




  怎么办好呢:对特定角色的工作有疑问,要直接咨询此人,同时确保产品被知会到。




  交互设计师




  面对产品经理的痛苦:




  1. 功能点照抄竞争对手,以至于界面无需思考,照抄即可。




  怎么办好呢:请产品经理讲清楚每个功能点背后的用户需求和真实的生活场景,描绘该产品对用户的生活会带来怎样的帮助。




  2. 需求思考不清楚,经常变更。




  怎么办好呢:争取参与前期的需求制定阶段,辅助产品经理讨论清楚用户使用场景和功能点,然后再列述下来。各合作方在需求评审会上公开确认需求。




  3. 过度干涉控件布局等细节。




  怎么办好呢:产品经理应首先专注于挖掘靠谱的用户需求,并清晰地列述功能点和帮助用户实现的目标。这些用户目标就是用来衡量交互方案是否有效的客观目标。切忌用主观标准否定设计方案。




  面对视觉设计师的痛苦:




  1. 以美观之名更换控件,扰乱任务流,忽视对相关页面的影响。




  怎么办好呢:交互应该设计中期就拉入视觉一起讨论,让视觉知道每个控件的用意,同时坦然接受视觉对交互方式提出的合理建议。




  2. 调整控件布局,扰乱元素的主次关系




  怎么办好呢:同上。




  视觉设计师




  面对产品经理的痛苦:




  1. 用主观的“我不喜欢、我觉得不好看”来否定设计稿,无法用客观的词汇描述预期效果。




  怎么办好呢:产品经理应该将对视觉方案的要求书面留档,并以此为作为评估设计方案的客观标准。




  2. 经常变更需求,并且天真地认为所需要做的调整超级简单,一秒搞定




  怎么办好呢:产品不要低估调整视觉方案的工作量。视觉也可以在初稿阶段试试产品经理的口味,多倾听一下彼此的意见。




  3. 对自己的审美能力很自信,对设计稿指指点点说“要这样移、那样调”




  怎么办好呢:视觉风格方面产品经理应充分信任视觉设计师的审美能力,给建议时也要态度诚恳,淡化盛气凌人的感觉。




  面对交互设计师的痛苦:




  1. 布局控件时不与视觉沟通,直接丢一套线框过来。




  怎么办好呢:交互邀请视觉参与线框图的设计阶段。




  2. 设计的交互稿没新意,太老套死板,了无趣味。




  怎么办好呢:交互要多玩多看多体验,丰富自己的设计储备库,以便厚积薄发提出让人眼前一亮的设计。




  面对开发工程师的痛苦:




  1. 改参数,并坚称自己做的更美观。




  怎么办好呢:视觉对于自己责任范围内的设计稿参数标注要尽量详尽,给出完备的视觉设计稿作为客观的衡量标准。在开发完成后要及时走查,并跟进问题的解决。




  2. 不用切图素材,用代码来实现效果。




  怎么办好呢:视觉首先要确保给出的切图素材十分完备;开发也要克服惰性,将视觉素材充分利用起来。




  3. 对像素、肌理、阴影不敏感,看设计稿不仔细,实现效果与视觉稿差异很大。




  怎么办好呢:对开发容易忽略的视觉细节,视觉设计师要与面向开发讲述。交付的设计稿只是备案,不是高效的沟通方式。开发同志们是没有视觉那样的像素眼的。




  面对产品经理的痛苦:




  1. 对产品前景没有充足考虑,每次发新版本代码都需要推到重来。




  怎么办好呢:产品经理要明确产品发展的大方向,并将远景清晰地阐述给合作伙伴,以便开发在搭建程序时为未来留好空间。




  面对交互设计师的痛苦:




  1. 设计稿缺少细节:每个页面可响应事件的区域,响应的动作,操作成功和失败的反馈。




  怎么办好呢:交互设计师除了描绘页面之间的跳转关系,还应该将页面内部所有的事件响应文档化,减少开发的误解。不要怕麻烦。




  面对视觉设计师的痛苦:




  1. 没有定量标注设计稿的每一个细节。




  怎么办好呢:请视觉认识到定量标注细节对于开发无损地实现视觉稿的重要性。开发是没有精力去猜或者量一个特定参数的。




  2. 切图不完备,遗漏细节,需要开发自己用代码补。




  怎么办好呢:每一个细节的素材都切图切出来,并系统地使用文件名命名方法,帮助开发理解。




  一遍看下来,有没有觉得背上冒冷汗呢?一切依着自己的性子往前走,真的很难发现自己有哪些地方做的不对,不知不觉就给别人留下了心灵的创伤。

资源下载链接为: https://pan.quark.cn/s/22ca96b7bd39 在当今的软件开发领域,自动化构建与发布是提升开发效率和项目质量的关键环节。Jenkins Pipeline作为一种强大的自动化工具,能够有效助力Java项目的快速构建、测试及部署。本文将详细介绍如何利用Jenkins Pipeline实现Java项目的自动化构建与发布。 Jenkins Pipeline简介 Jenkins Pipeline是运行在Jenkins上的一套工作流框架,它将原本分散在单个或多个节点上独立运行的任务串联起来,实现复杂流程的编排与可视化。它是Jenkins 2.X的核心特性之一,推动了Jenkins从持续集成(CI)向持续交付(CD)及DevOps的转变。 创建Pipeline项目 要使用Jenkins Pipeline自动化构建发布Java项目,首先需要创建Pipeline项目。具体步骤如下: 登录Jenkins,点击“新建项”,选择“Pipeline”。 输入项目名称和描述,点击“确定”。 在Pipeline脚本中定义项目字典、发版脚本和预发布脚本。 编写Pipeline脚本 Pipeline脚本是Jenkins Pipeline的核心,用于定义自动化构建和发布的流程。以下是一个简单的Pipeline脚本示例: 在上述脚本中,定义了四个阶段:Checkout、Build、Push package和Deploy/Rollback。每个阶段都可以根据实际需求进行配置和调整。 通过Jenkins Pipeline自动化构建发布Java项目,可以显著提升开发效率和项目质量。借助Pipeline,我们能够轻松实现自动化构建、测试和部署,从而提高项目的整体质量和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值