团队管理

产品目标

根据前几天管理层对2017年度规划的整理和逐渐成型，我们会看到一幅激动人心的产品发展图景：200+客户，双十一百万级的订单处理，千万级的营业额，基于ERP产品的协同产品的雏形……这样一幅图景，必须要一个足够优秀的产品作为支撑的，而这也需要市场、产品和研发三个团队的协作才能完成。我们需要的是

1. 市场团队的嘴，要跟客户去聊，宣传我们的产品；
2. 产品团队的腿，要到客户处实际调研，精准定位产品需求；
3. 研发团队的脑子和手，要将需求转化为算法和数据结构，并亲手敲出每一行代码，将产品实现。

三者缺一不可。那么，什么样的产品才能支持这个规划，从研发角度看产品，应该有什么样的目标呢？我个人认为就是以下三字诀

稳（稳定）：我不止一次从产品和市场团队的同事那里听到过，一年200个客户的目标其实不难，首要的条件就是产品的稳定。通过2016年产品的演化，我们也确实发现稳定是第一要务。只有产品稳定了，才能做到满足客户90%以上的常规使用需求，以及实现现场不留人。这样实施团队才能以更多的精力扑到市场拓展中；
准（准确）：稳定之上的要求就是准确。库存不准一直是困扰我们WMS产品的一个大问题。随着各种数据积累的越来越多，各种报表需求的逐渐涌现，准确的归集和展示数据将成为我们的下一个挑战。产品功能和性能的改进是产品好不好用的区别，数据准确性问题却是ERP产品能不能用的区别，所以准确这一点是无论怎么强调都不过分的；
狠（性能狠）：稳定之上的另外一个要求就是性能。现在客户少，性能瓶颈体现的不明显。随着2017年客户数的增加，我预计有些以前不是问题的问题会成为我们的困扰。这不是增加服务器所能解决的（而增加硬件投入本身就是成本），还是需要在产品中应用一些以提高产品性能为目的的关键技术。

稳定是一个中心，准确和性能是两个基本点，三者同样是不可或缺的。只有做到了这三点，我们才敢拍胸脯说我们的产品从设计开发角度是可以胜任用户的需求，满足大量用户的正常使用，是真正的SaaS产品。

以上谈了这么多，是希望2017年我们在产品研发过程中，能够将目标具体化和可量化。除此之外还有一些具体的改进希望大家能够引起重视。

加强项目管理

最近2个月，我们在使用禅道进行管理的尝试中，逐渐体会到这个工具的便利性和对我们项目管理的帮助。2017年我们应该在现有使用经验的基础上，更加规范项目管理的过程。具体要求如下：

1. 产品团队提出的业务需求以及研发团队内部的改进需求（例如性能改进）要100%体现在禅道的需求中；
2. 每天的工作要100%体现在禅道的任务中。年后我们会试行通过禅道任务来统计周工作量，用更精准的数据替代周报的作用；
3. 通过禅道这个工具，能够比较准确的划分每个产品的迭代，以及比较准确的预估工作量。这个要求是和使用者的能力相匹配的，不仅仅是个工具问题。我们要在新的实践中，根据迭代时间合理选择需求，并能够根据实际比较准确的预测每个需求开发的周期；
4. 维护好Bug，严重的问题做到日清。同时bug的改动要在任务中有所体现，这样能更好的实现“禅道任务统计工作量”的目标。因为我们改bug也需要时间，更何况有些修改相当于实现另外的需求。

加强代码管理和审核

2017年，我们要加强以git为基础的代码管理和审核，具体要求如下：

1. 实行Owner负责制。Git上每个项目会有一个owner，对这个项目的代码负责。其他开发者的提交要由Owner进行审核，并由Owner管理每个迭代发布版本。
2. 坚持fork-PR的提交模式不变，不能随意在主项目上新建分支，PR的格式要求不变。随着代码越来越稳定，每个PR的内容应该更加明确，改了什么，解决了什么问题，都清晰的记录在案。现在对格式要求不是那么严格，主要还是考虑现实情况不允许过于严格，并不是废弃这种要求。所以还是希望大家在比较重要的PR上执行提交规范。
3. Owner要负起审核代码的责任，最好在提交前就能发现一些不符合要求的代码。对于一次PR提交过多文件的现象一定要特别的予以重视。
4. 坚决杜绝不经过测试就提交代码的行为。不要总认为自己修改的内容少就不测试，直接提交。最后往往给测试团队和其他开发人员带来不必要的困扰；不要总认为测试团队是为我们服务的，功能完成了，自己不怎么测试就丢到了uat上，再等着打回来修改。这两种认识误区都会导致欲速则不达，降低了整体的效率。

加强技术学习和应用

在新技术的学习和应用上，我们希望在2017年可以百尺竿头更进一步。通过对现有产品的理解，为了达到以上的“稳、准、狠”的目标，包括并不限于以下三个方面都有学习和应用的必要：

1. 开发：开发中涉及到的编程技术和架构实践，例如，Java8，微服务，分布式事务一致性等；
2. 数据库：数据库层面的性能优化，例如，主从分离，全文搜索，分库分表等；
3. 运维：运营维护中和开发息息相关的部分，例如，自动化运维（异常发现等），ELK等。

有了学习的方向，我们还应该多进行技术上的分享。2017年我们会固定一个时间段做技术分享沙龙（DUP Share Salon）。除了分享大家的学习成果以外，我们还可以就已经应用的技术给大家做一些普及工作，例如git flow，宏观的系统架构，业务模块涉及的一些技术原理（最典型的就是DTS），以及前端的一些基础专业知识等，甚至于Idea的高效实用技巧。内容是不限定的，只要觉得有助于提高大家的技术水平和工作效率的内容，都可以开坛授课。同时也能逐步锻炼出大家善于表达，敢于开口的能力。

加强业务沟通和思考

尽管说我们需要在今年加强技术方面的学习和应用，但产品的业务实现依然是重中之重，这是由ERP产品和后续的协同产品的特性决定的。并且由于我们都不是业务专家，所以在业务实现过程中，必须加强和产品团队的业务沟通，理解每一个业务名词所代表的含义，明确每一个业务需求的具体要求。

在我们使用禅道的过程中，要杜绝完全按照任务描述去完成功能，而缺乏独立思考的问题。写的再详尽的需求，拆解的再合理的任务，也会在落地时产生一些变化和意想不到的影响，何况我们现阶段还做不到这么精准的需求和任务。那么就需要开发者在做的过程中，多一步思考这个功能会带来什么其他的影响，需要什么其他的改变。我们在合并拆分、采购、组合商品、智能波次等特定业务场景中，都遇到了这种情况。未来还会有很多，需要我们发挥聪明才智，找到那些隐藏在复杂业务场景下的隐秘的关联关系。

规范考勤制度

随着公司业务范围的扩大，越来越多的人加入到团队中来。我们的管理不能还只停留在小作坊的模式，要向正规公司转变。原来我们在考勤制度这块是有所缺失的。有些同学可能认为规范考勤制度是对研发人员的束缚，其实并不是这样的。

首先我们现在还没有像袁红岗那样的大牛程序员，完全不能被这些俗事束缚；其次我们需要团队集体工作的氛围；再次，规范考勤制度，也部分的减轻了大家的工作强度，做到因人而异。所以新的一年在考勤制度方面，我们先规范起来。

1. 试行部分的弹性工作制：以9点-19点为标准上班时间（中午1小时午休，周六减2个小时），上下扩展2个小时，但不能早过8点，也不能晚过10点。早来早走，晚来晚走。
   在这个制度下，完全依靠大家的自觉性，现阶段不做强制性的检查；
   这个制度会引导大家尽量增加上午的工作时间，一天之计在于晨，上午更能保持清醒的头脑和高昂的斗志。晚上多花费一些时间陪伴家人；
   由于我们的任务都已经录入禅道，每日的任务必须完成，但会尽量不占用大家的休息时间；
2. 迟到是不被允许的，10点之后即为迟到。每次迟到请自觉留下10元钱，作为大家夏天的防暑降温费；
3. 请假不能事后宣布，要在休假之前发送一封电子邮件给[e-mail]，说明请假的时间段，并提前做好backup；
4. 所有法定节假日按国家规定休息。如遇加班，紧急任务完成后会进行调休