เหตุใดการอัปเกรดการเขียนโค้ดของคุณจึงไม่ทำให้คุณเป็นนักพัฒนาที่ดีขึ้น

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

ตำนานเกี่ยวกับนักพัฒนาที่ดีคือเขา:

1. เขียนโค้ดที่สะอาด
2. รู้เทคโนโลยีมากมาย
3. งานเขียนโค้ดเร็วขึ้น
4. รู้อัลกอริธึมและรูปแบบการออกแบบมากมาย
5. สามารถปรับโครงสร้างโค้ดใดๆ ก็ได้โดยใช้ Clean Code
6. ไม่เสียเวลากับงานที่ไม่ใช่การเขียนโปรแกรม
7. เชี่ยวชาญเทคโนโลยีที่คุณชื่นชอบ 100%

นี่คือวิธีที่ HR มองเห็นผู้สมัครในอุดมคติ และตำแหน่งงานว่างก็มีลักษณะเช่นนี้เช่นกัน

แต่ประสบการณ์ของฉันบอกว่าสิ่งนี้ไม่เป็นความจริงมากนัก

ประการแรก ข้อจำกัดความรับผิดชอบที่สำคัญสองประการ:
1) ประสบการณ์ของฉันคือทีมผลิตภัณฑ์ เช่น บริษัทที่มีผลิตภัณฑ์ของตนเอง ไม่ใช่การจ้างบุคคลภายนอก ในการจ้างทุกอย่างอาจแตกต่างกันมาก
2) หากคุณเป็นรุ่นน้อง คำแนะนำบางข้ออาจใช้ไม่ได้ทั้งหมด และหากฉันเป็นคุณ ฉันจะเน้นไปที่การเขียนโปรแกรมในตอนนี้

นักพัฒนาที่ดี: ความเป็นจริง

1: ดีกว่าโค้ดทั่วไป

นักพัฒนาที่ดีรู้วิธีสร้างสถาปัตยกรรมเจ๋งๆ เขียนโค้ดเจ๋งๆ และไม่สร้างข้อบกพร่องมากเกินไป โดยทั่วไปแล้ว เขาทำได้ดีกว่าค่าเฉลี่ย แต่เขาไม่ได้อยู่ใน 1% แรกของผู้เชี่ยวชาญ นักพัฒนาที่เจ๋งที่สุดที่ฉันรู้จักส่วนใหญ่ไม่ใช่ผู้เขียนโค้ดที่เก่ง พวกเขาเก่งในสิ่งที่พวกเขาทำ แต่พวกเขาไม่สามารถทำอะไรที่พิเศษสุดๆ ได้

2: แก้ไขปัญหามากกว่าการสร้างมันขึ้นมา

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

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

3: พยายามใช้ความพยายามเพียงเล็กน้อยเพื่อให้ได้ผลลัพธ์สูงสุด แม้ว่าจะต้องเขียนไม้ค้ำยันก็ตาม

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

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

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

4. มีระบบการจัดการธุรกิจของตนเองและสามารถทำงานในโครงการที่มีความซับซ้อนได้

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

5. สอบถามและชี้แจงเงื่อนไขและการแนะนำต่างๆ

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

6. ปรับปรุงกระบวนการและผู้คนรอบตัวคุณ

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

7. เก่งในการจัดการผู้อื่น แม้ว่าจะไม่ใช่ผู้จัดการก็ตาม

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

8. ไม่รับรู้ว่าความรู้ของเขาเป็นเพียงความเชื่อ แต่เปิดรับคำวิจารณ์อยู่ตลอดเวลา

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

มาเปรียบเทียบความคิดของฉันเกี่ยวกับนักพัฒนาในอุดมคติกับแนวคิดที่เป็นที่ยอมรับโดยทั่วไป:

รูปภาพนี้แสดงจำนวนจุดที่อธิบายไว้ข้างต้นที่เกี่ยวข้องกับโค้ด และกี่จุดที่ไม่เกี่ยวข้องกับโค้ด การพัฒนาในบริษัทผลิตภัณฑ์เป็นเพียงหนึ่งในสามของการเขียนโปรแกรม ส่วนที่เหลืออีก 2/3 มีส่วนเกี่ยวข้องกับโค้ดเพียงเล็กน้อย แม้ว่าเราจะเขียนโค้ดจำนวนมาก แต่ประสิทธิภาพของเราขึ้นอยู่กับสองในสามที่ "ไม่เกี่ยวข้อง" เหล่านี้อย่างมาก

ความเชี่ยวชาญ ลักษณะทั่วไป และกฎ 80-20

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

กฎ 80-20 บอกเราว่า 80% ของผลลัพธ์มาจาก 20% ของความพยายาม รายได้ 80% มาจากลูกค้า 20% กำไร 80% มาจากพนักงาน 20% และอื่นๆ ในการสอน นี่หมายความว่า 80% ของความรู้ที่เราได้รับจาก 20% แรกของเวลาที่ใช้ไป

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

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

ทักษะที่เกี่ยวข้องสามารถฝึกฝนได้ไม่ใช่ 80% แต่ 30-50% หลังจากใช้เวลา 10-20 ชั่วโมง คุณจะพัฒนาในด้านที่เกี่ยวข้องอย่างเห็นได้ชัด เข้าใจกระบวนการต่างๆ ที่เกิดขึ้นในนั้นมากขึ้น และมีความเป็นอิสระมากขึ้น

ในระบบนิเวศไอทีในปัจจุบัน การมีทักษะให้มากที่สุดเท่าที่จะเป็นไปได้จะดีกว่าและไม่ต้องเป็นผู้เชี่ยวชาญในทักษะใดๆ เพราะอย่างแรก ทักษะเหล่านี้ทั้งหมดจางหายไปอย่างรวดเร็ว โดยเฉพาะอย่างยิ่งเมื่อพูดถึงการเขียนโปรแกรม และอย่างที่สอง เพราะ 99% ของเวลาที่เราใช้ไม่เพียงแต่ขั้นพื้นฐานเท่านั้น แต่ยังไม่ใช่ทักษะที่ซับซ้อนที่สุดอย่างแน่นอน และนี่ก็เพียงพอแล้วแม้แต่ในการเขียนโค้ด แม้แต่ใน บริษัทเจ๋งๆ

และสุดท้าย การฝึกอบรมคือการลงทุน และการกระจายความเสี่ยงเป็นสิ่งสำคัญในการลงทุน

จะสอนอะไร.

แล้วจะสอนอะไรและอย่างไร? นักพัฒนาทั่วไปในบริษัทที่แข็งแกร่งมักจะใช้:

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

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

ในพื้นที่ใดที่ควรค่าแก่การพัฒนา?

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

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

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

4. ทุกสาขาที่เกี่ยวข้องจนถึงระดับพื้นฐาน ทุกคนมีพื้นที่เฉพาะของตนเอง แต่สิ่งสำคัญคือต้องเข้าใจว่าด้วยการใช้เวลา 10-20 ชั่วโมงเพื่อยกระดับทักษะ "ต่างประเทศ" คุณจะสามารถค้นพบโอกาสและจุดติดต่อใหม่ ๆ มากมายในการทำงานประจำวันของคุณ และเวลาเหล่านี้อาจ ก็พอไปจนหมดอาชีพ

สิ่งที่ต้องอ่าน

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

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

2. Stephen R. Covey “นิสัย 7 ประการของผู้มีประสิทธิภาพสูง”. การผสมผสานทักษะต่างๆ ตั้งแต่ทักษะเชิงรุกไปจนถึงทักษะด้านอารมณ์ โดยเน้นที่การบรรลุการทำงานร่วมกันเมื่อคุณต้องการเปลี่ยนทีมเล็กๆ ให้เป็นพลังอันยิ่งใหญ่ นอกจากนี้ยังอ่านง่าย

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

4. เดวิด อัลเลน “ทำสิ่งต่างๆ ให้สำเร็จ”. การอ่านภาคบังคับเพื่อเรียนรู้การจัดระเบียบตนเอง ไม่ใช่เรื่องง่ายที่จะอ่าน แต่มีชุดเครื่องมือที่ครอบคลุมสำหรับการจัดการชีวิตและกิจการ ตรวจสอบทุกด้านอย่างละเอียด และช่วยให้คุณตัดสินใจว่าคุณต้องการสิ่งใดบ้าง ด้วยความช่วยเหลือของเธอ ฉันจึงสร้างระบบของตัวเองที่ช่วยให้ฉันทำสิ่งที่สำคัญที่สุดได้ตลอดเวลาโดยไม่ลืมส่วนที่เหลือ

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

ที่มา: will.com