V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
refresh
V2EX  ›  程序员

你会百分百重现设计师或者产品经理的东西么?

  •  
  •   refresh · 2013-12-07 14:57:07 +08:00 · 3482 次点击
    这是一个创建于 4032 天前的主题,其中的信息可能已经有所发展或是发生改变。
    比如有时候可能是觉得他们不合理;有时候可能是因为他们不懂某种技术,所设计的某种效果或功能不经济,例如一个用户并不觉得好或者感觉不到的效果,你可能需要多花一天的工作量;有些时候可能是设计/产品人员真的不太懂,例如在在Android上呈现iOS的UI,或者把iOS的UI照搬到WP上去。

    遇到这些问题,你怎么办,完全按需求做?提一提,不同意就算了?尽量坚持自己的想法,说服他们?
    似乎蛮多公司要的是完全按需求做的人,执行力与创造力会不会有些矛盾?
    10 条回复    1970-01-01 08:00:00 +08:00
    mongodb
        1
    mongodb  
       2013-12-07 15:46:21 +08:00
    完成工作是分内之事,假如闷头按要求做完全无可厚非。
    与设计和产品多做沟通提出自己的见解也是理所当然,有能力做好交流并在设计里体现自己的想法那是能力的体现,要是无法说服就努力提升自己让自己有能力有资格去实现自己想要的东西。

    没任何矛盾,只有自己能力的问题。不管是自己的眼界还是和团队沟通的能力。
    bombless
        2
    bombless  
       2013-12-07 16:06:03 +08:00   ❤️ 1
    还有一种情况是,他没想到他的2个想法其实是互相冲突的,不可能2个都实现
    这种情况下只有解释清楚了,不去解释就是你不负责任了。当然对方没考虑好他也有责任

    实际工作中,如果他自信心很强大不觉得2个想法有冲突,那我没办法了,先实现其中一个想法,让他看过之后数落我一通让我改,我再改回另一种。来回改几次他就会意识到他的想法有多蠢了。

    当然啦,这种拉锯战都是费时费力,负合游戏。但你还能怎么办呢?
    只有一个终极的解决方法:换雇主。
    当然,你牛的话,也可以让对方走人。
    66450146
        3
    66450146  
       2013-12-07 16:06:13 +08:00
    试图说服他们,但是最终由他们来决定

    如果要增加很多工作量,就让他们知道需要很多工作量,让他们自己去决定

    最后一点:没有报酬的加班免谈。控制不好进度是管理的问题,不是开发人员的问题
    dorentus
        4
    dorentus  
       2013-12-07 19:35:18 +08:00 via iPhone
    不会。反正最终做成啥是我自己决定和负责的…
    railgun
        5
    railgun  
       2013-12-07 20:28:03 +08:00   ❤️ 1
    默认情况下,是按照最初商量好的方案做。
    中间我想改的话会找他们商量,他们不同意就按他们的想法去做,反正不是我的产品(我是外包的临时工……)
    如果他们途中要改我会尽量推到下个版本去。反正原则是增加的工作量另外算,交货时间顺延。
    kamal
        6
    kamal  
       2013-12-07 23:30:10 +08:00
    @66450146
    对,你根据不同的设计估算出来工作量让他们决定好了。

    关于设计,你可以提出自己的意见,给设计师参考,让专业的人来做决定。
    dorentus
        7
    dorentus  
       2013-12-07 23:32:45 +08:00 via iPhone
    我以前在的那家互联网公司是这样的:设计、产品、开发同属一个一个团队,大家是平级的,理想情况下是产品经理给出策划案,然后设计和开发作为下游在策划案的基础上工作,设计师的工作成果最终也是给开发用的,于是开发者就是最终的下游了。

    实际实施的时候肯定会有上游想错了、下游做错了的情况出现,那么发生这种事情的时候肯定是要尽早沟通的。另外作为上游,如果经常搞飞机;或者作为下游,发现问题仍然硬上,那么就有必要反省下自己是否称职了。

    对于来自上级的要求,假如有问题的话也很简单,问题肯定还是要好好反馈的,如果上级决定硬上,那么也没问题,出了问题我这边不负责就是了。
    sgissb1
        8
    sgissb1  
       2013-12-08 01:03:07 +08:00   ❤️ 1
    知己知彼,百战百胜。

    码代码的不一定什么都懂,产品/设计也不一定什么都不懂。

    搞清楚自己是不是真的能不能做,以及搞清楚对方是不是为了敷衍kpi或者推卸责任到开发身上,或者装逼比较重要。

    这样看问题就能够客观了。该拒绝的还是要拒绝,做不了的要上升到管理层去讨论。这才是高效做事。
    太差的码字员要早点换,太恶心的产品/设计要早点滚蛋。

    剩下的就是磨合问题了。
    charlestang
        9
    charlestang  
       2013-12-08 01:04:54 +08:00
    产品经理也有区别的,有的产品经理非常地感性化,这种类型多出现在女性身上,容易陷入局部思维,对某个细节狠扣,其实呢,捡了芝麻,丢了西瓜,而且还总容易站上道德制高点,比如说“用户会觉得难用”这种话,就是经常用来说服开发的理由;另一些,是理性化的,喜欢全盘分析,抓重点,这样的产品经理关注目的,在手段方面,容易妥协,比如开发说,这样不行,他会说,那那样也可以,比较好说话;

    我比较倾向于喜欢以理服人的产品经理,使用数据、实验结果说话,而不是把自己当成用户去代入,然后给出情感化的论断。

    关于产品经理的职权问题,这很重要,如果公司是产品经理导向,你有些时候,真的不得不执行一些自己不喜欢的命令,实现一些自己不喜欢的特性;我的leader在这方面很值得人学习,他很有耐心,反复从多方面论证并说服,就算无法说服,他会先接下来,然后实现它,想办法用更好的证据,证明这是个错误,比如数据说话,用户说话之类;但是我很难有这个耐心,就容易生出对工作的倦怠,觉得一群扯淡的家伙,但事实证明,这没给我带来任何好处,也没有解决问题;

    现在,我似乎更容易妥协,一般我肯定会指出我觉得不妥的地方,然后告诉产品经理说,关于这个潜在的问题,你要确定你是知道的,对方如果确定,我就会去实现那个功能;这些无非就是浪费一点时间而已,对产品的伤害往往没有想像得那么大,不过要因此助长了产品的歪风,危害到更大;所以,作为一个热爱产品的开发,要尽可能爬到高位,到时候选择余地要大一些
    loading
        10
    loading  
       2013-12-08 10:41:31 +08:00 via iPhone
    设计那个也是我。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2574 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 10:34 · PVG 18:34 · LAX 02:34 · JFK 05:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.