复盘
前记：时隔1年，来复盘1年前参与一项目，此项目从开始的立项（未参与），团队搭建（未参与），后期实施（无法实施）经历过各种坑，项目到立项都具有失败性，从坑中等到了新领导到来，才得到一丝曙光，才坚持到如今；下面有会从一下几个纬度对此项目进行复盘解释，希望本人经历的坑，大家能有借鉴的作用；
项目立项
一个产品的立项如果产品没有参与立项，后面会导致一系列问题，立项的背景能代表业务方对项目的诉求；由于本小白在立项之后加入公司，进来之后对业务的熟悉度，项目的背景，部门之间的合作方式都不甚了解；项目立项的依据也没有相关的背书，亦没有相关的业务性文档；
整体团队（研发）现状
部门是新部门，这个部门只有6人1年以上工作经验，本业务线也只有1人有1年工作经验，后续本业务线由第一人（研发经理）后续慢慢过渡到7人，所以整体团队来讲是新部门，从事教育行业经验者两年以上者只有2人（本人和研发经理），由于是新人没有参与到后面的团队建设工作，由研发经理一人独立建山，所以在人员建设方面会出现能力不匹配，人员缺少的情况，首先是产品，UI：后台开发，前端开发，测试的比例是：1:1:3（研发经理是后台但几乎没有任何输出）:2：0，没有测试，没有架构师，新团队；新团队第一个是团队融合度的问题，一个好的团队起码需要将近3个月的磨合期才能达到正常的轨道水平，整个团队90%以上都是新人，一开始去做项目注定会效率低下，无法形成一定的凝聚力，对于软件工程，需要各个环节的配合，从业务方， 产品，UI，前端开发，后台开发（包含数据库搭建），到具体测试验收整个环节来讲，是环环相扣，任何一个环节有问题都会造成项目某一纬度会存在一定行的偏差；软件项目的成败来自于细节。
产品现状
新项目是基于内部的B端运营产品上进行搭建，初来时候，我已经想吐糟下这个运营产品，但领导无不说此产品已经运营多年，比较成熟稳定；此款产品是研发从另一条业务线复制而来，在基础上做了一定改良，算是投机取巧，没有任何业务型文档给下面接盘的人有指导性建议，除了一堆代码和操作说明书，整个团队来讲也是研发来管项目，导致产品和研发之间失去一定的平衡性；需求方面也几乎拿到的是二次需求，业务方直接将需要功能告知开发，这种流程也基本上10年前，当时的遇到此种场景，心中凉凉，需求上不能从顶层的角度进行设计，初期再好的产品，到后来只会变成一盘散沙；基于这样的背景，是万丈深渊也只能走下去，基于原来的产品以及已立项的项目，工作继续开展；
项目总结
从上面的任何一点都能意向都此项目注定会失败；从项目总结来讲：此项目的失败主要点是在立项没有相应的关键人员，已一开发来驱动一项目的立项评审，到团队搭建，以及业务关系维护，这不是三年左右程序员所具备的能力；所谓的关键人员有2到2个以上的成功项目经验，并且接触过项目从零到一的各个阶段，既有较强的团队建设能力，又有较强的项目管理能力，这样的项目成功率才会比较高；
产品总结
从产品角度来讲，产品经理在建立新项目时，也需要将团队的基本情况考虑到产品当中，团队的融合度，团队的业务能力，团队的开发能力，团队的完整性，若是新团队，则前期要考虑产品更应该轻而快，给团队一定的时间来进行融合，能一方面也能测试新团队的具体开发能力，为后期的重需求大好一定的基础，再好的愿景，没有能人，没有高融合的团队，也无法达到，从另一方面来讲，产品必须要具备一定的项目管理能力，一个的产品好坏和项目的管理和理解有直接关系，而且项目管理占整个产品能力的30%以上；从产品纬度来讲，产品在需求环节更需要现有数据做依据，来证实需求的真实性；
网友评论