რატომ მხოლოდ თქვენი კოდირების განახლება არ გახდით უკეთეს დეველოპერად

Techlead Skyeng კირილ როგოვოი (ფლეშჰჰჰ) აკეთებს პრეზენტაციას კონფერენციებზე, სადაც საუბრობს იმ უნარებზე, რომლებიც უნდა განავითაროს ყველა კარგმა დეველოპერმა, რათა გახდეს საუკეთესო. ვთხოვე, ჰაბრას მკითხველებისთვის გაეზიარებინა ეს ამბავი, სიტყვას კირილს ვაძლევ.

მითი კარგი დეველოპერის შესახებ არის ის, რომ ის:

1. სუფთა კოდს წერს
2. იცის ბევრი ტექნოლოგია
3. ამოცანების კოდირება უფრო სწრაფად
4. იცის რამდენიმე ალგორითმი და დიზაინის ნიმუში
5. შეუძლია ნებისმიერი კოდის რეფაქტირება სუფთა კოდის გამოყენებით
6. არ კარგავს დროს არაპროგრამირების ამოცანებზე
7. თქვენი საყვარელი ტექნოლოგიის 100% ოსტატი

ასე ხედავს HR იდეალურ კანდიდატებს და ვაკანსიები, შესაბამისად, ასე გამოიყურება.

მაგრამ ჩემი გამოცდილება ამბობს, რომ ეს არ არის ძალიან სიმართლე.

პირველი, ორი მნიშვნელოვანი უარყოფა:
1) ჩემი გამოცდილება არის პროდუქტის გუნდები, ე.ი. კომპანიები საკუთარი პროდუქტით და არა აუთსორსინგით; აუთსორსინგში ყველაფერი შეიძლება ძალიან განსხვავებული იყოს;
2) თუ უმცროსი ხარ, მაშინ ყველა რჩევა არ იქნება გამოყენებული და მე რომ შენ ვიყო, ახლა პროგრამირებაზე გავამახვილებდი კონცენტრირებას.

კარგი დეველოპერი: რეალობა

1: საშუალოზე უკეთესი კოდი

კარგმა დეველოპერმა იცის როგორ შექმნას მაგარი არქიტექტურა, დაწეროს მაგარი კოდი და არ დაუშვას ძალიან ბევრი შეცდომა; ზოგადად, საშუალოზე უკეთ გამოსდის, მაგრამ სპეციალისტების ტოპ 1%-ში არ არის. ყველაზე მაგარი დეველოპერების უმეტესობა, რომელსაც მე ვიცნობ, არც თუ ისე კარგი კოდირებულია: ისინი კარგები არიან იმაში, რასაც აკეთებენ, მაგრამ მათ არ შეუძლიათ არაჩვეულებრივი რამის გაკეთება.

2: აგვარებს პრობლემებს, ვიდრე ქმნის მათ

წარმოვიდგინოთ, რომ ჩვენ გვჭირდება გარე სერვისის ინტეგრირება პროექტში. ვიღებთ ტექნიკურ მახასიათებლებს, ვათვალიერებთ დოკუმენტაციას, ვხედავთ, რომ იქ რაღაც მოძველებულია, გვესმის, რომ საჭიროა დამატებითი პარამეტრების გავლა, რაღაცის დახვეწა, ვცდილობთ ეს ყველაფერი როგორმე განვახორციელოთ და რაღაც ცრუ მეთოდმა სწორად იმუშაოს, ბოლოს და ბოლოს, შემდეგ რამდენიმე დღეში ჩვენ გვესმის, რომ ასე გაგრძელება არ შეიძლება. დეველოპერის სტანდარტული ქცევა ამ სიტუაციაში არის ის, რომ დაუბრუნდეს ბიზნესს და თქვას: „მე გავაკეთე ეს და ეს, ეს ასე არ მუშაობს და ის საერთოდ არ მუშაობს, ასე რომ წადი შენ თვითონ გაარკვიე. ” ბიზნესს აქვს პრობლემა: თქვენ უნდა ჩაუღრმავდეთ მომხდარს, დაუკავშირდეთ ვინმეს და შეეცადოთ როგორმე მოაგვაროთ იგი. გატეხილი ტელეფონი იწყება: "შენ უთხარი მას, მე მივწერ, ნახე რა უპასუხეს."

კარგი დეველოპერი, ასეთი სიტუაციის წინაშე აღმოჩნდება, თავად იპოვის კონტაქტებს, დაუკავშირდება მას ტელეფონით, განიხილავს პრობლემას და თუ არაფერი გამოვიდა, შეკრებს სწორ ადამიანებს, აუხსნის ყველაფერს და შესთავაზებს ალტერნატივებს (სავარაუდოდ, არის სხვა გარე სერვისი უკეთესი მხარდაჭერით). ასეთი დეველოპერი ხედავს ბიზნეს პრობლემას და წყვეტს მას. მისი ამოცანა დახურულია, როცა საქმიან პრობლემას აგვარებს და არა როცა რაღაცას წააწყდება.

3: ცდილობს დახარჯოს მინიმალური ძალისხმევა მაქსიმალური შედეგის მისაღწევად, თუნდაც ეს ყავარჯნების წერას გულისხმობს

პროდუქტის კომპანიებში პროგრამული უზრუნველყოფის შემუშავება თითქმის ყოველთვის ყველაზე დიდი ხარჯია: დეველოპერები ძვირია. და კარგ დეველოპერს ესმის, რომ ბიზნესს სურს მიიღოს მაქსიმალური თანხა მინიმალური დახარჯვით. მის დასახმარებლად კარგ დეველოპერს სურს დახარჯოს თავისი ძვირადღირებული დროის მინიმალური ოდენობა დამსაქმებლისთვის მაქსიმალური მოგების მისაღებად.

აქ ორი უკიდურესობაა. ერთი ის არის, რომ ზოგადად ყველა პრობლემის გადაჭრა შეგიძლიათ ყავარჯნით, არქიტექტურით შეწუხების გარეშე, რეფაქტორირების გარეშე და ა.შ. ჩვენ ყველამ ვიცით, როგორ მთავრდება ეს ჩვეულებრივ: არაფერი მუშაობს, ჩვენ თავიდან ვწერთ პროექტს ნულიდან. მეორეა, როდესაც ადამიანი ცდილობს თითოეული ღილაკისთვის იდეალური არქიტექტურის შექმნას, დავალებას დახარჯავს ერთ საათს, ხოლო რეფაქტორირებას ოთხ საათს. ასეთი სამუშაოს შედეგი მშვენივრად გამოიყურება, მაგრამ პრობლემა ის არის, რომ ბიზნესის მხრივ ათი საათი სჭირდება ღილაკის დასრულებას, როგორც პირველ, ასევე მეორე შემთხვევაში, უბრალოდ სხვადასხვა მიზეზის გამო.

კარგმა დეველოპერმა იცის როგორ დააბალანსოს ამ უკიდურესობებს შორის. მას ესმის კონტექსტი და იღებს ოპტიმალურ გადაწყვეტილებას: ამ პრობლემაში მე დავჭრი ყავარჯენს, რადგან ეს არის კოდი, რომელსაც ყოველ ექვს თვეში ერთხელ ეხება. მაგრამ ამ შემთხვევაში მე შევწუხდები და ყველაფერს გავაკეთებ რაც შეიძლება სწორად, რადგან ასი ახალი ფუნქცია, რომელიც ჯერ კიდევ არ არის შემუშავებული, დამოკიდებული იქნება იმაზე, თუ რას მივაღწევ.

4. აქვს საკუთარი ბიზნესის მართვის სისტემა და შეუძლია მასში ნებისმიერი სირთულის პროექტებზე მუშაობა.

პრინციპებზე მუშაობა მიღების რამ გაკეთდა – როცა ყველა თქვენს დავალებას იწერთ რაიმე სახის ტექსტურ სისტემაში, არ დაივიწყოთ შეთანხმებები, უბიძგოთ ყველას, გამოჩნდით ყველგან დროულად, იცოდეთ რა არის მნიშვნელოვანი და რა არ არის მნიშვნელოვანი ამ მომენტში, არასოდეს კარგავთ დავალებებს. ასეთი ადამიანების ზოგადი მახასიათებელია ის, რომ როცა რაღაცაზე ეთანხმები, არასოდეს ინერვიულო, რომ დაივიწყონ; და ისიც იცი, რომ ყველაფერს წერენ და შემდეგ ათას კითხვას არ დასვამენ, რომლებზეც პასუხები უკვე განხილულია.

5. კითხვებს და განმარტავს ნებისმიერ პირობას და შესავალს

აქაც ორი უკიდურესობაა. ერთის მხრივ, შეგიძლიათ იყოთ სკეპტიკურად განწყობილი ყველა შესავალი ინფორმაციის მიმართ. ხალხი, სანამ რაღაც გადაწყვეტას მოიფიქრებდით, მაგრამ ფიქრობთ, რომ უკეთესად შეგიძლიათ და დაიწყოთ ყველაფრის ხელახლა განხილვა, რაც თქვენს წინაშე იყო: დიზაინი, ბიზნეს გადაწყვეტილებები, არქიტექტურა და ა.შ. ეს კარგავს დიდ დროს როგორც დეველოპერს, ისე მის გარშემო მყოფებს და უარყოფითად აისახება კომპანიის ნდობაზე: სხვა ადამიანებს არ სურთ გადაწყვეტილების მიღება, რადგან იციან, რომ ის ბიჭი დაბრუნდება და ყველაფერს დაარღვევს. მეორე უკიდურესობაა, როდესაც დეველოპერი აღიქვამს ნებისმიერ შესავალს, ტექნიკურ მახასიათებელს და საქმიან სურვილს, როგორც ქვაზე მოჩუქურთმებულ რაღაცას და მხოლოდ გადაუჭრელი პრობლემის წინაშე იწყებს ფიქრს, აკეთებს თუ არა ამას საერთოდ. კარგი დეველოპერი აქაც პოულობს შუა გზას: ის ცდილობს გაიგოს მის წინ თუ მის გარეშე მიღებული გადაწყვეტილებები, სანამ დავალება განვითარებაში გადავა. რა სურს ბიზნესს? ვაგვარებთ მის პრობლემებს? პროდუქტის დიზაინერმა მოიფიქრა გამოსავალი, მაგრამ მე მესმის, რატომ იმუშავებს გამოსავალი? რატომ გამოიგონა გუნდის ლიდერმა ეს კონკრეტული არქიტექტურა? თუ რამე გაუგებარია, მაშინ უნდა წახვიდე და იკითხო. ამ დაზუსტების პროცესში, კარგმა დეველოპერმა შეიძლება დაინახოს ალტერნატიული გამოსავალი, რომელიც აქამდე უბრალოდ არავის მოსვლია.

6. აუმჯობესებს თქვენს გარშემო არსებულ პროცესებს და ადამიანებს

ჩვენს ირგვლივ უამრავი პროცესი მიმდინარეობს – ყოველდღიური შეხვედრები, შეხვედრები, სკრამები, ტექნიკური მიმოხილვები, კოდების მიმოხილვა და ა.შ. კარგი დეველოპერი ადგება და იტყვის: აჰა, ჩვენ ვიკრიბებით და ყოველ კვირა ერთსა და იმავეს განვიხილავთ, არ მესმის რატომ, შეიძლება ეს საათიც Contra-ზე გავატაროთ. ან: ზედიზედ მესამე დავალებაზე ვერ შევდივარ კოდში, არაფერია გასაგები, არქიტექტურა სავსეა ხვრელების; შესაძლოა, ჩვენი განხილვის კოდი კოჭლია და ჩვენ გვჭირდება რეფაქტორირება, მოდით, შევცვალოთ შეხვედრა ყოველ ორ კვირაში ერთხელ. ან კოდის განხილვისას ადამიანი ხედავს, რომ მისი ერთ-ერთი კოლეგა არ იყენებს გარკვეულ ინსტრუმენტს საკმარისად ეფექტურად, რაც იმას ნიშნავს, რომ მას მოგვიანებით სჭირდება მოსვლა და რჩევის მიცემა. კარგ დეველოპერს აქვს ეს ინსტინქტი; ის ასეთ რამეებს ავტომატურად აკეთებს.

7. შესანიშნავია სხვების მართვაში, თუნდაც არა მენეჯერი

ეს უნარი კარგად უკავშირდება თემას „პრობლემის შექმნის ნაცვლად გადაჭრა“. ხშირად ვაკანსიის ტექსტში, რომელზეც ჩვენ ვაცხადებთ, არაფერი წერია მენეჯმენტზე, მაგრამ შემდეგ, როცა შენს კონტროლს მიღმა პრობლემის წინაშე დგახარ, მაინც უნდა მართო სხვები ამა თუ იმ გზით, მიაღწიო მათ რაიმეს, თუ დაავიწყდა - უბიძგე, დარწმუნდით, რომ მათ ყველაფერი გაიგეს. კარგმა დეველოპერმა იცის ვის რა აინტერესებს, შეუძლია დარეკოს ამ ადამიანებთან შეხვედრაზე, დაწეროს შეთანხმებები, გაუგზავნოს ისინი, შეახსენოს მათ სწორ დღეს, დარწმუნდეს, რომ ყველაფერი მზად არის, თუნდაც ის პირადად არ იყოს პასუხისმგებელი. ეს ამოცანა, მაგრამ მისი შედეგი დამოკიდებულია მის განხორციელებაზე.

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 საათის გატარების შემდეგ, თქვენ შესამჩნევად გაუმჯობესდებით დაკავშირებულ სფეროებში, გაიგებთ მათში მიმდინარე პროცესებს და გახდებით ბევრად უფრო ავტონომიური.

დღევანდელ IT ეკოსისტემაში უმჯობესია გქონდეთ რაც შეიძლება მეტი უნარები და არ იყოთ რომელიმე მათგანის ექსპერტი. იმიტომ რომ, ჯერ ერთი, ყველა ეს უნარი სწრაფად ქრება, განსაკუთრებით მაშინ, როცა საქმე პროგრამირებას ეხება და მეორეც, იმიტომ, რომ 99% ჩვენ ვიყენებთ არა მხოლოდ საბაზისო, არამედ, რა თქმა უნდა, არა ყველაზე დახვეწილ უნარებს და ეს საკმარისია კოდირების დროსაც კი, თუნდაც მაგარი კომპანიები.

და ბოლოს, ტრენინგი ინვესტიციაა, დივერსიფიკაცია კი მნიშვნელოვანია ინვესტიციებში.

რა ასწავლოს

მაშ რა ვასწავლოთ და როგორ? ძლიერი კომპანიის ტიპიური დეველოპერი რეგულარულად იყენებს:

• კომუნიკაცია
• თვითორგანიზაცია
• დაგეგმვა
• დიზაინი (ჩვეულებრივ კოდი)
• და ზოგჯერ მენეჯმენტი, ლიდერობა, მონაცემთა ანალიზი, წერა, რეკრუტირება, სწავლება და მრავალი სხვა უნარი

და პრაქტიკულად არცერთი ეს უნარი არანაირად არ იკვეთება თავად კოდთან. მათ ცალ-ცალკე უნდა ასწავლონ და განაახლონ და თუ ეს არ გაკეთდა, ისინი დარჩებიან ძალიან დაბალ დონეზე, რაც არ იძლევა მათი ეფექტურად გამოყენების საშუალებას.

რა სფეროებში ღირს განვითარება?

1. რბილი უნარები არის ყველაფერი, რაც არ ეხება ღილაკების დაჭერას რედაქტორში. ასე ვწერთ მესიჯებს, როგორ ვიქცევით შეხვედრებზე, როგორ ვურთიერთობთ კოლეგებთან. ეს ყველაფერი აშკარად ჩანს, მაგრამ ძალიან ხშირად მათ არ აფასებენ.

2. თვითორგანიზაციის სისტემა. პირადად ჩემთვის ეს გასული წლის განმავლობაში ძალიან მნიშვნელოვანი თემა გახდა. ყველა მაგარ IT მუშაკს შორის, რომელსაც მე ვიცნობ, ეს არის ერთ-ერთი ყველაზე განვითარებული უნარი: ისინი სუპერ ორგანიზებულები არიან, ყოველთვის აკეთებენ იმას, რასაც ამბობენ, ზუსტად იციან რას გააკეთებენ ხვალ, ერთ კვირაში, ერთ თვეში. აუცილებელია შენს ირგვლივ ააშენო სისტემა, რომელშიც ჩაიწერება ყველა საკითხი და ყველა კითხვა; ეს მნიშვნელოვნად უწყობს ხელს სამუშაოს თავად და დიდად უწყობს ხელს სხვა ადამიანებთან ურთიერთობას. ვგრძნობ, რომ გასული წლის განმავლობაში ამ მიმართულებით განვითარებამ ბევრად უფრო გამიუმჯობესა, ვიდრე ტექნიკური უნარების გაუმჯობესებამ; დროის ერთეულზე მნიშვნელოვნად მეტი სამუშაოს კეთება დავიწყე.

3. პროაქტიული, გონებაგახსნილი და დაგეგმილი. თემები ძალიან ზოგადი და სასიცოცხლოა, არ არის უნიკალური IT-ისთვის და ყველამ უნდა განავითაროს ისინი. პროაქტიულობა ნიშნავს არ დაელოდოთ სიგნალს მოქმედების გასატარებლად. თქვენ ხართ მოვლენების წყარო და არა მათზე რეაქციები. გონებაგახსნილობა არის ნებისმიერი ახალი ინფორმაციის ობიექტურად მოპყრობის უნარი, სიტუაციის შეფასება საკუთარი მსოფლმხედველობისა და ძველი ჩვევებისგან იზოლირებულად. დაგეგმვა არის მკაფიო ხედვა იმისა, თუ როგორ წყვეტს დღევანდელი ამოცანა კვირის, თვის, წლის პრობლემას. თუ ხედავ მომავალს კონკრეტული ამოცანის მიღმა, ბევრად უფრო ადვილია გააკეთო ის, რაც გჭირდება და არ შეგეშინდეს დროის გასვლის შემდეგ, რომ გააცნობიერო, რომ ის დაიხარჯა. ეს უნარი განსაკუთრებით მნიშვნელოვანია კარიერისთვის: შეგიძლიათ წარმატებით მიაღწიოთ შედეგებს წლების განმავლობაში, მაგრამ არასწორ ადგილას და საბოლოოდ დაკარგოთ მთელი დაგროვილი ბარგი, როდესაც ირკვევა, რომ არასწორი მიმართულებით მოძრაობდით.

4. ყველა დაკავშირებული სფერო საბაზისო დონეზე. ყველას აქვს საკუთარი სპეციფიკური სფეროები, მაგრამ მნიშვნელოვანია გვესმოდეს, რომ 10-20 საათის დახარჯვით გარკვეული „უცხო“ უნარების დონის ამაღლებაზე, თქვენ შეგიძლიათ აღმოაჩინოთ მრავალი ახალი შესაძლებლობა და საკონტაქტო წერტილი თქვენს ყოველდღიურ საქმიანობაში, და ეს საათები შეიძლება. საკმარისი იყოს კარიერის ბოლომდე.

რა წაიკითხოს

არსებობს უამრავი წიგნი თვითორგანიზაციის შესახებ; ეს არის მთელი ინდუსტრია, სადაც ზოგიერთი უცნაური ბიჭი წერს რჩევების კრებულს და აგროვებს ტრენინგებს. ამავე დროს, გაუგებარია, რას მიაღწიეს მათ ცხოვრებაში. აქედან გამომდინარე, მნიშვნელოვანია ავტორებს ფილტრები დავაყენოთ, შევხედოთ ვინ არიან და რა აქვთ უკან. ჩემს განვითარებასა და მსოფლმხედველობაზე უდიდესი გავლენა მოახდინა ოთხმა წიგნმა, ყველა მათგანი ამა თუ იმ გზით დაკავშირებული იყო ზემოთ აღწერილი უნარების გაუმჯობესებასთან.

1. დეილ კარნეგი „როგორ მოვიპოვოთ მეგობრები და მოვახდინოთ გავლენა ადამიანებზე“. საკულტო წიგნი რბილი უნარების შესახებ, თუ არ იცით საიდან დაიწყოთ, მისი არჩევა მომგებიანი ვარიანტია. ის აგებულია მაგალითებზე, ადვილად იკითხება, არ საჭიროებს დიდ ძალისხმევას წაკითხულის გასაგებად და შეძენილი უნარების გამოყენება შესაძლებელია დაუყოვნებლივ. მთლიანობაში, წიგნი მოიცავს ადამიანებთან კომუნიკაციის თემას.

2. სტივენ რ. კოვეი "ძლიერ ეფექტური ადამიანების 7 ჩვევა". სხვადასხვა უნარების ნაზავი, პროაქტიულობიდან რბილ უნარებამდე, აქცენტით სინერგიის მიღწევაზე, როდესაც საჭიროა პატარა გუნდი გადააქციოთ უზარმაზარ ძალად. ასევე ადვილი წასაკითხია.

3. რეი დალიო "პრინციპები". ავლენს გახსნილობისა და პროაქტიულობის თემებს, ავტორის მიერ აშენებული კომპანიის ისტორიაზე დაფუძნებული, რომელსაც იგი მართავდა 40 წლის განმავლობაში. ცხოვრებიდან მიღებული მრავალი მაგალითი გვიჩვენებს, თუ რამდენად მიკერძოებული და დამოკიდებული შეიძლება იყოს ადამიანი და როგორ უნდა მოვიშოროთ იგი.

4. დევიდ ალენი, "საქმის დასრულება". სავალდებულო კითხვა თვითორგანიზაციის სწავლისთვის. მისი წაკითხვა არც ისე ადვილია, მაგრამ ის უზრუნველყოფს ინსტრუმენტების ყოვლისმომცველ კომპლექტს ცხოვრებისა და საქმეების ორგანიზებისთვის, დეტალურად განიხილავს ყველა ასპექტს და დაგეხმარებათ გადაწყვიტოთ რა გჭირდებათ. მისი დახმარებით მე ავაშენე ჩემი საკუთარი სისტემა, რომელიც საშუალებას მაძლევს ყოველთვის გავაკეთო ყველაზე მნიშვნელოვანი საქმეები დანარჩენის დავიწყების გარეშე.

უნდა გესმოდეთ, რომ მხოლოდ კითხვა არ არის საკმარისი. შეგიძლიათ კვირაში ერთი წიგნი მაინც გადაყლაპოთ, მაგრამ ეფექტი რამდენიმე დღე გაგრძელდება, შემდეგ კი ყველაფერი თავის ადგილს დაუბრუნდება. წიგნები უნდა იქნას გამოყენებული, როგორც რჩევის წყარო, რომელიც დაუყოვნებლივ პრაქტიკაში გამოცდილია. თუ ამას არ გააკეთებთ, მაშინ ყველაფერი რაც მათ მოგცემთ არის თქვენი ჰორიზონტის გაფართოება.

წყარო: www.habr.com