项目技术复盘

背景

该项目接手时已是8月中下旬，并且客户要求九月中旬输出第一版本。这么紧急的节奏，不知道商务是如何答应的。临危受命，让我承担开发经理岗位，主导该项目。

开发团队
岗位	人员	base
架构师兼高级软件工程师	季工	上海
高级软件工程师	李工	上海
中级软件工程师	刘工	上海
开发经理兼高级软件工程师	本人（谢艺华）	合肥

问题

如何打入陌生团队

正如项目背景介绍的，该项目是临危受命，并且项目工期十分赶。我刚开始十分怀疑主管是让我来背锅的，但是无可奈何，只能硬着头皮上了。我遇到的第一个难题就是:对开发组成员并不认识，甚至都没有交流过，后续如何开展工作。经过向领导打听，了解到他们三个之前是在泛亚项目中一起共事，并且技术都相当不错。如何快速融入这个陌生的小团队中，方便以后开展工作呢？我是从以下几个方面做的，并且最终的效果自我感觉也还行。

面对面交流，是了解一个人最快速的方式

因为他们三个都是base上海，并且我们从来都没有交流过。为了团队成员之间加快了解，我建议他们三个先出差合肥，大家进行集中办公，快速输出第一版本。很可惜，刘工因为某些原因，没有一起来合肥办公。

经过几天的相处，我大致了解了季工和李工的特点：

季工：工龄12年左右，技术能力强，做事周全。工作中会主动考虑一些全局的东西，如何方便他人开发，提供别人的效率。平时喜欢打lol。

李工：工龄6年左右，技术能力较强，属于同年龄中的佼佼者，因此有一些傲气。当然自身的实力，也是他傲气的资本。对技术喜欢深究，专研。

承认对方的优秀，同时展现自己的实力

季工和李工两人的技术很厉害，刚当上管理角色的小伙伴，可能会有这样的纠结：如何能在团队中让他们信服我，愿意听我的安排呢？他们技术能力这么强，我说的一些他们很有可能会提反对意见，造成分歧，对项目进展造成影响。

其实大可不必有这样的担忧，你可能陷入了以下几个误区：

当今社会，在团队中，一个人基本不可能面面俱到，总会遇到在某方面比你强的人。承认别人的同时，也不要妄自菲薄。
团队中的每个人的目标都是将事情做好，
团队中有讨论才是良性循环。并不要因为你是开发经理，别人都应该听你的。你的想法如果能站的脚，能够说服组员，自然会听你的。

我的做法就是：

尽量发挥自己的优势。术业有专攻，每个人都有自己的优势。比如，他们之前仅做过泛亚项目，而我已经做过江铃，长城，甚至已经做过从0到1的东风商用车项目。因此，在OTA的业务上，我应该比他们理解更为深刻。OTA 各模块中，安装模块一定是最复杂和繁琐的，大家基本都会避而远之，而我则主动承接。一是对自己的信心，二是这么重要的模块，也不放心给其他人；又比如，身为开发经理，我的重心会放在项目的整体需求，不仅需要熟悉自己的模块，对其它模块也要有一定的了解，这样才能通过日会了解目标的进度（这是开发经理的职责所在）。
给彼此一些自由度，尊重他人，快乐自己。技术能力强的人，一定会有自己的想法。我的做法就是需求给他到，明确我的要求，定好deadline，剩下的交给他自由发挥。往往会有不错的效果。
主动承担岗位职责。开发经理的职责我理解主要有3点。一，控制项目开发进度，识别风险，解决风险。二，作为项目技术对外对接人，包括对需求的确认，第三方对接。三，对内进行技术支持。因此，在涉及到对外交接的地方或需求存在疑虑的地方，我一般都会主动去确认，再转达给内部。让他们更多的专注于开发工作。

从结果而言，大家彼此配合起来还是不错的。以上仅是我个人的经验。

如何快速输出第一个版本

我们团队成员应该是在8.20确定的。而客户要求9.16输出第一个版本。经与项目经理和客户的确认，按照客户的需求，想在这个时间点输出第一个版本，基本是不可能的。我的做法：

减少工作量。与客户进行battle，表明工作量之大，难度之高。适当的做减法，将一些功能剥离出来，放在下一个版本。
对内明确需求。因为时间十分的紧迫，根本没有给我们犯错的时间。因此每个人对自己的开发任务都要清晰，不能走弯路。
任务粒度适当。我将每个人的任务进行分解，基本都在1天或2天的工时。这样可以时长关注大家的进度。而不用过度开会。

经过大家的努力，我们如期将第一个版本输出，并得到客户及领导的认可。

第一次通宵熬夜

现在回顾项目周期，唯一一次的熬夜加班就是第一个版本发布。背景是这样的。正如上面介绍的，因为第一个版本时间比较紧，我们当时的工作分配：每个人负责对应一个或几个模块，开发完成后，需要进行自测。9.10需要完成，之后，留一周的时间，进行全流程的联调。

而结果是，我和季工，李工都按时完成了，并进行了自测。但是刘工并没有按时完成，并且联调时会发现很多问题，经常crash,或需求不匹配。（季工和李工的问题基本没有，其实这时我的内心很崩溃的，因为之前我每天会咨询进度，他都说完成并自测了）。没想到临近发布时间，出现这个问题。

究其原因，还是对刘工不了解，并不清楚他的工作方式。当然我也有问题，过于放松了，没有真正的把控住开发进度和质量。

若是让我再来一遍，我会定期走读他们的代码，做到真正把握进度和质量。

需求不断迭代，看不到终点

另一个痛点就是需求的不断变化。因为该项目的需求是由客户输出，我们没有产品经理介入。因此就出现需求完全由甲方控制，随意的增加或修改。曾出现以下的困境：

同一个需求，不断的修改。比如用户授权后等待时间，就从30s 改为 60s,120s，300s等。
需求一点点的增加。在开发过程中，他们可能会发现一些流程不合理的地方，有些问题可以在OTA端完善，也可以在第三方完善。但是因为需求由他们定，就会优先选择让我们修改。
流程的推翻，部分模块需要重写。让我印象最深的就是开发半年了，安装模块功能已经基本稳定，客户却提了一个新需求，就是安装流程的变化。当我看了需求之后，发现现有的模块流程基本不能满足，需要重写。

在这样的背景下，我们大约开发了半年。我觉得这样下去肯定是不行的，何时才是个头呢？于是我就向项目经理和领导反馈这个问题。后续我们的做法是。

让产品经理介入，整理出《需求规格说明书》，《需求矩阵》等文档，与客户进行评审。双方达成认可后，就按照这个《需求规格说明书》来。后续的需求修改，都需要进行邮件发送。新增的需求要重新评估工时，排期。

之后，客户的需求变更就少了，即使需要变更，也会主动和我们确认。