欧宝平台从职责图和流程图对应到我们实际处在软件开发过程中好像就是这样，并无不妥的地方；但是拆分下去并结合你的岗位工作经验就会发现某些环节难以形成流程标准，和很多需要注意的细节。接下去我们可以来聊聊其中的问题。

　　以上的各岗位所管理的项目系统是涉及到与其他同事协作的工作内容，有依赖时间顺序欧宝平台、有依赖他人工作和需做出回应的。

　　涉及到协作的工作内容，我们应该做好本职工作以免给他人添加额外的时间成本、工作量，导致嫌隙；不利于团队关系和气氛。

　　在开发流程中，在完成本职工作上，为什么我们应该更加注重团队协作和工作上的合作、磨合？？？

　　软件开发需要较少的人员参与，但工作也是人做的，都会带入情绪、情感，协作上我们应该尽量通过标准化流程避免些不必要的摩擦；带给员工良好的合作体验；

　　软件开发的人员画像大部分是些内向、不善沟通、不愿多沟通的；应通过协作管理工具和流程标准来减少不必要的沟通；这样就能更专注的coding和设计，不常被流程外的消息打断、打扰，扰乱思绪。

　　在把控进度和质量上，要善于利用任务管理工具；如：Tower，任务状态更改，相关人员都会接受到通知，减少程序员的沟通时间和避开他们当面沟通能力不足的情况，转而通过文档沟通

　　对内把控项目进度、质量之外，他们的日常工作更应该关注团队管理，了解成员情况，消除不和谐因素，充当团队润滑剂。了解员工留在公司的原因，通勤时间短、公司稳定、薪资待遇、同事团队和谐、团队氛围好、职位有的发展、有利于当前学习？以及近期将来的打算和职业规划。这得要求管理者比较懂得一些为人处世的经验。

　　然而大部分中小团队的技术负责人、管理者大多都是由开发技术好的程序员晋升上去，大部分程序员性格内向、不善沟通，缺乏为人处世和管理的经验；性格里更是不愿意去触碰这些与人打交道的事情。他们更喜欢沉浸在自己的coding世界中。他们喜欢有产出，但是管理岗这工作实际工作量很多，不易看出实际的产出。对于程序员转岗的管理者来说，带不来多大的成就感，反而还加重他们的负担。在中间管理岗，对上得负责，忙于沟通，对下也得指导沟通；自己反而没时间专注写代码。最后这样的管理者会逃避管理方面的工作内容或逃离管理岗。

　　大部分中小团队提拔管理者只看到技术能力这方面的考核，过于片面，未正确认识管理者充当的角色和工作内容。

　　软件开发的技术更新速度较块，程序员这个群体是需要时间学习的，管理者要适当留出时间给他们学习，一直压榨员工时间在业务上，只会捡了芝麻丢了西瓜。

　　产品在整个开发流程中是处于关键的协作位置：原型和文档的输出、需求评审会等都确保其他岗位对于需求的理解保持一致，并且要求同短时期内的需求理解一致，因为互联网需求变更周期较短。不管哪一方需求理解错误，将会导致翻倍的沟通时间以及返工的时间。产品在设计的时候跟写程序一样要多思考边界情况，尽量减少非需求变更导致的原型和文档变更。

　　开发过程中：跟进开发产出结果确保需求正确、变更需求积主动极沟通多方到位确保对于变更的需求理解一致

　　因为：项目经理、开发、测试、UI的工作都有依赖于产品原型和需求文档； 项目经理依赖需求控制开发周期和任务；开发开发得业务当然依赖需求；测试的测试用例依赖需求；UI设计也依赖需求。需求一变更，下面的流程就得重新走一遍。需求一动则全身动。要时刻确保大家对于需求的理解一致，就得要求产品经理主动积极沟通到位，而不是其他岗位反过来沟通产品经理。

　　需求文档不用写，原型画的最粗糙、简单的那种，某些交互都不说明的；他以为你们都看的懂原型和他画的原型上的交互的。

　　需求确定后，通知下午X点后会议集合，然后放映原型，说这次我们要做这个，大概交互是这样。。。

　　然后我们是第一次在会议室见到原型，我们能理解要做什么呢？？？我们什么都不懂好不，多脸懵逼逼逼逼逼逼逼逼。。。

　　然后讲的过程中贼快，这个需求就是这样，这个页面就过了，下一个页面。。。。

　　首先得提早1-2天通知我们要开需求会，先把需求原型熟悉过几遍，对于不理解或不合理的地方记录下来，会议上讨论。

　　基于此，管理者就开始派发任务，各方自己去理解原型，不理解的地方再各自私聊产品，理解原型和沟通的时间算在开发时间上。这样就会产生多个版本的需求理解。

　　开发期间，都是多方在主动找产品沟通的，然后产品原型修改后并没有通知到所有人，就只有提出问题的人知道某个需求修改，多个人提出问题，最后就会导致多方多个需求理解不一致，需求理解没实时保持一致。

　　收尾的时候，前后端业务需求不一致，开发和测试bug冲突，测试和产品，开发和产品，ui和前端冲突，测试按自己理解提出的bug，服务端不不理任务是前端的问题（各方都以为自己理解是正确）抛给前端，前端认为是设计问题，关闭bug。测试再去跟产品沟通，再次打开bug并在bug上备注“产品这样说的”，然而前端不买账直接转给产品，产品再备注bug要求前端和服务端改。

　　导致了多少的工作量和沟通时间，我都把自己说绕了。这时候我40米的大刀已握的紧紧。

　　所以综上所述，产品经理实时维护好原型、需求文档并主动积极沟通多么的重要。

　　如图所示，UI岗看似被所需沟通的岗并不多，整个开发过程参与度也比较低，输出完UI稿算是完成工作了；依赖产品原型，给予前端UI实现帮助，实时维护UI稿项目管理，有变动做到及时通知前端，收尾时变动得再提醒测试。

　　UI岗有点要注意的是，设计不能太天马行空给开发带来很多实现上的困难，同一套系统UI标准一定要规范化，设计尽量组件化。

　　前端主要是以页面、app、小程序等可视化程度高的为产出，这个岗位的工作内容偏依赖于其他岗位，如：产品原型、需求文档；UI稿；服务端的API文档等。所以在开发协作上也是需要经常沟通的。

　　作为开发这类人的性格都偏向不爱当面沟通，沟通能力也一般，然后前端又比较多沟通，怎么办呢？？？

　　所以要借助各方所管理的协作文档和工具，进行文本沟通欧宝平台。如tower任务回复、依赖线上UI稿（蓝湖）产出UI界面、依赖API文档联调接口、bug管理系统等。

　　日常工作中更多的是于前端撕逼，针对某个功能点自己实现复杂麻烦，前后端都想让对方来实现，这时候斗舞就开始了，就看谁的理由更加充分更能说服对方了，说不过的一方只能忍气吞声了，所以说前后端的关系通常也没那么好。

　　服务端跟前端协作该做好的一点就是，尽早设计好API接口文档，这样前端在写好UI界面就能今早进入接口联调阶段。服务端也能安心写接口实现功能等。不用空出时间和前端battle。

　　前后端在开发前尽量协商好api文档的交互数据结构，不然开发后都不好改，让谁改都容易产生点摩擦。

　　互联网开发团队通常都是偏中小团队，或者按项目分组；团队人员相对少，加重了团队协作的重要性，活是人干的，要注重团队间的相处沟通和氛围，团队管理者应及时缝合团队裂缝，加固团队团结。开发团队的人员画像的特征也比较明显，要结合这群人的特征，按症下药来协调管理整个工作流程。