วิธีที่มีประสิทธิผลที่สุดในการจัดการกับความล้มเหลวที่เกี่ยวข้องกับการพัฒนาคืออะไร? [ปิด]


49

เราเคยไปที่นั่น:

  • โครงการของคุณล้มเหลวหรือถูกยกเลิก
  • รหัสที่คุณใช้เวลาทำงานหลายวันถูกทีมของคุณถูกปฏิเสธ
  • รูปแบบการออกแบบที่คุณแนะนำให้กับทีมสร้างความโกลาหล
  • ทุกคนไม่สนใจความคิดของคุณ

คำถามของฉันคืออะไรเป็นวิธีที่มีประสิทธิผลมากที่สุดสำหรับโปรแกรมเมอร์ในการจัดการกับความล้มเหลวที่เกี่ยวข้องกับการพัฒนาเช่นนี้?


ในฐานะที่เป็นส่วนหนึ่งของที่กำลังริเริ่ม Cleanup Tag โครงสร้างคำถามนี้จะถูกกล่าวถึงในเว็บไซต์เมตาการสนทนาของเรา

คำตอบ:


79

โครงการของคุณล้มเหลว

การพัฒนาซอฟต์แวร์มีแนวโน้มสูงที่จะเกิดความล้มเหลวของโครงการและขึ้นอยู่กับความรุนแรงการจัดการที่ดีที่สุดนี้ได้รับการจัดการ

หลายโครงการล้มเหลวและอื่น ๆ อีกมากมายจะล้มเหลวดังนั้นจดบันทึก! เรียนรู้ว่าเหตุใดโครงการของคุณจึงล้มเหลวดังนั้นคุณจึงไม่ทำผิดพลาดครั้งต่อไป คุณเรียนรู้มากขึ้นจากความล้มเหลวของคุณมากกว่าจากความสำเร็จของคุณ

สิ่งที่คุณใช้เวลาในการเขียนโค้ดวันนั้นถูกปฏิเสธโดยทีมของคุณ

บันทึกงานของคุณ (สำหรับภายหลัง) มีความเป็นไปได้สองประการ: (ก) มันแย่และความจริงที่คนหลายคนตอบสนองแบบเดียวกันคือสิ่งบ่งบอกถึงสิ่งนี้ (ข) มันเป็นอัจฉริยะอย่างแท้จริง แต่เหนือกว่าสิ่งที่ผู้คนคุ้นเคย คนทั่วไปไม่ชอบสิ่งที่พวกเขาไม่เข้าใจ อาจดีกว่าที่จะแสดงเมื่อถึงเวลาหรือในสถานที่ที่แตกต่างกับ "วัฒนธรรม" ที่แตกต่างกัน

ไม่มีใครฟังความคิดของคุณใน บริษัท ของคุณ

อาจเป็นความคิดที่ไม่ดีหรือวัฒนธรรมไม่สอดคล้องกับความคิดของคุณ ย้ายไปยังสถานที่ที่สนับสนุนวัฒนธรรมของคุณหรือประเมินความคิดของคุณอีกครั้ง (โดยไม่มีอคติของคุณเอง) -> ความคิดของฉันดีจริงหรือ <- ฆ่าอัตตาของคุณ

รูปแบบการออกแบบที่คุณแนะนำด้วยแรงในทีมของคุณสร้างความยุ่งเหยิง

บอกตามตรงว่าคุณพยายามอย่างเต็มที่ แต่ก็ไม่ได้เป็นไปตามที่วางแผนไว้ อาจเป็นการดีกว่าถ้าเริ่มใหม่อีกครั้งหรือเรียนรู้จากความผิดพลาดที่เกิดขึ้นในการออกแบบเป็นทีมและก้าวไปข้างหน้า


29

พวกเขาไม่ใช่ความล้มเหลว - เป็นประสบการณ์

คุณเรียนรู้และเติบโตจากประสบการณ์ของคุณโดยไตร่ตรองว่าพวกเขาทำให้คุณรู้สึกอย่างไรและถ้าคุณต้องการความรู้สึกนั้นมากขึ้น

หากเป็นประสบการณ์ที่ไม่ดี (เช่นรายการที่คุณเสนอ) ความรู้สึกที่ไม่ดีที่เกิดขึ้นอาจเป็นสิ่งที่คุณต้องการหลีกเลี่ยง (สมมติว่าคุณไม่ผิวคล้ำจนคุณไม่สนใจผลกระทบจากการกระทำของคุณ)

โดยรวมไม่ได้มีส่วนร่วมมากเกินไปในการเปรียบเทียบตัวเองกับคนอื่น ๆที่พวกเขากำลังมีปัญหาเพียงเท่าทำงานผ่านมันทั้งหมดที่คุณมี


1
เพียงแค่คำสองคำ: เสริมสร้างการเรียนรู้
Wok

-1: ทั้งประสบการณ์และความล้มเหลว
Thomas Eding

14
  • ใจเย็น ๆ อย่าตกใจมันจะไม่ทำให้อะไรดีขึ้น
  • การควบคุมความเสียหาย - บันทึกสิ่งที่สามารถบันทึกได้
  • เรียนรู้จากความผิดพลาดของคุณ - การทำสิ่งผิดพลาดอีกครั้งอาจจะไม่ได้ผล
  • พิจารณาการเริ่มต้นใหม่ - เริ่มต้นความพยายามครั้งต่อไปโดยไม่ต้องแบกเป้ผิดหวังและความรู้สึกผิด
  • ดูความล้มเหลวที่ใหญ่กว่า - เปรียบเทียบกับเที่ยวบินแรกของ Ariane 5ความล้มเหลวของคุณเล็กน้อย
  • ปรึกษานักจิตอายุรเวทถ้าคุณไม่สามารถจัดการมันคนเดียวได้

11

คุณสร้างบางสิ่งบางอย่าง

สำหรับฉัน (ฉันไม่คิดว่ามันเหมาะกับทุกคน) การสร้างบางสิ่ง (การ์ตูนภาพวาดเกมเล็ก ๆ น้อย ๆ อะไรก็ได้) ก็เหมือนกับการสร้างความมั่นใจเล็กน้อยเพื่อกลับไปสู่การต่อสู้ที่ล้มเหลว มันอาจเป็นวิธีที่ดีในการแสดงความโกรธหรือความขมขื่นหรือความรู้สึกใด ๆ ที่สัมพันธ์กับความล้มเหลว แต่เป็นวิธีที่ "สร้างสรรค์"

สำหรับฉันแล้วล่ะ


6

ดีคุณถาม :) หนึ่งโดยหนึ่ง:

* Your project failed.

นั่นเป็นเรื่องใหม่แทบจะไม่ เราทุกคนล้มเหลวโดยส่วนตัวและเราทุกคนล้มเหลวในมุมมองแบบเต็มของเพื่อนของเรา ทุกคนที่ผ่านการศึกษาระดับประถมและมัธยมมีประสบการณ์ในเรื่องนี้

หากฉันไม่สามารถทำผิดพลาดและคาดหวังการจ้างงานที่มั่นคงคุณควรพิจารณาส่งบันทึกถึง HR เพื่อให้พวกเขารู้ว่ามนุษย์จะถูกแบนจากการพิจารณาในอนาคต

ความล้มเหลวหลายอย่างในแถวหมายความว่าคุณมีความต้องการและข้อกำหนดที่ไม่สมเหตุสมผลหรือคุณไม่ได้เรียนรู้จากความผิดพลาดของคุณ สถานการณ์สมมติไม่ว่าจะเป็นการกระทำในทันที

เป็นไปได้ว่าหลาย ๆ คนเซ็นสัญญากับสิ่งที่เพิ่งได้รับการจ้างงานจากนั้นหาวิธีทำข้อกำหนดบางอย่างที่เกิดขึ้น

* What you have spent days coding was rejected by your team.

เกิดขึ้น. ดังที่คนอื่น ๆ ให้บันทึกไว้ ทำมันอีกครั้ง. นี่คือเหตุผลที่เราเรียกมันว่าทำงาน ฉันคิดว่าในกรณีนี้คุณอาจไม่ได้เกี่ยวข้องกับทีมมากนักในสิ่งที่คุณทำ

อาจเป็นไปได้ว่าข้อกำหนดนั้นเปลี่ยนไปเมื่อวานนี้หรือหนึ่งชั่วโมงก่อน นี่ควรเป็นข้อยกเว้นไม่ใช่บรรทัดฐานอย่างไรก็ตาม ความเห็นจากคนรอบข้างนั้นโหดร้ายเท่าที่จะเป็นประโยชน์ หากรหัสของคุณถูกไล่ออกอย่างต่อเนื่องว่า 'ไม่เพียงพอ' (หรืออะไรทำนองนั้น) คุณควรใช้เวลามากขึ้นในการเลือกสมองและเกี่ยวข้องกับผู้อื่น ฉันเชื่อว่าคำถามนี้เป็นความผิดพลาดในการตั้งค่าทีมส่วนใหญ่เว้นแต่ 'ทีม' จะเป็นทุกอย่างยกเว้นการอธิบายตนเอง

* Nobody listens to your ideas in your company.

อีกครั้งนี้ต้องการบริบท คุณเคยอยู่ที่นั่นนานแค่ไหน? เพื่อนแฮกเกอร์ของคุณไว้วางใจในความสามารถของคุณมากแค่ไหน? คุณเคยคิดหรือไม่ว่าความคิดที่ส่งผลให้มีงานมากขึ้นสำหรับหลาย ๆ คนอาจเชิญเหตุผลใด ๆ ให้เลิกทำ ฉันเคยมีบางสิ่งที่ถูกไล่ออกเพราะยังไม่พร้อม IPV6 แต่ใช้ซ็อกเก็ตโดเมนแบบง่ายบนอุปกรณ์ลูปแบ็ค (เฉพาะ) คนที่จมลงก็ไม่สามารถทำงานได้อีกต่อไป

นอกจากนี้คุณพูดได้ดีแค่ไหน? คุณสามารถเป็นเพื่อนและมีอิทธิพลต่อผู้คนได้หรือไม่?

* The design pattern you introduced with force in your team created a mess.

เหตุใดจึงควรหลีกเลี่ยงการใช้กำลัง ความสามารถในการพูดคุยไม่ใช่สิ่งที่จำเป็นสำหรับการฟัง ไม่มีความคิดเห็นอื่น


5

โอ้เจ้านั่นมากถ้าคุณหมายถึงทุกสิ่งที่เกิดขึ้นกับคุณจริงๆ!

คำเตือน : ในหลายประเด็นด้านล่างคุณอาจรู้สึกว่าฉันวิพากษ์วิจารณ์คุณและฉันต้องการให้คุณรับผิดชอบต่อความผิดพลาดและไม่พิจารณาปัจจัยภายนอก ฉันไม่. เป็นเพียงการที่คุณไม่ให้รายละเอียดมากนักและฉันเพียงแค่เตรียมรายการตรวจสอบการกระทำเพื่อรับรองว่าสิ่งต่าง ๆ ไม่ได้ผิดปกติ ฉันรู้ว่าฉันทำผิดพลาดมากมาย (ทุกคนทำ) และเราจะดีขึ้นถ้าเราเรียนรู้จากพวกเขา และเพื่อเรียนรู้จากพวกเขาเราต้องเริ่มเห็นพวกเขาเป็นความผิดพลาดตั้งแต่แรกและยอมรับความรับผิดชอบในสิ่งที่ผิดพลาดในส่วนของเรา นรกยอมรับความรับผิดชอบในสิ่งที่ผิดพลาดในส่วนของคนอื่นคุณสามารถเรียนรู้จากสิ่งนั้นได้เช่นกัน

โครงการของคุณล้มเหลว

ไม่มากที่คุณสามารถทำได้เพื่อลดผลกระทบในตอนนี้

อย่างไรก็ตามคุณสามารถทำได้หลายวิธีเพื่อหลีกเลี่ยงการทำซ้ำในอนาคต ฉันขอแนะนำให้พยายามพัฒนาโครงการและทักษะการบริหารเวลาของคุณ

หนึ่งในหนังสือที่มีอัตราส่วนที่ดีที่สุด ((คำแนะนำที่ถูกต้อง) / หน้า) ผมเคยอ่านเกี่ยวกับเรื่องนี้ในขณะที่อาจจะไม่ดีที่สุดก็ร็อบ Thomsett ของการบริหารจัดการโครงการหัวรุนแรง

คุณไม่ได้ระบุสิ่งที่โครงการของคุณล้มเหลว แต่ฉันคิดว่าการรวมกันของสิ่งต่าง ๆ ซึ่งทำให้เกิดความไม่สมดุลในรูปสามเหลี่ยมราคา / เวลา / qualiyปกติ ปัจจัยที่สำคัญที่สุดในสายตาของฉันคือการเป็นผู้นำโครงการและการพัฒนาในขณะที่ติดต่อกับนักแสดงด้านเทคนิคของคุณ (นักพัฒนาซอฟต์แวร์และผู้ทดสอบ) เสมอ โครงการมากเกินไปล้มเหลวเพราะพวกเขาไม่ฟังผู้สนับสนุนหรือผู้มีส่วนได้ส่วนเสียและไม่ผลักดันให้พวกเขามีส่วนร่วมในกระบวนการ

หากพวกเขาไม่เกี่ยวข้องคุณไม่สามารถรู้สิ่งที่พวกเขาต้องการ หากคุณไม่สามารถรู้ว่าสิ่งที่พวกเขาต้องการคุณไม่สามารถส่งมอบมัน หากคุณไม่ส่งมอบมันจะไม่มีความสุข นั่นคือความล้มเหลว นอกจากนี้หากคุณไม่เกี่ยวข้องกับผู้มีส่วนได้เสียพวกเขาจะถูกตัดการเชื่อมต่อจากความเป็นจริงของวิศวกรรมซอฟต์แวร์ซึ่งหมายความว่าพวกเขาไม่เข้าใจปัญหาของคุณ หากพวกเขาติดต่อกับคุณบ่อยครั้งพวกเขาจะเข้าใจสิ่งที่คุณต้องรับมือได้ดีขึ้น พวกเขาจะสามารถเข้าใจได้มากขึ้นเมื่อคุณบอกพวกเขาว่าคุณลักษณะ "เล็ก" [เสียงหัวเราะ] จะใช้เวลาเป็นเดือน พวกเขาสามารถไว้วางใจการวางแผนของคุณได้ดีขึ้นเพราะพวกเขาช่วยสร้างมัน โครงการไม่สามารถประสบความสำเร็จได้ด้วย "รายละเอียดที่จุดเริ่มต้นการพัฒนาการทดสอบการส่งมอบตอนท้าย" มันไม่เคยทำ คุณอาจส่งมอบสิ่งที่ถามในรายละเอียด

สิ่งที่สำคัญที่สุดก็คือทำเรื่องย้อนหลังและทำให้แน่ใจว่าเกมนี้ไม่มีอัตตาและไม่ใช่เกมโทษ เพียงระบุปัญหา

สิ่งที่คุณใช้เวลาเป็นวันทำการโดยทีมงานของคุณถูกปฏิเสธ

ฉันอยู่ในสถานการณ์นั้น อีกครั้งคุณไม่สามารถทำได้เพื่อลดขนาดนั้นยกเว้น:

  • เก็บไว้ใน SCM ภายหลัง
  • อาจพยายามดันบิตขนาดเล็กและชิ้นเข้าไปในฐานรหัสหลักแทนการเปลี่ยนขนาดใหญ่

แต่มีอีกหลายสิ่งที่คุณสามารถทำได้เพื่อป้องกันสถานการณ์เช่นนี้:

  • ทำไมมันเกิดขึ้น อะไรคือสาเหตุของการถูกปฏิเสธ?
  • ส่วนใหญ่เวลาที่ฉันเห็นสิ่งนี้เกิดขึ้น (และนั่นก็เป็นกรณีของฉันด้วยเช่นกัน) นั่นหมายถึงนักพัฒนาไปคนเดียวหรือในโหมดการเข้ารหัสโคบอย - บอยและสร้างสิ่งที่ไม่เคยถาม รหัสที่ไม่ได้มาจากความต้องการทางธุรกิจอาจเป็นเรื่องแฟนซีและ "ดีกว่า" แต่มักจะเสียเวลาและเงิน นอกจากนี้ยังมีค่าใช้จ่ายมากขึ้นหากคุณรวมเข้ากับมันเพราะมันจะต้องมีการทดสอบอีกครั้ง คิดเหมือนคนที่จัดการเงินให้คุณ: คุณต้องมีประสิทธิภาพในระดับนั้นเช่นกัน
  • คุณภาพของซอฟต์แวร์ที่ผลิตนั้นเป็นที่น่าพอใจหรือไม่? มันเป็นไปตามมาตรฐานและอนุสัญญาในกิจกรรมที่ บริษัท ของคุณ?
  • คุณรายงานเป็นระยะ ๆ (และบ่อยครั้ง!) ถึงผู้จัดการโดยตรงเกี่ยวกับเรื่องนี้หรือไม่? คุณแลกเปลี่ยนกับผู้พัฒนาคนอื่น ๆ ของทีมเป็นครั้งคราวหรือไม่? ถ้าไม่พวกเขาไม่รู้อะไรเลยมันจะมีค่าใช้จ่ายมากสำหรับพวกเขาในการประเมินและตรวจสอบตอนนี้ มันไม่ได้บัญชีในเวลาเดียวกันในที่สุด มันเหมือนพยายามทำความสะอาดอพาร์ทเมนต์ให้เช่าของคุณเสมอและพยายามทำความสะอาดเมื่อคุณย้ายออก: มันเป็นงานที่ยุ่งเหยิงเหนื่อยมากมันยากกว่าที่เคยทำมาเป็นประจำและบ่อยครั้งจะไม่ทำ ขวา.
  • คุณผลิตการทดสอบผลิตผลหรือไม่ ทดสอบหน่วย? การทดสอบบูรณาการ?
  • มีการตรวจสอบรหัสของคุณใน SCM เป็นประจำหรือไม่ มันแตกต่างจากสาขาอื่นหรือไม่? มันต้องการกิ่งที่แตกต่างกันหรือว่าจะทำในลำตัว? การปิดรหัสยืนยันมักเป็นสัญญาณที่ไม่ดี เห็นได้ชัดว่าบางครั้งคุณถูกล่อลวงให้ทำ แต่คุณเพียงแค่ยิงตัวคุณเอง

ไม่มีใครฟังความคิดของคุณใน บริษัท ของคุณ

ทีนี้มีตัวเลือก 2 ตัวที่นี่และเราจะดูทั้งสองอย่าง:

  • คุณมีไอเดียไม่ดี
  • คุณมีความคิดที่ดี

เรามาเริ่มสมมติว่าพวกมันแย่ (อีกครั้งการไตร่ตรองตนเองและยอมรับความคิดของคุณก็แค่เลวร้าย ๆ อาจเป็นเรื่องยากฉันรู้) คุณจะเปลี่ยนอะไร

  • ทำไมคุณถึงคิดด้วย? อะไรคือเหตุผล ? มีความจำเป็นจริง ๆ ไหมที่ความคิดของคุณพยายามนำไปที่โต๊ะ?
  • คุณคิดอย่างไร? คุณทำด้วยตัวเอง? คุณแบ่งปันหรือไม่ ระดมความคิด? วางแผน? ต้นแบบ? (ทำสิ่งเหล่านี้ตามลำดับที่ถูกต้องหากล้มเหลวระหว่างทางให้ละทิ้งความคิดอย่าไปต่อหรืออย่างน้อยก็ไม่ได้อยู่ในตารางงานของคุณ)

ความคิดเป็นเพียงความคิด หากคุณเพียงแค่แนะนำให้พวกเขาเป็นแนวคิดและพวกเขาถูกปฏิเสธฉันไม่เห็นว่าทำไมคุณถึงรู้สึกไม่ดีเกี่ยวกับมัน หากคุณทำตามพวกเขาโดยไม่ต้องแจ้งใครแล้วส่งความคิดของคุณและพวกเขาก็ถูกปฏิเสธแน่นอนว่าฉันรู้สึกหงุดหงิดในเวลาที่เสียไป และผู้จัดการของคุณทำเพื่อ!

สมมติว่าความคิดของคุณเป็นสิ่งที่ดี:

  • การนำเสนอของคุณดีไหม
  • คุณมีวิธีการนำเสนอที่ดีหรือไม่? (ฉันเป็นนักพัฒนาฉันรู้ว่าสิ่งที่ผมพูดเกี่ยวกับ: เราไม่พอใจหยิ่ง , อวดความรู้ Pitas ที่อยู่เสมอขวาและกับใครมันเป็นเรื่องยากที่จะทำงานร่วมกับเพราะบ่อยของอัตตาสัดส่วนของเรา )
  • คุณมีแผนที่จะใช้มันหรือไม่? คุณคิดเกี่ยวกับค่าใช้จ่ายและเวลาหรือไม่? คุณคิดว่ามันมีประโยชน์ต่อผู้ใช้ / ลูกค้าอย่างไร? คุณคิดว่ามันส่งผลกระทบต่อยอดขายหรือไม่ คุณคิดว่าการทำงานกับความคิดนั้นอาจส่งผลกระทบต่อโครงการและลำดับความสำคัญอื่น ๆ ได้อย่างไร คุณจะบอกฉันว่า "ทำไมฉันต้องทำสิ่งเหล่านี้พวกเขาเป็นหน้าที่ของผู้จัดการของฉันและทีมการตลาดหรือการขาย!" ยกเว้นตอนนี้คุณกำลังพยายามทำส่วนหนึ่งของงานทั้งหมดของพวกเขา

รูปแบบการออกแบบที่คุณแนะนำด้วยแรงในทีมของคุณสร้างความวุ่นวาย

  • ทำไมคุณถึงแนะนำรูปแบบ?
  • หากมันสร้างความยุ่งเหยิงก็อาจเป็นได้ทั้ง:
    • ไม่ใช่รูปแบบที่ถูกต้อง
    • ไม่ถูกต้อง
    • ไม่ถูกต้อง
  • คุณแนะนำอย่างไร คุณกำหนดสถานะ "ระเบียบ" ได้อย่างไร?
    • อ่านน้อยรหัส?
    • บำรุงรักษาน้อยลงหรือไม่
    • งานสร้างเสียหายหรือไม่
    • มี "ระเบียบ" ที่แตกต่างกัน การรู้ว่าสิ่งที่ยุ่งเหยิงคืออะไรอาจช่วยให้รู้ว่าความล้มเหลวในนั้นคืออะไรและถ้าเป็นความผิดของรูปแบบการออกแบบ

นอกจากนี้ฉันรู้สึกประหลาดใจเล็กน้อยจากแนวทางนี้ คุณต้องผลักดันรูปแบบการออกแบบจริง ๆหรือไม่ ดูเหมือนจะค่อนข้างแปลก รูปแบบอาจมีอยู่แล้วหรือคุณจำเป็นต้องปรับโครงสร้างส่วนหนึ่งของโซลูชันตามรูปแบบ คุณไม่ต้องผลักดันมันเหมือนกับว่าคุณจะต้องใช้เฟรมเวิร์กหรือเทคโนโลยี (เช่นผู้ที่ผลักอย่างหนักเพื่อให้มี XML อยู่ทุกหนทุกแห่งและตอนนี้ผู้คนเริ่มที่จะผลักดันให้สามารถเขียนHTML5บนผลิตภัณฑ์ได้ด้วยตัวอักษรขนาดใหญ่)

ทำไมคุณต้องผลักดัน ทำไมถึงมีการต่อต้าน? อาจจะเป็นธรรม

คุณสามารถให้ตัวอย่างที่รูปแบบเฉพาะนี้จะช่วยในการปรับปรุงฐานรหัสของคุณในรูปแบบที่สำคัญ (ตัวอย่างเช่นโดยการจับคู่กับตัวอย่างของการเปลี่ยนรูปแบบเป็นรูปแบบ )


หมายเหตุนอกหัวข้อทั้งหมดแต่นั่นคือสิ่งแรกที่ฉันนึกถึงเมื่อฉันอ่านชื่อคำถามเนื่องจากฉันคิดว่ามันอ้างถึงความล้มเหลวของซอฟต์แวร์ ... ฉันมีซอฟต์แวร์ที่ใช้คลาส BlackHole เพื่อจัดการข้อยกเว้นแบบพิเศษอย่างใดอย่างหนึ่ง ส่วนประกอบ ดูเหมือนว่า (และจริงๆแล้ว) เป็นแฮ็คที่แปลกและสกปรกอย่างเห็นได้ชัด แต่การตั้งชื่อตัวเองนั้นยอดเยี่ยมมากเราทุกคนชื่นชมมันสำหรับวิธีที่ยอดเยี่ยมในการจัดการกับความล้มเหลว! :)


@ ราเชล: ขอบคุณสำหรับการแก้ไขเพื่อให้สอดคล้องกับความพยายามของ META-SO ของคุณ ฉันไม่ได้สังเกตว่าคำถามได้ถูกเขียนซ้ำอีกครั้งตั้งแต่นั้นมา
haylem

3

ขั้นตอนที่ 1: โอเคที่จะโกรธ!

ครั้งแรกเป็นที่เข้าใจได้ว่าอารมณ์เสียหรือโกรธเมื่อพบกับความล้มเหลว หากให้คำแนะนำกับใครบางคนในสถานการณ์เช่นนี้พวกเขาส่วนใหญ่จะไม่อยากได้ยิน "แค่เอาชนะและไปต่อ" หรือ "แค่คิดว่ามันเป็นโอกาสในการเรียนรู้"

ในความเป็นจริงฉันคิดว่ามันจะมีสุขภาพดีและมีประสิทธิผลในการทำให้อารมณ์เสียและระบายความผิดหวังของคุณโดยที่คุณทำแบบส่วนตัวหรือกับเพื่อน ผู้คนมีวิธีการที่แตกต่างกัน แต่ฉันคิดว่าวิธีที่มีประโยชน์ที่สุดวิธีหนึ่งคือการเขียนจดหมายปลอมที่โกรธ(สำคัญ! อย่าส่งจดหมายนี้ให้ใคร ) อธิบายความรู้สึกของคุณเช่นทำไมคุณถึงรู้สึกว่าสิ่งที่เกิดขึ้นนั้นไม่ยุติธรรม

ขั้นตอนที่ 2: ใช้เวลาสักพักเพื่อสงบสติอารมณ์

ตรวจสอบให้แน่ใจว่าคุณได้แสดงทุกสิ่งที่คุณรู้สึกและหลังจากระบายความโกรธของคุณออกไปเพียงแค่ใช้เวลาสักพักเพื่อสงบสติอารมณ์ บางทีคุณอาจต้องการเวลาเพียงไม่กี่นาทีหรืออาจจะเพียงไม่กี่ชั่วโมง

ขั้นตอนที่ 3: ตรวจสอบสิ่งที่เกิดขึ้นในขั้นตอนที่ 1

ณ จุดนี้คุณหวังว่าจะสามารถคิดอย่างเป็นกลางเกี่ยวกับสถานการณ์ หากคุณเขียนจดหมายให้อ่านด้วยตัวคุณเอง หากคุณเชื่อใจใครสักคนพยายามจำสิ่งที่คุณพูด หากคุณแค่จินตนาการว่ากำลังตะโกนใส่ใครซักคนก็ให้ลองทบทวนดูว่า

ฉันมักจะเขียนจดหมายเมื่อฉันโกรธและหลังจากนั้นฉันก็สงบลงฉันจะพยายามปรับแต่งจดหมายให้ชัดเจนยิ่งขึ้นเพื่อสื่อสารสิ่งที่ฉันพยายามจะพูดในตอนแรกจนกระทั่งฉันพอใจว่ามีคนอ่านมันจะเข้าใจสิ่งที่ฉันเป็น ความรู้สึกในเวลา

ประเด็นก็คือพยายามเลือกสิ่งที่คุณเป็น พวกเขาทำให้รู้สึก? บางทีพวกเขาต้องการคำชี้แจงหรือรายละเอียดเพิ่มเติม พวกเขาไม่มีมูลความจริง? ถ้าคุณตั้งใจใส่รองเท้าของคนอื่นคุณจะเข้าใจประเด็นที่คุณทำหรือไม่? คุณเห็นด้วยกับประเด็นเหล่านี้หรือไม่ คุณสามารถใช้โอกาสนี้ในการประเมินตนเอง คุณทำอะไรได้ดี อะไรคือสิ่งที่คุณสามารถทำได้ดีกว่า

ขั้นตอนที่ 4: ตัดสินใจเลือกแนวทางปฏิบัติ

มีบางอย่างที่สามารถทำได้เพื่อแก้ไขสถานการณ์หรือเพื่อปรับปรุงอย่างน้อย? ใช้เวลาสักครู่เพื่อพิจารณาว่ามีสิ่งใดที่สามารถทำได้จริงเพื่อแก้ไขหรือปรับปรุงสถานการณ์ บ่อยครั้งที่ไม่มี แต่บางครั้งก็มี

หากคุณผิดสำหรับบางสิ่งบางอย่างนั่นอาจเป็นคำขอโทษอย่างเป็นทางการสำหรับใครบางคนอธิบายอย่างชัดเจนว่าเกิดอะไรขึ้นสิ่งที่คุณทำสาเหตุที่คุณทำและสิ่งที่คุณจะทำเพื่อแก้ไขหรือป้องกันไม่ให้เกิดขึ้นใน อนาคต.

ถัดไปพิจารณาสิ่งที่คุณสามารถทำได้เพื่อปรับปรุงอนาคต คุณจะทำอย่างไรเพื่อป้องกันไม่ให้สิ่งเดิมเกิดขึ้นอีก ตัดสินใจว่าอะไรคือสิ่งที่คุณต้องการบรรลุและใช้สิ่งที่คุณเรียนรู้จากขั้นตอนที่ 3 เพื่อสร้างแผนสำหรับตัวคุณเอง

หากสิ่งอื่นล้มเหลวให้ลองรีบูตเครื่อง:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.