학습 패턴/문제가 발생하면 사람들에게 알리세요

This page is a translated version of the page Learning patterns/When things go wrong, just tell people and the translation is 100% complete.
문제가 발생하면 사람들에게 알리세요.
문제모든 것이 끔찍하게 잘못되었습니다! 공황! 아무에게도 말하지 마십시오. 그러면 문제가 사라질 수 있습니다!
해결 방법사람들에게 말하십시오. 그들은 당신을 구제할 수 있습니다.
생성자Isarra
지지
생성00:32, 26 January 2019 (UTC)
상태:DRAFT

이것은 어떤 문제를 해결합니까?

프로젝트가 크게 잘못되었나요? 예정보다 몇 개월 늦었나요? 모든 것이 불타고 있습니까? 당신의 개발자가 버스에 치였습니까?[1] 당신은 완전히 불가능한 것으로 판명된 해결책을 약속했고, 지금 다른 것을 생각해내기 위해 허둥지둥하고 있습니까? 당신은 확실히 이 모든 것을 "인정"할 수 없습니다. 이제 할 수 있습니까? 그것은 당신이 두려워하는 만큼 당신을 무능하게 보이게 할 뿐입니다!

해결책은 무엇입니까?

당신은 무능하지 않습니다.[2] 이것은 모든 사람에게 때때로 발생합니다.[3] 그냥 사람들에게 말하면 우리가 해결할 수 있습니다. 근본적인 문제를 해결하려면 리소스가 필요하고 리소스가 존재하므로 더 빨리 문제에 도달하고 문제를 처리할수록 이러한 리소스가 더 많이 사용됩니다.

고려해야 할 사항

  • 다섯 번 연속으로 발생해서는 안 됩니다. 이것이 연속으로 다섯 번째 발생하는 경우 누군가에게 이에 대해 알리고 일반적으로 전체 관리 문제에 대한 도움을 받을 수 있는지 확인하십시오. 즉, 이 시점에서 다른 사람이 그 부분을 하도록 하는 것입니다.[4]
  • 당신의 리드 개발자가 정말로 죽었고 그들이 처음부터 당신의 코드베이스를 이해한 유일한 사람이라면 문제가 있을 수 있습니다. 그러나 해결 방법도 있습니다. 예를 들어 코드베이스가 완전히 끔찍하지 않은 경우 다른 개발자는 약간의 추가 시간이 주어지면 너무 많은 문제 없이 알아낼 수 있습니다. 그리고 그것이 끔찍하다면 실제로 그런 종류의 일을 전문으로하는 정말 미친 개발자도 있습니다.
  • 실제로 위키에 불이 붙으면 사람들이 알아차릴 것이고, 직접 신고하고 고치려고 노력하면 훨씬 보기 좋아집니다. 그러니 가서 하세요. 지금.
  • 문제가 특정인인 것 같으면 해고를 고려할 수 있습니다. 그러나 먼저 문제가 실제로 무엇이든 찾을 수 있는지 확인하십시오. 그들에게도 가서 이야기해 보세요. 양방향으로 작동합니다.
  • 감옥에 갇히거나, 입원할 위험이 있거나, 그 사실을 말함으로써 자신이나 다른 사람을 실제 위험에 빠뜨릴 수 있다고 예상되는 경우에는 반드시 적용되는 것은 아닙니다. 그런 경우에는 단순히 모든 것을 포기하고, 이름을 바꾸고, 국가를 탈출하고, 일어난 모든 증거를 제거하는 것을 고려하십시오. 특정 프로젝트에는 자신의 죽음을 속이는 방법에 대한 유용한 조언이 있을 수도 있습니다.

사용 시기

모든 것이 끔찍하게 잘못되었을 때:

  • 6년 동안 적절한 백업 설정을 미루고 하드 드라이브에 장애가 발생하여 전체 데이터베이스를 잃었습니다. 다행스럽게도 우리가 소문을 듣고 난 후, 임의의 사용자가 몇 달 전에 서버에 침입하여 일부 로컬 백업을 복사한 것으로 밝혀졌습니다. -- 사이트를 유지하는 바보 2018년 3월 8일 22:30(UTC)
  • 계단에서 머리를 부딪혀 전체 프로젝트가 두 달 동안 지연되었습니다. 저는 제가 충분히 나아졌을 때 사람들에게 그런 일이 있었고 두 달 동안 아무것도 하지 않은 이유를 말했고 그들은 마치 "아, 멋지네요. 계속하세요."라고 말했습니다. 그리고 휴가를 다녀왔습니다.[5] --개발자 (무시된 풀 요청) 2019년 1월 26일 00:55(UTC)

추천

  • I wrote it. I'm not sure I should be admitting this, but it's a whole pattern about admitting to things, so here I am. -— Isarra 21:25, 28 January 2019 (UTC)[reply]
  • This is something which helped with the "shared variables" part of the AbuseFilter overhaul project. In general, I think it's vital to always admit it if something goes wrong. Failing to do so will usually lead to problems much migger than the original one. --Daimona Eaytoy (talk) 16:34, 25 March 2021 (UTC)[reply]
  • I am the project manager and lead developer of the Web2Cit project. During the first half of the project I was also finishing my PhD thesis, and it soon became apparent that it was taking me longer than expected. This was a source of frustration and stress, because I could no longer postpone writing my thesis, but at the same time I felt terrible that the development branch of the project was starting to fall behind. Finally, we did what we should have done from the beginning, which was telling the grant officer about the situation and asking for a two-month extension of the midpoint report due date. The request was kindly accepted and it was such a relief after that! I could write my thesis with much less pressure, and we met the midterm report goals on time with the new due date. Diegodlh (talk) 10:52, 28 March 2022 (UTC)[reply]

같이 보기

관련 패턴

반대의 문제가 있고 아무 문제가 없는 경우에도 다음과 같이 도움을 드릴 수 있습니다.

외부 링크

각주

  1. 의도적으로요? 여러번? 당신의 다른 개발자가?
  2. 아마도.
  3. 팀 스털링을 제외하고
  4. 여전히 잘못되더라도 적어도 그 시점에서는 귀하의 잘못이 아니기 때문에 유용합니다. 그것은 그들의 것이다. 그들은 이제 관리인이기 때문에 책임을 집니다.
  5. 이것은 실제로 일어났습니다. 이제 보고서와 모든 것이 있기 때문에 문제가 없는 것으로 판명되었습니다.