Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /home/liter/domains/vmatianyu.cn/public_html/wp-includes/plugin.php on line 601

聚划算android客户端2期总结(待续) 5

1. 掌握整体,关心细节:和测试、开发人员沟通确定每个职位的人了解各自的流程和细节;
实例:布置好一切之后,本以为完整的掌握了项目,但是在云飞(开发)和小改(测试)的疑问下其实很多问题还没有清楚,这也是必然的,所以要关心细节才能更好的掌握整体!
2. 提前疏导流程和关节,排除项目中存在的风险。
实例:测试人员很担心2天的时间不能搞定测试任务,我们做了提前的流程疏导和关键节点打通,在真实PID没有的情况下,使用伪PID(测试必须的)走下流程,与合作测试部门电话沟通保证顺利进展。
3. 确定问题,‘想当然,甚至是猜测’是绝对不靠谱的,需要找专门、专业的人确定是怎样。
实例:接手无线联盟初期,我什么都不了解,找到PD、TL、对方开发、运营、通过专业的人确认了专业的问题。
4. 了解问题,即追根溯源才能治病除根。刨根问底
实例:Bug也不可以说基本上解决了,要确定真的是这里问题,治病除根。聚划算消息功能上线后引起了重复的问题,我们失误没有真正确认在服务器、代码上的问题,并给与彻底解决就上线了。可用 可靠 可扩展
5. 终结问题,先不做定义,为引出话题,在入题之初,看我杜撰的一个问题:
A询问了你一个问题,但你杜绝确实是不知道,不过同组的B知道,你将如何答复A?
你要先靠直觉,你真遇到了同样情况,你会怎样处理? 再参考下我个人理解。
这个问题有N种答案,每种都代表着不同的做事风格。
1 坦诚不知。你很诚实,但是在于事无补,基本是推卸了问题,同时不相信同伴。

2 告诉A:B知道。很自然的答案,不过这并没有终结问题而是将问题传递了;
3 靠自己弄清楚。能力不错,不过没有充分利用已有条件,是缓慢的解决了问题。

4 和B直接沟通,快速找到答案,答复A。

很小的问题,我将其阐释为一个道理:避免做问题制造者和问题传递者,而是要尽量快速终结它。
5. 时间VS质量:时间换质量,质量第一,时间有时可以适当让步。有很多问题,甚至会惹恼用户,就算按时发了版本又能如何呢?
6. 发布下载点统一调用一个逻辑页面完成下载,统一、动态返回包地址。
7. 测试一个功能一次通过了远远不够,一次通过、数量稍多、大量测试的结果可能远远不同。
原则1:质量第一。追根溯源,杜绝P3以上级别Bug出现!
质量没了,一切无从谈起。
原则2:联调先自检。联调问题,首先自检,杜绝己方出现问题而导致进入混沌状态。
猜测各种环节上的可能,而忽略了确认自己完全没有问题,是不理智的做法。
更多经验分享请看我的另一篇分享:  http://www.vmatianyu.cn/summarization-of-technical-experience.html

5 thoughts on “聚划算android客户端2期总结(待续)

  1. Reply Loading 4月 16,2013 上午 10:13

    而对于 “时间 VS 质量”的问题,还是得看项目和客户,控制风险的关键就是控制这两个,也不能一味追求质量而delay.

    • Reply mty 4月 16,2013 下午 10:15

      对的,平衡时间和质量只能是尽量去做的事。对外包来说规定时间内完成功能是第一位的,但自主产品一定不要贪快而降低用户体验。快是有前提的,那就是稳定否则快的意义不大。

  2. Reply Loading 4月 16,2013 上午 10:12

    对于“终结问题”这个思考,我觉得关键还是看个人的在团队中的角色,如果你是leader,你当然要主动承担责任而且要做问题的终结者,至少要去跟踪问题;而如果你是开发者,而这一块不属于你的工作,则在有条件的情况下可以同B一起搞定。

    • Reply mty 4月 16,2013 下午 10:08

      这不矛盾,既然问你而你又可以解决,何乐不为?还有如果自己定位为开发,不会从整体来考虑情况,如果还只想完成自己的部分可能有自扫门前雪的感觉。试想一个公司怎么可能把你能干的不能干的都问你都让你干,这怎么可能,假如可能,离开这家公司。

Leave a Reply