背景介绍
- 当上开发经理不到半年时间。
- 团队共5个人。
- 团队主要负责混合云相关的一款公有云产品的优化和维护。
身份的转变
程序猿
- 如期完成开发经理安排的开发工作。
- 遇到一些解决不了的问题，可以说：完不成了，抛给开发经理。
- 对小组内的其它同事的工作可以不关心不过问。
开发经理
- 不再过多关心自己写了多少漂亮代码，完成了多么优秀的一些事情；而是以整个团队的整体输出为主要目标。
- 接到需求了，首要考虑的问题是：1.什么时候完成。2.谁来完成比较合适（关于合适，考虑的维度会比较多）。而不是我要如何来做完这个事情。方向一定是：管理。
- 需要清楚团队每个成员的性格以及工作能力，有针对性的安排任务。
- 需要保持比较合理的产品迭代进度，让团队成员觉得比较合适；也就是必须要有阶段目标，而且是一直要有；谁没事干了，那就是你的责任。
- 时刻要有自己的想法，当前阶段需要做什么，未来应该做什么；不要等领导或者产品经理提需求，然后才去做，没有需求的时候，团队做什么（这个可能得看团队或者产品，暂时我没有经历过一直有需求的时候）。
- 上对部门领导，下对团队成员，左对产品经理，右对测试人员，面对多种角色，沟通一定要到位。
- 团队的每一件事情，都和你有关系，要对每一件事情负责。
开发过程管理
工作的安排
安排工作的一些基本内容：
- 以合适的迭代进度来安排任务，比如一周或者两周；每个迭代都要有对应的里程碑，比如公有云产品的上线，小版本的升级，或者重大功能的完成，最好能有阶段性总结。
- 每个任务都得有开始时间以及deadline，一定要具体到个人。
- 一件事情，我们的需求是什么，现状是什么，目标是什么，以及要达成这个目标的话，接下来可能需要关注哪些重点（这个视情况而定，有时间有必要的情况下，可以做一些说明），上面这些点，在安排任务的时候就得全部说清楚；或者其实是要求开发经理，要先想明白，否则根本无法落实。
- 不一定任何事情，开发经理都知道怎么去做，没有关系，只要说明白你想要什么，并且这个目标是可实现的，然后让同事去自由发挥就行了。
- 工作中肯定会处理一些需要相互协作（团队内部的协作）的工作，所以一定要在安排的时候想清楚每个人负责的边界，不能含糊不清。坚决不允许出现：本身被划分得很细的一件事情同时由多人去做的情况。
安排工作中一些关于个人成长的内容：
- 知人善任，给什么样的人安排什么样的活，说起来挺简单的，做起来不容易。
- 考虑这几个因素：
- 个人能力属于哪个层次------决定了安排什么复杂程度的工作。
- 个人所喜欢做的事情以及不喜欢做的事情------安排做喜欢的事情当然很乐意，不喜欢做的事情难免有一些抵触情绪（工作嘛，当然不是喜欢不喜欢，但得知道）。
- 个人较强的方面以及稍弱的方面------较强的方面，可以把一些紧急的任务安排下去，也能够保证进度；稍弱的方面，就是你来负责提升的点，适当的时候应该给予机会去让其锻炼和成长（前提是对方愿意，这个从侧面了解或者正面直接沟通就行了）。
- 个人对待工作的态度、做事情的方式------这个决定了工作中如何沟通吧，最难的一个吧。
- 安排工作的时候，一定要给同事留一定的发挥空间；把自己该做的做了，剩下的相信他们，让他们去做。
- 有挑战性的，或者无聊的搬运工作，相互兼顾着来吧。
- 适当的时候，安排一些超过个人能力本身的工作，其实就是把本来应该自己做的事情安排下去，比如一些设计或者调研工作；或者一些个人没有做过的工作。
工作的跟进
工作安排出去了，那到底做得怎么样，什么时候才能够让你看一下效果，什么时候能够开发完成，什么时候测试就可以介入测试，能不能按照预期的做完，这些事情，你都必须要清楚。
简单来讲，你需要一个：任务看板。
任务看板的具体形式的话，根据情况而定吧，一般情况下，公司内部会有有关开发过程管理的工具，比如jira，或者更简单的一些，就是excel表格了，最好能够共享的那种。
不管是什么样的形式，一个任务看板中要能够包含下述基本内容：
- 每一个迭代中所包含的所有任务。
- 每个人手中目前有多少个任务。
- 每个任务当前处于什么样的阶段：未开始、开发中、开发完成自测中、测试介入等等。阶段的话，主要是以你所关心的阶段为主。
- 最重要的一点：每个人要主动实时的更新任务的状态；被迫更新的话，可能就只是单纯的做一些面子工程了，也起不到开发过程的管理效果了。
但是实际上，小团队的开发过程往往都是敏捷开发，而且加上小团队本身的特点（人数少，迭代快，距离近交流方便），如果非得用任务看板来推进的话，可能会浪费一定时间而且效果也不少，距离这么近，一句话就能说明白，还非得用看板？
可能对于一个事业部老大而已，几十或者几百人，那他们肯定只能看任务看板了，然后到了每个部门的话，有大概10-30人左右，对于部门经理，没有办法详细跟进每个任务，那也只能看面板。但是到了每个开发小组的话，就那么点人，再继续用的话，可能就不是特别合适了。
所以一定要根据实际的情况，有针对性的使用一些过程管理工具来提高开发效率。
我这边目前的一些做法就是：
- 使用jira来记录跟踪一些比较大的特征。
- 使用协同文档excel来细化每一个开发特征，列出具体的开发任务、负责人、迭代结束的日期等。（目前我们这边开发过程管理工具更多的是从产品层面来使用的，但是从开发角度来说的话，还差那么点意思，比如可能要关注哪些方面，要重构哪些代码等等，所以就用表格了，感觉更能满足我的需求）
- 发现的bug，用Jira来记录，这个可以上传图片、附件等，完成了打个关闭，然后自己去验证，可以验证通过或者不通过。
使用什么样的工具或者方式来进行开发过程的管理，不重要，重要的是我们保证开发任务的正常迭代，所以根据实际的情况找出合理的方式才是最重要的，而且要不断升级优化自己的管理迭代方式。
另一方面，跟同事说任务进度的时候，可能需要注意的点：
- 可以一次性安排很多任务，在不着急的情况下，可以让他们自由安排，按照自己的想法去执行就行了。但是得说一个整体的截止日期，或者针对某个任务的截止日期。
- 一些任务变得紧急了，立即告诉同事，直接调整安排的进度。
- 一些任务眼看着要完不成了，要适当地说一些比较重要，必须完成之类的话，要想办法促进任务的迭代速度，有一些适当的鼓励措施，对个人，对团队。
- 充分沟通之后，要是还是做不完的话，就得及时提前和相关人员沟通好延期问题。
工作的提交、测试
前面说到安排和跟进，完成了以后，那就要提交了。
- 需要一个清单，这个可能和开发任务或者特征有所不同；这个清单是给产品和测试人员看的，所以更多的是功能清单，以及需要注意的点，影响的范围，基本的测试方案。
- 用这个清单，和测试人员交流一次，然后去测试。
- 测试完全通过以后，让测试把所有的测试用例整理出来，再过一波，看看有没有遗漏的；然后用这份测试用例用于后面的迭代上线。
- 列一份上线流程，在预发、灰度等环境就直接使用此流程上线。
- 需要额外记录一下在预发环境、灰度环境遇到的所有问题，彻底分析问题如何产生的，怎么解决，以及如何在正式环境避免。
- 上线结束后，做一份上线总结，总结做的好的地方，进行鼓励和表扬；但是对做的不好的地方，仍然需要指出来，责任自己先背了，但是怎么处理以及后续避免的方式，让相关的责任去完成。
其它方面
上面主要分享了身份转变以及开发过程管理的一些感受吧，要说的话，还有其它的一些方面：
- 团队工作氛围的营造,工作方式的规范。
- 开发经理的持续成长。
- 如何成为开发经理。
后面再分享吧，就先说这么多。