背景
该项目接手时已是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端完善，也可以在第三方完善。但是因为需求由他们定，就会优先选择让我们修改。
-
流程的推翻，部分模块需要重写。让我印象最深的就是开发半年了，安装模块功能已经基本稳定，客户却提了一个新需求，就是安装流程的变化。当我看了需求之后，发现现有的模块流程基本不能满足，需要重写。
在这样的背景下，我们大约开发了半年。我觉得这样下去肯定是不行的，何时才是个头呢？于是我就向项目经理和领导反馈这个问题。后续我们的做法是。
让产品经理介入，整理出《需求规格说明书》，《需求矩阵》等文档，与客户进行评审。双方达成认可后，就按照这个《需求规格说明书》来。后续的需求修改，都需要进行邮件发送。新增的需求要重新评估工时，排期。
之后，客户的需求变更就少了，即使需要变更，也会主动和我们确认。
优点
当然，项目过程中，我们也有做的比较不错的地方。
参数配置化
季工的最大特点就是提供一些好用工具，帮助大家提高开发效率。其中有一个比较好的，就是参数配置化的功能。
季工引入的这个工具，可以将一些参数保存至配置文件中。程序启动时，会从配置文件中读取。好处如下：
-
可以给测试人员，集成时，一定的自由度。比如，我们可以通过配置开关，控制OTA的流程，若HMI功能异常，我们可以skip 该流程。
-
需求更改时，不需要修改代码。比如上面提到的，用户授权的等待时间，经过多次的修改。若是写到代码中，我们肯定做了多次的修改发版。而通过配置文件，大大减少了类似的时间消耗。
真诚才是必杀技
我身边有些同事与客户的交流方式，让我不太理解。总是不会坦诚相待，比如一个问题出现了，第一句话总是："我没有问题，你们先看看吧"，即使发现是自己的问题，也不会承认。在下个版本默默修改好。经常就会陷入与客户面红耳赤的地步。
我觉得完全没有这个必要，大家都是开发人员，都是为了解决问题而努力，开诚布公，才是对项目更友好的方式。
客户反馈的问题。我一般都会立刻响应，若比较忙的话，也会如是说："现在比较忙，稍后看一下"。但是对客户的每一个问题，我是一定会有应答和结论的 。客户有时会向我请教一些crash问题，我也会主动帮他们分析，教他们怎么使用gdb和一些高阶用法。
这样给我带来的好处就是。当我遇到一个OTA 问题时，需要系统工程师协助分析时，客户那边就会非常主动，积极的帮我找相关的同事，拉会，沟通。我这边的问题处理起来也会快很多；遇到一些节点delay的情况，客户也会比较好说话，不会追究什么。
整体而言，项目开发过程中，出现过很多问题，但是基本都会很快解决。这也离不开客户的支持与帮助。
展望
本文只是分享一下带项目过程中遇到一些问题及解决方式，希望能给正在经历的人一些帮助或参考。若有更好的建议，也十分欢迎一起讨论。
也欢迎大家分享自己的经验或吐槽~~
