这篇文章是我2015年的总结。 2015年的经历是我过去五年的缩影，但给我自己的迎接带来的思考不足远远大于过去五年。
在项目开发的过程中，
首先了解商业需求，互联网公司对了解商业需求提出了更多的要求。 不仅要理解要做什么，还要关注为什么要做这个，会给客户带来什么。 客户真正需求的目的是什么？ 客户在使用功能过程中，最关注的是什么？
在业务实现过程中，
关注代码质量、单元测试。 在编码过程中参与codereview事件，并在提交代码时成对review。 这些活动，才是真正能够提高产品质量的措施。
以往的开发经验，个人更注重完成更多的功能，让更多的功能上线。 这种想法问题很多，大多依赖于开发的个人资质，遇到开发能力差的开发，提交的代码质量往往很差。
假设某开发者有能力制作完整的单元测试，这样开发的产品质量可靠，无需测试就能验证功能。 可以让产品体验功能。
开发人员在了解功能后，通过编写对应的单元测试用例，不仅可以保证高质量的产品交付，还可以实现单元测试的积累。
单元测试在长期提高质量的同时，往往也有助于代码的设计。
存在的疑问：传统公司可以花一个开发、一个测试、一个开发周期、一个测试周期来完成工作，但是招募两个开发，在两个周期内完成一个功能生产更有效的产品。 国外很多公司都是这种模式。 而且，一个开发本身应该对自己的生产质量负责，而不是写完就交给测试。
在管理上，
在技术管理、大项目上，我会关注，发现其中的技术难点，询问开发思路，提出自己的设计思路。 最终实行开发。 通常一般的小设计，没有太多技术难点，所以我也忽略了这个问题。 开发者的开发能力也达不到真正工程师的开发水平。 一心想着加快进度，上了很多功能，但也招来了很多怨恨和非议。
总体上我们也采用了Scrum方式。 日常开发工作包括以下几个方面。
业务功能分解这里分解粒度比较的重要性在于，一个crud基本上可以作为一个功能点、一个技术难点、一个交互式界面。 需要划分为单独的功能。 工作的分配在于敏捷开发。 这需要开发者自己做出选择。 如果执行的话，好处是显而易见的。 可以提高开发者的积极性。 但是，目前我们的方式还没有取得好的成果。 通常，我会根据每个人的特点来安排任务。 后台的系统很多，功能很潦草。 我将每个系统，划分系统的owner，根据人员特点，组成编码pair，后期项目质量提升明显。 评估工作量并制定开发日程，在这里需要考虑开发能力、功能难度和结合测试的时间。 如果你是开发组长，并且期望能交付高质量的产品，那么这里就要确保开发有足够的时间完成工作。 如果你是项目经理，你需要争取尽可能多的时间完成。 当然，通常不会给你太多时间。 互联网的时间就是时间。 谁是最早的生产线功能，谁能占得先机？ 那么，如果时间紧张，该怎么办？ 砍掉需求，这要看你的本事了。 在这方面，我很薄弱。 我以前被告知，我认为努力工作，与人撕毁是浪费时间。 事实上，就连产品经理也觉得，除了实现编码外，还需要多动脑筋参与开发。 其次，如果开发工作量饱和，不要着急增加工作，也不要加班完成某些功能。 往往，有些需求并不是很急，只是产品YY了，我觉得需求很急。 我们的业务系统意识到的柚子有一个业务功能，就是产品很急。 虽然一定要上传，但是因为没有时间开发，所以这个功能过了8个月还没有上线。 你认为是重要的需求吗？ 总之，在这个阶段，需要争取足够的时间。 每天了解开发进度的站位会议在任务安排好后，需要每天更新进度。 一个是如果开发者自己能更新的话，就可以避免开发者束手无策。 早上的会议是了解彼此工作内容的过程。 晨会期间，很多人只关心自己，完了什么也不做。 实际的晨会也是提高自己的机会，也有人说自己面临的问题和解决方案。 积极的人，会提出自己的想法，提高在自己团体中的影响力。 探讨和跟进各种具体的技术问题，在一般的业务需求层面，尤其是项目建设完成后，需要设计的内容不多。 大多数开发都知道如何使用redis、sql、mongo等。 在典型开发中，最擅长的是定义service、dao并与其他模块交互的地方，发送MQ消息或直接的RPC调用。 在这个框架下编写代码，并不是考验开发的设计能力，而只是业务的编码实现能力，实际上需要参与设计的地方并不多。 但是，不成熟的团队需要不断地理解
他们的实现方案，否则极有可能做出一个上线就OOM，或者不能处理大量请求的功能。 这也是普通开发人员和高级开发人员的差别。 互联网产品，遇到最多的是高并发的大量请求，一般的开发人员没有经验就容易犯错。 协调一些产品需求变更 我经常跟产品说，有需求变更不要紧，没有人会一次就考虑到所有的功能。但是，刚好是这样思维，让我自己没有去追求完美。我原来是一个追求完美的人，弄的别人会紧张，尤其是家里人。后来放弃自己追求完美的个性，这个思维放到了工作中，却让我自己吃亏。我之前一直觉得，好的开发，应该在开发的过程中设计一个可扩展的架构，以方便后续产品的变动。但是，换到产品的角度想，他们却希望，每个人都给他们提建议，这样，他们做出的产品才会好用。换成你，可能也一样。在需求一开始，就应该仔细的参与讨论，让产品需求能够尽可能打磨精细。让开发在后期的改动尽量少。但是变动总会有，我通常只会去协调他们找对应的开发。需求的变动，我并不总会去关心，有大的需求变化，开发自己也会跳出来说。 跟进相关功能上线 功能完成上线后，在线上环境可能会出现一些问题，一些未覆盖到的场景，由于提供的接口被多个模块调用，可能会出现一些问题。当这些线上问题出现后，开发人员需要迅速的定位。这个是比较考验开发人员的技术能力的。作为一个互联网公司的技术团队，我们应该还有能力直接响应市场、运营、客服或其他部门同事的业务需求。
因为产品部门有时考虑的只是怎么来增加新功能，会忽视来自其他部门的真实的实时的需求。因为有些需求，在他们看来是不重要的。这个和组织结构相关，如果产品和技术是两个独立的部门，产品只关注产品部门自己的绩效，并不一定需要实时的来响应其他部门的需求。
而技术，则并不应该期望自己只成为一个执行部门，需要扩展技术的影响力，这种情况下，积极的去主动了解其他部门的需求，并主动的改进到工作中。不要成为一个Code Machine。