先间接释放出我对软件设计的有关相关人员职能和业务流程：
下列是截图的合作开发业务流程横杆图：
横轴是有关合作开发者的组织工作组件；横轴从上至下合作开发排程周期性。
从职能图和排程相关联到他们前述处于软件设计操作过程中好似是这种，并无欠妥的地方性；但分拆下来并紧密结合你的工作岗位组织工作实战经验就会辨认出这类各个环节无法逐步形成业务流程国际标准，和许多须要特别注意的技术细节。Nagaon他们能来谈谈当中的难题。
合作开发业务流程牵涉到别人协作的组件：
部门副经理：各项任务信息系统（Tower各项任务管理工作软件）；
商品副经理：商品蓝本和市场需求文件格式（Axure蓝本）；
UI雕塑家：UI稿管理工作工程项目（沙浦）；
服务器端/后端：apiUSB等文件格式（YApi）；
试验组：bug信息系统（思道）。
以上的各工作岗位所管理工作的工程项目系统是牵涉到与其他同事协同的组织工作内容，有依赖时间顺序、有依赖别人组织工作和需做出回应的。
牵涉到协同的组织工作内容，他们应该做好本职组织工作以免给别人添加额外的时间成本、组织工作量，导致嫌隙；不利于团队关系和气氛。
在合作开发业务流程中，在完成本职组织工作上，为什么他们应该更加注重团队协同和组织工作上的合作、磨合？？？
软件工程项目的合作开发更注重各工作岗位的协同，才能更好更快的产出预期的工程项目；软件设计须要较少的相关人员参与，但组织工作也是人做的，都会带入情绪、情感，协同上他们应该尽量通过国际标准化业务流程避免些不必要的摩擦；带给员工良好的合作体验；软件设计的相关人员画像大部分是些内向、不善沟通、不愿多沟通的；应通过协作管理工作软件和业务流程国际标准来减少不必要的沟通；这种就能更专注的coding和设计，不常被业务流程外的消息打断、打扰，扰乱思绪。他们逐一分解各工作岗位的影响圈，以及在协同方面应该做好哪些：
合作开发主管/部门副经理：
工作岗位解读：
在把控进度和质量上，要善于利用各项任务管理工作软件；如：Tower，各项任务状态更改，有关相关人员都会接受到通知，减少程序员的沟通时间和避开他们当面沟通能力不足的情况，转而通过文件格式沟通
对内有利于当前学习？以及近期将来的打算和职业规划。这得要求管理工作者比较懂得一些为人处世的实战经验。
然而大部分中小团队的技术负责人、管理工作者大多都是由合作开发技术好的程序员晋升上去，大部分程序员性格内向、不善沟通，缺乏为人处世和管理工作的实战经验；性格里更是不愿意去触碰这些与人打交道的事情。他们更喜欢沉浸在自己的coding世界中。他们喜欢有产出，但管理工作岗这组织工作前述组织工作量许多，不易看出前述的产出。对于程序员转岗的管理工作者来说，带不来多大的成就感，反而还加重他们的负担。在中间管理工作岗，对上得负责，忙于沟通，对下也得指导沟通；自己反而没时间专注写代码。最后这种的管理工作者会逃避管理工作方面的组织工作内容或逃离管理工作岗。
大部分中小团队提拔管理者只看到技术能力这方面的考核，过于片面，未正确认识管理工作者充当的角色和组织工作内容。
软件设计的技术更新速度较块，程序员这个群体是须要时间学习的，管理工作者要适当留出时间给他们学习，一直压榨员工时间在业务上，只会捡了芝麻丢了西瓜。
商品副经理：
工作岗位解读：
商品在整个合作开发业务流程中是处于关键的协同位置：蓝本和文件格式的输出、市场需求评审会等都确保其他工作岗位对于市场需求的理解保持一致，并且要求同短时期内的市场需求理解一致，因为互联网市场需求变更周期性较短。不管哪一方市场需求理解错误，将会导致翻倍的沟通时间以及返工的时间。商品在设计的时候跟写程序一样要多思考边界情况，尽量减少非市场需求变更导致的蓝本和文件格式变更。
商品在整个合作开发操作过程中都要求积极参与、沟通:
合作开发初期：设计商品，市场需求评审会确保多方理解商品市场需求正确
合作开发操作过程中：跟进合作开发产出结果确保市场需求正确、变更市场需求积主动极沟通多方到位确保对于变更的市场需求理解一致
合作开发结尾阶段：验收商品、更改设计不合理的地方性，再积极沟通到位
为什么那么强调要：主动积极沟通呢？？？
因为：部门副经理、合作开发、试验、UI的组织工作都有依赖于商品蓝本和市场需求文件格式； 部门副经理依赖市场需求控制合作开发周期性和各项任务；合作开发合作开发得业务当然依赖市场需求；试验的试验用例依赖市场需求；UI设计也依赖市场需求。市场需求一变更，下面的业务流程就得重新走一遍。市场需求一动则全身动。要时刻确保大家对于市场需求的理解一致，就得要求商品副经理主动积极沟通到位，而不是其他工作岗位反过来沟通商品副经理。
举个错误的例子：
某互联网公司技术部的某商品如何设计蓝本和如何主导沟通市场需求组织工作的？？？
市场需求文件格式不用写，蓝本画的最粗糙、简单的那种，这类交互都不说明的；他以为你们都看的懂蓝本和他画的蓝本上的交互的。之前偶尔开过市场需求评审会或者不开了，怎么开的呢？市场需求确定后，通知下午X点后会议集合，然后放映蓝本，说这次他们要做这个，大概交互是这种。。。你们有什么不懂的地方性或者建议都能提出来。。。。然后他们是第一次在会议室见到蓝本，他们能理解要做什么呢？？？他们什么都不懂好不，多脸懵逼逼逼逼逼逼逼逼。。。然后讲的操作过程中贼快，这个市场需求是这种，这个页面就过了，下一个页面。。。。就这种？？？到底是怎么样？？？他们就这种多脸懵逼离开会议室这种开市场需求有何意义呢，首先得提早1-2天通知他们要开市场需求会，先把市场需求蓝本熟悉过几遍，对于不理解或不合理的地方性记录下来，会议上讨论。基于此，管理工作者就开始派发各项任务，各方自己去理解蓝本，不理解的地方性再各自私聊商品，理解蓝本和沟通的时间算在合作开发时间上。这种就会产生多个版本的市场需求理解。合作开发期间，都是多方在主动找商品沟通的，然后商品蓝本修改后并没有通知到所有人，就只有提出难题的人知道某个市场需求修改，多个人提出难题，最后就会导致多方多个市场需求理解不一致，市场需求理解没实时保持一致。收尾的时候，前后端业务市场需求不一致，合作开发和试验bug冲突，试验和商品，合作开发和商品，ui和后端冲突，试验按自己理解提出的bug，服务器端不屌不理各项任务是后端的难题（各方都以为自己理解是正确）抛给后端，后端认为是设计难题，关闭bug。试验再去跟商品沟通，再次打开bug并在bug上备注“商品这种说的”，然而后端不买账直接转给商品，商品再备注bug要求后端和服务器端改。导致了多少的组织工作量和沟通时间，我都把自己说绕了。这时候我40米的大刀已握的紧紧。
这让整个团队产生了多少的间隙，还谈什么团队氛围。
让他们来康康bug如何流转的：
这只是bug流转图的某个分支，最后多方互相伤害一波，火药味浓浓啊。
所以综上所述，商品副经理实时维护好蓝本、市场需求文件格式并主动积极沟通多么的重要。
UI雕塑家：
工作岗位解读：
如图所示，UI岗看似被所需沟通的岗并不多，整个合作开发操作过程参与度也比较低，输出完UI稿算是完成组织工作了；依赖商品蓝本，给予后端UI实现帮助，实时维护UI稿工程项目管理工作，有变动做到及时通知后端，收尾时变动得再提醒试验。
UI岗有点要特别注意的是，设计不能太天马行空给合作开发带来许多实现上的困难，同一套系统UI国际标准一定要规范化，设计尽量组件化。
后端/客户端：
工作岗位解读：
后端主要是以页面、app、小程序等可视化程度高的为产出，这个工作岗位的组织工作内容偏依赖于其他工作岗位，如：商品蓝本、市场需求文件格式；UI稿；服务器端的API文件格式等。所以在合作开发协同上也是须要经常沟通的。
作为合作开发这类人的性格都偏向不爱当面沟通，沟通能力也一般，然后后端又比较多沟通，怎么办呢？？？
其他与多方合作该特别注意的技术细节都在上图。
服务器端：
服务器端解读：
服务器端的组织工作内容相对其他合作开发会多些，具体的见最上图的鱼骨图。
日常组织工作中更多的是于后端撕逼，针对某个功能点自己实现复杂麻烦，前后端都想让对方来实现，这时候斗舞就开始了，就看谁的理由更加充分更能说服对方了，说不过的一方只能忍气吞声了，所以说前后端的关系通常也没那么好。
服务器端跟后端协同该做好的一点是，尽早设计好APIUSB文件格式，这种后端在写好UI界面就能今早进入USB联调阶段。服务器端也能安心写USB实现功能等。不用空出时间和后端battle。
前后端在合作开发前尽量协商好api文件格式的交互数据结构，不然合作开发后都不好改，让谁改都容易产生点摩擦。
总结：
互联网开发团队通常都是偏中小团队，或者按工程项目分组；团队相关人员相对少，加重了团队协同的重要性，活是人干的，要注重团队间的相处沟通和氛围，团队管理工作者应及时缝合团队裂缝，加固团队团结。合作开发团队的相关人员画像的特征也比较明显，要紧密结合这群人的特征，按症下药来协调管理工作整个组织工作业务流程。
