在最近几个月内，我都在致力于转变团队被动交付的现状，做了一系列团队管理的动作，先从需求收口开始整理拆分需求，再去把控交付效能，交付质量。这一番折腾完事，团队的效率是有所提升，需求管理更规范了一些，但是仍然没有改变团队被动的现状，依旧是业务方说，我们做。同学也觉得很委屈，需求来回改，重复返工还被业务方批评。
我一直认为这些问题是团队缺少专职的产品和设计、测试导致的，毕竟如果有了产品可以明确功能流程，有了设计可以确定页面元素和用户交互，有了测试可以大幅提高交付质量。昨天偶然有个朋友跟我聊天诉苦，说她在公司总会被领导区别对待，希望领导也能优待她。我半开玩笑的跟她说，你提升提升自己的价值，多主动思考提提意见就行了。说完我觉得这话应该说给我自己。。
当我执着于改进团队交付流程和规范的时候，一直忽视了团队成员们自己的主观能动性在需求交付过程中的作用。虽然我明确拆分过需求，安排过工期，检查过进度，但这些都弥补不了组员主观能动性差带来的问题——机械劳动，被动接收必然导致需求理解不充分，更对需求变更持抵触情绪，最终草草写完代码交付了事。可想而知心情差的时候写出来的代码质量有多堪忧，业务方也难免不满：改个页面怎么会有这么多问题。
究其原因，需求之所以变更，可以说大部分的原因是因为业务方没有想清楚自己想要一个什么样的产品，边做边改。另外一种情况就是做着做着，突然发现把路越做越窄，不得不推翻重来。这两种情况可以说不可能完全避免，如果把自己当成一个做事小弟\前端切图仔，不去理解需求变更背后的原因，只是机械的接需求，被动的干活时，看到的是频繁变更的页面设计，和业务方对重复返工的不满。但如果换一种思路，把自己当作是需求的解决者，和业务方一起主动寻求这个需求的解决方案时，则会看到业务方给出的需求设计的合理与不合理之处，主动提出自己的想法和意见，同时也会理解需求为什么要变更，抵触情绪也就不存在了。
把思路从跟着业务方做事变成与业务方共事，一方面会由于理解需求变更的内在原因而减轻对代码变动的抵触心理，更重要的一方面是当自己把自己当成是需求的主人时，更会自觉的为页面的设计出谋划策，为交付质量随手做一轮测试，自主的思考系统的某一个功能实现是否可扩展可抽象，我相信这其中为个人为团队带来的改变，远非是招几个产品设计测试所能解决的。
