Тим Листър - съавтор на книги
- „Човешки фактор. Успешни проекти и екипи“ (оригиналната книга се казва „Peopleware“)
- „Валс с мечките: управление на риска в софтуерни проекти“
- „Побъркани от адреналин и зомбирани от модели. Модели на поведение на проектните екипи"
Всички тези книги са класика в своята област и са написани съвместно с колеги в . В Русия неговите колеги са най-известни - и , който също е написал много известни произведения.
Тим има 40 години опит в разработката на софтуер; през 1975 г. (нито един от тези, които са написали този хабрапост не е роден тази година), Тим вече е бил изпълнителен вицепрезидент на Yourdon Inc. Сега той прекарва времето си в консултации, преподаване и писане, като от време на време посещава конференции по света.
Направихме интервю с Тим Листър специално за Хабр. Той ще открие конференцията DevOops 2019 и имаме много въпроси относно книги и други. Интервюто водят Михаил Дружинин и Олег Чирухин от програмния комитет на конференцията.
Майкъл: Можете ли да кажете няколко думи за това, което правите сега?
Тим: Аз съм ръководител на Гилдията на атлантическите системи. Шестима сме в Гилдията, наричаме се принципали. Три в САЩ и три в Европа - затова Гилдията се нарича Атлантическа. Толкова години сме заедно, че не можеш да ги преброиш. Всички имаме своите специалитети. Работя с клиенти през последното десетилетие или повече. Моите проекти включват не само управление, но и определяне на изисквания, планиране на проекти и оценка. Изглежда, че проектите, които започват зле, обикновено завършват зле. Затова си струва да се уверите, че всички дейности са наистина добре обмислени и координирани, че идеите на създателите са комбинирани. Струва си да помислите какво правите и защо. Какви стратегии да използвате, за да доведете проекта до завършване.
От много години консултирам клиенти по различни начини. Интересен пример е компания, която произвежда роботи за операции на коляно и тазобедрена става. Хирургът не оперира напълно самостоятелно, а използва робот. Безопасността тук, честно казано, е важна. Но когато се опитвате да обсъждате изисквания с хора, които са фокусирани върху решаването на проблеми... Ще прозвучи странно, но в САЩ има (Федерална администрация по лекарствата), която лицензира продукти като тези роботи. Преди да продадете нещо и да го използвате върху живи хора, трябва да получите лиценз. Едно от условията е да покажете вашите изисквания, какви са тестовете, как сте ги тествали, какви са резултатите от тестовете. Ако промените изискванията, тогава трябва да преминете през целия този огромен процес на тестване отново и отново. Нашите клиенти успяха да включат визуален дизайн на приложенията в своите изисквания. Имаха екранни снимки директно като част от изискванията. Трябва да ги извадим и да обясним, че в по-голямата си част всички тези програми не знаят нищо за коленете и бедрата, всички тези неща с камерата и т.н. Трябва да пренапишем документите с изискванията, така че те никога да не се променят, освен ако не се променят някои наистина важни основни условия. Ако визуалният дизайн не е в изискванията, актуализирането на продукта ще бъде много по-бързо. Нашата работа е да намерим тези елементи, които се занимават с операции на коляно, тазобедрени стави, гръб, да ги извадим в отделни документи и да кажем, че това ще бъдат основните изисквания. Нека направим изолирана група изисквания за операции на коляното. Това ще ни позволи да изградим по-стабилен набор от изисквания. Ще говорим за цялата продуктова линия, а не за конкретни роботи.
Беше свършена много работа, но те все пак стигнаха до места, където преди това прекарваха седмици и месеци на повтарящи се тестове без смисъл и нужда, защото техните изисквания, описани на хартия, не съвпадаха с реалните изисквания, за които са изградени системите. FDA им казваше всеки път: вашите изисквания са се променили, сега трябва да проверите всичко от нулата. Пълните повторни проверки на целия продукт убиваха предприятието.
И така, има толкова прекрасни задачи, когато се окажете в самото начало на нещо интересно и още първите действия определят по-нататъшните правила на играта. Ако се уверите, че тази ранна дейност започва да работи добре както от управленска, така и от техническа гледна точка, има шанс да завършите със страхотен проект. Но ако тази част е излязла извън релсите и се е объркала някъде, ако не можете да намерите фундаменталните споразумения... не, не че проектът ви непременно ще се провали. Но вече няма да можете да кажете: „Справихме се страхотно, направихме всичко наистина ефективно.“ Това са нещата, които правя, когато общувам с клиенти.
Майкъл: Тоест стартирате проекти, правите някакъв начален удар и проверявате дали релсите вървят в правилната посока?
Тим: Имаме и идеи как да сглобим всички парчета от пъзела: какви умения са ни необходими, кога точно са необходими, как изглежда ядрото на екипа и други подобни фундаментални неща. Имаме ли нужда от служители на пълен работен ден или можем да наемем някой на непълен работен ден? Планиране, управление. Въпроси като: Какво е най-важно за този конкретен проект? Как да постигнете това? Какво знаем за този продукт или проект, какви са рисковете и къде са неизвестните, как ще се справим с всичко това? Разбира се, в този момент някой започва да крещи "Ами пъргави?!" Добре, всички сте гъвкави, но какво от това? Как точно изглежда проектът, как ще го изведете по начин, който отговаря на проекта? Не можете просто да кажете, че „нашият подход се простира до всичко, ние сме Scrum екип!“ Това са глупости и глупости. Къде ще отидете след това, защо трябва да работи, къде е смисълът? Уча клиентите си да мислят за всички тези въпроси.
19 години пъргав
Майкъл: В Agile хората често се опитват да не дефинират нищо предварително, а да вземат решения възможно най-късно, казвайки: твърде големи сме, няма да мисля за цялостната архитектура. Няма да мисля за куп други неща, вместо това ще доставя нещо, което работи на клиента точно сега.
Тим: Мисля, че гъвкавите методологии, като се започне с през 2001 г. отвори очите на индустрията. Но от друга страна нищо не е перфектно. Аз съм изцяло за итеративно развитие. Итерацията има много смисъл в повечето проекти. Но въпросът, върху който трябва да помислите, е: след като продуктът излезе и се използва, колко дълго издържа? Това продукт ли е, който ще издържи шест месеца, преди да бъде заменен с нещо друго? Или това е продукт, който ще работи много, много години? Разбира се, няма да назовавам имена, но... В Ню Йорк и неговата финансова общност най-фундаменталните системи са много стари. Това е невероятно. Гледате ги и си мислите, само ако можехте да се върнете назад във времето, до 1994 г., и да кажете на разработчиците: „Дойдох от бъдещето, от 2019 г. Просто развивайте тази система толкова дълго, колкото ви е необходимо. Направете го разширяем, помислете за архитектурата. След това ще се подобрява повече от двадесет и пет години. Ако забавите развитието още малко, в голямата схема на нещата никой няма да забележи!“ Когато оценявате нещата в дългосрочен план, трябва да вземете предвид колко ще струва общо. Понякога добре проектираната архитектура наистина си заслужава, а понякога не. Трябва да се огледаме и да се запитаме: дали сме в правилната ситуация за такова решение?
Така че идея като „Ние сме за agile, клиентът сам ще ни каже какво иска да получи“ е супер наивна. Клиентите дори не знаят какво искат и още повече не знаят какво могат да получат. Някои хора ще започнат да цитират исторически примери като аргументи, това вече го видях. Но технически напредналите хора обикновено не казват това. Те казват: „2019 г. е, това са възможностите, които имаме, и можем напълно да променим начина, по който гледаме на тези неща!“ Вместо да имитирате съществуващи решения, като ги правите малко по-красиви и по-сресани, понякога трябва да излезете и да кажете: „Нека напълно преоткрием това, което се опитваме да направим тук!“
И не мисля, че повечето клиенти могат да мислят за проблема по този начин. Те виждат само това, което вече имат, това е всичко. След което идват с молби като „нека направим това малко по-просто“ или каквото там обикновено казват. Но ние не сме сервитьори или сервитьорки, така че можем да вземем поръчка, колкото и глупава да се окаже, и след това да я изпечем в кухнята. Ние сме техните водачи. Трябва да им отворим очите и да кажем: хей, тук имаме нови възможности! Осъзнавате ли, че наистина можем да променим начина, по който се извършва тази част от вашия бизнес? Един от проблемите с Agile е, че премахва осъзнаването на това какво е възможност, какво е проблем, какво дори трябва да направим, какви налични технологии са най-подходящи за тази конкретна ситуация.
Може би съм твърде скептичен тук: има много прекрасни неща, които се случват в гъвкавата общност. Но имам проблем с това, че вместо да дефинират проект, хората започват да вдигат ръце. Тук бих попитал - какво правим, как ще го направим? И някак магически винаги се оказва, че клиентът трябва да знае по-добре от всеки друг. Но клиентът знае най-добре само когато избира от вече построени от някого неща. Ако искам да си купя кола и знам размера на семейния си бюджет, тогава бързо ще избера кола, която отговаря на начина ми на живот. Тук знам всичко по-добре от всеки друг! Но имайте предвид, че някой вече е направил колите. Нямам идея как да измисля нова кола, не съм експерт. Когато създаваме персонализирани или специални продукти, гласът на клиента трябва да бъде взет предвид, но това вече не е единственият глас.
Олег: Споменахте Agile манифеста. Трябва ли по някакъв начин да го актуализираме или преработим, като вземем предвид съвременното разбиране на проблема?
Тим: Не бих го докоснал. Мисля, че това е страхотен исторически документ. Искам да кажа, той е това, което е. Той става на 19 години, стар е, но навремето направи революция. Това, което направи добре, беше, че предизвика реакция и хората започнаха да шушукат за него. Вие най-вероятно все още не сте работили в индустрията през 2001 г., но тогава всички работеха според процесите. Институт за софтуерно инженерство, пет нива на модела за пълнота на софтуера (CMMI). Не знам дали подобни легенди от дълбока древност ви казват нещо, но тогава това беше пробив. Първоначално хората вярваха, че ако процесите са настроени правилно, тогава проблемите ще изчезнат сами. И тогава Манифестът се появява и казва: „Не, не, не – ще се базираме на хора, а не на процеси.“ Ние сме майстори в разработката на софтуер. Разбираме, че идеалният процес е мираж, той не се случва. Има твърде много идиосинкразия в проектите, идеята за един перфектен процес за всички проекти няма никакъв смисъл. Проблемите са твърде сложни, за да се твърди, че има само едно решение за всичко (здравей, нирвана).
Не се наемам да гледам в бъдещето, но ще кажа, че хората вече започнаха да мислят повече за проекти. Мисля, че Agile Manifesto е много добър в изскачането и казването: „Хей! Вие сте на кораб и вие самият управлявате този кораб. Ще трябва да вземете решение - ние няма да предложим универсална рецепта за всички ситуации. Вие сте екипажът на кораба и ако сте достатъчно добър, можете да намерите път към целта. Имаше други кораби преди вас и ще има други кораби след вас, но все пак в известен смисъл вашето пътуване е уникално. Нещо такова! Това е начин на мислене. За мен няма нищо ново под слънцето, хората са плавали преди и ще плават отново, но за вас това е основното ви пътуване и няма да ви кажа какво точно ще ви се случи. Трябва да имате умения за координирана работа в екип и ако наистина ги притежавате, всичко ще се получи и ще стигнете там, където искате.
Peopleware: 30 години по-късно
Олег: Беше ли Peopleware революция, както и Манифеста?
Тим: Peopleware... Том и аз написахме тази книга, но не мислехме, че ще се случи по този начин. По някакъв начин това резонира с идеите на много хора. Това беше първата книга, която казва: разработването на софтуер е много интензивна човешка дейност. Въпреки нашия технически характер, ние също сме общност от хора, които изграждат нещо голямо, дори огромно, много сложно. Никой не може да създаде такива неща сам, нали? Така че идеята за "отбор" стана много важна. И не само от управленска гледна точка, но и за технически хора, които се събраха, за да решат наистина сложни дълбоки проблеми с куп неизвестни. За мен лично това беше огромен тест за интелигентност през цялата ми кариера. И тук трябва да можете да кажете: да, този проблем е повече, отколкото мога да се справя сам, но заедно можем да намерим елегантно решение, с което да се гордеем. И мисля, че тази идея получи най-голям отзвук. Идеята, че работим част от времето сами, част от времето като част от група и често решението се взема от групата. Груповото решаване на проблеми бързо се превърна във важна характеристика на сложните проекти.
Въпреки факта, че Тим е изнесъл огромен брой лекции, много малко от тях са публикувани в YouTube. Можете да разгледате доклада „Завръщането на Peopleware” от 2007 г. Качеството, разбира се, оставя много да се желае.
Майкъл: Промени ли се нещо през последните 30 години от издаването на книгата?
Тим: Можете да погледнете на това от много различни ъгли. Социологически казано... едно време, в по-прости времена, вие и вашият екип сте седели в един и същи офис. Може да сте близо всеки ден, да пиете кафе заедно и да обсъждате работа. Това, което наистина се промени, е, че екипите вече могат да бъдат разпределени географски, в различни държави и часови зони, но все още работят върху един и същ проблем и това добавя изцяло нов слой сложност. Това може да звучи старомодно, но няма нищо като комуникация лице в лице, когато всички сте заедно, работите заедно и можете да отидете до колега и да кажете, вижте какво открих, как ви харесва това? Разговорите лице в лице осигуряват бърз начин за преминаване към неформална комуникация и мисля, че ентусиастите с гъвкавост също трябва да ги харесат. Освен това се притеснявам, защото в действителност светът се оказа много малък и сега целият е покрит с разпределени екипи и всичко е много сложно.
Всички живеем в DevOps
Майкъл: Дори от гледна точка на програмния комитет на конференцията имаме хора в Калифорния, в Ню Йорк, Европа, Русия... в Сингапур все още няма никой. Разликата в географията е доста голяма и хората започват да се пръскат още повече. Ако говорим за развитие, можете ли да ни кажете повече за devops и премахването на бариерите между екипите? Има концепция, че всеки си седи в бункерите, а сега бункерите се рушат, какво мислите за тази аналогия?
Тим: Струва ми се, че в светлината на последните технологични пробиви devops е от голямо значение. Преди това имахте екипи от разработчици и администратори, те работеха, работеха, работеха и в един момент се появи нещо, с което можете да отидете при администраторите и да го пуснете за производство. И тук започна разговорът за бункера, защото админите са нещо като съюзници, поне не врагове, но с тях се говори едва когато всичко е готово за производство. Отидохте ли при тях с нещо и казахте: вижте какво приложение имаме, но можете ли да пуснете това приложение? И сега цялата концепция за доставка се промени към по-добро. Искам да кажа, имаше тази идея, че можете бързо да прокарате промените. Можем да актуализираме продуктите в движение. Винаги се усмихвам, когато Firefox на моя лаптоп изскача и казва, хей, актуализирахме вашия Firefox във фонов режим и щом имате минута, бихте ли щракнете тук и ще ви дадем най-новата версия. И аз си казах: „О, да, скъпа!“ Докато спях, те работеха върху това да ми доставят ново издание на компютъра ми. Това е прекрасно, невероятно.
Но тук е трудността: имате тази функция с актуализирането на софтуера, но интегрирането на хора е много по-трудно. Това, което искам да кажа в основната бележка на DevOops, е, че сега имаме много повече играчи, отколкото някога сме имали. Ако просто помислите за всички, участващи в един отбор... Мислехте за това като за екип, а това е много повече от просто екип от програмисти. Това са тестери, ръководители на проекти и куп други хора. И всеки има свои собствени виждания за света. Продуктовите мениджъри са напълно различни от ръководителите на проекти. Администраторите имат свои собствени задачи. Става доста труден проблем да се координират всички участници, за да продължат да са наясно какво се случва и да не полудеят. Необходимо е да се разделят задачите на групата и задачите, които се отнасят за всички. Това е много трудна задача. От друга страна, мисля, че всичко е много по-добре, отколкото беше преди много години. Точно това е пътят, по който хората растат и се учат да се държат правилно. Когато правите интеграция, разбирате, че не трябва да има подземно развитие, така че в последния момент софтуерът да не изпълзи като жак в кутията: вижте какво направихме тук! Идеята е, че ще можете да правите интегриране и развитие и накрая ще се разгръщате по чист и итеративен начин. Всичко това означава много за мен. Това прави възможно създаването на повече стойност за потребителите на системата и за вашия клиент.
Майкъл: Цялата идея на devops е да предостави значими разработки възможно най-рано. Виждам, че светът започна да се ускорява все повече и повече. Как да се адаптираме към такива ускорения? Преди десет години това не съществуваше!
Тим: Разбира се, всеки иска повече и повече функционалност. Няма нужда да се движите, просто натрупайте повече. Понякога дори трябва да забавите скоростта за следващата инкрементална актуализация, за да донесете нещо полезно - и това е напълно нормално.
Идеята, че трябва да бягате, бягате, бягате, не е най-добрата. Малко вероятно е някой да иска да живее живота си така. Бих искал ритъмът на доставките да определя собствения ритъм на проекта. Ако просто създадете поток от малки, относително безсмислени неща, всичко това няма смисъл. Вместо безсмислено да се опитвате да пуснете нещата възможно най-рано, това, което си струва да обсъдите с водещите разработчици и мениджъри на продукти и проекти, е стратегията. Това изобщо има ли смисъл?
Модели и антимодели
Олег: Обикновено говорите за модели и антимодели и това е разликата между живота и смъртта на проектите. И сега devops нахлува в живота ни. Има ли някакви свои собствени модели и анти-модели, които могат да убият проекта на място?
Тим: Модели и анти-модели се случват през цялото време. Нещо за разговор. Е, има нещо, което наричаме "лъскави неща". Хората наистина, наистина харесват новите технологии. Те просто са хипнотизирани от блясъка на всичко, което изглежда готино и стилно, и спират да задават въпроси: нужно ли е изобщо? Какво ще постигнем? Надеждно ли е това нещо, има ли смисъл? Често виждам хора, така да се каже, на върха на технологиите. Те са хипнотизирани от това, което се случва в света. Но ако погледнете по-отблизо какви полезни неща правят, често просто няма нищо полезно!
Тъкмо обсъждахме с нашите другари, че тази година е юбилейна година, петдесет години от кацането на хората на Луната. Това беше през 1969 г. Технологията, която помогна на хората да стигнат до там, дори не е технология от 1969 г., а по-скоро от 1960 или 62 г., защото НАСА искаше да използва само това, което имаше добри доказателства за надеждност. И така го гледате и разбирате - да, и те бяха верни! Сега, не, не, но изпадате в проблеми с технологията, просто защото всичко се пробутва твърде силно, продава се от всички пукнатини. Хората крещят отвсякъде: „Виж какво нещо, това е най-новото нещо, най-красивото нещо на света, подходящо за абсолютно всеки!“ Е, това е... обикновено всичко това се оказва просто примамка и тогава всичко трябва да бъде изхвърлено. Може би всичко е, защото вече съм стар човек и гледам на такива неща с голяма доза скептицизъм, когато хората изтичат и казват, че са намерили Единствения, най-правилния начин за създаване на най-добрите технологии. В този момент в мен се събужда глас, който казва: “Каква бъркотия!”
Майкъл: Наистина, колко често сме чували за следващия сребърен куршум?
Тим: Точно така и това е обичайният ход на нещата! Например... изглежда, че това вече се превърна в шега по света, но тук често се говори за блокчейн технология. И те всъщност имат смисъл в определени ситуации! Когато наистина се нуждаете от надеждни доказателства за събития, че системата работи и че никой не ни е измамил, когато имате проблеми със сигурността и всички тези неща, смесени заедно - блокчейнът има смисъл. Но когато казват, че Blockchain сега ще помете целия свят, помитайки всичко по пътя си? Мечтайте повече! Това е много скъпа и сложна технология. Технически сложно и времеемко. Включително чисто алгоритмично, всеки път, когато трябва да преизчислявате математиката, с най-малки промени... и това е страхотна идея - но само за определени случаи. Целият ми живот и кариера са свързани с това: интересни идеи в много специфични ситуации. Много е важно да разберете точно каква е вашата ситуация.
Майкъл: Да, основният „въпрос на живота, вселената и всичко останало“: подходяща ли е тази технология или подход за вашата ситуация или не?
Тим: Този въпрос вече може да бъде обсъден с технологичната група. Може дори да доведе някой консултант. Погледнете проекта и разберете - сега ще направим ли нещо правилно и полезно, по-добро от преди? Може би ще пасне, може би не. Но най-важното е, че не вземайте такова решение по подразбиране, просто защото някой избухна: „Ние отчаяно се нуждаем от блокчейн! Току-що прочетох за него в едно списание в самолета!“ Сериозно? Дори не е смешно.
Митичният „devops инженер“
Олег: Сега всички внедряват devops. Някой чете за devops в интернет, а утре се появява друга свободна позиция в сайт за набиране на персонал. "devops инженер". Тук бих искал да насоча вниманието ви: смятате ли, че терминът „devops инженер“ има право на живот? Има мнение, че devops е култура и тук нещо не се вписва.
Тим: Горе-долу. Нека веднага да дадат някакво обяснение на този термин. Нещо, което да го направи уникален. Докато не докажат, че има някаква уникална комбинация от умения зад вакантно място като това, няма да го купя! Искам да кажа, добре, имаме длъжност „инженер по devops“, интересна титла, да, какво следва? Общо взето длъжностите са много интересно нещо. Да кажем „разработчик“ – какво е това все пак? Различните организации означават напълно различни неща. В някои компании висококачествени програмисти пишат тестове, които имат повече смисъл от тестове, написани от специални професионални тестери в други компании. И какво, сега програмисти ли са или тестери?
Да, имаме длъжности, но ако задавате въпроси достатъчно дълго, в крайна сметка се оказва, че всички решаваме проблеми. Ние търсим решения и някои имат някои технически умения, а други имат различни. Ако живеете в среда, в която DevOps е проникнал, вие сте ангажирани с интегрирането на разработката и администрирането и тази дейност има доста важна цел. Но ако ви попитат какво точно правите и за какво отговаряте, оказва се, че хората са правили всички тези неща от незапомнени времена. „Аз отговарям за архитектурата“, „Аз отговарям за базите данни“ и така нататък, каквото и да е, нали разбирате – всичко това беше преди „devops“.
Когато някой ми каже длъжността си, всъщност не слушам много. По-добре е да го оставите да ви каже за какво всъщност е отговорен, това ще ни позволи да разберем проблема много по-добре. Любимият ми пример е, когато човек твърди, че е „мениджър на проекти“. Какво? Това не означава нищо, все още не знам какво правиш. Мениджърът на проекти може да бъде разработчик, ръководител на екип от четирима души, който пише код, върши работа, който е станал лидер на екипа, когото самите хора разпознават помежду си като лидер. Освен това ръководителят на проекти може да бъде мениджър, който управлява шестстотин души по проект, управлява други мениджъри, отговаря за изготвянето на графици и планирането на бюджети, това е всичко. Това са два напълно различни свята! Но длъжността им звучи по същия начин.
Нека обърнем това малко по-различно. В какво си наистина добър, имаш много опит, имаш ли талант? За какво ще поемете отговорност, защото смятате, че можете да се справите със задачата? И тук някой веднага ще започне да отрича: не, не, не, изобщо нямам желание да се занимавам с ресурси на проекта, това не е моя работа, аз съм технически пич и разбирам от използваемост и потребителски интерфейси, не разбирам искам изобщо да управлявам армии от хора, нека по-добре да отида на работа.
И между другото, аз съм голям привърженик на подход, при който този вид разделяне на уменията работи добре. Където техниците могат да развиват кариерата си доколкото желаят. Въпреки това все още виждам организации, в които техничарите се оплакват: ще трябва да отида в управлението на проекти, защото това е единственият начин в тази компания. Понякога това води до ужасни резултати. Най-добрите техници изобщо не са добри мениджъри и най-добрите мениджъри не могат да се справят с технологиите. Нека бъдем честни за това.
Виждам голямо търсене за това сега. Ако сте специалист в технологиите, вашата компания може да ви помогне, но независимо от това, вие трябва, наистина трябва да намерите своя собствена кариера, защото технологията непрекъснато се променя и вие трябва да преоткривате себе си заедно с нея! Само за двадесет години технологиите могат да се променят поне пет пъти. Странно нещо са технологиите...
„Експерти по всичко“
Майкъл: Как хората могат да се справят с такава скорост на технологичните промени? Тяхната сложност расте, броят им расте, общото количество комуникация между хората също расте и се оказва, че не можете да станете „експерт по всичко“.
Тим: вярно! Ако работите в областта на технологиите, да, определено трябва да изберете нещо конкретно и да се задълбочите в него. Някои технологии, които вашата организация намира за полезни (и може би наистина ще бъдат полезни). И ако вече не се интересувате от това - никога не бих повярвал, че ще кажа това - добре, може би трябва да се преместите в друга организация, където технологията е по-интересна или по-удобна за изучаване.
Но като цяло, да, прав си. Технологиите растат във всички посоки едновременно; никой не може да каже „Аз съм експерт технолог във всички технологии, които съществуват“. От друга страна има гюбеци, които буквално поглъщат технологично знание и са луди по него. Виждал съм няколко такива хора, те буквално дишат и живеят, полезно и интересно е да говоря с тях. Те изучават не само това, което се случва вътре в организацията, но като цяло, те говорят за това, те също са наистина готини технолози, те са много съзнателни и целеустремени. Те просто се опитват да останат на гребена на вълната, независимо каква е основната им работа, защото тяхната страст е движението на технологиите, насърчаването на технологиите. Ако внезапно срещнете такъв човек, трябва да отидете на обяд с него и да обсъдите различни готини неща по време на обяд. Мисля, че всяка организация се нуждае от поне няколко такива хора.
Рискове и несигурност
Майкъл: Заслужени инженери, да. Нека се докоснем до управлението на риска, докато имаме време. Започнахме това интервю с обсъждане на медицинския софтуер, където грешките могат да доведат до тежки последствия. Тогава говорихме за Лунната програма, където цената на една грешка е милиони долари, а вероятно и няколко човешки живота. Но сега виждам обратното движение в индустрията, хората не мислят за рисковете, не се опитват да ги предвидят, дори не ги наблюдават.
Олег: Движете се бързо и разбивайте нещата!
Майкъл: Да, движете се бързо, чупете неща, още и още неща, докато умрете от нещо. От ваша гледна точка, как обикновеният разработчик трябва да подходи към управлението на риска в обучението сега?
Тим: Нека теглим граница между две неща: рискове и несигурност. Това са различни неща. Несигурността възниква, когато нямате достатъчно данни във всеки даден момент, за да стигнете до окончателен отговор. Например, в много ранен етап на проект, ако някой ви попита „кога ще завършите работата“, ако сте доста честен човек, ще кажете: „Нямам представа“. Ти просто не знаеш и това е добре. Все още не сте проучили проблемите и не сте запознати с екипа, не познавате уменията им и т.н. Това е несигурност.
Рисковете възникват, когато потенциалните проблеми вече могат да бъдат идентифицирани. Такова нещо може да се случи, вероятността му е по-голяма от нула, но по-малка от сто процента, някъде по средата. Заради него може да се случи всичко – от забавяне и ненужна работа, та дори до фатален изход за проекта. Резултатът, като кажете - момчета, да сгъваме чадърите и да се махаме от плажа, никога няма да го довършим, всичко свърши и точка. Направихме предположението, че това нещо ще работи, но то изобщо не работи, време е да спрем. Това са ситуациите.
Често проблемите са най-лесни за разрешаване, когато вече са се появили, когато проблемът се случва точно сега. Но когато проблемът е точно пред вас, вие не управлявате риска – вие решавате проблеми, управлявате кризи. Ако сте водещ разработчик или мениджър, сигурно се чудите какво може да се случи, което да доведе до забавяне, загуба на време, ненужни разходи или крах на целия проект? Какво ще ни накара да спрем и да започнем отначало? Когато всички тези неща работят, какво ще правим с тях? Има прост отговор, който е валиден за повечето ситуации: не бягайте от рисковете, работете върху тях. Вижте как можете да разрешите рискова ситуация, да я сведете до нищо, да я превърнете от проблем в нещо друго. Вместо да казваме: добре, ще решаваме проблемите, когато възникнат.
Несигурността и рискът трябва да са в челните редици на всичко, с което се занимавате. Можете да вземете план на проекта, да разгледате определени критични рискове предварително и да кажете: трябва да се справим с това сега, защото ако нещо от това се обърка, нищо друго няма да има значение. Не трябва да се притеснявате за красотата на покривката на масата, ако не е ясно дали можете да готвите вечеря. Първо трябва да идентифицирате всички рискове от приготвянето на вкусна вечеря, да се справите с тях и едва след това да мислите за всички останали неща, които не представляват реална заплаха.
Отново, какво прави вашия проект уникален? Нека да видим какво може да накара нашия проект да излезе извън релсите. Какво можем да направим, за да сведем до минимум вероятността това да се случи? Обикновено не можете просто да ги неутрализирате на 100% и да заявите с чиста съвест: „Това е, това вече не е проблем, рискът е решен!“ За мен това е признак на поведение на възрастен. Това е разликата между дете и възрастен - децата си мислят, че са безсмъртни, че нищо не може да се обърка, всичко ще бъде наред! В същото време възрастните гледат как тригодишни деца скачат на детската площадка, следят движенията с очите си и си казват: „О-о-о, о-о-о“. Стоя наблизо и се приготвям да хвана, когато детето падне.
От друга страна, причината, поради която толкова много харесвам този бизнес, е, че е рискован. Правим неща и тези неща са рисковани. Те изискват подход на възрастен. Само ентусиазмът няма да реши проблемите ви!
Инженерно мислене на възрастни
Майкъл: Примерът с децата е добър. Ако съм обикновен инженер, тогава ми е приятно да съм дете. Но как да преминете към по-възрастно мислене?
Тим: Една от идеите, която работи еднакво добре както с начинаещ, така и с утвърден разработчик, е концепцията за контекст. Какво правим, какво ще постигнем. Какво е наистина важно в този проект? Няма значение кой сте в този проект, дали сте стажант или главен архитект, всеки има нужда от контекст. Трябва да накараме всеки да мисли в по-широк мащаб от собствените си произведения. „Правя своето парче и докато моето парче работи, аз съм щастлив.“ Не и пак не. Винаги си струва (без да сме груби!) да напомняме на хората за контекста, в който работят. Това, което всички се опитваме да постигнем заедно. Идеи, че можете да бъдете дете, стига всичко да е наред с вашата част от проекта - моля, не правете това. Ако изобщо пресечем финалната линия, ще я пресечем само заедно. Не си сам, всички сме заедно. Ако всички хора в проекта, и стари, и млади, започнат да говорят какво точно е важно за проекта, защо компанията инвестира пари в това, което всички ние се опитваме да постигнем... повечето от тях ще се почувстват много по-добре, защото ще видят как тяхната работа корелира с работата на всички останали. От една страна разбирам парчето, за което нося лична отговорност. Но за да завършим работата, имаме нужда и от всички други хора. И ако наистина смятате, че сте готови, винаги имаме работа за вършене в проекта!
Олег: Относително казано, ако работите според Kanban, когато попаднете на тясното място на някои тестове, можете да напуснете това, което правите там (например програмиране) и да отидете да помогнете на тестерите.
Тим: Точно. Мисля, че най-добрите техници, ако ги погледнете отблизо, те са един вид сами себе си мениджъри. Как мога да формулирам това...
Олег: Вашият живот е вашият проект, който управлявате.
Тим: Точно! Имам предвид, че поемате отговорност, разбирате проблема и влизате в контакт с хората, когато видите, че вашите решения могат да повлияят на работата им, подобни неща. Не става въпрос просто да седите на бюрото си, да си вършите работата и дори да не осъзнавате какво се случва около вас. Не не не. Между другото, едно от най-хубавите неща на Agile е, че предложиха кратки спринтове, защото по този начин състоянието на нещата на всички участници е ясно видимо, те могат да го видят всички заедно. Всеки ден си говорим един за друг.
Как да влезем в управлението на риска
Олег: Има ли някаква формална структура на знанието в тази област? Например, аз съм разработчик на Java и искам да разбирам управлението на риска, без да ставам истински ръководител на проекти по образование. Вероятно първо ще прочета "Колко струва един софтуерен проект" на Макконъл и после какво? Какви са първите стъпки?
Тим: Първият е да започнете да общувате с хората в проекта. Това осигурява незабавно подобряване на културата на общуване с колегите. Трябва да започнем, като отворим всичко по подразбиране, вместо да го скриваме. Кажете: това са нещата, които ме притесняват, това са нещата, които ме държат буден през нощта, днес се събудих през нощта и си казах: Боже мой, трябва да помисля за това! Дали другите виждат същото? Като група трябва ли да реагираме на тези потенциални проблеми? Трябва да можете да подкрепите дискусия по тези теми. Няма предварително изготвена формула, по която работим. Не става въпрос за правене на хамбургери, всичко е за хората. „Направих чийзбургер, продадох чийзбургер“ изобщо не ни харесва и затова толкова много обичам тази работа. Харесва ми, когато всичко, което мениджърите са правили, сега става собственост на екипа.
Олег: Говорили сте в книги и интервюта за това как хората се интересуват повече от щастието, отколкото от числата на графиката. От друга страна, когато кажете на екипа: преминаваме към devops и сега програмистът трябва постоянно да комуникира, това може да е далеч извън неговата зона на комфорт. И в този момент той може, да кажем, да е дълбоко нещастен. Какво да правим в тази ситуация?
Тим: Не съм сигурен какво точно да направя. Ако разработчикът е твърде изолиран, той не вижда защо работата се върши на първо място, те просто гледат своята част от работата и трябва да навлязат в това, което наричам „контекст“. Той трябва да разбере как всичко е свързано заедно. И разбира се, нямам предвид официални презентации или нещо подобно. Говоря за това, че трябва да общувате с колегите за работата като цяло, а не само за частта от нея, за която отговаряте. Това е мястото, където можете да започнете да обсъждате идеи, общи споразумения, за да направите работата си добре съвместима и как да се справите заедно с общ проблем.
За да им помогнат да се адаптират, те често искат да изпратят техници на обучение и обсъждат обучение. Един мой приятел обича да казва, че обучението е за кучета. Има обучение за хора. Едно от най-добрите неща при ученето като разработчик е взаимодействието с връстниците ви. Ако някой наистина е добър в нещо, трябва да го наблюдавате как работи или да говорите с него за работата му или нещо подобно. Някой конвенционален Кент Бек непрекъснато говореше за екстремно програмиране. Смешно е, защото XP е толкова проста идея, но причинява толкова много проблеми. За някои правенето на XP е като да бъдеш принуден да се съблечеш гол пред приятели. Ще видят какво правя! Те са ми колеги, не само ще видят, но и ще разберат! ужасно! Някои хора започват да се изнервят сериозно. Но когато осъзнаете, че това е най-добрият начин да научите, всичко се променя. Работите в тясно сътрудничество с хората и някои хора разбират темата много по-добре от вас.
Майкъл: Но всичко това ви кара да излезете от зоната си на комфорт. Като инженер трябва да излезете от зоната си на комфорт и да общувате. Като човек, който решава проблеми, трябва постоянно да се поставяте в слаба позиция и да мислите какво може да се обърка. Този тип работа по своята същност е предназначена да бъде неудобство. Вие съзнателно се поставяте в стресови ситуации. Обикновено хората бягат от тях, хората обичат да бъдат щастливи деца.
Тим: Какво може да се направи, можете да излезете и открито да кажете: „Всичко е наред, мога да се справя! Не съм единственият, който се чувства неудобно. Нека да обсъждаме различни неудобни неща, всички заедно, като екип!“ Това са ни общи проблеми, трябва да се справяме с тях, разбирате ли? Мисля, че идиосинкратичните гениални разработчици са като мамути, те изчезнаха. И тяхното значение е много ограничено. Ако не можете да общувате, не можете да участвате добре. Затова просто говорете. Бъдете честни и открити. Много съжалявам, че това е неприятно за някого. Представяте ли си, преди много години имаше проучване, според което основният страх в Съединените щати не е смъртта, а познайте какво? Страх от публично говорене! Това означава, че някъде има хора, които предпочитат да умрат, отколкото да кажат комплимент на глас. И мисля, че е достатъчно да имате някои основни умения, в зависимост от това какво правите. Умения за говорене, умения за писане - но само толкова, колкото наистина е необходимо в работата ви. Ако работите като анализатор, но не можете да четете, пишете или говорите, тогава, за съжаление, няма да имате какво да правите в моите проекти!
Цената на комуникацията
Олег: Наемането на такива напускащи служители не е ли по-скъпо по различни причини? В края на краищата те постоянно си чатят, вместо да работят!
Тим: Имах предвид ядрото на отбора, а не всички. Ако имате някой, който наистина е готин в настройването на бази данни, обича да настройва базите данни и ще продължи да настройва вашите бази данни до края на живота си и това е, страхотно, продължавайте в същия дух. Но аз говоря за хора, които искат да живеят в самия проект. Ядрото на екипа, насочен към развитието на проекта. Тези хора наистина имат нужда постоянно да общуват помежду си. И особено в началото на проекта, когато обсъждате рискове, начини за постигане на глобални цели и други подобни.
Майкъл: Това важи за всички, участващи в проекта, независимо от специализацията, уменията или начина на работа. Всички сте заинтересовани от успеха на проекта.
Тим: Да, чувствате, че сте достатъчно потопени в проекта, че задачата ви е да помогнете на проекта да се реализира. Независимо дали сте програмист, анализатор, дизайнер на интерфейси, всеки. Това е причината да идвам на работа всяка сутрин и това е, което правим. Ние сме отговорни за всички тези хора, независимо от техните умения. Това е група хора, които водят разговори за възрастни.
Олег: Всъщност, говорейки за приказливите служители, се опитах да симулирам възраженията на хората, особено на мениджърите, които са помолени да преминат към devops, срещу тази изцяло нова визия за света. И вие, като консултанти, трябва да сте наясно с тези възражения много по-добре от мен, като разработчик! Споделете какво притеснява най-много мениджърите?
Тим: Мениджъри? хм Най-често мениджърите са подложени на натиск от проблеми, изправени пред необходимостта спешно да освободят нещо и да направят доставка и други подобни. Гледат как постоянно обсъждаме и спорим за нещо и го виждат така: разговори, разговори, разговори... Какви други разговори? Върни се на работа! Защото говоренето не им се струва работа. Не пишете код, не тествате софтуер, не изглежда да правите нищо - защо не ви изпратят да направите нещо? В крайна сметка доставката е вече след месец!
Майкъл: Отидете да напишете код!
Тим: Струва ми се, че не се притесняват от работата, а от липсата на видимост на напредъка. За да изглежда, че се доближаваме до успеха, трябва да ни видят как натискаме бутони на клавиатурата. Цял ден от сутрин до вечер. Това е проблем номер едно.
Олег: Миша, мислиш за нещо.
Майкъл: Съжалявам, потънах в мислите си и хванах ретроспекция. Всичко това ми напомни за един интересен митинг, който се случи вчера... Вчера имаше твърде много митинги... И всичко това звучи много познато!
Живот без заплати
Тим: Между другото, изобщо не е необходимо да се организират „митинги“ за комуникация. Искам да кажа, че най-полезните дискусии между разработчиците се случват, когато те просто говорят помежду си. Влизаш сутрин с чаша кафе, а петима души са се събрали и яростно обсъждат нещо техническо. За мен, ако аз съм мениджър на този проект, е по-добре просто да се усмихна и да отида някъде по моя бизнес, нека ги обсъдят. Те вече са ангажирани, доколкото е възможно. Това е добър знак.
Олег: Между другото, във вашата книга имате куп бележки за това кое е добро и кое е лошо. Използвате ли някои от тях сами? Относително казано, сега имате компания, която е структурирана по много неортодоксален начин...
Тим: Неортодоксално, но това устройство ни пасва напълно. Познаваме се отдавна. Ние си вярваме, вярвахме си много, преди да станем партньори. А ние например изобщо нямаме заплати. Ние просто работим и например, ако спечелих пари от клиентите си, тогава всички пари отидоха при мен. След това плащаме членски внос на организацията и това е достатъчно за издръжка на самата компания. Освен това всички сме специализирани в различни неща. Аз например работя със счетоводители, попълвам данъчни декларации, правя всякакви административни неща за фирмата и никой не ми плаща за това. Джеймс и Том работят на нашия уебсайт и никой не им плаща. Докато плащате задълженията си, никой няма да се сети да ви казва какво трябва да направите. Например Том сега работи много по-малко, отколкото преди. Сега той има други интереси, той прави някои неща не за Гилдията. Но докато си плаща задълженията, никой няма да дойде при него и да каже: „Хей, Том, отивай на работа!“ Много лесно се справяте с колегите, когато между вас няма пари. И сега нашата връзка е една от основните идеи по отношение на различни специалности. Работи и то много добре.
Най-добър съвет
Майкъл: Връщайки се към „най-добрия съвет“, има ли нещо, което казвате на клиентите си отново и отново? Има идея за 80/20 и някои съвети вероятно се повтарят по-често.
Тим: Веднъж си мислех, че ако напишеш книга като Валс с мечки, това ще промени хода на историята и хората ще спрат, но... Е, вижте, компаниите често се преструват, че всичко е наред с тях. Щом се случи нещо лошо, за тях това е шок и изненада. „Вижте, тествахме системата и тя не преминава никакви системни тестове, а това са още три месеца непланирана работа, как може да се случи това? Кой знаеше? Какво може да се обърка? Сериозно, вярвате ли в това?
Опитвам се да ти обясня, че не бива да се ядосваш твърде много от настоящата ситуация. Трябва да го обсъдим, наистина да разберем какво може да се е объркало и как да предотвратим подобни неща да се случват в бъдеще. Ако се появи проблем, как ще се борим с него, как ще го овладеем?
На мен всичко това ми изглежда страшно. Хората се справят със сложни, изнервящи проблеми и продължават да се преструват, че ако просто стискат палци и се надяват на най-доброто, „най-доброто“ наистина ще се случи. Не, не става така.
Практикувайте управление на риска!
Майкъл: Според вас колко организации се занимават с управление на риска?
Тим: Това, което ме вбесява е, че хората просто записват рисковете, гледат получения списък и отиват на работа. Всъщност идентифицирането на рисковете за тях е управление на риска. Но това ми звучи като причина да попитам: добре, има списък, какво точно ще променяте? Трябва да промените стандартните си последователности от действия, като вземете предвид тези рискове. Ако има най-трудна част от работата, трябва да се заемете с нея и едва след това да преминете към нещо по-просто. В първите спринтове започнете да решавате сложни проблеми. Това вече прилича на управление на риска. Но обикновено хората не могат да кажат какво са променили, след като съставят списък с рискове.
Майкъл: И все пак, колко от тези компании се занимават с управление на риска, пет процента?
Тим: За съжаление не ми е неприятно да го казвам, но това е много незначителна част. Но повече от пет, защото има наистина големи проекти и те просто не могат да съществуват, ако не направят поне нещо. Да кажем, че ще бъда много изненадан, ако е поне 25%. Малките проекти обикновено отговарят на такива въпроси по следния начин: ако проблемът ни засяга, тогава ще го решим. Тогава те успешно се забъркват в проблеми и се занимават с управление на проблеми и управление на кризи. Когато се опитвате да разрешите проблем и проблемът не е решен, добре дошли в управлението на кризи.
Да, често чувам „ще решаваме проблемите, когато възникнат“. Сигурно ще го направим? Ще решим ли наистина?
Олег: Можете да го направите наивно и просто да напишете важни инварианти в хартата на проекта и ако инвариантите се счупят, просто рестартирайте проекта. Оказва се много пиембук.
Майкъл: Да, случвало ми се е, когато се задействат рискове, проектът просто да бъде предефиниран. Браво, бинго, проблемът е решен, не се притеснявайте повече!
Тим: Да натиснем бутона за нулиране! Не, не става така.
Основна бележка на DevOops 2019
Майкъл: Стигнахме до последния въпрос от това интервю. Идвате на следващия DevOops с основна бележка, бихте ли повдигнали завесата на тайната на това, което ще кажете?
Тим: В момента шестима от тях пишат книга за работната култура, негласните правила на организациите. Културата се определя от основните ценности на организацията. Обикновено хората не забелязват това, но след като сме работили дълги години в консултантската сфера, сме свикнали да го забелязваме. Влизате в компания и буквално след няколко минути започвате да усещате какво се случва. Наричаме това „вкус“. Понякога този аромат е наистина добър, а понякога е, ами, опа. Нещата са много различни за различните организации.
Майкъл: Аз също се занимавам с консултации от години и разбирам добре за какво говорите.
Тим: Всъщност едно от нещата, за които си струва да говорим в основната бележка, е, че не всичко се определя от компанията. Вие и вашият екип, като общност, имате своя екипна култура. Това може да бъде цялата компания или отделен отдел, отделен екип. Но преди да сте казали, ето в какво вярваме, ето какво е важно... Не можете да промените култура, преди да бъдат разбрани ценностите и вярванията зад конкретни действия. Поведението е лесно за наблюдение, но търсенето на вярвания е трудно. DevOps е просто чудесен пример за това как нещата стават все по-сложни. Взаимодействията само стават по-сложни, те изобщо не стават по-чисти или по-ясни, така че трябва да се замислите в какво вярвате и за какво мълчат всички около вас.
Ако искате да постигнете бързи резултати, ето една добра тема за вас: виждали ли сте компании, в които никой не казва „не знам“? Има места, където буквално измъчваш човек, докато не си признае, че не знае нещо. Всеки знае всичко, всеки е невероятен ерудит. Доближавате се до всеки човек и той трябва незабавно да отговори на въпроса. Вместо да казвате „не знам“. Ура, наеха един куп ерудити! И в някои култури обикновено е много опасно да се каже „не знам“; това може да се възприеме като признак на слабост. Има и организации, в които, напротив, всеки може да каже „не знам“. Там това е напълно законно и ако някой започне да дърдори в отговор на въпрос, е напълно нормално да отговори: „Не знаеш какво говориш, нали?“ и превърнете всичко в шега.
В идеалния случай бихте искали да имате работа, където да сте щастливи през цялото време. Няма да е лесно, не всеки ден е слънчев и приятен, понякога трябва да работиш много, но когато започнеш да правиш равносметка, ще се окаже: леле, това е наистина прекрасно място, чувствам се добре да работя тук, както емоционално, така и интелектуално. А има компании, в които отиваш като консултант и веднага разбираш, че не можеш да издържиш три месеца и ще избягаш от ужас. Това е, за което искам да говоря на доклада.
Тим Листър ще пристигне с основна бележка на конференцията DevOops 2019, която ще се проведе на 29-30 октомври 2019 г. в Санкт Петербург. Можете да закупите билети . Очакваме ви в DevOops!
Източник: www.habr.com