如同没有完美的架构，我想也不存在完美的项目管理，只有不断演进可能变得更好的项目管理。
入行这么多年经历过形形色色的项目管理，散养式、独裁式、随心所欲式、瀑布式、敏捷式都曾体验过，究竟怎样才是我心目中理想的项目管理呢？传统行业的软件有做项目和做产品之分，需求要么来自于甲方客户要么来自行业长期的积累。相比之下互联网行业更侧重于做产品，而需求主要来自于产品经理的想法。这一特点决定了互联网行业需要更多试错的机会，也就需要更频繁快速的迭代以交付可用的产品。
产品经理首先需要确定需求范围和设计原型，并召集相关人员进行一次头脑风暴，一是让大家都明确大概的需求是什么，二是可以大致梳理清楚主要的用户故事。评估可以投入的开发和测试资源，通过计划扑克对用户故事的工时进行评估，与产品经理确定用户故事的优先级。综合每个用户故事的评估并结合风险控制，估算出团队的开发效率，进而预估出总工时，如果总工时较长可以拆分成若干次迭代，每次迭代尽可能控制在10个工作日左右，既可以保证有较充足的开发时间，又可以保证相对较快地迭代出一定的成果。具体的开发过程中可以设立一个白板，针对不同的开发阶段设定Todo、Doing、Done的区域，分配给每个开发的任务开始都位于Todo区域，每当任务开始会移动到Doing区域，任务完成会挪到Done区域。可以在每天早晨进行一次简短的15分钟立会，对每个人的开发进度和遇到的困难进行简单汇总。对于整个项目的进度可以用燃尽图进行描述，如果遇到导致项目滞后的问题应及时和产品经理沟通，适当地对任务作出调整。对于需求的把控原则是，每轮迭代任务确定后设置基线不允许再做出变更，新需求和无法避免的需求变更尽量调整到下一次迭代中。开发和测试进行并行的迭代，每当开发人员进行一轮迭代的时候，测试人员需要对需求进行了解并开始着手准备测试用例，待开发结束就可以立刻投入到测试中，开发人员又将投入下一轮迭代中。每轮迭代结束都需要对开发效率进行重新评估，以确定下一轮开发是否需要做出调整。项目开发过程中我们还需要借助版本控制Git、持续集成Jenkins、容器技术Docker等工具提升开发流程自动化、持续集成、持续交付的能力。
项目管理是折中的艺术，在时间、成本和质量间寻找平衡点。但项目管理做得好不好归根到底还是人的问题，沟通顺畅了项目执行得也会流畅，开发觉得有成长有激励有成就感才会更有干劲开发效率才会有持续的保证，警惕不要为了盲目追求进度而忽略了人的感受。
