怎么看待认识开发,产品,和整个团队的合作?

有一段时间没有写博客了,最近几个月比较忙,再加上一些惰性也没有提起笔来,昨天读了一个大神的写作说到写作积累思考的一些重要性,鄙人顿时自惭形秽,奋笔疾书,总结一下心得吧

最近一直打磨产品和业务,在想大家是怎么看待开发,产品,和整个团队的?如何看待沟通的?也许从方方面面看待都有很多形容词来总结,不过我只想强调最重要的东西,把最重要的抓好了,其他方面的即使没有也不会影响大局。


1.产品的设计:

(1)解决问题:除了功能本身,更是用户体验,它们来源于数据的分析提出的需求,进而以解决问题为目的,或者是未雨绸缪,主动性的去设计某某功能,为了吸引用户,增加粘性等等,说到底也是以解决问题为目的,如果说用户体验也是产品为了解决这个问题而去设计的话也未尝不可,这些基本都可以以数据为支撑  告诉产品现在是什么现状,需要解决什么问题。 

(2)大局观:我不是产品啊,但是我觉得整个业务都是产品设计的,那么产品一定站在一定的高度上去思考问题,这种思考也相当于开发的架构,考虑其逻辑上的扩展性,合理性,以及外观上的设计新奇,心思缜密,应该大多数时候都是运筹帷幄的,当然这也是一个比较资深的产品经理了。

我原来遇到一个产品,这边主要功能还不完善呢,他就给你提那种畸形需求,推翻了原来的一些设计,你要说没用吧,人家还是有用的,但是这东西第一有主有次,第二你得根据业务以及数据来看,第三违背初衷的事最好少干,特别是基础设计的改动,比如说你投胎生为男人,你还能重新投胎为女人吗,当然这个有点极端了啊,不过道理是这样的

开发没有什么是难以做到的,但是需求确实是有质量的,产品的设计直接影响开发的设计,因为大家都是服务一个产品嘛


2.开发的扩展性

(1)技术:如果说不重视技术那是扯淡,身为开发要知道你可以暂时不会,但是不可以一直不会,都是要不断学习不断进步的,都说程序员累啊苦啊,我觉得还好,三百六十行,哪行不累,都是矫情话,把自己的技术提升上来,效率就会提高很多,技术跟不上除了效率不行更会犯很多错误,直接导致各种bug。

各行各业的经验和规律都是有迹可循的,切忌闭门造车,有些东西很简单,可能就是不知道而已,看看好的代码习惯,好的使用习惯,好的技术总结,好的设计灵感都是不错的主意,现在都讲究共享经济,大家好才是真的好

(2)业务:开发时间越长越知道身为开发你要关注的不仅仅是开发本身而已,你更要关注业务,如果身为后端更要关注数据。就好像你是个画家,你得知道你画的是什么,都用哪些颜色了,画好后是不是自己或者用户想要的。

也就是说要对自己所服务的事情负责,产品来源于数据的支撑,开发制造工具,产生数据,那么工具和数据也是工作的一部分,缺一不可,那么开发和产品经理就会在一个战线上考虑问题,定位也就准确了很多,要知道有什么问题,才能对症下药给出什么样的解决方案进行解决,更何况代码还需要设计,需要扩展性,好的项目负责人也算是半个产品经理了

当然了,说到底一个人本身得有一个负责的态度,那么做什么事情他都会负责,原来有过这样一个经历,你和他一同开发某某模块,人家看图开发完事就可以了,什么测试啊,需求是否合理啊,改动啊人家一概不管,给什么做什么,出了问题也不是人家的责任,当然这本身也不是什么大不了的,但是如果我是老板我就不愿意用这样的员工,这个东西就和变法一样要有思考有斗志,大家都要有一个共同的认知:知道自己的工作范围,不偷懒,才能消除灰色工作地带


3.整个团队的协作性

(1)配合力:也许每个人的单兵作战能力并不是顶尖,但是一个好的团队的配合力是重中之重,大家都知道最好的对接方式和沟通方式是什么,你说的我能很快的懂,我说的你也能很快的懂,那真是和聪明人说话就是舒服哈哈,这效率不就提上来了

话说回来,这个好的对接方式是什么?产品-开发-测试,其他的暂且就不说了,有一个客观事实是我们都无法完全读懂对方的心意,更何况我们的角色不同,注重的方面也就是不同的

(2)明确:产品移交开发和测试,明确都有哪些点,列出原型和文档,完美

(3)完善:相信产品经理已熟悉整个流程,尽可能地完善思考好,站在开发和用户两个角度去想问题也许会有侧成峰的感觉,这涉及到后续改需求,产品和开发很大的痛点在于改需求,这个产品要理解一下开发人员了,很坑,小改还好,改动大了需要重新设计,反复改更恶心,这影响的不仅仅是开发本身,还有测试人员,测好的模块可能需要重新测试,有时候改动的东西可能影响到了关联业务,反反复复,严重影响上线质量和上线时间,这个产品经理需要慎重一些,这就想到了一个项目的项目负责人

(4)项目负责人:一般公司都是技术负责人担任吧,我想应该不是产品经理,如果是的话真的不太好

技术项目负责人,因为知道如何分配任务,掌控整个上线进度和上线时间,还有就是产品经理后续如果更改增加需求需要与项目负责人对接,评审迭代范围,业务影响,进而重新判断上线时间

如果是产品经理是项目负责人就很尴尬,因为站的角度不同想的就会不同,出于对用户体验的想法,增加了/修改了某某需求,开发和测试一顿忙,出于哪里不合理了,增加/修改了某某需求,开发和测试又一顿忙,没有话语权也无法做决定,所以定好项目负责人还是蛮重要的

这个现象应该很多人都知道吧,我遇到了,产品经理增加需求了,更新了下文档,告诉了前端人员,没有告诉后端,或者是告诉前端人员告诉后端人员对接一下,然后前端人员忘了。。。然后就没有然后了,这也算是项目负责人一块,有了这个角色就好多了

(5)沟通,万万没想到啊,十分重要的一块写这了,沟通很重要啊我的哥,总听人说,要会听话,听懂话,会用正常,完整的语言表达自己的意思,不怕啰嗦,就怕没头没脑的一句问别人,胡乱问别人,给其他人以不好的印象,这小子,说啥呢?。。。

啰里啰唆这么多,其实如果往大了说都是习惯,工作流程是一个大习惯,个人是小习惯,不论态度,风格,说话办事,养成一个好的习惯一切就不难了

有想法的欢迎留言啊,愿意探讨

 

 

发布了45 篇原创文章 · 获赞 44 · 访问量 17万+

猜你喜欢

转载自blog.csdn.net/Goligory/article/details/86564943