产品经理对接最多的就是你所负责的产品的程序员，而且沟通频率最高的应该也就那么几个，如果能够得到他们的足够信任和理解，相信你的很多需求都能事半功倍。
如何建立和维系自己对接的程序员的和谐关系，应该是每一个产品经理都会面对的问题。
这就像互联网从业人员如何平衡工作和家庭一样，是一个永恒的命题，但却没有一个标准的答案。
因为每一个产品处理需求的方法论、做人做事的方式都不尽相同，我只说下自己的体会。
我对接的研发使用的语言是Java，数据库有MySQL、hive、Redis等。
可以利用自己的业余时间和需求沟通中，了解一些基本知识。
比如Java的数据类型、逻辑运算符。
这些在做一些数据需求和逻辑判断、跳转的需求中能够用到。
而数据库查询是我日常使用频率最高的，必备的就是常用select语句，有了这些基本可以脱离研发，自己定位一些线上问题的原因，比如问题数据的重试次数、错误码、落库消息内容等。
能够掌握上述两个主要工具的部分技能，个人感觉已经不错了。
另外还有一些公司级的中间件，比如MQ管理系统、线上发布系统、性能测试系统等，这些系统因公司不同而异，不过功能基本相似，对于产品来说是锦上添花的技能输出。
毕竟，技多不压身，时间和精力都允许的情况下产品可以多多涉猎。
一个需求完整生命周期的80%的精力应该放在需求开发前的准备工作：
需要覆盖的业务范围、可能出现的正向逆向场景、需要的数据类型枚举、对上下游的影响等。
尽量把需求细化，需求做的足够细化就会大大减少需求变更的次数。
达到这个目标的一个必要不充分条件就是：
产品对自己负责的方向有足够的项目经验或需求经验积累，以及由此沉淀出的解决类似问题或相关问题的方法论。
所以，在完成自己本职工作之外，对自己已完成工作的总结和思考也是自我提升的一个捷径。
在没有足够的需求说明、培训资料的前提下，一个产品如果要深入的了解自己系统的功能，多数情况下是依赖研发，因为他们可以通过代码、注释来对你的疑问进行讲解。
作为产品，即使你对自己的方法有足够的自信，也尽量不要“生死看淡，不服就干”这种态度来命令研发怎么做，毕竟大家都想听好话，你说对吧？
“用XXX方法弄”和“是不是可以考虑用XXX方法实现呢？
“，同样都是建议，如果换了是你，也一定知道选哪个。
退一步，如果自己建议的方案有问题，这种咨询和试探性的语气能让研发感受到对其能力的尊重，他也可以从专业角度给你一些建议。
另外，实现一个需求，可以有多种方案，并不是每个需求都是
高并发、高性能、高可用的业务场景。所以，“北京市第三项目组提醒您：方案千万条，和谐第一条。沟通不规范，产品两行泪”。
每天怀着愉悦的心情工作，也是一种享受。
个人觉得，工作和生活之间的界限没有那么清晰，不是“进了公司门，我们聊工作；出了公司门，互相不认识”那么纯粹，起码我是做不到。
一个大项目上线无问题，请研发GG一起吃个饭撸个串什么的。找研发聊需求的时候看看程序员买了什么定制款键盘，穿的AJ多少钱抢的，买的车是什么配置。这些看似扯淡的闲聊无意间就缩短了你们之间的距离，甚至后期你都能在闲聊中把自己小的优化需求说了，而他最多骂你一句不要脸。不要问我是怎么知道的。
以上都是针对产品的建议，如有不足，欢迎大家指正。另外也欢迎程序员分享你们的一些建议或心得，这样也能帮助我提高。
每一个程序员都是折翼的天使。所以，好好守护他们吧。
———— / END / ————
作者：接蒜君
微信公众号：接蒜君（jiesuanjun）
一个专注结算方向的互联网产品。本公众号经授权发布本文，转载请联系作者。
