工作警醒录
您目前处于:敏捷  2017年06月17日

承载 —— more、fast

大公司学做事。实事求是,就事论事。


一 快速处理需求

了解团队在做的事,必须参与所有需求评审、设计评审和测试用例评审等,了解细节。

故事1

敏捷团队就像一驾马车,每个迭代就像从一个驿站行驶到下一个驿站。马车装满着货物,每个货物就是一个故事,不同的规模就如同不同大小的货物。马车在颠簸荆棘的道路上高速奔跑,如果马车头也不回的只顾前行,就有可能最终由于长时间的奔波造成马死货毁。要学会在中途停下来进行调整,检查下马匹和车辆,以及货物是否安全,将断裂的绳索拴牢,将松散的货物绑牢。同时,不能只自顾向前,要看看别的团队,有可能别的团队已经开上汽车或火车了。

在每次迭代过程中,最需要注意的有两点:一是马车能载多少货物,如果评估不准,那大多数就会超载,最终受累的还是自己,更不要盖着黑布拉货。二是在路途中很有可能会顺路带个货物,例如途中被要求多载箱葡萄,那问题在于,马车是否还有空间挪出来装下葡萄,如果出发前评估不准,大多数会被加进来,自然受累的还是自己。而且其中还有风险,如果这箱葡萄已经变质了,与其他货物放在一起,可能会造成整车其他水果也变质了,所以对于在途中有新货物,不仅要评估其规模,更要评估其风险隐患。

注意1 (由Scrum改为ScrumBan)

需求梳理是这样的:由主产品经理统筹,完成对业务需求汇总、整理、排期等,只有完成产品方案的需求才能在需求代办列表中排列优先级;由团队系统负责人对技改需求汇总、整理、排期等;整理持续的需求池文档。Scrum敏捷转型ScurmBan,团队不在对迭代内故事进行承诺(迭代内完成),而是转由对看板内的故事承诺(迅速推送),同时也允许对需求池内的需求进行随时调整,但尽量避免大动作的调整。不在看版上的需求都是假需求

注意2

拉取Story到下一列都必须有明确的DoD。Ready列放入的不是一句话需求,是产品方案,有哪些功能?页面长啥样?啥时候要求上线?等等

注意3

如何设置在制限制品,不仅可以设置列的拉取限制,还可以根据团队每个成员承接故事进行限制,如为每个小伙伴分配两个头像,当两个头像都分配到了故事,则限制不能再处理新故事。

注意4

在每日站立会议团队更新故事后,更新追踪表和统计进度。故事追踪表,关注的是故事,不是数据。严控拉入ScurmBan的每个故事(DoD)。

注意5

定期召开团队会议,整合Review、Retro和Planning Meeting。月初和月中召开计划会议,阐述需求,更新需求池;月末号开Review和Retro,Review对Deployed的Story进行演示,Retro通过数据进行复盘,包括业务数据、监控指标和团队数据。而站立会议产品重点说下变更和新增需求,而团队研发根据看板故事说进度。

图片1

故事2

狼性文化:野、贪、残、暴。我们想要我们在团队中是一只狼,还是一只驴。也许我们感觉每天驾车都在高速奔驰,但我们可能只是一只驴,不停地在原地转啊转啊,为什么?因为我们不够贪婪,其次我们没有狼一样锋利的牙齿和利爪,面对挑战,不能凶残的将对手撕碎。

狼是一种群居动物,它们懂得如何配合和协作,例如在面对一群羊时,会有狼充当诱饵,引走猎犬,会有狼冲散羊群,形成包围圈,会有狼,迅速的猎杀猎物,再有狼掩护撤退。每只狼,都有自己的职责,如果充当诱饵狼不能引走猎犬,那么就不能给其他狼找到机会,如果猎杀不能迅速完成,那猎犬回来就可能丢失战机。

我们是想成为一群狼,还是一只驴。如果我们想成为一群狼,我们首先要磨砺我们牙齿和爪子,这就要求我们要学会成长,通过每次迭代不断总结,而不是只顾前行。另外,更要懂得配合协作,才能不断挑战更强大的目标。

注意6

团队研发负责人职责:带领团队成功。业务类需求一定是产品经理统筹规划,出产品方案的;技改类需求一定是团队系统负责人整理考虑的,如此分工才能避免不必要的推诿,若是无产品经理,也寻求个产品助理来支援。任何人都可以质疑和挑战产品和设计方案,避免产品过度设计或过度复杂交互。并且团队负责人对产品的规模/工时是有绝对的话语权的,以及研发资源的分配权;若业务方先定了时间节点,则必须在可能造成风险延期和简化需求之间做选择,选择后者,若选择前者需告之其风险,并寻求更多资源支持。而整个周期的排期是由团队一起决定的,并由团队一起承诺完成。绝不认同一个谁谁的业务方就随意拍个需求过来,再由一个外部专家指指点点,团队负责人是最了解团队能力的人。(面对整个问题,实事求是,解释团队能力边界/团队极限,以及资源太少时间太紧等实现问题,还有产品设计过于复杂设计等)

注意7

当遇到问题(除消极怠工等类似问题)造成上线延期,只需要合理解释原因,并承担相应责任即可。也正因为责任,每个人(研发、测试、产品、运营和业务方)都要为此做好充分的准备和足够的努力。但是,需求永远是变化的,上线前一天都可能再改需求,所以延期往往是避免不了的。敏捷团队拥抱变化, 需求的变化,设计的变化,也接受延期的变化,敏捷从来都是小步快跑,即时反馈进行调整。但绝对不能以此为借口。

“一个公司有了产品经理就不需要项目经理了,只需要配置一个懂技术的技术统筹就可以了,如果一个公司有了项目经理,就不需要产品经理,只需要一个懂产品的产品助理设计产品就够了,要是一个公司同时有产品经理和项目经理,这两个人就是笨蛋。”

有一句话讲的很精辟:

产品经理 —— 靠想。产品经理是做正确的事,其所领导的产品是否符合市场的需求,是否能给公司带来利润的。

项目经理 —— 靠做。项目经理是把事情做正确,把事情做到完美,在时间,成本和资源约束的条件下完成目标。

注意8

产品经理做正确的事,如果事是错的,那团队即使在努力,最终结果也是错误的,做得越多错的越多。那什么是正确的事?一件事错了,有人唱反调,那一定是这个事没有照顾到某些人的利益,什么KPI,什么ROI,最关键的是否达到了每个人的心里预期。否则,坑了自己,也坑了队友。“得道者多助,失道者寡助。”

注意9

业务满足市场变化提出需求,从来没有错!产品通过调研需求内容,评估需求优先级,出产品规划、产品方案、产品排期等,以及过程中问题沟通和风险把控,这都是产品需要做的,满足不了业务需求,也绝不是业务的问题,一定是产品设计的问题!产品的能力就是把需求简单化。所以一个小需求,为什么要搞得那么复杂。

说明1

业务方代表需求,产品经理代表产品,团队负责人代表团队,立项锁定研发资源。

说明2

比产品更了解业务,你无需指导产品,但不能被牵着鼻子走。


二 如何制定合理排期

使用 ScrumBan 模式,可以根据 Cycle 时间和 Story Point 差值的统计数据,计算出团队评估一个故事需求规模(人日)所对应需要的工作日

注意1

按工作日评估时间节点,不要按人日评估;研发排期,工作日 = (人日 / 人) * (1 + 1/3)

注意2

制订方案需考虑多种场景:临时方案、折中方案、完美方案,并从工时、改造内容、风险性、稳定性、兼容性等多角度考虑

注意3

一个重要时间节点的上线,需要制订详细的计划,包括‘准备’‘上线’‘验证’等不同阶段需要做的工作项和详细时间点,以及每个阶段内工作项的应急备案


三 重视评审结果

所有会议纪要、评审记录和讨论结果,必须邮件群组,且cc关键人


四 严控上线质量

注意1

上线前按要求收集上线内容,确认后邮件发CheckList

注意2

线上问题第一时间通知上级,尽快定位问题原因,弄清的最好办法就是你自己能复述一遍 ,确认后邮件发送事故报告

注意3

明确值班责任(可用率报警等于系统功能出现不可用,性能报警等于功能使用影响用户体验),第一时间处理

注意4

如果是很严重的问题,1个小时内还未有结果,应立即升级,2小时内仍未未有结果,应根据严重等级,立即上报领导


五 积极向上级汇报

对上汇报:自信,及时,如实,准确。

注意1

解决方案给上级做选择题

注意2

正式重要汇报用正式会议室

注意3

重要内容汇报一定使用投影仪或大电视,并打印重要资料


六 横向沟通

横向沟通,找对关键人

注意1

参加其他团队的早会和演示会议,可以了解更多情况。(让团队有关联的小伙伴旁听其他组的早会、计划会议等)

注意2

绝不在人背后说事,更不在人背后对其指指点点。如果这事跟他有关,就需要一起沟通,不在人背后搞动作;在问题上,可以是这个事他做的有问题,但不能说找个人有问题

注意3

讨论沟通,应说你建议什么,不说你不建议什么

注意4

做事给留面子,相互尊重。(竞争对手往往是最值得尊重的人)

注意5

你的事你做,我的事我做,不越权,不抢功。(亲兄弟,明算账)

注意6

做事要顺势而为,不适应环境的人只会被淘汰。

注意7

祸从口出,韬光养晦(不要锋芒毕露,不要让别人看透你)


七 团队护犊子

我可以训我的人,你不行。

注意1

该我的责任,我认,不该的,不认。该说清楚的一定说清楚。需要背黑锅的,提前说清楚。


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/张松然)