今天聊聊“斯巴达”这个事儿，不是说那个古希腊城邦，是我自己实践中的一点体会。
大概是前年，我手上负责一个项目，一开始摊子铺得老大，大家想法很多，你加个功能，他要个优化，需求列表拉出来能吓死人。项目进度嘛自然是一拖再拖，眼看就要黄了。
那时候真是头大，每天开会就是扯皮，代码改来改去，净做无用功。我寻思这样下去不行，得下猛药。突然就想到了“斯巴达”那套，虽然咱不能真搞体罚啥的，但那种极简、残酷、只求生存和胜利的精神，我觉得可以借鉴一下。
我的“斯巴达”实践
于是我决定对这个项目来一次“斯巴达式”的改造。怎么搞？
- 第一步，砍需求。 我开了个会，态度很强硬，直接把需求列表从头到尾捋了一遍。凡是不是核心功能、不是没它就活不下去的需求，全部砍掉。不管是谁提的，不管之前讨论得多热闹，一刀切。当时很多人不理解，觉得可惜，但我坚持住了，告诉他们：“先活下来，再谈别的。”
- 第二步，定死规矩。 重新定了非常严格的开发流程和时间节点。每天早上站会，不超过15分钟，只说三件事：昨天干了今天打算干遇到啥问题需要谁帮忙。谁要是跑题、超时，我直接打断。沟通尽量用最直接的方式，少点没用的客套和废话。代码提交、测试，都定了硬指标，完不成就有“惩罚”——当然不是体罚，可能是周末需要自己加班补上，或者在团队内部做检讨。
- 第三步，聚焦核心。 整个团队的目标只有一个：在规定时间内，把最核心的功能做出来，能跑通就行。界面丑？不管。性能不是最优？先放放。有些边界情况没处理？只要主体流程没问题，暂时忽略。那段时间，整个团队的氛围就是高度紧张，目标极其单一。
- 第四步，资源倾斜。 把所有能调动的人员、设备资源，全部压到这个核心目标的实现上。其他所有旁枝末节的事情，要么暂停，要么找其他人先顶着。就是要确保这个“斯巴达冲锋”不受干扰。
刚开始推行的时候，阻力不小。有人抱怨太死板，有人觉得不人性化。我也知道这样搞大家肯定不舒服，但没办法，项目要活命，只能硬着头皮上。我那段时间也挺累的，不仅要顶住压力，还要不断给大家打气，强调我们这是在“求生”。
过程确实挺“残酷”的，有点像电影里演的，为了最终目标，牺牲掉了很多舒适和“人性化”的东西。我们把所有精力都集中在刀刃上，其他的一概不理。
结果怎么样？
项目最终是按时交付了核心功能。虽然上线版本看起来很“简陋”，甚至有点“丑”，但它能用，解决了最关键的问题。后续我们才慢慢地在这个基础上，逐步把之前砍掉的一些重要功能和优化给加回来。
这回经历让我体会挺深的。有时候，面对复杂混乱的局面，采取这种看似极端、甚至有点“不近人情”的“斯巴达”方式，聚焦核心，强制简化，反而是最有效的解决之道。这种方法不能常用，毕竟团队氛围和成员感受也很重要，但作为特殊时期的特殊手段，确实管用。就像斯巴达人为了生存和战斗力，牺牲了很多东西一样，咱们在项目中，有时候也得为了保住核心目标，做出一些“残酷”的取舍。
还没有评论，来说两句吧...