时隔10年，我的职业生涯迎来了第二次职位晋升。（虽然没加薪，但也挺开心的：））
而这一次，我将带领一个4个人的小团队，负责一块业务条线。
工作这么久，第一次真正意义上的带领团队。
其实7月份的时候，领导让我管理一些做核验的实习生，那个时候才是真的考验我的时候。
当时面临着3个难题：
1、核验的数据量上不去
2、实习生难管理
3、核验的准确性有待验证
后来经过我的努力，做了3点有针对性的改善：
1、核验的薪资采用底薪+提成的方式，跟核验数量挂钩
2、换人，要求HR招聘大专及以上学历的学生，不要职高的学生
3、开展质检工作，制定惩罚机制，定期培训强调易错点
一套动作下来，从人均一天完成10来件，到现在人均一天完成60件左右，可以说效率、质量都大幅提升了。
但这一切都跟我的本职工作产品设计没有太大的关联。
所以这一次我又将面临新的挑战。
一上来就遇到了一个大难题——需求对接人拒绝在需求确认书上签字。
而这个需求已经拖了2个多月了，团队的小伙伴前前后后反复修改原型图、需求文档无数次。
在了解了背景后，我开始参与团队跟客户的需求评审会，会上我发现客户主要的顾虑有3点：
1、想在一份文档里罗列出所有能够想到的需求，担心需求对接人更换，还要再重复一次（因为前面换了两次）
2、每一句话都要写的非常清楚（咬文嚼字），生怕没有传达清楚，研发出来的东西差强人意
3、担心想的不够到位，上线后领导或者其他使用者不满意
针对上面的顾虑，我又迅速开展了我的应对方案，具体如下：
1、把需求拆分成多个版本，而不是在一个版本里包含太多内容；建立需求池，随时增加文档中没包含的部分或者新想到的想法，定期由产品经理评审把控，建立新版本去迭代；
2、研发过程中保持良好的沟通，充分利用好测试阶段，让客户积极参与，可随时提出问题，我们再来评估是当前版本修改还是放到下一期，承诺可以持续迭代；
3、夸赞她太有责任心，但必须灌输她从0-1的思维，举例打动她，比如说微信第一个版本上线时反对声音也非常多。积极倾听、保持迭代才会有越来越好的产品，有了1才能有N，否则一直不去实施，就什么都没有
上面的处理方式果然有效，两多月的拉锯战终于结束，客户很积极的配合签了字，终于可以提交给研发了。
这几个月以来，我从如何理解客户需求设计好产品的角色转变为处理更复杂的关于“人”的问题，对我来说是一种新奇又富有挑战的体验。这期间我也没有放弃输入，看了4本跟管理学相关的书籍。待有空时再来写一写。
