大家好?
我目前作为SES工程师驻扎在一个客户的现场，正在参与某个项目，但是这个项目得到了好评。火焰开始真正燃烧已经过去了大约五个月。嗯，这一次，我想从我自己的角度去思考起火的原因，并把它作为我未来的自己的资产。
顺便说一句，作为前提，我对参加这个火爆的项目没有消极的想法，现在我有自己的时间和体力，所以我很享受它作为一种体验。尤其是deadline的前一天，当我满负荷工作的时候，就像“我赶不上，但我必须尽我所能”那样，我喜欢那种头脑逐渐清醒的感觉向上。嗯，我认为这是因为处于 BP 的位置很容易。
让我们进入正题。
项目概况
- 金融公司客户管理网页应用新开发
- 最终交货日期是今年11月左右。但是，到那时有一个月的交货日期。例如，如果整个应用有 100 个屏幕，如果我们现在开始开发，我们将在 10 月交付 50 个屏幕，到 11 月交付剩余的 50 个屏幕。
- 瀑布开发
商业流程图
我属于N公司，分包商。
很抱歉，因为是SES，所以无法知道项目全貌等信息。有可能B公司和C公司把工作岗位往下扔，而且由于是大型金融项目，看起来商业流程比图表要复杂。我以居民的身份来概括，但严格来说，这就像我被N公司解雇一样。但是，我工作的N公司，是根据总包商提供的设计文件，完成从开发到测试的所有工作，并交付产品，所以我的位置如图。
会员资格
-
PM：1人，PL：1人，Members：5到14人，我的职位是member
-
由于 PM 有多个项目，因此只有大约 30% 的时间可以用于这个项目。
-
在适当的成员中，只有 PM 了解此开发中使用的语言和 FW
不知何故，我有一个PM负责项目管理的形象，但是这个项目中的PM就像“它不在那里吗？”，而PL正在做各种事情，例如进度管理。
项目起火原因
我想写任何想到的东西，从外部问题到内部问题。但是，请注意，这不是抱怨或不满之类的，这只是对项目失火原因的纯粹分析。
让我们进入正题。
1、规范中有太多不明确的地方和矛盾之处
例如，每个规范的DB列名和数据类型存在差异，通常会移交带有注释“一经决定就描述”的规范。现场将当月交付产品的规格交给会员并进行了开发，但在开发前所交的规格存在不明确的点和矛盾，现阶段我们会落后由 PL 设定的时间表。
2. 对规范中的不清楚点反应太慢
我们以QA表的形式向主承包商A公司询问关于1中提到的规格的不清楚点，但大约需要2-3周的时间才能回复，因此我们的政策是澄清不清楚的点。应该通过“从所有规范中可以想到的最合理的方法”临时实施。但是，由于是临时实现，感觉内容是空的，只有参数和返回值一致，所以毕竟要在原承包商回复后进行实际实现。
这可能是理所当然的，但由于QA规范在数量上还没有固定下来，所以实现端也会一边开发一边感觉“这个实现好不好？”不香。
这是不可避免的，因为如果你不做临时实施，你将无法继续进行可以实施的部分的工作。我觉得我在浪费
3. 度赞麦
规格的 QA 收据是在交货日期前一到两周的完美时间，因此将根据产品实施，根据产品，它将是“我在交期结束，我会在下一个开发期处理。”应该是卸载交付。
这样做的问题是系统不一致，所以在交付前的测试过程中会出现很多问题。作为我们的使命，如果我们要交付20个屏幕，在交付前需要对每个屏幕进行单元测试，以及集成测试，看看这20个屏幕的过渡是否可以正确执行。因此，许多连接测试部分出现问题。如果有很多错误，就会有很多修复。即使它应该已经修复，它也充满了度数。因为我们没有一致的规范。
4. 我在规范确定之前创建了测试规范。
我们根据规范创建了测试规范，但正如我到目前为止所写的那样，尽管很难说规范是固定的，但我们最终还是创建了测试规范。我认为这也可能是一个问题。现实中，规范的修改和开发是同时进行的，我认为火起来的原因之一是增加了一些不必要的任务，比如在测试阶段修改测试规范，也就是在交货期限。
你可能会问，“为什么我们不在规范完成后创建测试规范？” 就此而言，我认为“创建测试规范→开发→测试”是合适的，但是我们的开发团队基本上存在人员短缺的问题，等完成测试规范的准备后，我们再参与开发。”所以，无论如何，还是要尽快准备好测试规范，参与开发。最重要的是，“规范不固定”的问题重叠了，一旦测试规范创建者自己去开发，他们就无法根据 QA 的答案来纠正测试规范。不幸的是，我在在交货期间的测试过程中要抓紧时间。
5.即使屏幕没有完成，我也开始测试
由于进度延迟，有时会出现“我们正在开发屏幕，但我们必须开始测试由于截止日期而已经实现的功能。”我正在逐个测试。但是，正如我写的《度数赞麦》，当屏幕实现完成后进行剩余测试项时，出现NG，由于修正的影响，开发时OK的测试项将被重新测试. 我最终不得不重做所有事情，因为我需要它。
当我工作的时候，我想，“没错”，但我想知道 PL 是否处于恐慌状态，也许是因为临近截止日期的压力。
6. 很少有成员匹配项目的技术栈
就像开发团队中的一些成员在他们的技术堆栈中拥有该项目中使用的技术。另外，在合适的成员中，匹配技术栈的PM只有那些处于“我不知道该怎么做”状态的PM，所以匹配技术栈的BP也很少。所以，只有那些人一个月去另一个项目，开发团队来来往往，在保障人员方面已经被毁了。
当然，实施往往会陷入困境，进度往往会延迟。但是，他们没有等到交货期，加人也不容易，我只好加班，下班补上，整个团队都失去了活力。
我认为这是一个困难的部分，因为似乎涉及到预算等各种事情，但如果这不顺利，很有可能命运会很艰难，开发成员将直接遭受损失。我想让你做点什么。不像我们无法控制的部分，比如主承包商抛出的低质量规格，我们可以控制部分，所以我认为我们应该好好准备。
除非开发跨度很长，并且有一个环境可以让技术堆栈不匹配的成员赶上所使用的技术。
7. 追赶增员的文件不维护
正如我之前写的，这是一个成员在一个月后离开的项目，并且成员更换很多，所以成员被补充是很常见的。但是，没有用于构建增加成员的环境的文档，也没有用于理解系统概述的文档，或者任何提供增加成员工作所需的信息的文件，所以我们将开始实际工作。很长时间才能完成，其他开发成员不得不停止工作，以赶上关于增加成员数量的信息。
既然没有人，如果我们试图增加人数，工作效率就会下降……已经是恶性循环了。如果这是距离交货日期还有几个月的阶段，工作效率会暂时下降，但在那之后，我认为它会急剧增加，但在这个项目中，从一个交货到下一个交货的时间是一月，效果我感觉不到。
但是，项目火了之后，我没有时间准备这样的文件，所以我想我应该在项目启动时好好准备。我认为如果您依赖 BP 或外部人员进行开发，情况更是如此。
8. 无用的进度报告会议
在这个项目中，我们每天早上 9:30 到 10:30 开始工作前都有一个进度报告，但是当“我不能按时完成”的问题成为现实时，现在 13 次进度报告会议即将到来:00 和 13:30。由于午休时间是12:00到13:00，所以这次进度汇报会其实是12:00一个半小时，上午进度汇报会10:30结束，中午12点开始午休： 00.即使我做了，也是两个半小时工作的进度报告会。
这是一场毫无意义的会议，用这样的话来形容很可笑，但从“我来不及”的现实中，PL惊慌失措，“我怎么能赶得上？我认为它增加了不必要的工作。
既然有聊天工具，我觉得工作完成的时候可以通过聊天来汇报工作，遇到阻塞可以通过聊天分享情况。我认为有必要“在没有达到最后期限的情况下找到妥协”，但我认为没有必要让所有成员停止工作几个小时的进度会议。
另外，等到“我赶不上截止日期”的问题成为现实时，即使我详细了解成员们的进度，我也不认为有什么可以赶上截止日期的。在看到火花的那一刻，我想如果我不采取措施就为时已晚。就像真正的火一样，一旦开始燃烧，就会以难以置信的速度蔓延开来，所以我觉得有必要有很多抽屉，比如“如果发生这种情况，就会发生这种情况”。
9. PL没有人评论
上一句我写了“PL处于恐慌状态”，但是没有人能说“这不是错了吗？”我觉得这是一个我做不到的问题。
常驻公司好像是传统的日系合同开发公司，资历感很强，就连正人君子也不能对他们的前辈PL说什么。即使在适当的当事方之间，我们也处于这样一种状态，以至于我们 BP 什么也说不出来。
嗯，这个问题，也就是说，成员们在感受到PL的压力的同时感觉他们正在工作，所以他们想说的话很难说出来的气氛完全完成了。
让我印象深刻的一件事是，其中一位成员报告说，“我对XX的实施感到困惑，我正在研究实施方法。”，作为回应，有这样的对话“我认为它会在一天结束时完成'你不知道，'我在想。
就个人而言，这里对PL的反应是“如果你调查了大约XX分钟后不知道如何实施，请报告。我会问在公司做其他项目的成员。”我想知道它是否正确。如果我可以通过研究找到它就可以了，但我认为最好假设最坏的情况并给出如何处理它的政策。
嗯，我认为最好的事情是营造一种氛围，可以说“我没有如何实施它的计划，所以说实话，我不知道它什么时候完成。”但是，如果 PL 没有抽屉，就无法对“我不知道什么时候结束”的答案给出计划，所以我们将经历一场地狱般的时间会议，彼此将安静。顺便说一句，我自己也经历过。
另外，我认为这是这个项目独有的问题，但这是一种情况，PM就像“有PM吗？”我想。我想我在关键点上咨询了 PM，但项目的规模让我无法独自做任何事情......
在最后
写了好久，个人觉得
- 不要迷失自我
- 冷静想想现在该做什么
- 在发生或可能发生问题时做出响应的能力比创建 WBS 的能力更重要
首先，不要因为眼前的最后期限而匆忙忘记自己。如果项目负责人变得不耐烦或沮丧，气氛就会蔓延到整个团队。扰乱团队气氛的领导者是最糟糕的。在我之前参与的一个项目中，有一个人在进度会上编组成员，但是这种气氛蔓延到整个团队，降低了团队的士气。就算不忘掉自己，本来性格那么差就完蛋了，不过我觉得有些人平时很善良，但走投无路时往往会重拳出击，所以在任何情况下都不要忘记自己.我觉得很重要。
接下来，冷静地思考现在该做什么。为了“消除浪费而不增加浪费”，我认为始终具有冷静选择事物的能力很重要。
最后，当问题发生时，获得在可能发生时做出反应的能力。随着经验的积累，我想我会画得更多，但是网上的信息来源很多，比如管理方面的书籍，燃烧案件的回忆录，所以我认为如果你想学习，你会掌握一定的知识。。
我认为，如果以上三点一致，你所要做的就是展示你的力量。鸟瞰的能力，营造团队氛围等。管理人员意味着与 10 个不同的人打交道，我认为没有银弹说“我应该这样做”，例如如何与每个人打交道以及如何分配任务。因为。嗯，我认为这是管理工作有趣的部分开始的地方。
------- 切里森 --------
在我的通勤时间里，我会想很多事情，比如“团队目前的状态是什么？
自从我参加燃烧项目以来，已经过去几个月了。站在难得的强者角度，可以说我还有很长的路要走，但最近一直加班到23:00左右，每周工作6天，休息1天，所以我'我开始认为是时候过上正常的生活了。确实。
有过以“我从死亡行军中幸存下来，所以我现在在这里”为主题而取消活动的案例。不过，我个人认为，相比其他工程师的正常工作，我可以从 Desma 身上学到的东西不多，而且考虑到我没有时间进行私人或自我提升，这是相当不利的，所以如果你遇到这样的我认为最好尽快逃跑。把你的生命花在一个永无止境的项目上真是浪费时间。
我写这篇文章是因为我想从这个糟糕的燃烧项目中创造至少一个积极的体验，所以我不会让自己和我周围的工程师再次有同样的感觉。我想我会离开它作为一个教训。我不认为日本 IT 行业的性质会改变，项目往往会火上浇油。
唉，我能在这种情况下幸存下来吗？
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308626332.html