我们管理20人团队的方法

我们是一家技术服务型公司,公司性质决定我们的研发情况比做一个单独项目节奏还要快,处理的问题更为复杂,这套流程目前来说执行的较好,它可以很好的帮助我们进行阶段性的规划及验收,辅助产品及商务对进行项目的合理评估。

作者:小东小西小心情

我们是一家技术服务型公司,公司性质决定我们的研发情况比做一个单独项目节奏还要快,处理的问题更为复杂,这套流程目前来说执行的较好,它可以很好的帮助我们进行阶段性的规划及验收,辅助产品及商务对进行项目的合理评估。

首先大的方向及目标可以大致划分为项目的执行和过程的监控

迭代执行:任命项目负责人,并对执行过程进行监控,同时进行风险预警。

迭代细化:项目负责人对需求及工作量进行落地分配,产品经理对需求进行区分,将非功能性需求在细化阶段刨除,并反馈上级。

考虑每个迭代需要达成的目标:工作量评估、功能性需求。非功能性需求。

项目的研发周期有长有短,有难也有简单。我们将研发流程划分为几个阶段。

1)原型演示:阶段性须有可查看的交互文件,需要确定时间:迭代开发、自测完成,准备提交测试前。团队内部进行需求评审,为团队成员进行需求讲解,同时由听审成员提出执行意见,(这个阶段将个别实现困难,设置不合理等潜在影响交付的风险进行排除。)

2)测试用例评审:测试工程师根据需求文档编写测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例。

3)开发:根据前期的铺垫,通过相关文档进行有计划的开发,开发过程做关键性节点检查。检查由测试工程师与产品经理负责

4)开发自测:在开发过程中,每完成部分功能点,都需要及时的进行开发自测并通知相关人进行验收

5)BUG修改:在IT平台中获取分配给自己的BUG进行修改。

6)测试和回归:提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试BUG,ui设计师进行视觉验收,根据不同工种的验收标准给出产品是否发布的意见。如验收不通过将打回项目负责人进行内部整改。

7)验收:验证通过后方可流到产品经理及商务负责人交付客户。

8)灰度发布:迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

9)项目总结与信息收集:会议在产品上线后由项目负责人组织。会议期间,由项目负责人组织大家体验并将项目中所遇到问题及解决方案进行总结。会后由参与各人发出总结留档。

这套流程应该有更好的方案,我们还在不断的学习和优化这套方案,所谓因地制宜,我们需要辩证的看待公司情况,如果没有好的方向倒是可以参考,我们主要业务是做互联网产品的研发及维护,涉及到的有教育、金融方向的产品,根据客户实际情况推荐使用app、微信、pc不同方案进行开发,其目的是希望为客户提供更满意的产品。如果你有更好的开发流程且是流程的受用者欢迎与我讨论。

阅读余下内容

发表评论

电子邮件地址不会被公开。 必填项已用*标注


京ICP备12002735号