题外话
在此以前，笔者主要从事传统IT企业的研发技术管理工做，对项目管理虽然有必定的经验，但纯粹摸石子过河，没有系统的学习过项目管理理论，也很容易犯下技术人员对项目管理的一系列毛病。前端
以前带的项目通常都是非产品型项目，功能通常以实现为主，对细节没有太多要求。项目通常采用瀑布模型，项目之初通常会制定一个很是详细的研发计划，涵盖需求分析、设计、研发、测试、验收的全过程。因为用户验收测试每每须要花大量时间，所以会输出一份沉甸甸的需求说明书，而后让客户签字，并在验收阶段，在现场维持长时间的驻场开发，以便实时跟进需求的变化。曾经创造了带领10人研发团队、连续3个月，天天维持12个小时以上工时的工做记录。（堪称土劳模）程序员
这是第一次参与互联网项目的开发，有明确的迭代周期和需求计划，可是因为各类缘由，却逐渐走向失控，过程当中究竟发生了什么缘由？数据库
失控全过程
话很少说，直接进入正题。后端
我将尽可能以第三人称视角记录一个失控的项目，但事实上我实际是项目负责人，因此不免有失偏颇。工具
这是B公司一个面向特定行业的虚拟建站平台产品，虽然市面上建站产品很是多，但因为B公司在该行业很有地位，可以得到一些比较实用的数据，这些数据是目标用户群体很是渴求的宝贵资源，所以若是将这些数据作成可视化组件而后打造这样的精准型建站产品，显然具备独特性的优点，可以为目标用户带来便利。学习
产品于2月底开始启动会，由研发部门内部碰头后，直接开始启动项目。（该公司管理比较扁平化，产品、研发、测试、设计分属技术部四个不一样的团队）。测试
因为是互联网产品，所以每每会选择竞品。竞品为为3个比较热门的互联网建站平台，其目标是要知足这些建站平台的特性，包含一个功能强大、效果优雅、流程简单的设计器；实现自动化建站部署等。在项目初期仅明确了总功能点的约40%，初步估计须要完成大大小小的页面15个，设计数据库20几个表。网站
（最终作出的页面数量虽然没增长，可是前端的逻辑也很是复杂、后端逻辑也有点复杂，数据库有45个表，大小接口将近80个）spa
技术总监指示：采用敏捷开发模式。总工期为8周，按2周一迭代。项目启动时，共有后端开发者3人，前端1人、产品1人、设计1人，测试1人。由本人担任整体负责人和后端开发者。设计
这个配比自己不太合理的项目，显然8周时间不可能完成，但领导没有进一步的时间计划，只能基于现有资源制定为期八周的先启阶段，其目标是搭建符合流程的最小可行版本(MVP)。因为大部分功能都在前端，可是实际上仅配了一位前端，并且这位前端是公司的前端负责人，天天仅能花不到40%的时间投入到项目研发过程当中。后端则能够开始根据现有需求进行数据库、接口的设计。
这个MVP版本包含网站定义、网站编辑、网站设计器和发布流程、目前需求范围内的接口功能开发，工期为8周。
项目组还需另外招聘3位前端开发者。
到五月底最终完成整个MVP功能开发花了十周时间。由于前端部分的工做量大于预估，仅设计器就花了6周。5月完成简单的演示，基本符合主体流程。
此时项目需求已经明确了60%，技术总监认为7月底能够完成功能的开发。
因而从5月开始，到7月底，共有10周时间，开始进入倒排期。庆幸项目组成员已经配齐，至少是有人能够用。但在需求池里面的需求很是多，因此你们得加班。因而集体开始进入加班状态。
项目很给力，动做交互和逻辑很是多，许多样式和动做都须要前端开发，几乎没有任何能够复用的经验，因为设计器自己是赶工期赶出来的，功能不完善，并且还有不少组件功能须要开发，最终于7月20几号左右完成主体功能的开发，可是有较多量的bug，推迟到8月6日才能交付测试，而后还剩余的40%功能点。
因为项目已经严重滞后，上线目标定在9月中旬，又是一轮加班，坚持到8月底。
需求勉强控制住了，可是bug却愈来愈多，已经远远不可能在9月交付了。
一句话总结：开始时，没人，赶时间；后来人来了，可是任务多，赶时间；最后，任务多，bug多，也赶时间。 程序员们的996,就是这么产生的。
项目结局
进入9月，公司高层对项目提出了新的要求，项目需求将进一步增长。
因为负面情绪的影响、以及对在这家公司的发展前途迷茫、没法忍受高强度的工做、转Java等缘由，本人提出离职；
而担任前端开发工做的核心开发者也一样由于待遇问题、发展前途、技术路线不匹配等缘由提出离职。
项目完全失控。
问题分析
- 未能及时的向上级汇报可能存在的风险，未能考虑补偿资源等问题。未能实时的进行问题的跟进，汇报和沟通，直到最终问题没法弥补而爆发。
- 项目管理过程当中过程数据不完善，没法造成有效的经验教训知识库，容易形成组织过程资产的流失。
- 这个项目前期需求范围虽然比较明确，可是技术细节多，人员不足，设定工期内明显完不成。
- 项目团队属于从新组建的团队，都是入司未满一年的新员工，且还有一半是在项目期间组建的新员工，彼此缺少磨合。
- 项目任务优先级不明确，对MVP的粒度划分也不合理。（由于设计器功能很复杂，花费了大量的时间去开发）前期的功能粒度划分不合理，测试没法第一时间介入，问题积累到后期爆发。
- 功能逻辑复杂，细节颇多。拍脑壳式的工时估算和计划不适合此类项目。
- 异地沟通自己存在时延，影响了项目执行效果。
- 因为为了完成不可能完成的任务，项目组成员被迫赶工期，为了盲目应对需求变化而投机取巧，不免会改出新问题。
- 公司内部对代码质量和工期提出了新要求，延迟这么凶的项目显然不会得到高绩效；除此以外，内部政策变更，要求实施9116的工做制度，加上提出了封闭项目等政策，让内部消极情绪开始占上风。
- 自己存在一些技术问题。
结论
使用好项目管理工具备利于知识的传承和积累，对项目管理过程来讲尤其重要，这个项目虽然使用了Jira做为项目管理工具，设定了迭代目标和周期，可是未能妥善使用，依然是用excel进行项目管理，措施不科学，也没法直观的观察项目进程。
互联网产品致力于为用户提升更高的用户体验，所以须要花更长的时间和精力进行UI级的打磨、开发者也一样须要花更大的时间来完成对应的开发任务，做为项目经理要学会作好上下沟通，遇到问题应该给出本身的专业意见，有问题应该尽早向领导汇报风险，积极的反馈意见，哪怕收不到积极的响应，也能起到提早预防的做用。
进度和计划当然是很重要的，可是要认识到人才是企业的核心竞争力，一支对产品精益求职的产品设计团队、一支天天愿意花10小时耐心写代码、努力提升研发产出的软件工程师团队是互联网产品成功的核心关键。
一味的压缩工时来完成产品的研发不现实，在时间、进度、质量之间，必须找到一个中间点，这就要求作好客户的预期管理。
