阅读: 270
答案 1：
呵呵，个人不喜欢用KPI和所谓制度去压技术，我比较喜欢在前期解决问题。这个方法其实也很简单。让美工、技术更早的进入到项目里。需求确认后，做原型之前，就把技术负责任拉进来一起讨论清楚细节、接口传递方式、相关依赖项等等。做原型之后，让技术再确认，原型和之前讨论的需求实现方式是否吻合，不吻合进行调整。这时就要提前告知美工需要制作的总页面数，如果页面很多，要求美工做一张确认一张切一张，和技术同步进行。原型提交美工后，花一点时间和设计人员说清楚，你要的是什么，哪些需要为技术保留，哪些请直接做成图片，哪些地方是按钮，哪些会进行动态调用别做死在页面上。和技术确认的排期，除非是非常非常确认的时间点，否则，请用动态管理方式，如：页面获取后，10个工作日内完成开发，预计联调测试需要1天时间。留出充分的时间。比如，本来开发到测试完成是11天，多留1天作为机动，以备不时之需。验收测试的时候，请亲自参与，并及时调整测试环境中发现的问题。上线后2小时内，请首先作为用户去体验正式环境的各种情况。随时进行调整。（一般上线后2小时内可以进行简单的调整，若正式环境发现大BUG，那么赶紧下线还来得及）调整完成后，宣传就上吧，呵呵。答案 2：
几点心得，谈不上方法：1、远期沟通，充分沟通。在项目尚未立项的阶段就与参与人员尤其是研发人员沟通，让大家对于项目的意义、需求、目标有充分了解，这样大家心才能往一处使2、充分评估与时间预留。对于项目的时间周期评估，需要建立在方法1的基础上，而且是对主体细节有充分了解，同时，对衔接出有buffer预留，避免意外情况3、需求锁定与细节让步。需求提出后，在研发过程中需要处于锁定期，不得随意修改；而由于评估不完善造成的部分细节实现难度，在不影响大前提的条件下，产品人员要有优先级概念，对可让步的内容进行让步，并思考补救措施4、全程的review。在产品demo基本完成后，不需要等到功能完整，产品人员就应该介入观察，不要把风险都堆积到上线前的验证。答案 3：
制度和认识很关键，每个时间的交付物定死，之后不能随意改变。1. 需求评审通过后，需求不能变。2. 技术部门定出的上线时间不能变。3. 如果需求有变更，那么上线时间要做相应的调整，需求提出方负责任。4. 如果是技术的原因，技术部门负责任。5. kpi考核严格执行，用数据说话。答案 4：
方法更需要因应实际情况而定。若所在的团队因技术能力问题而出现状况，那么跟进的方法就应该抓住key-n，与其分享项目的实现价值，并分析出问题出现阻力的地方，协助其找到方法或资源去解决问题。如果团队因职业素质问题出现状况，则需要从管理上着手建立成员的危机感以及在职感。强势要求一些多人协作的加班时间，从中发现问题的性质是偏缺利诱还是散漫或安逸，再针对性地制定出奖罚，并持续放大地执行，从而影响团队重新打起精神。如果以上都不是，仅仅是在正常情况下分享跟进项目的经验，那么用团队最易接受并能执行的方式去掌握“时”与“质”就好了。保持团队内的沟通，反复检视工作顺序的安排是否合理，以及检视细分项目的开发工时是否合理，以确保“时”在掌控之中。尽量让团队保持迭代的开发模式，这很难。但能实现的话能在“时”的基础上就有“质”的保证，某种角度来看也是项目跟进的保障。答案 5：
楼主可以邀请几个人来回答嘛，坐板凳，观望……答案 6：
初期就成立一个团队，随时保持联络。答案 7：
我觉得项目上，沟通环节是少不了的，时间计划也都会有。我觉得重点问题是在于不精通技术的产品经理如何去设定产品开发真正所需的时间周期（而不是由技术员说几天就几天）以及如何验收代码（即评估代码质量，而不是找BUG）分享常识给亲友.
下一篇:如何看待 Apple 暗中收集用户地理位置信息？ 下一篇 【方向键 ( → )下一篇】
上一篇:《印刻》盈利吗？ 上一篇 【方向键 ( ← )上一篇】
快搜