Посвећено пројектним менаџерима (и онима који сањају да постану шефови).
Писање тона кода је тешко, али управљање људима је још теже! Дакле, ова књига вам је потребна само да научите како да радите обоје.
Да ли је могуће комбиновати смешне приче и озбиљне лекције? Мајкл Лоп (у уским круговима познат и као Рандс) је успео. Пронаћи ћете измишљене приче о измишљеним људима са невероватно корисним (иако измишљеним) искуствима. Овако Рандс дели своја разнолика, понекад чудна искуства стечена током година рада у великим ИТ корпорацијама: Аппле, Пинтерест, Палантир, Нетсцапе, Симантец, итд.
Да ли сте менаџер пројекта? Или желите да разумете шта ваш проклети шеф ради цео дан? Рандс ће вас научити како да преживите у Токсичном свету надуваних ћурака и напредујете у општем лудилу дисфункционално блиставих људи. У овој чудној заједници манијакалних паметњака постоје још чуднија створења - менаџери који су мистичним организационим ритуалом стекли власт над плановима, мислима и банковним рачунима многих људи.
Ова књига није налик било ком рукопису руковођења или руковођења. Мајкл Лоп ништа не крије, само прича онако како јесте (можда не треба све приче јавно објавити: П). Али само тако ћете разумети како да преживите са таквим шефом, како да управљате штреберима и штреберима и како да „тај проклети пројекат“ доведете до срећног краја!
Извод. Инжењерски менталитет
Размишљања о: Да ли треба да наставите да пишете код?
Рандсова књига о правилима за менаџере садржи веома кратку листу савремених менаџерских „обавезних обавеза“. Лаконизам ове листе произилази из чињенице да је концепт „мора“ нека врста апсолута, а када су људи у питању, апсолутних појмова је врло мало. Успешан метод управљања за једног запосленог биће права катастрофа за другог. Ова мисао је прва ставка на менаџеровој листи „обавезних задатака“:
Останите флексибилни!
Мислити да већ све знате је веома лоша идеја. У ситуацији када је једина стална чињеница да се свет непрестано мења, флексибилност постаје једина исправна позиција.
Парадоксално, друга ставка на листи је изненађујуће нефлексибилна. Међутим, ова тачка је мој лични фаворит јер верујем да помаже у стварању темеља за менаџерски раст. Овај параграф гласи:
Престани да пишеш код!
У теорији, ако желите да будете менаџер, морате научити да верујете онима који раде за вас и да им у потпуности предате кодирање. Овај савет је обично тешко сварљив, посебно за новопечене менаџере. Вероватно је један од разлога зашто су постали менаџери због њихове продуктивности у развоју, а када ствари крену наопако, њихова прва реакција је да се врате вештинама у које имају пуно поверење, а то је њихова способност да пишу код.
Када видим да новопечени менаџер „тоне” у писање кода, кажем му: „Знамо да умеш да пишеш код. Питање је: можете ли да водите? Више нисте одговорни само за себе, одговорни сте за цео тим; и желим да будем сигуран да можете натерати свој тим да самостално решава проблеме, а да не морате сами да пишете код. Ваш посао је да схватите како да се скалирате. Не желим да будеш само један, желим да буде много попут тебе.”
Добар савет, зар не? Скала. Менаџмент. Одговорност. Такве уобичајене речи. Штета што је савет погрешан.
Неисправан?
Да. Савет је погрешан! Не потпуно погрешно, али довољно погрешно да сам морао да позовем неке бивше колеге и да се извиним: „Сећате се оне моје омиљене изјаве о томе како треба да престанете да пишете код? То је погрешно! Да... Почните поново да програмирате. Почните са Питхон-ом и Руби-јем. Да, озбиљан сам! Ваша каријера зависи од тога!”
Када сам започео своју каријеру као програмер софтвера у Борланду, радио сам у Парадок Виндовс тиму, који је био огроман тим. Било је само 13 програмера апликација. Ако додате људе из других тимова који су такође константно радили на кључним технологијама за овај пројекат, као што су језгро базе података и основне апликације, добићете 50 инжењера директно укључених у развој овог производа.
Ниједан други тим за који сам икада радио није ни близу ове величине. Заправо, сваке године се постепено смањује број људи у тиму у којем радим. Шта се дешава? Да ли смо ми програмери заједно све паметнији и паметнији? Не, ми само делимо терет.
Шта су програмери радили последњих 20 година? За то време смо написали гомилу кода. Море кода! Написали смо толико кода да смо одлучили да би било добро да све поједноставимо и идемо на отворени код.
На срећу, захваљујући Интернету, овај процес је сада постао што једноставнији. Ако сте програмер софтвера, можете то проверити одмах! Претражите своје име на Гуглу или Гитхубу и видећете код на који сте одавно заборавили, али који свако може да пронађе. Страшно, зар не? Зар нисте знали да тај код живи заувек? Да, он живи вечно.
Код живи заувек. А добар код не само да живи вечно, већ и расте јер они који га цене стално се старају да остане свеж. Ова гомила висококвалитетног, добро одржаваног кода помаже у смањењу просечне величине инжењерског тима јер нам омогућава да се фокусирамо на постојећи код уместо на писање новог кода, и да посао обавимо са мање људи иу краћем временском оквиру.
Ова линија резоновања звучи депресивно, али идеја је да смо сви ми само гомила интеграционих аутомата који користе љепљиву траку за повезивање различитих дијелова постојећих ствари заједно како бисмо створили мало другачију верзију исте ствари. Ово је класична линија размишљања међу вишим руководиоцима који воле оутсоурцинг. „Свако ко зна да користи Гугл и има лепљиву траку може ово да уради! Зашто онда плаћамо много новца за наше машине?"
Плаћамо ове момке из менаџмента заиста велике паре, али они мисле такве глупости. Још једном, моја кључна поента је да на нашој планети постоји много бриљантних и веома вредних програмера; они су заиста бриљантни и вредни, иако нису провели ни минут седећи на акредитованим универзитетима. О да, сада их је све више!
Не предлажем да почнете да бринете о свом месту само зато што га неки сјајни другови наводно траже. Предлажем да почнете да бринете о томе јер се еволуција развоја софтвера вероватно креће брже од вас. Радите десет година, од тога пет као менаџер, и мислите: „Већ знам како се софтвер развија. Да, знаш. Здраво…
Престани да пишеш код, али...
Ако следите мој оригинални савет и престанете да пишете код, такође ћете добровољно престати да учествујете у процесу креирања. Из тог разлога не користим активно оутсоурцинг. Аутомати не стварају, они производе. Добро осмишљени процеси штеде много новца, али не доносе ништа ново у наш свет.
Ако имате мали тим који ради много за мало новца, онда ми идеја да престанете да пишете код изгледа као лоша одлука у каријери. Чак и у монструозним компанијама са њиховим бескрајним прописима, процесима и политикама, немате право да заборавите како сами да развијате софтвер. А развој софтвера се стално мења. Тренутно се мења. Под ногама! У овој секунди!
Имате примедбе. Разумети. Послушајмо.
„Рандс, на путу сам до директорске фотеље! Ако наставим да пишем код, нико неће веровати да могу да растем.”
Желим да вас питам следеће: откако сте седели у својој столици „Ускоро ћу да будем извршни директор!”, да ли сте приметили да се пејзаж развоја софтвера мења, чак и унутар ваше компаније? Ако је ваш одговор потврдан, онда ћу вам поставити још једно питање: како се то тачно мења и шта ћете учинити у вези са тим променама? Ако сте одговорили са „не“ на моје прво питање, онда морате да пређете на другу столицу, јер (кладим се!) поље развоја софтвера се мења у овом тренутку. Како ћете икада расти ако полако али сигурно заборавите како се развија софтвер?
Мој савет је да се не обавезујете на имплементацију тона функција за ваш следећи производ. Морате стално да предузимате кораке да бисте остали у току са начином на који ваш тим гради софтвер. То можете да радите и као директор и као потпредседник. Нешто друго?
„Уф, Рандс! Али неко мора да буде арбитар! Неко мора да види ширу слику. Ако напишем код, изгубићу перспективу."
И даље морате да будете судија, још увек морате да преносите одлуке, и још увек морате да обиђете зграду четири пута сваког понедељка ујутру са једним од својих инжењера да бисте слушали његову недељну поруку „Сви смо осуђени на пропаст“ за 30 минута. ! Али поред свега тога, морате да задржите инжењерски начин размишљања и не морате да будете програмер са пуним радним временом да бисте то урадили.
Моји савети за одржавање инжењерског менталитета:
- Користите развојно окружење. То значи да бисте требали бити упознати са алатима вашег тима, укључујући систем за прављење кода, контролу верзија и програмски језик. Као резултат тога, постаћете течни језиком који ваш тим користи када говори о развоју производа. Ово ће вам такође омогућити да наставите да користите свој омиљени уређивач текста, који савршено функционише.
- Морате бити у могућности да нацртате детаљан архитектонски дијаграм који описује ваш производ на било којој површини у било које време. Не мислим на поједностављену верзију са три ћелије и две стрелице. Морате знати детаљан дијаграм производа. Онај најтежи. Не било какав сладак дијаграм, већ дијаграм који је тешко објаснити. То би требало да буде мапа погодна за потпуно разумевање производа. Она се стално мења и увек треба да знате зашто је дошло до одређених промена.
- Преузми спровођење једне од функција. Буквално се трзам док ово пишем јер ова тачка има много скривених опасности, али заиста нисам сигуран да можете постићи тачку #1 и тачку #2 без обавезивања да ћете имплементирати барем једну функцију. Ако сами имплементирате једну од функција, не само да ћете бити активно укључени у процес развоја, већ ће вам такође омогућити да повремено прелазите са улоге „Менаџера који је задужен за све“ на улогу „Човека задуженог за имплементацију једне од функција“. функција.” Овај скроман и скроман став подсетиће вас на важност малих одлука.
- Још увек се тресем. Чини се да ми већ неко виче: „Менаџер који је на себе преузео спровођење функције?! (И слажем се са њим!) Да, ти си још увек менаџер, што значи да би то требало да буде нека мала функција, у реду? Да, имате још много посла. Ако једноставно не можете да преузмете имплементацију функције, онда имам резервни савет за вас: поправите неке грешке. У овом случају нећете осетити радост стварања, али ћете разумети како производ настаје, што значи да никада нећете остати без посла.
- Напишите јединичне тестове. Још увек то радим касно у производном циклусу када људи почну да лудују. Размислите о томе као о здравственој контролној листи за ваш производ. Радите ово често.
Опет приговор?
„Рандс, ако напишем код, збунићу свој тим. Неће знати ко сам - менаџер или програмер."
У реду.
Да, рекао сам, "У реду!" Драго ми је што мислите да можете збунити свој тим само пливањем у рибњаку за развијање. Једноставно је: границе између различитих улога у развоју софтвера су тренутно веома замагљене. УИ момци раде оно што се широко може назвати ЈаваСцрипт и ЦСС програмирањем. Програмери уче све више о дизајну корисничког искуства. Људи комуницирају једни са другима и уче о грешкама, о крађи туђег кода, а такође и о томе да нема доброг разлога да менаџер не учествује у овој масовној, глобалној, унакрсној информацијској вакханалији.
Осим тога, да ли желите да будете део тима који се састоји од лако заменљивих компоненти? Ово неће само учинити ваш тим окретнијим, већ ће сваком члану тима дати прилику да види производ и компанију из различитих перспектива. Како можете почети да поштујете Френка, мирног момка задуженог за градње, више него након што видите једноставну елеганцију његових скрипта за израду?
Не желим да ваш тим постане збуњен и хаотичан. Напротив, желим да ваш тим ефикасније комуницира. Верујем да ћете, ако сте укључени у креирање производа и рад на функцијама, бити ближи свом тиму. И што је још важније, бићете ближе сталним променама у процесу развоја софтвера унутар ваше организације.
Немојте престати да се развијате
Једна моја колегиница у Борланду ме је једном вербално напала јер сам је назвао „кодером“.
„Рандс, кодер је безумна машина! Мајмун! Кодер не ради ништа важно осим што пише досадне линије бескорисног кода. Ја нисам кодер, ја сам програмер софтвера!"
Била је у праву, мрзела би мој почетни савет новим извршним директорима: „Престаните да пишете код!“ Не зато што сугеришем да су они кодери, већ више зато што проактивно предлажем да почну да игноришу један од најважнијих делова свог посла: развој софтвера.
Тако да сам ажурирао свој савет. Ако желите да будете добар вођа, можете престати да пишете код, али...
Бити флексибилан. Запамтите шта значи бити инжењер и немојте престати да развијате софтвер.
О аутору
Мајкл Лоп је ветеран софтвера који још увек није напустио Силиконску долину. Током протеклих 20 година, Мајкл је радио за разне иновативне компаније, укључујући Аппле, Нетсцапе, Симантец, Борланд, Палантир, Пинтерест, а такође је учествовао у стартапу који је полако одлетео у заборав.
Ван посла, Мајкл води популарни блог о технологији и менаџменту под псеудонимом Рандс, где са читаоцима разговара о идејама из области менаџмента, изражава забринутост због сталне потребе да држи прст на пулсу и објашњава да, упркос великодушне награде за креирање производа, ваш успех је могућ само захваљујући вашем тиму. Блог се може наћи овде .
Мајкл живи са породицом у Редвуду у Калифорнији. Увек нађе времена да се бави брдским бициклом, игра хокеј и пије црно вино, јер је важније бити здрав од посла.
» Више детаља о књизи можете пронаћи на
»
»
За Кхаброзхителеи 20% попуста користећи купон - Управљати људима
По уплати папирне верзије књиге, електронска верзија књиге биће послата е-поштом.
ПС: 7% од цене књиге иде на превод нових компјутерских књига, списак књига предатих у штампарију .
Извор: ввв.хабр.цом