项目主管新手求助， java 开发人员配合问题

json 的话 spring 配合 jackson 就很好用，如果单独用就 gson ，也是好用到不行，很简单。
如果返回不规范，只能说你那个同事真的好水，这种只能强制要求用什么东西的。

这些家伙就找个机会开了吧，找别人顶上，唔，个人感觉还不如我这么没毕业的

@julor 不知道是你理解的问题还是我说的不够清楚，帖的那段代码是说明 json 对空白字符不敏感的，而不是转换程序

@SoloCompany 应该我理解错了，但是我确实是使用 JSON.parse 无法正常转换

楼主不急 , 由我个这个产品狗(顺带项目经理)给楼主解释下.

从楼主的描述里面来看. 楼主是缺少点 IT 项目经验, 特别是比较规范的 IT 开发模式. 但是楼主还是很好学的,不然也不来这咨询.

1. 行有行规,作为 IT 就需要按照标准来, JAVA 用 Webservice,还是直接的 HTTP 请求,返回 XML. 返回 JSON 都是很容易的,而且也是必须的. 现在如果接口只是给前端 Web 页面使用,都使用 JSON, 至少我是这么要求的.
XML 这个一般都是做给其他系统做接口用. 楼主可以先把相应的 JSON 格式定义好,然后交有后端人员开发.告诉他们,我就要这个格式. 前端也会按照这个格式解析. 约定好. 通过邮件,说明书的方式.

2. 很多 IT 人事虽然工作年限多,但是都是小公司到小公司.未进行系统的学习,不了解一些最佳项目实践.在他们的印象中,能完成工作就行了,不会去考虑太多的规范的事. 需要楼主去引导,拿出例子,比如上个项目怎么怎么. 对于他的态度,楼主大可放心,慢慢他回适应的,你得给他适应期.

3. 楼主需要加强学习..系统的学习 IT 最佳实践. :)

楼歪了， LZ 来问管理相关的事情，都在说技术的问题，看来一个是技术宅比较多。

我和你一样是新人，但有几点 LZ 你没有说清楚：
1 ，你目前和其他两个同事的关系（职位或管理与被管理者之间的关系）
2 ，项目管理比较抽象，最好说清楚你的具体职责内容（在不同的公司项目管理者的职责是有区别的）

就我看 LZ 的问题作出的几点推测：
1 ， LZ 工作大约在 5 年左右，或者>= 5 年
2 ， LZ 管项目，可能没有在管人

我的看法：
1 ，程序员走到带管理头衔以后，打交道的通常不是人就是机器。因为长期和机器打交道习惯，很多事情或许就有点像当然了的，因为与人打交道是最复杂也最难的，主要来源于人拥有感情和思想两种属性。
2 ，在做管理层的时候，除非是老板，其实都是夹心层。凡事不能仅仅看结果，还要多少关注过程。有些指令也好，软磨硬泡也罢，表面上看达到了效果，其实对方有千万个神兽在奔跑。这次的合作“成功”不代表长期的合作“成功”
3 ，作为项目管理，也分为产品类和技术类。不管自身出身如何，主要看头衔属于哪一类。如果偏向于产品类，最好多用产品方面的思维和语言同程序员打交道。如果属于技术类管理者，除了要用技术的思维和语言打交道，关键还有了解产品的一些“细节”（但不需要了解的太细），同时也需要了解到实现的难度与意义。
换句话说，如果你是偏向产品类的项目管理者，你用产品的思维去处理最合适，千万不要带着你曾经的技术背景去和程序员打交道，因为具体的开发人员并不买这一套，而且最终做下来，你会发现你的管理产品不像产品，技术不像技术。
对于偏向技术类项目管理者，你最好用技术的思维处理问题，但也要学会体谅开发人员的难处。
4 ，信任手底下的人，但也不要太信任。正如人是具备思维和感情的，你不能保证情商极低的程序员把对公司的火发在你的项目上，直接导致项目流产或者失败。所以应有的信任应该给予，但对于那些不该信任的人，你要小心点。
5 ，技能水平和工作年限不一定存在比例关系。我这么给你说，我曾经遇到的一个 82 年的人，硕士毕业，按照从本科毕业+硕士折算工作经验的方式计算，这哥们差不多也有 10 年工作经验了。但事实上呢？连个 mfc 的工程都不会建，最简单的 C++内存泄漏都不会检查，什么是野指针和零指针都不知道。还成天宣扬自己工作 10 年，写了 10 年的 ace ，做了 10 年的内存池和线程池，最简单的用 win32 api 都不会开线程，最基本的线程通讯都不会。
所以，不要简单的按照工作经验或工作市场看待人。工作经验或工作时长，只是工作的一个敲门砖而已！



说这么多，祝 LZ 一切顺利。以前成天当个板砖的小屌丝快快乐乐的写代码，没心没肺的过日子。当作上包工头以后，没见工资涨，但烦恼就来了。共同磨练哈！

等等，我最近对接过一个公网项目，对方是 java 开发的接口，返回的是不标准 json ，主要是自己拼接了某个字段导致的 o(╯□╰)o

@salltm 明显发现基本不按讨论来，看来还的用邮件强制说明，规定一些要求。

@salltm 我倒非常想定下规定，可是没这个权利，算来算去只有责任没有权利，听无听对他们影响不大。

@julor @hantsy 的建议是非常中肯的，如果你有探讨技术架构的权限，我觉得你可以尝试改变一下，这也是技术管理者的义务和职责，没必要总是把眼光看着下面的人。