主要从以下几个方面解决：
明确开发流程，并明确每个阶段对应人员的工作职责
选择一款合适的团队协作工具对整个开发流程进度进行把控
人事部需要制定合适的绩效考核制度，提高员工工作积极性及责任感
对沟通方式、文档管理、代码规范、项目交付管理等方面进行规范
对可能造成项目延期的客观原因应该及时与客户沟通并保留记录
应当有专人担当项目经理一职，负责整个项目的开发进度及质量
具体的解决方案如下：
1.明确开发流程，并明确每个阶段对应人员的工作职责
设计阶段
参与人员：设计部相关成员
工作内容：完成项目前期设计、明确客户需求、完成需求确认书
产出物：原型图、业务流程图、需求确认书、开发过程中需要的素材（如用户协议、产品中需要用到的音乐图片等）
注意事项：
原型图应该尽可能的做到每个界面都清晰易懂、对于有多种跳转结果的页面，应当注释标注
业务流程图应该对整个业务流程进行梳理，并产出文档，具体格式参考下图
需求确认书在签订时，应该告知客户修改需求会造成项目延期及成本增加的风险，规避客户在研发阶段做一些无意义的附加修改，影响研发组进度。
某些复杂功能的实现需要与研发组负责人协商、以评估项目进度及风险。
需求确认书必须覆盖所有已确认的需求，同时一旦定稿签订不得修改，后续的修改请客户直接与研发组负责人联系。
开发阶段
参与人员：研发部参与项目的全体成员
工作内容：充分理解需求、定义编码规则（命名风格、通用约束等）、召开项目启动会议、项目经理制定开发计划、开发人员进行开发并保证代码质量
产出物：项目启动会议记录、编码规则文档、开发计划
注意事项：
在项目开始前，开发人员应该仔细阅读需求文档及业务流程图，保证能够理解需求。
编码规则应该包含：①命名规则（类、对象、文件、组件、函数、方法等） ②编码风格（缩进、换行、块大小、文件大小、注释等）③框架搭建负责人、版本提交负责人、提交方式
启动会议所有项目组成员必须参加，对于项目存在的疑问要及时提出并讨论解决方案。
项目经理在启动会议结束后需要制定开发计划，分配开发任务、设置开发时间节点。
开发人员在完成模块功能编写后必须进行自测，如果一般性bug被测试组发现，可以采取减少绩效等处理措施。
将整个业务流程划分为多个user story，可以以每周任务的形式分配，测试人员根据story列出story测试用例，每周五下午进行所有开发人员进行本周story验收，如不通过，周末加班处理。
项目经理需要每日通过任务分配平台分配当日工作内容，以保证项目进度按时推进。
开发阶段，项目经理需要与客户直接接触，对于客户提出的需求变更，在评估变更风险后以邮件的形式告知客户处理意见，然后再做处理。同时，项目经理应该配合客户完成服务器购买、域名申请、开发者账号申请等工作。
测试阶段
参与人员：测试组
工作内容：编写测试用例、执行测试用例、提交bug、跟踪bug直至关闭、提交测试报告
产出物：测试用例、bug列表、测试报告
注意事项：
测试用例编写前要充分理解需求，要包含所有业务流程。
bug提交时应该描述清晰明了，需要截图的地方附上截图。
如果在验收阶段，客户反馈出现明显的严重bug，测试人员与对应的开发人员需承担相应责任。
2.选择一款合适的团队协作工具对整个开发流程进度进行把控
推荐使用鱼骨
1).任务分配方式
任务分配
可以对任务进行优先级、截止时间、对应项目、预计工时设置
每个任务有对应的负责人、抄送人、审核人
任务状态操作人性化
任务操作
2).即时交流便捷
可以直接针对单个任务发起相关人员的讨论
发起讨论
3).文件管理
可以将项目相关文件统一存放于鱼骨中
文件管理
总体来看，鱼骨的功能可以有效的解决公司现阶段面临的项目管理问题，但还需要从成本、私有化部署、易用性等方面考虑，需要开会商议。
3).人事部需要制定合适的绩效考核制度，提高员工工作积极性及责任感
绩效考核制度需要开会讨论
对于员工入职及离职流程应该建立完善的制度体系，入职需要进行入职培训、离职需要完成工作交接。
4).对沟通方式、文档管理、代码规范、项目交付管理等方面进行规范
增强使用邮件的意识。
项目组每周至少要进行不少于两次的集体交流（交流不限制时间长短、方式、内容可以从需求到设计到实现、甚至是抱怨）。
项目文档应当有专人或项目经理管理并内部共享。
开发人员应该有良好的代码规范意识。
项目交付时，应当对安卓签名文件、ios开发者账号、数据库账号、服务器账号等一并提交给客户（如客户要求）或整理归档。
5).对可能造成项目延期的客观原因应该及时与客户沟通并保留记录
项目经理需要与客户直接接触，对于客户提出的需求变更，在评估变更风险后以邮件的形式告知客户处理意见，然后再做处理。
6).应当有专人担当项目经理一职，负责整个项目的开发进度及质量
项目经理角色至关重要，担任者需要内部讨论决定。
Tip：引入 Story 演示有什么好处
Story 验收测试用例从用户价值的角度定义了 Story 的最低质量标准。Story 演示通过评估这些用例的执行通过情况决定相应 Story 是否允许转测从而保证了转测 Story 的最低质量要求，有效降低了由于转测 Story 质量低下而导致的多次修正代码多次再转测的返工可能性。返工作为软件开发过程中一种最为常见的浪费现象，它不仅阻碍了进度，也降低了质量。因此，从短期角度看，Story 演示的好处在于它能够有效减低返工的可能性，提高 Story 代码的质量。
Story 演示是由开发人员和测试人员共同参与的。Story 演示所呈现的软件功能作为开发人员的作品，对于往往有着弊帚自珍心理的开发人员来说，他总是不愿看到其作品在他人面前出现缺陷的。因此，Story 演示前，开发人员必须做好充分的单元测试才能避免在演示时当众“出丑”。于是，通过一次次的 Story 演示可以强化开发人员的质量意识。而开发人员的质量意识很大程度上决定了bug的数量。毕竟bug不是由测试人员“发现”出来的，而是开发人员“创造”了大部分bug。
另一方面，Story 演示过程中，开发人员往往能够自己发现一些在此之前不曾发现的问题，这些由其自身发现的问题往往能给其留下深刻的印象因而有利于其避免下次再犯同样或者类似的错误。这有利于开发人员自身的持续改进，提高其个人能力。因此，从长期角度看，Story 演示的好处在于它强化了开发人员的质量意识，并促进开发人员个人能力的持续改进。
能够从短期和长期的角度去理解实施 Story 演示的好处非常重要，因为这会影响到我们如何具体实施 Story 演示。
