遇到问题 → 解决问题 → 总结问题

759 阅读5分钟

相信每个开发团队在开发过程都不是一帆风顺的,今天主要分享下我在项目中遇到的一些问题,希望能对更多人起到预防的作用。

一、盲目开始,没有规划

领导一句话“我们要做XXX”,没有需求文档、没有用户调研、没有规划,只有简单的做了下竞品分析,就盲目的开始了设计,在开发过程中才发现我们自身的数据难以支撑现在的设计,只好不断删减内容,从而在还原度的路上越走越远...也远离了做这个产品的初衷。 所以切记,一定要准备好了在开始,就像盖楼,如果地基不稳,就着急开始盖,盖着盖着楼倒了。我们做产品同样也需要从产品的根基抓起,如制定战略层、功能规划、进度规划、设计规划等等,只有打稳根基,才能一步一步的走下去。

二、有需求文档却不看

在项目开发中,会有一些开发不认真看需求文档,对方案和细节都不了解。这会导致在开发过程中,开发频频找产品经理或设计确认需求。这不仅会让产品和设计焦头烂额,同时还会影响整个开发效率和开发质量。 开发们不认真看文档的原因有很多,一个是个人习惯的原因,喜欢先凭着感觉写,到时候测试测出问题再改;还有一个是觉得在评审时,听懂了就可以了,实际上不看文档在参加评审时根本听不懂,回头写代码的时候更是一点思路也没有。
解决办法:经过开发流程优化,让开发画有关项目的交互时序图,这样在评审时,就能将一些重要问题提前暴露出来。

三、无效沟通

开发中遇到争端,我们基本都是如下套路:要么忍,要么撕,要么撕,要么撕……
其实,撕X的背后,并不一定是脾气暴躁,很有可能总是存在无效沟通而造成的。因为我们希望取得的结果,并不是获胜,而是解决问题。因此,建立有效的沟通方式是很有必要的。
曾经看见过一个短视频,是一个产品人通过讲述一个日本人沟通的案例来教大家该如何学会有效沟通:
产品人介绍日本人安排一个工作时至少说5遍:
第一遍,麻烦你做个什么事;
第二遍,麻烦你重复一下我让你做什么事;
第三遍,你知道我让你做这个事的目的是什么吗;
第四遍,这个事会不会出现什么意外,你怎么应对;
第五遍,你自己做这个事,有什么想法和建议。

这样一来,工作目的以及逻辑在一遍一遍的询问中就会看出来其在哪里出现了不明白、理解不对的地方,及时纠正避免走弯路。
因此我们也可以借鉴此方法:
Q:我要的要效果是,点击按钮-弹出删除弹窗二次确认后删除
Q:你听明白了么?
Q:能重复一下我说的是啥么?
Q:这样写有什么问题么?
Q:你有什么更好的建议?

四、注重体验

团队中UI这个角色不只是把原型或者静态页完成交付开发就算是完成任务了,用户体验才是我们要注重的地方,在开发过程中要时刻盯紧开发,他们是一群有着奇怪思想的动物,容易按照自己的想法去实现,如果任凭其发展则一发不可收拾,所以要将其圈在可控范围之内,如果开发完成后在回过头来改交互,为时已晚(千万不要相信开发说回头会给你改的鬼话)。

五、无形压力

在有的开发和设计眼中,产品经理就是一个天杀的存在,因为他们经常变换需求,把做好的东西推翻再改。可是在互联网产品开发中,需求变更是经常的事情,就算是临近上线了也会临时添加产品需求,更不用说在开发过程中了。实际上有时也不是产品经理想改需求,而是种种无形的压力在驱动让他们不得不改,但是,因为需求变更频繁而经常延缓产品更新上线,则是不可取的。

例子: 产品新版本临近计划上线时间,正处于测试阶段时,各种的压力就都找上门来了 boss说:这个功能为什么不加,竞品都有,我们也要有还要比他们牛逼,加上在上线! 用户说:能不能加一个什么什么功能,这样我就能怎样怎样... boss的话肯定是要听的,用户需求也要加,这种无形的压力说来就来。所以我们要学会拥抱变化~~~~,一味的抱怨是没用的。

六、技术难题

对于一个初创开发团队来说,团队技术水平有限,所以当项目开始时只能开启“摸着石头过河”模式,直到项目上线,虽然结果可能会略有瑕疵,但要相信毕竟它还是个孩子,他会越变越完美的。总之开始总是最难,但这也是进步的过程,不停地技术调研,交互方法研究,可以从中学习到很多的新知识,来填充自己的不足,大家共同进步,在挫折中成长(前提是公司愿意给你时间在实践中去学习),所以一定要珍惜眼下学习的时间,一旦时间流逝,等待我们的可能就只有淘汰。

总结

在开发过程中遇到问题不可怕,可怕的是遇到问题第一时间想到的不是解决问题而是抱怨。时刻谨记我们是个集体,遇到问题 → 解决问题 → 总结问题,调整心态,积累经验,才能让我们的团队走的更远。