—致与程序猿的那段撕逼岁月

以前，总觉得程序猿是个可爱的物种，但自己真正做项目，与他们合作的时候，才发现什么叫“物种差异”，作为产品汪，特别是小白产品汪，有时候真的很难理解程序猿的思维，加之产品汪容易暴躁的天性，于是乎，撕逼也在所难免！一场场腥风血雨拉开帷幕，悲壮而惨烈！！（=。=此处略有夸张）

虽然撕逼的过程极为虐心和残暴，但鲁迅欧巴不是说过吗：“真正的勇士，敢于正视淋漓的鲜血”，于是，我今天就扯开伤疤和大家分享一下我与程序猿的撕逼经历与心得！（=。=来来来，一起舔伤口）

下面是我遇到的一些程序猿喜欢使用的大招：(前方高能！！)

PS：很想把它画出来，可惜小女不才……

大招一：“介个很简单哒！”

产品汪：“猿猿，设计狮这两天有点忙，设计图暂时出不了啦~为了项目进度，这两天要不你们就先按原型搭框架吧~”

程序猿：“这个完全没有必要啊，介个这么简单，给图四五天就搞定啦，很快的！”

产品汪：“恩，好哒！”

N(N>10)天过去啦……..

产品汪：“猿猿，×××写好了没，能给我看一下demo吗？”

程序猿：“这个，得自己写插件诶，花得时间会比较多，所以…”

产品汪：“…”〒_〒

分析诊断：这个场景除去程序猿稍微有点点偷懒的嫌疑之外，主要反应了产品汪和程序猿间信息不对等的问题。产品汪提供想法，知道表现形式，但却不清楚其本身的原理与实现，于是，因为没有对界面元素进行基本的开发难度分析，就丧失了很多对项目整体的把握权，处于一个被动的地位。所以，如果产品能够懂一点计算机语言，对整个产品的掌握就会更深层次一些，更有利于对项目的管理。

大招二：“我想按照自己的想法来哟”

产品汪：“猿猿，你最近进度很慢，是不是有其他事在忙啊？”

程序猿：“没有啊，一直都在写啊，我在用我自己的方式在写。”

产品汪：“噢~自己的方式？”

程序猿：“我想按照自己的想法来写，×××时间我给你完整版的，这期间就不向你每天汇报进度了。”

产品汪：“额…好的吧~”

×××时间差两天时…

产品汪：“猿猿，快到×××时间啦，应该快搞定了吧？”

程序猿：“还没，倒数第二个功能刚写完，要开始倒数第一个了”

产品汪：“速度有点慢，要抓紧时间噢~”

×××天加四天……

产品汪：“猿猿，说好的demo呢？”

程序猿：“晚上给你。”

晚上到了…

产品汪充满期待地打开程序猿发的应用包，瞬间石化了。。满满的UI bug，部分界面惨不忍睹…O_o

分析诊断：程序员对项目实现有自己的想法固然好，但毕竟对一个应用来说，优美的UI和良好的用户体验也是极为重要的，但程序猿注重得更多的是代码，而缺乏对UI和用户体验的思考，单用编程的思维去思考一个功能的实现当然是不合适的。所以，当程序猿对你说他想按照他的想法来做的时候，一定不能让他放任自流，一定一定要先问问他的想法是什么，和他把细节完善好，至少要给他提出相应的UI要求和用户体验目标！给程序猿开发自由也是要有限度的呢！－O－

大招三：“UI bug下一版再改”

产品汪：“猿猿，这个测试包里面还有很多问题哦，我整理好了文档，你对照着修改一下bug噢！三天以后要给我哟~”

程序猿：“好的，我看看。”

两天后…

程序猿：“已经把几个模块连接到一起了。”

产品汪：“好哒，真棒呢！”

当产品汪欣喜若狂地打开测试包，瞬间石化了：那些可耐的bug依旧静静地躺在那里，不离不弃〒_〒

产品汪：“你为什么没有修改我给提的那些问题啊？”

程序猿：“只要没有功能Bug就先上线吧，下一版再改。”

产品汪：“可是酱紫很影响用户体验诶，酱紫没法上线啊！”

程序猿：“UI bug又不会影响应用上线，一定要做得那么十全十美吗？”

其间省略一大段撕逼……简直没法沟通啊Orz

分析诊断：在程序猿的思维方式中，对用户体验方面的因素很可能会缺少考虑或者直接忽略，对他们而言，最应该修复的是功能bug，的确是产品bug对于产品来说最重要，但这并不能说明修复UIbug是锦上添花的事情。所以，产品汪还是应该多和程序猿进行沟通，让其了解到一个适合应用的UI对产品的意义，当然必须得有理有据噢~

大招四：“应该可以完成。”

产品汪：“猿猿，介个功能得快点完成，你××号能写好吗？”

程序猿：“应该可以做完，我尽量。”

产品汪：“好哒~那××号check噢~”

程序猿：“恩，好….”

日月如梭，××号到啦！

产品汪：“猿猿，搞定了咩~”

程序猿：“额….还没呢，其间出现太多bug了，而且××功能比较难实现，我正在想实现方式…”

就酱紫，产品汪的DDL君很不爽，因为每次约好和新功能见面，结果几乎都被放鸽子了……

分析诊断：这种情景的粗线排除有时候可能有程序猿懒病犯了之外，更多的时候是二者都有做得不妥当的地方。对产品汪来说，制定DDL一方面要根据项目的进度，但也应该考虑到程序猿的开发难度、开发时间，盲目地单方面的制定DDL是不可行的。对程序猿来说，觉得产品汪压榨太残暴时，应该斩钉截铁地拒绝，再和汪汪沟通商量出一个适合自己开发速度和能力的DDL!或许是因为猿猿太过于羞射，不怎么会表达，所以，产品汪们得注意，当你发现程序猿言辞中有“应该、可能、我尽量”的词时，要考虑考虑是不是DDL出了问题！

..................................................我是泡沫横飞的口水线......................................................

那么，怎样才能减少撕逼，和平相处呢？来来来，一起来放大招！

大招一：沟通！沟通！沟通！

产品定义初期，产品需求实现，添加新功能、修改功能时，和程序猿沟通沟通，看看哪些能实现，是否必要，怎么实现最简单高效。这些东西前期处理好了，一方面能增加程序猿的项目决策参与感，让他们感到自己不再是只是个敲代码的，另一方面，能让程序猿理解你的产品思维和逻辑，减少了很多后期撕逼的发生！

大招二：产品需求文档——防撕逼神器！！

最好写一个产品需求文档，它能清晰地展现出整个产品的脉络和逻辑，书写它能够帮助产品汪理清产品的思路，完善细节，酱紫能减少很多因产品汪思考不清而导致的错误开发、需求更改太频繁等原因所造成的撕逼，它能有效减少因为程序猿搞不懂产品汪的逻辑所导致的撕逼，这类的撕逼少了，项目进度就快了，那么又能减少程序猿因思路不清晰开发过慢，DDL总超期所造成的撕逼……（此处省略N个它能）

大招三：关心他们！——做他们的私人程序猿鼓励师！

说到介个，应该又会有很多人在脑补产品汪变身贴心的sweat的鼓励师，端茶送水，按摩捶背，撒娇卖萌…..如果产品汪刚好是只公的，那画面就真是太美了！！嘻嘻，说正经的，产品汪站在一个动物保护协会的角度上，平常也应该多关心关心脆弱的程序猿，不要一找他就是催进度，改需求，各种撕逼，找他聊聊天，聊点生活的呀，学习的呀，情感的呀，如果能顺便帮忙给他们介绍个女票也是极好的！开会的时候带点吃的呀，时不时请他们出去吃一顿，看看电影，放松放松呀！酱紫，撕逼在愉悦的相处氛围中就会慢慢离去了~

大招五：告诉他们你是“学霸”

作为“学霸”的你应该眼观四路耳听八方，知识渊博，掌握行业内的各种动态，分析市场趋势，没事就盯着友盟的数据看，各种国外新推出的牛逼产品统统用起来。那么程序猿们会觉得你什么都知道，你的判断八成是靠谱的，在你为他提出修改建议的时候，或许就不会那么抗拒了。

大招六：我很负责哟！

在被追问为什么进度这么慢，为什么还没上线的时候，冲上前去说，“都是我的错，前几天又改了个需求”。（此条略有夸张，只是为了强调产品汪一定要有责任心~~）不论什么时候，都要对产品，对团队百分之百地负责和用心，责任心可获取信任，他们会觉得你很踏实！

大招七：招美美的妹纸！！

在招新的时候，为招新策划一个great的方案，拼尽全力招很多养眼的妹纸，最好还懂点技术，最好还是单身……（此条纯属YY哈！哈！哈！）

只要你修炼完这七个大招，保证你轻轻松松KO撕逼大怪！加油，少年郎，看好你哟！

致读者：hello!各位亲爱的boys and girls!

我是大bo，为了避免大家在看文章时产生疑惑，在这里先和大家简单声明一下~我现在是一个互联网学生团队的成员，还没有毕业，所以这些内容写得都是团队里发生的事哟~并不是公司里哒~虽然会有些差别，公司的程序猿可能没这么任性，pm可能不像我这么水，但还是有些可以参考的地方哟！嘻嘻，共勉！！

第一次发文排版很丑，感谢你萌能赏脸读完！！