1、多沟通，尤其对于分歧点多做沟通，着重沟通，直至双方（各方）理解业务，基于一个项目而言，很多的分歧点之间联系紧密，宏观看不出来的点，是需求变动，设计开发不断修改的前兆，是后期运维难填的坑，一个项目实施的业务方、需求方、设计、开发、测试、运维、管理息息相关，所以千万不能因为上火、所谓麻烦而回避沟通；
2、回避隐性问题能获得一时的轻松，大环境如此，如果你努力了，多方建议了，给出实施方案了，坚持了，却被不做沟通和讨论的回避了，那么请自重，时间诚可贵！
注：
（1）想出办法不参与上线后的各种背锅会议，注意啊，是背锅会议，口舌之战勿参与，当时的建议和方案在当时邮件抄送协同人员；
（2）自己负责的模块开发结束后，趁早及时参与到其他项目中去；
（3）项目经理买的奶茶千万别喝！！项目经理给的零食千万别吃！！——一个JAVA小开发的吐血经验
3、别人给的帽子不要随便戴，自己立场要鲜明，热衷拳击的人戴个热衷打太极的帽子，同是挥挥拳，但是，是2种截然不同的运动哦~~所以即便你挂个名也会给协同方带来严重的认知误差，何况还是别人给你戴的帽子；
4、坚持自己的做事原则，时常自省；
5、平台虽小，亲历的的那些事情越是要多做思考和总结——请深度思考，借助思维导图给自己理清事情发展的来龙去脉，从宏观看发展方向，从微观做不同角色的实施，即便不能面面俱到，踩坑和少踩坑带来的损失、责任、效率、收获、项目前景不同；
6、不做工作总结的人，98%的可能其工作协同能力、管理能力、自我约束也不行，与这样的人合作除了事事当心以外，还需对症制药。这类人属于大类大概率大范围的群体，不可避免。
举例说明：身在项目，协同工作，职责很多时候可能划不清，有些协同工作总是定位不清问题，那么自己要分类处理，什么类型的工作范畴找什么人去沟通协作，需求阶段、开发阶段，运维阶段参与程度不同，不同阶段找不同权重的人；
问题分类.jpg
上图分类中：新业务需求、需求变更、需求理解找参与权重最大的那个业务人员去沟通，让其安排处理，分配任务，控制格局，切勿越俎代庖或找权重小的干系人（因为这类人一般没有担当、也不主动担当）；
7、做IT开发的，知识不断迭代更新，很多原理性的以前都没有弄懂或是渐渐遗忘了，需要定期以求职找工作的心态去进行知识的Review。
——2周前整理的面试题，2周后看着问题很多居然回答不上来，即便有些是在开发项目时用过的。
网友评论