追求梦想
18年年初的时候，研发部门的开发经理找我讨论新工作流时，让我对我自己的产品工作有了新的希望，讨论了如何管理需求，如何落地需求，希望能够从产品部门发挥优势，改变目前的局面，这是在无领导授意下的一次变革，我知道这意味着最后的结果是什么，但我觉得这是我在这工作的新动力，我接受了并认识到这次变化到最后会意味着什么，我准备接受的原因有两点，一个是对公司的工作方式彻底失望，想从自己动手，去获取我的产品经验，另一个是经过朋友的介绍，我了解了敏捷项目管理的方法，让我有了一种可以知行合一的机会，把学到的进行实践。
于是，我开始动手准备，从需求收集到需求分析、从讨论需求的可行性到如何可视化工作流等等；第一次先进行对开发小组各负责人进行培训，告诉他们以往发生的问题是因为没有对需求进行矩阵分析的原因，先分类需求后，再进行开发可以有效地提高工作效率，然后再从目前的需求收集方式改善的好处，来证明以后的需求会有所改善，提高开发人员的信心，然后讲解了KanBan的工作方式，来进行可视化工作流，因为从我学习到的知识发现，这家公司并不具备直接Scrum的实力，第一是开发人员习惯了原有的工作方式，在自己接受了需求以后，自己开发，并未考虑价值和更好地实现方式，或者在发现有问题以后，无法确认无法落实，只能错有错招的进行，另一方面是因为测试团队并没有自动化测试的方式来提高工作效率，还是保持着手动测试的方式进行黑盒测试，甚至是同一个需求，两个人在没有沟通的情况下测试了两遍，或者并不了解业务的情况下直接关闭了工作，导致问题重重。
在很仓促的情况下，开展了第一次的每日站会，说真的，我也是认为很形式主义，因为大家并没有在做一件事，只是把各自的情况进行了汇报，说出是否能够完成自己的工作和是否遇到问题，并且按照小组的方式引导个人来领取任务，唯一的保证是每个人每次只做一件事，并且能够有责任完成它。但是从每个人的状态来看，属于突然被拉来开了一场不知所以然的例会，并没有从中得到好处；就这样，先过了新年，在过年中，我反思了学习的知识和遇到的现实问题，并总结了观察到目前的开发的工作方式，于是我觉得从原有的10人小组减少人数变为4人小组，并且按照开发经理的安排，从内控模块下手，统一目标，由一个产品、一个开发负责人（敏捷教练），两个开发人员的四人小组方式固定工作模式，然后保持公开透明的原则，大家在讨论上可以保持开放的原则，进行沟通，并形成可行的方案；然后在以后的发版之后，要组织总结反思，找到可以落实的改进点，不断完善我们的工作方式，迭代到最好。
第一次会议就此开始了，四个人的讨论并未带来有效地进展，反而拖慢了分析的节奏，拉长了时间，于是我们立即改变了需求分析会的方式，由产品+开发负责，两个人来进行需求分析和设计方案的讨论，然后由开发人员从开发负责人这里获得设计方案来进行实施，产品经理则负责需求收集、需求分析、需求确认、需求池维护、相关文档撰写、保证统一目标和价值点的工作，开发负责人则参与需求分析和保证开发流程和质量的工作；开发人员则保证设计方案确定的情况下进行模块开发、代码重构、冒火测试的工作。我们开始了小步快跑、迭代前进的工作，我们不求加快开发进度，只要求保证开发质量和是客户需要的，满足最小化投入最大化价值的工作理念，进行迭代发版工作。在开展工作中，我们遇到了领导突然抽调人手的问题、遇到了突然安排紧急任务的问题、遇到了其他团队在需求不明确的时候传递任务的问题，遇到了两个团队协作交换数据的问题，遇到了外包团队在完成项目后遗漏的功能不完整问题等等，最重要的还是领导拍脑袋决策，认为一切开发的实现方式都很简单的问题。
会有破灭
一切的问题我们都一起讨论，一起分析，然后排列优先级，在有序的情况下逐一解决，这是我们也都始料未及的，到了6月的工作总结的时候，我们意外地发现，我们做了很多的事情。然后因为领导带领着关系户在做另一个模块因为需求不清晰，又反复的原因导致了迟迟没有成绩的原因，我就被意外劝退了。
虽然被劝退了，我还是想总结一下这将近一年的工作经验，反思得失，我认为才能有所进步，否则做了就忘记了，没有思考，没有发现问题，一直都是重复的行为，没有得益。
虽然领导和关系户都认为可能保持这一套新的工作流就能解决需求以往不能及时应对的问题，但是开发的人员都认为并没有那么简单，我从心底里认为也是如此，但是从哪些方面是我的优势，哪些方面还需要再进行改善，我觉得在我休息的这段时间有必要进行一个总结。
反思才能进步
好的方面：
第一点，我认为无论是Scrum还是KanBan还是Dev，尊重每一个人都是第一位的，给你做和一起做的概念完全不同，如果是一个自学习自我完善的小组，那终将会变成一个全栈小组；那么整个企业的实力也是会飞速提升的；
第二点是我认为，虽然可视化的工作流很清晰，流程很清楚，但是产品经理的决策也很重要，如何让需求进入方便，让需求确认，梳理产品路线图和优化方向，明确任务目标和小组收获，也是极为关键的，这是胜负手的关键，并不是看得见摸得着的，因为它是实时变化的。
第三点，在做需求分析的时候，需求讲解，需求答疑和需求补充非常地明确，让开发人员清楚了背景，为什么做，怎样的收益，描述是否模糊，哪些方面需要明确，在处理异常和边界的时候，应该怎么设计
第四点，我们小组无论是日常需求还是其它情况，都保持信息透明共享，这样子可以更好的管理活动、解决问题和风险，最终做到了“同心山成玉、协力土成金”的合力。我们之间相互帮助、相互信任、相互包容、相互谦让。
第五点，我们的目标是以市场为导向，讲究是适时，因为时滞的影响非常大，会影响对外部门的工作进度，从而完成不了公司的整体目标，我们在做需求时，不堵塞需求渠道，反而采用了“堵不如疏”的疏解方式，有效地缓解了各部门之间的矛盾情况，从而从销售、实施到测试部门，都对我们的工作非常支持，对我们的工作成果非常满意。
第六点，采用了OK的方式进行开发（O产品、K开发负责）的方式有效地开展了小组工作，节省了更多的时间。
存在的问题：
第一点， 我们始终面对测试团队无能为力，因为手动测试和测试小组的不沟通问题，导致重复测试，无关键点的重新开启任务频发，后来因为休产假的一名测试回来后，我们才有所好转，但是单凭个人的能力，丢失了测试小组的测试前置，让我们的质量始终无法得到保证，会出现问题。
第二点， 我们面对运维团队感到失望，运维团队的负责人因为是关系户的缘故，导致了此人只解决自己明白的问题，自己从不学习和理解业务，就是单独从服务器这些方面去看待，进而影响了开发和运维的配合，导致了发版之后的问题频发（更不用谈及工单处理时的乱导入问题），从我的观察得出，运维团队根本不具备运维能力，只是单纯的从国企角度，切割责任而已。
第三点， 我们面对领导的临时任务和拍脑袋决策让我们失去了热情和方向，对于吹牛逼和关系客户的临时任务，领导向来是来者不拒，这导致了因为解决问题而完善，不断地解决各种问题，导致原有的产品变成了打补丁，没有路线，没有方向，虽然我们在规划上有了侧重点，但仍难避免乱打枪的问题。
第四点， 我们缺乏明确的OKR制度，没有办法将实施结果进行衡量，无法确认是否开发的功能满足客户使用，而不是白用功，无法监测到平台的使用情况和运营情况；没有数据支撑的分析就是拍脑袋。
第五点， 开发---测试---运维的工作模式无法协同，导致了问题频出。缺乏共同的目标和可视化的后台，不容易查看问题和运营情况，只能每次从数据库和日志中进行查询和纠正。
网友评论