Посветено на ръководителите на проекти (и тези, които мечтаят да станат шефове).
Писането на тонове код е трудно, но управлението на хора е още по-трудно! Така че просто ви трябва тази книга, за да научите как да правите и двете.
Възможно ли е да се съчетаят забавни истории и сериозни уроци? Майкъл Лоп (известен в тесните кръгове и като Рандс) успя. Ще намерите измислени истории за измислени хора с невероятно възнаграждаващи (макар и измислени) преживявания. Така Рандс споделя своя разнообразен, понякога странен опит, натрупан през годините на работа в големи ИТ корпорации: Apple, Pinterest, Palantir, Netscape, Symantec и др.
Вие сте ръководител на проекти? Или искате да разберете какво прави проклетият ви шеф по цял ден? Рандс ще ви научи как да оцелявате в токсичния свят на напомпаните пуйки и да процъфтявате в общата лудост на дисфункционално пищни хора. В тази странна общност от маниакални мозъци има още по-странни същества - мениджъри, които чрез мистичен организационен ритуал са придобили власт над плановете, мислите и банковите сметки на много хора.
Тази книга не прилича на всеки ръкопис за управление или лидерство. Майкъл Лоп не крие нищо, той просто го разказва така, както е (може би не всички истории трябва да бъдат публични: P). Но само по този начин ще разберете как да оцелеете с такъв шеф, как да управлявате маниаци и маниаци и как да доведете „този проклет проект“ до щастлив край!
Извадка. Инженерен манталитет
Мисли относно: Трябва ли да продължите да пишете код?
Книгата на Рандс за правилата за мениджърите съдържа много кратък списък на съвременните управленски „задължителни неща“. Лаконичността на този списък се дължи на факта, че понятието „трябва“ е нещо като абсолют, а когато става дума за хора, има много малко абсолютни понятия. Успешният метод на управление за един служител ще бъде истинска катастрофа за друг. Тази мисъл е първият елемент от списъка със „задължителни неща“ на мениджъра:
Останете гъвкави!
Мисленето, че вече знаете всичко е много лоша идея. В ситуация, в която единственият постоянен факт е, че светът непрекъснато се променя, гъвкавостта става единствената правилна позиция.
Парадоксално, вторият елемент от списъка е изненадващо негъвкав. Тази точка обаче е моят личен фаворит, защото вярвам, че помага да се създаде основата за управленски растеж. Този параграф гласи:
Спрете да пишете код!
На теория, ако искате да бъдете мениджър, трябва да се научите да се доверявате на тези, които работят за вас и да предадете кодирането изцяло на тях. Този съвет обикновено е труден за смилане, особено за новоизпечените мениджъри. Вероятно една от причините да станат мениджъри е тяхната производителност в разработката и когато нещата се объркат, първата им реакция е да се върнат към уменията, на които имат пълно доверие, което е способността им да пишат код.
Когато видя, че новоизсечен мениджър „потъва“ в писането на код, му казвам: „Знаем, че можете да пишете код. Въпросът е: можете ли да водите? Вече не сте отговорни само за себе си, а за целия екип; и искам да съм сигурен, че можете да накарате екипа си да решава проблемите сам, без да се налага сами да пишете кода. Вашата работа е да разберете как да се мащабирате. Не искам да си само един, искам да има много като теб.
Добър съвет, нали? Мащаб. Управление. Отговорност. Такива общи модни думи. Жалко, че съветът е грешен.
неправилно?
да Съветът е грешен! Не напълно погрешно, но достатъчно погрешно, че трябваше да се обадя на някои бивши колеги и да се извиня: „Помните ли онова любимо мое изказване за това как трябва да спрете да пишете код? Грешно е! Да... Започнете да програмирате отново. Започнете с Python и Ruby. Да, сериозно ти говоря! Вашата кариера зависи от това!“
Когато започнах кариерата си като софтуерен разработчик в Borland, работих в екипа на Paradox Windows, който беше огромен екип. Само разработчиците на приложения бяха 13. Ако добавите хора от други екипи, които също непрекъснато работеха върху ключови технологии за този проект, като основната база данни и услугите на основните приложения, получавате 50 инженера, участващи директно в разработването на този продукт.
Никой друг екип, за който съм работил, дори не се доближава до този размер. Всъщност с всяка изминала година хората в екипа, в който работя, постепенно намаляват. Какво става? Ние, разработчиците, ставаме ли колективно все по-умни и по-умни? Не, ние просто споделяме товара.
Какво правят разработчиците през последните 20 години? През това време написахме купчина код. Море от код! Написахме толкова много код, че решихме, че би било добра идея да опростим всичко и да преминем към отворен код.
За щастие, благодарение на Интернет, този процес сега стана възможно най-прост. Ако сте разработчик на софтуер, можете да го проверите точно сега! Потърсете името си в Google или Github и ще видите код, който отдавна сте забравили, но който всеки може да намери. Страшно, нали? Не знаехте ли, че кодът живее вечно? Да, той живее вечно.
Кодът живее вечно. А добрият код не само живее вечно, но и расте, защото онези, които го ценят, постоянно гарантират, че той остава свеж. Тази купчина висококачествен, добре поддържан код помага за намаляване на средния размер на инженерния екип, защото ни позволява да се съсредоточим върху съществуващия код, вместо да пишем нов код, и да свършим работата с по-малко хора и за по-кратък период от време.
Тази линия на разсъждение звучи депресиращо, но идеята е, че ние всички сме просто куп интеграционни автомати, използващи тиксо, за да свързват различни битове от съществуващи неща заедно, за да създадат малко по-различна версия на едно и също нещо. Това е класическа линия на мислене сред висшите ръководители, които обичат аутсорсинга. „Всеки, който знае как да използва Google и има малко тиксо, може да направи това! Тогава защо плащаме много пари на нашите машини?“
Ние плащаме на тези мениджъри наистина много пари, но те мислят такива глупости. Още веднъж, моята ключова точка е, че има много брилянтни и много трудолюбиви разработчици на нашата планета; те са наистина брилянтни и усърдни, въпреки че не са прекарали нито минута в акредитирани университети. О, да, сега те стават все повече и повече!
Не ви предлагам да започнете да се тревожите за мястото си само защото някои брилянтни другари уж го търсят. Предлагам ви да започнете да се тревожите за това, защото еволюцията на разработката на софтуер вероятно се движи по-бързо от вас. Работите десет години, пет от които като мениджър, и си мислите: „Вече знам как се разработва софтуер.“ Да, знаеш. Чао…
Спрете да пишете код, но...
Ако следвате първоначалния ми съвет и спрете да пишете код, вие също доброволно ще спрете да участвате в процеса на създаване. Поради тази причина не използвам активно аутсорсинг. Автоматите не създават, те произвеждат. Добре проектираните процеси спестяват много пари, но не носят нищо ново в нашия свят.
Ако имате малък екип, който прави много за малко пари, тогава идеята да спрете да пишете код ми изглежда като лошо решение за кариера. Дори в чудовищни компании с техните безкрайни регулации, процеси и политики, нямате право да забравите как сами да разработвате софтуер. А разработването на софтуер непрекъснато се променя. В момента се променя. Под краката ти! Точно в тази секунда!
Имате възражения. Разберете. Нека слушаме.
„Рандс, отивам към режисьорския стол! Ако продължа да пиша код, никой няма да повярва, че мога да се развивам.”
Искам да ви попитам следното: откакто седнахте на вашия стол „На път съм да стана главен изпълнителен директор!“, забелязахте ли, че пейзажът на разработката на софтуер се променя, дори във вашата компания? Ако отговорът ви е да, тогава ще ви задам друг въпрос: как точно се променя и какво ще направите с тези промени? Ако сте отговорили с „не“ на първия ми въпрос, тогава трябва да се преместите на друг стол, защото (обзалагам се!) областта на разработката на софтуер се променя точно тази секунда. Как ще растете, ако бавно, но сигурно забравяте как да разработвате софтуер?
Моят съвет е да не се ангажирате с прилагането на тонове функции за следващия си продукт. Трябва постоянно да предприемате стъпки, за да сте в крак с начина, по който вашият екип изгражда софтуер. Можете да направите това както като директор, така и като вицепрезидент. Нещо друго?
„Уф, Рандс! Но някой трябва да бъде арбитър! Някой трябва да види голямата картина. Ако пиша код, ще загубя перспектива."
Все още трябва да сте съдията, все още трябва да излъчвате решенията и все още трябва да обикаляте сградата четири пъти всеки понеделник сутрин с един от вашите инженери, за да слушате седмичното му изказване „Всички сме обречени“ за 30 минути.! Но освен всичко това, трябва да поддържате инженерно мислене и не е нужно да сте програмист на пълен работен ден, за да направите това.
Моите съвети за поддържане на инженерен манталитет:
- Използвайте средата за разработка. Това означава, че трябва да сте запознати с инструментите на вашия екип, включително системата за изграждане на код, контрол на версиите и език за програмиране. В резултат на това ще станете опитни в езика, който вашият екип използва, когато говори за разработване на продукти. Това също ще ви позволи да продължите да използвате любимия си текстов редактор, който работи перфектно.
- Трябва да можете да начертаете подробна архитектурна диаграма, описваща вашия продукт върху всякаква повърхност по всяко време. Сега нямам предвид опростената версия с три клетки и две стрелки. Трябва да знаете подробната схема на продукта. Най-трудният. Не просто сладка диаграма, а диаграма, която е трудна за обяснение. Това трябва да е карта, подходяща за пълно разбиране на продукта. Той непрекъснато се променя и винаги трябва да знаете защо са настъпили определени промени.
- Поемете изпълнението на една от функциите. Буквално треперя, докато пиша това, защото тази точка крие много скрити опасности, но наистина не съм сигурен, че можете да изпълните точка #1 и точка #2, без да се ангажирате с внедряването на поне една функция. Като внедрите една от функциите сами, вие не само ще участвате активно в процеса на разработка, но и ще ви позволи периодично да превключвате от ролята на „Мениджър, който отговаря за всичко“ към ролята на „Човек, който отговаря за внедряването на едно на функциите.” Това смирено и непретенциозно отношение ще ви напомни за важността на малките решения.
- Още треперя цялата. Май вече някой ми вика: „Управителят, който се нагърби с изпълнението на функцията?! (И аз съм съгласен с него!) Да, все още сте мениджър, което означава, че трябва да е някаква малка функция, нали? Да, имате още много работа. Ако просто не можете да поемете изпълнението на функцията, тогава имам резервен съвет за вас: поправете някои грешки. В този случай няма да почувствате радостта от създаването, но ще имате разбиране за това как се създава продуктът, което означава, че никога няма да останете без работа.
- Напишете единични тестове. Все още правя това в края на производствения цикъл, когато хората започнат да полудяват. Мислете за това като за контролен списък за здравето на вашия продукт. Правете това често.
Отново възражение?
„Рандс, ако напиша код, ще объркам екипа си. Те няма да знаят кой съм – мениджър или разработчик.“
Добре.
Да, казах "Добре!" Радвам се, че мислиш, че можеш да объркаш екипа си само като плуваш в езерото за разработчици. Просто е: границите между различните роли в разработката на софтуер в момента са много размити. Момчетата от UI правят това, което най-общо може да се нарече JavaScript и CSS програмиране. Разработчиците научават все повече и повече за дизайна на потребителското изживяване. Хората комуникират помежду си и научават за бъгове, за кражба на код на други хора, а също и за факта, че няма основателна причина един мениджър да не участва в тази масивна, глобална, кръстосано опрашваща се информационна вакханалия.
Освен това, искате ли да бъдете част от екип, състоящ се от лесно заменяеми компоненти? Това не само ще направи екипа ви по-пъргав, но ще даде възможност на всеки член на екипа да види продукта и компанията от различни гледни точки. Как можеш да уважаваш Франк, спокойния човек, който отговаря за компилациите, повече от след като видиш простата елегантност на неговите скриптове за компилации?
Не искам екипът ви да стане объркан и хаотичен. Напротив, искам вашият екип да комуникира по-ефективно. Вярвам, че ако участвате в създаването на продукта и работите върху функции, ще бъдете по-близо до вашия екип. И което е по-важно, ще бъдете по-близо до постоянни промени в процеса на разработка на софтуер във вашата организация.
Не спирайте да се развивате
Един мой колега от Borland веднъж ме нападна устно, че я нарекох „кодер“.
„Рандс, кодерът е безсмислена машина! Маймуна! Кодерът не прави нищо важно, освен да пише скучни редове безполезен код. Аз не съм програмист, аз съм разработчик на софтуер!“
Тя беше права, щеше да намрази първоначалния ми съвет към новите изпълнителни директори: „Спрете да пишете код!“ Не защото предполагам, че са програмисти, а повече защото проактивно предлагам да започнат да пренебрегват една от най-важните части на работата си: разработката на софтуер.
Така че актуализирах съвета си. Ако искате да бъдете добър лидер, можете да спрете да пишете код, но...
Бъдете гъвкави. Помнете какво означава да си инженер и не спирай да разработваш софтуер.
За автора
Майкъл Лоп е ветеран разработчик на софтуер, който все още не е напуснал Силиконовата долина. През последните 20 години Майкъл е работил за различни иновативни компании, включително Apple, Netscape, Symantec, Borland, Palantir, Pinterest, а също така е участвал в стартиране, което бавно изплува в забрава.
Извън работата си Майкъл води популярен блог за технологиите и управлението под псевдонима Рандс, където обсъжда идеи в областта на управлението с читатели, изразява загриженост относно постоянната необходимост да държи пръста си на пулса и обяснява, че въпреки щедри награди за създаване на продукт, вашият успех е възможен само благодарение на вашия екип. Блогът може да намерите тук .
Майкъл живее със семейството си в Редууд, Калифорния. Винаги намира време да кара планинско колело, да играе хокей и да пие червено вино, тъй като да си здрав е по-важно от това да си зает.
» За повече информация относно книгата, моля посетете
»
»
За Khabrozhiteli 20% отстъпка от купона - Управление на хора
При заплащане на хартиената версия на книгата, електронна версия на книгата ще бъде изпратена по имейл.
PS: 7% от цената на книгата ще отидат за превод на нови компютърни книги, списък на книгите, предадени на печатницата .
Източник: www.habr.com