背景介绍
M是一款主要面向女性用户的购物类产品，解决女性用户买“包治百病”的需求，同时还能享受专属的低折扣优惠特权。（出于职业道德准则还是隐藏真实项目名称，用M代替）
这款产品当时是从另一个部门接手过来的，当时的状态是已接近开发完成，但没有上架应用市场，也无人负责运营，交接的文档仅有技术类接口文档，无详细的产品需求文档和原型文档，整个产品处于接近濒死的状态，可能当年的自己初生牛犊不怕虎，再加上当时特别想做C端产品，骨子里总想跃跃欲试，后面还是拉了团队去接手并且规划并研发了大约三个版本，后因公司业务调整，这款产品也就被砍了。
以下是写于2013年12月13日的小结文章，今天再回头看这篇小结，感慨万千，当初做产品的稚嫩与激情又悄然浮现眼前，当然，更重要的是：
忆往昔，总结经验和教训，更好上路！
如果你想解决一个问题，你一定会找到一个方法，如果你不想解决问题，你就会找到一个借口。
M5.1.2版本历经波折，终于在今天26日上线了，看到产品发布很开心，但后面我们的挑战更大，也希望借此次版本总结一下我们在产品过程中做的好以及不足的地方，未来再接再厉！
5.1.2版本时间线：11月8日确定版本计划，原定11月25日发布，因颜色对应的价格显示问题，延期一天发布，历时19天。
一、做的好的一面
1.开发之前的版本计划经过大家充分讨论确认，大家认可无异议，各个端自觉完成计划制定并且在项目管理系统中体现
2.每日桌会，抽出30-60分钟过每天开发过程中碰到的问题，及时沟通解决
3.和运营、部门主管的沟通及时，和项目组成员的信息互通共享及时
4.服务端、安卓端开发人员主动反馈问题，并想解决方案
5.测试比较细致负责
6.每周的问题收集，同合作方进行确认
二、做的不足的一面
1.产品层面
业务不熟悉，导致测试过程中发现越来越多的问题，需要不断和合作方沟通确认
产品功能需求文档没有补全，原来交接过来的文档写的不够细致
测试之前的测试账号余额没有提前申请，在测试过程中进行申请，虽然在两天之内搞定，但是耽误了一些测试时间
产品发布时准备材料没有提前说明，临时准备手忙脚乱
项目负责人请假期间，B岗在项目延期时没有及时预警
整体的项目进度把控还不够，前松后紧，无法预测可能出现的各个环节问题
2.开发层面
测试时发现原来代码里隐藏的BUG，开发人员无底气，询问时没有主动反馈，自己默默改BUG
没有团队工作的拼劲，在发现问题后没有主动加班解决问题避免延期
在知道项目延期的当天，没人主动加班处理问题，避免第二天发布可能会出现更重大的问题
项目整体进度前松后紧，发布当天进入特别紧张状态，更容易出错
3.测试层面
第一轮测试结束后没有及时反馈测试报告，及时预警
测试设备不足，临时找人征用
4.沟通层面
技术上的问题开发人员可以直接同合作方进行沟通确认，不需要等项目负责人沟通跟进，比如服务端的接口文档不全
产品发布时准备材料没有提前说明，临时准备手忙脚乱
三、我们可以改进
1.积极主动地承担工作，不要等着项目负责人分配任务，项目是团队的，并非项目负责人一人所有，项目做好了，大家都会有成就感
2.进入稳定阶段后的候选包准备，每个阶段准备一个包，发布时更有信心
3.每个版本发布的总结，延续做的好的地方，改进不足的地方
试问自己：如果这个项目放在今天来处理，我会怎么做？
首先，交接阶段，因该项目涉及跨部门交接，所以双方先明确需要交接的工作资料，并且罗列交接清单及交接情况，这个阶段尽可能要到比较全的项目资料，虽然有的资料不一会有，并且需要双方明确交接的时间，并安排每项任务的具体负责人核实，所有交接的资料清单及进度都及时同步双方主管，抄送主管领导，不要怕麻烦，同时针对原项目的问题尽可能多和交付方沟通清楚，避免后续有些问题牵扯不清。
交接清单包含并不限于：技术类文档/源代码/服务器、产品类文档/原型/操作手册/规划路标、UI效果图/源文件、测试报告/问题清单、项目涉及到的各工具地址账号密码、项目组员及对接人联系方式等。
第二，产品评估，这个阶段的重点是需要针对接收过来的资料进行梳理，并且评估该产品目前所处阶段，以及根据公司或部门业务发展情况，综合去考量，需要给产品匹配多少资源，大部分公司都有很多条业务线，有的产品因为不是公司重点业务，并且领导也不支持，那其实没必要在非重点业务上去浪费资源，只需要保障基本的运行即可。
第三，分工落实，因员工在各自的岗位上都有相应的工作任务，临时交接的项目若需要人力投入运维，需要明确具体运维的任务以及大概时间、周期，同时需要向主管领导申请确认匹配的人力方案，切记，这点很重要！千万不要自行去调配人力，后续因为交接的项目任务影响到员工正常工作任务，就会很麻烦。
至此，交接的工作基本上就告一段落，若后面产品需要继续优化更新版本，那就是产品规划设计阶段的事情了。
