工作流程不规范，环境不理想，怎么办？想办法让它变得理想，而不是一味的抱怨。
大部分人都游荡在黑暗中，他们只知道抱怨，却从不想办法寻找寻找电灯开关。
—— David Weiden
关于改变
初入职场，总是哪哪都看不惯，常常会抱怨为什么这么脑残，为什么大家的工作流程这么不规范，为什么有更好的工具却不用呢。世界上没有完美的公司，如果期待用跳槽来解决问题，那只能说太天真。周围很多人的做法是，一边工作、一边抱怨、一边筹划跳槽。最终，转了一大圈，发现每家公司都有各种各样乱七八糟的问题，初创公司，工作不规范、节奏快、累；大型成熟公司，内部斗争、缺乏个人成长体系等等。那么，在这样的环境下个人如何成长呢？
其实，每个人都能发现问题，但是只有想办法去解决问题的是真正的人才。
案例：
我：为什么公司PRD文档都写的这么不规范？网上那么多模板，随便Down一个下来参考啊。
老员工：写那么规范有什么用呢，开发都不看。
问题剖析：产品经理认为PRD文档可以不用写的规范，因为开发都不看。开发不愿意看PRD文档是因为他们一直以来已经习惯了口头沟通而不是文档沟通，所以觉得看文档很繁琐，有什么问题宁愿直接找PM。但是，我们能说这样的流程是对的吗？记得有次，我就这个问题与开发讨论：
我：“假设微信开发团队没有PRD文档，你觉得会怎么样？”
开发：“那就不会有今天的微信，产品根本就没办法推广。”
也就是说，开发也知道文档很重要，也明白文档不规范带来的问题是致命的，但是一直以来所有人就是这么干的，所以大家习惯性照搬现有的办事方法。明知道有更好的方法，却不愿意改变，因为嫌烦。也许经常有人会抱怨“怎么这么不规范啊！”，但是最终只有一个人，会想“要不要从我开始，去引导周围的人用更好的方法、更好的工具提高效率。”作为职场新人，我们总是想着，公司能提供给我们好的成长环境、能为我们提供好的做事方法，但是从公司的角度看，它也期待员工能给公司带来好的改变。
上面就是我的故事，我要时刻警醒自己，不要抱怨，遇到问题，想办法解决。以下就是一些我的一些故事。
方法没用对，经常感觉累
面临的问题1：
公司api接口文档还是采用原始的word编辑，每次后台接口有更新时，后台开发人员就得分别rtx发送给所有的终端开发人员。当终端开发人员数量比较多时，同步工作就会变得很繁琐并且很容易遗漏。另一个严重的问题是，当接口越来越多时，整个文档变得杂乱无章，对于终端开发人员而言，简直是噩梦。接口的测试也成为项目组的负担。
为了解决这个问题，决定引入api接口管理工具aPizza，慢慢引导周围同事使用。
面临的问题2：
需求文档等更新后同样需要rtx发送给所有相关人员，很容易发生其他人员忘记接收或更新文档，导致信息不同步。
其实解决的好办法是svn，但是，公司目前的svn有权限限制，开通起来比较麻烦，所有还是去网上找工具吧，最后决定用石墨文档来编辑。
公司目前使用的任务管理系统和BUG管理系统，可以满足项目协作的需求，所以不会再引入新的工具。
但是如果初创团队使用，推荐使用Teambition等协作工具。
讨好型人格不适合做产品经理
工作中强势还是柔和？
最近工作中遇到一个案例：
角色说明：
我：需求分析师（产品经理）
小X：工程技术（项目支持）在现场与客户直接沟通，负责获取初步需求
大H：设计师，资历老
场景：
小X将从客户处获取的初步需求，反馈给我，由我进行需求梳理，输出需求说明书和原型图。整理好需求文档和原型图之后，发给大H，进入设计阶段。
结果，发现设计师大H提供的图完全不符合我的要求，并没有根据我提供的原型图进行设计，有很多致命的缺点。其中一个问题是，页面中的条目项是通过接口动态获取的，且客户可在后台随意增删改，但是大H给的设计图却是固定条目。这样后续客户在后台添加、修改后，页面就得经常进行修改。
但是此时，项目支持的同事拿着这份图去和客户进行了沟通，客户表示满意。所以项目支持的同事和设计同事都表示，就按这份设计图来。后续事情的发展发表，这种方式的设计是存在弊端的，所以在开发过程中，进行了二次修改。工作中，发现问题不难。难的是说服对方，尤其是当对方是领导时。不坚持自己的想法，最后坑还得自己填。
以上。