IT 项目管理，从 4 人到 40 人团队

2016年初公司决定挑战新的产品方向，临时从原有项目小组抽调4人组成敢死队，进行封闭开发。由于我们做的是内容型产品，所以人员组成为：1个产品经理兼技术总监、1个安卓开发、1个设计师和我，我是底层开发兼管理。项目和人员的发展大致经历了三个刻骨铭心的阶段。

第一阶段-探索初创阶段。 项目处在创业初期，团队成员激情高涨。团队成员自发地将项目成功放到最重要的位置。我们当时对项目的定义是：虽然经过了市场调查以及竞品分析，但依据我们目前团队的实力，需要快速做出一个原型来验证可行性，每个人以为项目贡献自己的力量而感到骄傲，使得团队的高效协作发挥到了极致。工作流程非常简单，大家各司其职，分工明确。 产品需求和项目管理：管理 工具使用Teambition，可以轻松共享和讨论工作中的任务、文件、分享、日程等内容，他的提醒功能非常棒，大家都在紧张和认真的工作过程中，如果其中有一个伙伴完成了需求，只需要关闭相应的Item，系统就会通知关联人员。我们之前都是大嗓门的喊一下某某，这个会打扰到大家的专注力。 需求和技术讨论： 我们会随时进行，没有一个特别固定的时间。一般都会在下午3、4点钟，这个时间大家有些疲乏，我们会一起吃点零食和水果，在小黑板上画画。 团建： 没有正式的组织过，会买一些啤酒和零食，搞一些外卖烧烤，几个人在办公室吃起来。大家喝着啤酒，聊天，大部分内容还是关于产品怎么做好，憧憬着产品DEMO做出的那一刻。这个阶段的时间不长大概一个多月，我们来到了第二个阶段。第二阶段-扩大发展  阶段。 DEMO做出以后，找了一些用户试用了一下，觉得还不错。我们就进一步扩大发展，扩充了团队的成员，增加了iOS端开发、产品人员、服务端开发和测试人员。由于团队扩张速度太快，这个阶段我们犯了很多错误，总结了一下，问题出在以下几个方面：1. 招聘- 人员和流程。人员上没有具体规划要招几个人，对应的岗位补上人后，马上又停止了对该岗位的招聘，后边遇到更合适的人没有招进来，人员上没有Backup，导致出现人员离职后，该岗位人员缺失，不但影响项目进度又要马上启动对该岗位的招聘。招聘流程上，过多的感性判断，感觉合适就招进来了，适应了几天发现不合适，有主动离职的，有被动离职的，这个对团队影响也是非常大的。 2.产品 -产品需求的来源有产品经理日常需求、前方运营、非产品人员建议以及Boss需求等，这么多需求来源没有确定好优先级和产品现阶段重点，另外产品需求的临时变更也对整个项目流程有很大影响。由于产品人员少，前期项目以技术为主导，没有把产品经理重要性和话语权提升上来，导致产品经理推进解决问题无力，需求不能很好的被实现。总之，产品和产品需求在这个阶段没有得到足够的重视，这个是最严重的错误。 3.研发- 底层sdk、Android、iOS和服务端。先说底层sdk问题，底层开发提供sdk后，自测不全面，因为这个需要上层联合测试，这块做的不好导致bug出了之后责任人不明确。再次，Android端的功能早期原因快了iOS很多，iOS同学快速迭代追赶Android，很多需求的实现和技术细节与Android不一致。最后，服务端这块架构设计的耦合度较高，随着用户的增长，系统响应性和性能完全跟不上了。 4.测试- 测试case不足，研发打包时间太晚，基本都是每天下班之后打包，有时候测试环境宕机也影响了测试的进度和质量，测试机型不全面，没有有效的利用云测试平台，导致产品上线后质量不稳定。 5.团队 -由于人员能力参差不齐，各组Leader带小团队的经验不同，没有统一方法和战略作为指导，大家都摸索着管理团队，出现了很多不应该出现的沟通问题。在这个阶段我调整了两个月，还好大家都是积极努力的，新项目有很多学习和成长空间，大家不断的挑战技术和箭速迭代。经过了即兴奋又混乱的第二个阶段，来到了第三个阶段。第三阶段快速发展阶段。 这个阶段我对团队和项目流程做了很大的调整，非常时期，非常手段。

关于团队：

1.明确各小组负责人，建立核心领导班子，权责清晰，压力下放，共同承担，共同进步。

2.明确绩效考核内容和目标，让大家有明确的目标，赏罚分明，公平公正。

3.明确产品人员在团队中的位置、重要性和话语权，由产品团队推动整个团队向前。

4.建立有效的沟通机制和会议制度，早会、周会和月会等，有效沟通，高效率解决问题。

5.建立一套带队方法，尤其是新加入的成员，关注新人和老人的成长和成就感。

6.增加户外团建活动和分享交流机会，适当暴露每个人的弱点，互相理解，互相关心。

7.核心岗位人员长期招聘。用人和负责人一起面试，有任何一个负责人持有反对意见，我们都不会通过。制定新入职人员在试用期的工作目标、完成度，指定导师帮助解决遇到的问题。

关于项目：

1.产品所有来源的需求统一汇总到产品决策团队，产品决策团队制定三个月的计划和目标，版本开发需求提前一周规划，出详细需求，给开发预留足够时间。对临时需求把控更加严格，分析对上线产品质量的影响后，在确认是否加入。设计师设计好产品原型，召集涉及到的负责人和研发进行评审，没问题后给到研发进行开发。研发开发阶段，产品负责组织客户端、服务端一起讨论实现逻辑和跟进细节。产品上线前和测试一起做最终的需求审核。

2.底层sdk研发任何改动都需要同步到客户端，详细记录修改点，和测试人员一起制定测试用例。Android和iOS共同功能的研发一起讨论实现逻辑和细节，在产品需求制定后就开始进行。保证改动同步，每天五点钟准时打包。服务端代码上线到测试环境，测试人员根据功能测试完成后，在整体测试，没问题后等待最终发布上线到线上环境。

3.利用云测试平台进行兼容性测试，增加发版前集体测试流程，对主要服务端接口进行压力测试，完成后台接口的自动化case并且设计规范化云管理文档。在每次发布版本前召集各个组负责人，评估上线风险，做好上线后风险控制。发布测试报告，同步发版更新日志。

4.运维人员负责监控服务器，做好系统监控和业务监控，如果出现问题及时解决，做好发布后的代码回滚的准备。

关于沟通：我们基于SMART原则沟通，S:Specific，具体的内容。M:Measurable，可衡量的。A:Attainable，可达成且具有挑战性的。R:Result，可见的结果。T:Timeliness，有时间的限制的。一句话表达来-具体的且具有挑战的内容，在有限制的时间内，要保证质量的完成。

关于会议：要知道我们为什么要开会？是为了解决阻碍共同利益的问题而开会。会议里面要有引导者和参与者。开会前要有准备工作，会议的召集者最好提前通知各位与会者会议即将讨论的内容，以及讨论需要达到的效果。会议的参与者提前阅读邮件或者其他通知，在脑中对问题进行解析，将自己的思路形成草稿或者简单记录下来，到开会的时候发表自己的意见。在会议最开始的时候，引导者最好按照之间发给参与者的邮件重申一下会议需要解决的问题和达到的目的，然后逐项引导大家共同商定问题的解决办法。开会过程中，引导者和参与者都要学会的是沟通的本领，包括认真倾听、保证自己正确理解他人的观点以及不着急去反驳别人。引导者要比其他人更注重对会议的记录以及即时的梳理，在希望得出最后的解决办法的时候，最好按照问题的逻辑顺序重申一下已经发表过的观点，保证是没有错误理解的。最后大家统一意见，回去着手布置相关工作和实施。

我个人的成长是最大的，在这个过程中亲眼见证了项目从0到1的过程，从一个4人的小团队到现在的40多人的大团队，收获了很多很多。苏格拉底有句名言“自然赋予我们人类一张嘴，两只耳朵，也就是让我们多听少说”。我学会了 倾听 。以项目经理的角度换位思考，以负责任态度参与自己从事的项目。我学会了 角色的转变。 “你需要时时刻刻去帮助提升团队中每一个人的能力，这样才能打造强悍的执行力。”我知道了如何 发挥团队的力量。 在这个过程中，也遇到了很多挫折，但我始终相信：“有志者，事竟成。”，团队的力量是最大的，我热爱我的团队，祝2017年我们能取得更好的成绩！

欢迎大家多多交流，多多评论！

作者 风万里

关键字：创业, 产品经理, 团队

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！