წიგნი „როგორ ვმართოთ ინტელექტუალები. მე, ნერდები და გიკები"

ეძღვნება პროექტის მენეჯერებს (და მათ, ვინც ოცნებობს გახდეს უფროსობა).

ტონა კოდის დაწერა რთულია, მაგრამ ხალხის მართვა კიდევ უფრო რთული! ასე რომ, თქვენ უბრალოდ გჭირდებათ ეს წიგნი, რომ ისწავლოთ ორივეს გაკეთება.

შესაძლებელია თუ არა მხიარული ისტორიების და სერიოზული გაკვეთილების შერწყმა? მაიკლ ლოპმა (ვიწრო წრეებში ასევე ცნობილი როგორც რენდსი) წარმატებას მიაღწია. თქვენ იპოვით გამოგონილ ისტორიებს გამოგონილი ადამიანების შესახებ წარმოუდგენლად დაჯილდოვებული (თუმცა გამოგონილი) გამოცდილებით. ასე უზიარებს რენდსი თავის მრავალფეროვან, ზოგჯერ უცნაურ გამოცდილებას, რომელიც მიღებულ იქნა მსხვილ IT კორპორაციებში მუშაობის წლების განმავლობაში: Apple, Pinterest, Palantir, Netscape, Symantec და ა.შ.

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

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

ამონაწერი. საინჟინრო მენტალიტეტი

აზრები: უნდა განაგრძო კოდის წერა?

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

იყავი მოქნილი!

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

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

შეწყვიტე კოდის წერა!

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

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

კარგი რჩევაა, არა? მასშტაბი. მენეჯმენტი. პასუხისმგებლობა. ასეთი გავრცელებული ზარბაზნები. სამწუხაროა, რომ რჩევა არასწორია.

Არასწორი?

ჰო. რჩევა არასწორია! არა მთლად მცდარი, მაგრამ საკმარისად მცდარი, რომ მომიწია რამდენიმე ყოფილ კოლეგას დამერეკა და ბოდიში მომიხადა: „გახსოვს ჩემი საყვარელი განცხადება იმის შესახებ, თუ როგორ უნდა შეწყვიტო კოდის წერა? Შეცდომაა! დიახ... ისევ დაიწყეთ პროგრამირება. დაიწყეთ Python-ით და Ruby-ით. დიახ, მე სერიოზულად ვამბობ! შენი კარიერა მასზეა დამოკიდებული!”

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

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

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

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

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

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

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

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

შეწყვიტე კოდის წერა, მაგრამ...

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

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

თქვენ გაქვთ წინააღმდეგობები. გაიგე. Მოდი მოვუსმინოთ.

”რენდს, მე დირექტორის სავარძლისკენ მივდივარ! თუ კოდის წერას გავაგრძელებ, ვერავინ დაიჯერებს, რომ მე შემიძლია გავიზარდო“.

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

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

„აჰ, რენდსი! მაგრამ ვინმე უნდა იყოს არბიტრი! ვიღაცამ დიდი სურათი უნდა ნახოს. თუ კოდს დავწერ, პერსპექტივას დავკარგავ“.

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

ჩემი რჩევები ინჟინერიის მენტალიტეტის შესანარჩუნებლად:

1. გამოიყენეთ განვითარების გარემო. ეს ნიშნავს, რომ თქვენ უნდა იცოდეთ თქვენი გუნდის ინსტრუმენტები, მათ შორის კოდის აგების სისტემა, ვერსიის კონტროლი და პროგრამირების ენა. შედეგად, თქვენ დაეუფლებით იმ ენას, რომელსაც თქვენი გუნდი იყენებს პროდუქტის განვითარებაზე საუბრისას. ეს ასევე საშუალებას მოგცემთ გააგრძელოთ თქვენი საყვარელი ტექსტური რედაქტორის გამოყენება, რომელიც იდეალურად ფუნქციონირებს.
2. თქვენ უნდა შეძლოთ დახატოთ დეტალური არქიტექტურული დიაგრამა, რომელიც აღწერს თქვენს პროდუქტს ნებისმიერ ზედაპირზე, ნებისმიერ დროს. ახლა არ ვგულისხმობ გამარტივებულ ვერსიას სამი უჯრედით და ორი ისრით. თქვენ უნდა იცოდეთ პროდუქტის დეტალური დიაგრამა. ყველაზე რთული. არა რომელიმე საყვარელი დიაგრამა, არამედ დიაგრამა, რომლის ახსნაც რთულია. ეს უნდა იყოს რუკა, რომელიც შესაფერისია პროდუქტის სრული გაგებისთვის. ის მუდმივად იცვლება და ყოველთვის უნდა იცოდეთ რატომ მოხდა გარკვეული ცვლილებები.
3. აიღეთ ერთ-ერთი ფუნქციის განხორციელება. მე ფაქტიურად ვგიჟდები, რადგან ამას ვწერ, რადგან ამ პუნქტს ბევრი ფარული საფრთხე აქვს, მაგრამ ნამდვილად არ ვარ დარწმუნებული, რომ თქვენ შეგიძლიათ შეასრულოთ პუნქტი #1 და წერტილი #2 მინიმუმ ერთი ფუნქციის განხორციელების ვალდებულების გარეშე. ერთ-ერთი მახასიათებლის დანერგვით თქვენ არა მხოლოდ აქტიურად იქნებით ჩართული განვითარების პროცესში, არამედ საშუალებას მოგცემთ პერიოდულად გადახვიდეთ „ყველაფერზე პასუხისმგებელი მენეჯერის“ როლიდან „ადამიანის, რომელიც პასუხისმგებელია მის განხორციელებაზე“. ფუნქციებს“. ეს თავმდაბალი და თავმდაბალი დამოკიდებულება შეგახსენებთ მცირე გადაწყვეტილებების მნიშვნელობას.
4. ისევ ვკანკალებ სულ. როგორც ჩანს, ვიღაც უკვე მეძახის: „მენეჯერი, რომელმაც თავის თავზე აიღო ფუნქციის განხორციელება?!“ (და მე ვეთანხმები მას!) დიახ, თქვენ ჯერ კიდევ მენეჯერი ხართ, რაც ნიშნავს, რომ ეს რაღაც პატარა ფუნქცია უნდა იყოს, კარგი? დიახ, თქვენ ჯერ კიდევ ბევრი გაქვთ გასაკეთებელი. თუ უბრალოდ ვერ ახერხებთ ფუნქციის განხორციელებას, მაშინ მე მაქვს თქვენთვის სათადარიგო რჩევა: შეასწორეთ რამდენიმე ხარვეზი. ამ შემთხვევაში თქვენ არ იგრძნობთ შექმნის სიხარულს, მაგრამ გექნებათ იმის გაგება, თუ როგორ იქმნება პროდუქტი, რაც ნიშნავს, რომ არასოდეს დარჩებით სამუშაოს გარეშე.
5. დაწერეთ ერთეული ტესტები. ამას ჯერ კიდევ გვიან ვაკეთებ წარმოების ციკლში, როცა ხალხი გიჟდება. იფიქრეთ იმაზე, როგორც თქვენი პროდუქტის ჯანმრთელობის შემოწმების სიას. გააკეთეთ ეს ხშირად.

ისევ წინააღმდეგი?

„რენდს, თუ კოდს დავწერ, ჩემს გუნდს დავაბნევ. მათ არ იციან ვინ ვარ მე - მენეჯერი თუ დეველოპერი. ”

ყველა უფლება.

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

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

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

არ შეწყვიტო განვითარება

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

„რანდს, კოდირებელი უაზრო მანქანაა! მაიმუნი! კოდერი არაფერს აკეთებს მნიშვნელოვანს გარდა უსარგებლო კოდის მოსაწყენი ხაზების დაწერისა. მე არ ვარ კოდირებელი, მე ვარ პროგრამული უზრუნველყოფის შემქმნელი!”

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

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

იყავით მოქნილი. დაიმახსოვრე რას ნიშნავს იყო ინჟინერი და არ შეწყვიტო პროგრამული უზრუნველყოფის შემუშავება.

შესახებ ავტორი

მაიკლ ლოპი არის ვეტერანი პროგრამული უზრუნველყოფის შემქმნელი, რომელსაც ჯერ კიდევ არ დაუტოვებია სილიკონის ველი. ბოლო 20 წლის განმავლობაში მაიკლი მუშაობდა სხვადასხვა ინოვაციურ კომპანიებში, მათ შორის Apple, Netscape, Symantec, Borland, Palantir, Pinterest, და ასევე მონაწილეობდა სტარტაპში, რომელიც ნელ-ნელა დავიწყებას მიეცა.

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

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

» მეტი ინფორმაცია წიგნის შესახებ შეგიძლიათ იხილოთ აქ გამომცემლის ვებსაიტზე
» სარჩევი
» ნაწყვეტი

Khabrozhiteley-ზე 20% ფასდაკლება კუპონის გამოყენებით - ხალხის მართვა

წიგნის ქაღალდის ვერსიის გადახდის შემდეგ, წიგნის ელექტრონული ვერსია გაიგზავნება ელექტრონული ფოსტით.

PS: წიგნის ფასის 7% გადადის ახალი კომპიუტერული წიგნების თარგმნაზე, სტამბას გადაცემული წიგნების ნუსხა. აქ.

წყარო: www.habr.com