Тим Листер - коавтор на книги
- „Човечки фактор. Успешни проекти и тимови“ (оригиналната книга е наречена „Peopleware“)
- „Валцер со мечките: Управување со ризик во софтверски проекти“
- „Полуден од адреналин и зомбиран од шаблони. Модели на однесување на проектните тимови“
Сите овие книги се класици во својата област и се напишани заедно со колегите во . Во Русија, неговите колеги се најпознати - и , кој напишал и многу познати дела.
Тим има 40 години искуство во развој на софтвер во 1975 година (ниту еден од оние кои го напишаа овој хабрапост не е роден оваа година), Тим веќе беше извршен потпретседател на Yourdon Inc. Тој сега го поминува своето време во консултации, предавања и пишување, со повремени посети конференции низ светот.
Специјално за Хабр направивме интервју со Тим Листер. Тој ќе ја отвори конференцијата DevOops 2019, а ние имаме многу прашања, за книгите и многу повеќе. Интервјуто го водат Михаил Дружинин и Олег Чирухин од програмската комисија на конференцијата.
Мајкл: Можете ли да кажете неколку зборови за она што го правите сега?
Тим: Јас сум шеф на еснафот за системи на Атлантик. Ние сме шестмина во еснафот, се нарекуваме директори. Три во САД и три во Европа - затоа еснафот се нарекува Атлантик. Толку години сме заедно што едноставно не можете да ги изброите. Сите ние имаме свои специјалитети. Работам со клиенти во последната деценија или повеќе. Моите проекти вклучуваат не само управување, туку и поставување на барања, планирање на проекти и евалуација. Се чини дека проектите кои почнуваат лошо обично завршуваат лошо. Затоа, вреди да се осигураме дека сите активности се навистина добро обмислени и координирани, дека идеите на креаторите се комбинираат. Вреди да размислите што правите и зошто. Кои стратегии да се користат за да се доведе проектот до комплетирање.
Многу години ги советувам клиентите на различни начини. Интересен пример е компанија која произведува роботи за операција на колена и колк. Хирургот не оперира целосно независно, туку користи робот. Безбедноста овде, искрено кажано, е важна. Но, кога ќе се обидете да разговарате за барањата со луѓе кои се фокусирани на решавање проблеми... Ќе звучи чудно, но во САД постои (Федерална администрација за лекови), која лиценцира производи како овие роботи. Пред да продадете нешто и да го користите на живи луѓе, треба да добиете лиценца. Еден од условите е да ги покажете вашите барања, кои се тестовите, како сте ги тестирале, какви се резултатите од тестот. Ако ги промените барањата, тогаш треба повторно и повторно да го поминете целиот овој огромен процес на тестирање. Нашите клиенти успеаја да го вклучат визуелниот дизајн на апликациите во нивните барања. Тие имаа слики од екранот директно како дел од барањата. Мораме да ги извадиме и да објасниме дека во најголем дел сите овие програми не знаат ништо за колената и колковите, сите овие работи со камерата итн. Треба да ги преработиме документите за барања, така што тие никогаш не се менуваат, освен ако не се променат некои навистина важни основни услови. Ако визуелниот дизајн не е во барањата, ажурирањето на производот ќе биде многу побрзо. Нашата работа е да ги најдеме оние елементи кои се занимаваат со операции на коленото, колковите, грбот, да ги извлечеме во посебни документи и да кажеме дека тоа ќе бидат основните барања. Ајде да направиме изолирана група барања за операции на коленото. Ова ќе ни овозможи да изградиме постабилен сет на барања. Ќе зборуваме за целата производна линија, а не за конкретни роботи.
Беше направено многу работа, но тие сепак стигнаа до места каде што претходно поминуваа недели и месеци на повторени тестови без значење или потреба, бидејќи нивните барања опишани на хартија не се совпаѓаа со реалните барања за кои беа изградени системите. ФДА им кажуваше секој пат: вашите барања се сменија, сега треба да проверите сè од нула. Целосните повторни проверки на целиот производ го убиле претпријатието.
Значи, има такви прекрасни задачи кога ќе се најдете на самиот почеток на нешто интересно, а првите постапки ги поставуваат понатамошните правила на играта. Ако се погрижите оваа рана активност да почне да функционира добро и од менаџерска и од техничка гледна точка, постои шанса да завршите со одличен проект. Но, ако овој дел излезе од колосек и отиде некаде наопаку, ако не можете да ги најдете основните договори... не, не е дека вашиот проект нужно ќе пропадне. Но, повеќе нема да можете да кажете: „Поминавме одлично, направивме сè навистина ефикасно“. Ова се работите што ги правам кога комуницирам со клиентите.
Мајкл: Односно, започнувате проекти, правите некаков почеток и проверувате дали шините се движат во вистинската насока?
Тим: Имаме и идеи како да ги споиме сите делови од сложувалката: какви вештини ни се потребни, кога точно се потребни, како изгледа јадрото на тимот и други такви фундаментални работи. Дали ни требаат вработени со полно работно време или можеме да вработиме некој со скратено работно време? Планирање, управување. Прашања како: Што е најважно за овој конкретен проект? Како да се постигне ова? Што знаеме за овој производ или проект, кои се ризиците и каде лежат непознатите, како ќе се справиме со сето ова? Се разбира, во овој момент некој почнува да вика „Што е со агилен?!“ Добро, сите сте флексибилни, но што? Како точно изгледа проектот, како ќе го извадите на начин што одговара на проектот? Не можете само да кажете дека „нашиот пристап се протега на сè, ние сме тим на Scrum!“ Ова е глупост и глупост. Каде ќе одите понатаму, зошто да функционира, каде е поентата? Ги учам моите клиенти да размислуваат за сите овие прашања.
19 години агилни
Мајкл: Во Agile, луѓето често се обидуваат да не дефинираат ништо однапред, туку да донесуваат одлуки што е можно подоцна, велејќи: ние сме премногу големи, нема да размислувам за целокупната архитектура. Наместо тоа, нема да размислувам за еден куп други работи, ќе испорачам нешто што функционира на клиентот во моментов.
Тим: Мислам дека агилните методологии, почнувајќи со во 2001 година, ги отвори очите на индустријата. Но, од друга страна, ништо не е совршено. Јас сум за итеративен развој. Итерацијата има многу смисла во повеќето проекти. Но, прашањето за кое треба да размислите е: штом производот е излезен и во употреба, колку долго трае? Дали е ова производ кој ќе трае шест месеци пред да биде заменет со нешто друго? Или ова е производ кој ќе работи многу, многу години? Се разбира, нема да именувам имиња, но... Во Њујорк и неговата финансиска заедница, најфундаменталните системи се многу стари. Ова е неверојатно. Ги гледате и размислувате, само да можете да се вратите назад во времето, во 1994 година и да им кажете на програмерите: „Дојдов од иднината, од 2019 година. Само развивајте го овој систем онолку долго колку што ви треба. Направете го да може да се прошири, размислете за архитектурата. Потоа ќе се подобрува повеќе од дваесет и пет години. Ако го одложите развојот малку подолго, во големата шема на нештата никој нема да забележи!“ Кога ги проценувате работите на долг рок, треба да размислите колку ќе чини вкупно. Понекогаш добро дизајнираната архитектура навистина вреди, а понекогаш не вреди. Треба да погледнеме наоколу и да се запрашаме: дали сме во вистинска ситуација за таква одлука?
Така, идеја како „Ние сме за агилни, самиот клиент ќе ни каже што сака да добие“ - тоа е супер наивна. Клиентите дури и не знаат што сакаат, а уште повеќе не знаат што би можеле да добијат. Некои луѓе ќе почнат да наведуваат историски примери како аргументи, ова веќе го видов. Но, технички напредните луѓе обично не го кажуваат тоа. Тие велат: „2019 година е, ова се можностите што ги имаме и можеме целосно да го промениме начинот на кој гледаме на овие работи!“ Наместо да ги имитирате постоечките решенија, да ги правите малку поубави и поисчешлани, понекогаш треба да излезете и да кажете: „Ајде целосно да го измислиме она што се обидуваме да го направиме овде!“
И мислам дека повеќето клиенти не можат да размислуваат за проблемот на тој начин. Го гледаат само она што веќе го имаат, тоа е се. После тоа тие доаѓаат со барања како „да го направиме ова малку поедноставно“, или што и да кажат обично. Но, ние не сме келнери или келнерки, па можеме да земеме нарачка колку и да испадне глупаво и потоа да ја испечеме во кујна. Ние сме нивни водичи. Мораме да им ги отвориме очите и да им кажеме: еј, имаме нови можности овде! Дали сфаќате дека навистина можеме да го промениме начинот на кој се прави овој дел од вашиот бизнис? Еден од проблемите со Agile е тоа што ја отстранува свеста за тоа што е можност, што е проблем, што дури треба да правиме, кои достапни технологии се најпогодни за оваа конкретна ситуација.
Можеби овде сум премногу скептичен: во агилната заедница се случуваат многу прекрасни работи. Но, имам проблем со тоа што луѓето наместо да дефинираат проект, почнуваат да креваат раце. Тука би прашал - што правиме, како ќе го направиме тоа? И некако магично секогаш излегува дека клиентот треба да знае подобро од кој било. Но, клиентот најдобро знае само кога избира од некого веќе изградени работи. Ако сакам да купам автомобил и ја знам големината на мојот семеен буџет, тогаш брзо ќе изберам автомобил што одговара на мојот животен стил. Еве јас знам сè подобро од кој било! Но, имајте предвид дека некој веќе ги направил автомобилите. Немам идеја како да измислам нов автомобил, не сум експерт. Кога создаваме сопствени или специјални производи, гласот на клиентот мора да се земе предвид, но ова повеќе не е единствениот глас.
Олег: Го спомнавте Агилниот манифест. Дали треба некако да го ажурираме или ревидираме земајќи го предвид современото разбирање на проблемот?
Тим: Јас не би го допрел. Мислам дека тоа е голем историски документ. Мислам, тој е тоа што е. Наполни 19 години, стар е, но во свое време направи револуција. Она што добро го направи е тоа што предизвика реакција и луѓето почнаа да шепотат за него. Вие, најверојатно, сè уште не работевте во индустријата во 2001 година, но тогаш сите работеа според процесите. Институт за софтверско инженерство, пет нивоа на моделот на комплетноста на софтверот (CMMI). Не знам дали таквите легенди на длабоката антика ви кажуваат нешто, но тогаш тоа беше пробив. Отпрвин, луѓето веруваа дека ако процесите се постават правилно, тогаш проблемите сами ќе исчезнат. И тогаш доаѓа Манифестот и вели: „Не, не, не – ќе се засноваме на луѓе, а не на процеси“. Ние сме мајстори за развој на софтвер. Ние разбираме дека идеалниот процес е фатаморгана, тоа не се случува. Има премногу идиосинкразија во проектите, идејата за еден единствен совршен процес за сите проекти нема никаква смисла. Проблемите се премногу сложени за да се тврди дека има само едно решение за се (здраво, нирвана).
Не претпоставувам да гледам во иднината, но ќе кажам дека луѓето сега почнаа повеќе да размислуваат за проекти. Мислам дека Агилниот манифест е многу добар во скокање и кажување: „Еј! Вие сте на брод, а вие самите го возите овој брод. Ќе треба да донесете одлука - нема да предложиме универзален рецепт за сите ситуации. Ти си екипажот на бродот и ако си доволно добар, можеш да најдеш пат до целта. Имаше други бродови пред тебе, а ќе има и други бродови после тебе, но сепак, во извесна смисла, твоето патување е единствено“. Така нешто! Тоа е начин на размислување. За мене нема ништо ново под сонцето, луѓето пловеле и порано и ќе пловат повторно, но за тебе ова е твоето главно патување и нема да ти кажам што точно ќе се случи со тебе. Мора да ги поседувате вештините за координирана работа во тим, а доколку навистина ги имате, сè ќе успее и ќе стигнете таму каде што сте сакале.
Peopleware: 30 години подоцна
Олег: Дали Peopleware беше револуција како и Манифестот?
Тим: Peopleware... Том и јас ја напишавме оваа книга, но не мислевме дека вака ќе се случи. Некако одекна со идеите на многу луѓе. Ова беше првата книга која рече: развојот на софтвер е многу човечка интензивна активност. И покрај нашата техничка природа, ние сме и заедница на луѓе кои градат нешто големо, дури и огромно, многу сложено. Никој не може сам да создава такви работи, нели? Така, идејата за „тим“ стана многу важна. И не само од гледна точка на управување, туку и за технички луѓе кои се собраа да решат навистина сложени длабоки проблеми со куп непознати. За мене лично, ова беше огромен тест за интелигенција во текот на мојата кариера. И тука треба да можете да кажете: да, овој проблем е повеќе отколку што можам сам да се справам, но заедно можеме да најдеме елегантно решение со кое можеме да се гордееме. И мислам дека оваа идеја најмногу одекна. Идејата дека дел од времето работиме сами, дел од времето како дел од група, а често одлуката ја носи групата. Групното решавање на проблеми брзо стана важна карактеристика на сложените проекти.
И покрај фактот што Тим одржа огромен број разговори, многу малку од нив се објавени на YouTube. Можете да го погледнете извештајот „Враќањето на Peopleware“ од 2007 година. Квалитетот, се разбира, остава многу да се посакува.
Мајкл: Дали нешто се смени во последните 30 години од објавувањето на книгата?
Тим: Можете да го погледнете ова од многу различни агли. Социолошки гледано... еднаш одамна, во поедноставни времиња, ти и твојот тим седеше во иста канцеларија. Би можеле да бидете блиски секој ден, да пиете кафе заедно и да разговарате за работата. Она што навистина се промени е тоа што тимовите сега можат да се дистрибуираат географски, во различни земји и временски зони, но сепак тие работат на истиот проблем, а тоа додава сосема нов слој на сложеност. Ова можеби звучи како староскул, но нема ништо како комуникација лице в лице каде сте сите заедно, работите заедно, и можете да одите до колегата и да кажете, погледнете што открив, како ви се допаѓа ова? Разговорите лице-в-лице обезбедуваат брз начин за транзиција кон неформална комуникација, и мислам дека тоа треба да им се допадне и на агилните ентузијасти. И јас сум исто така загрижен бидејќи во реалноста светот се покажа како многу мал, а сега сето тоа е покриено со дистрибуирани тимови и сето тоа е многу сложено.
Сите живееме во DevOps
Мајкл: Дури и од гледна точка на програмскиот комитет на конференцијата, имаме луѓе во Калифорнија, во Њујорк, Европа, Русија... во Сингапур се уште нема никој. Разликата во географијата е доста голема, а луѓето почнуваат да се шират уште повеќе. Ако зборуваме за развој, можете ли да ни кажете повеќе за devops и рушење на бариерите помеѓу тимовите? Постои концепт дека сите седат во своите бункери, а сега бункерите се уриваат, што мислите за оваа аналогија?
Тим: Ми се чини дека во светлината на неодамнешните технолошки откритија, devops е од големо значење. Претходно имавте тимови од програмери и администратори, тие работеа, работеа, работеа и во одреден момент се појави нешто со кое можеше да дојдеш кај администраторите и да го пуштиш во продукција. И тука почна муабетот за бункерот, затоа што админите се некако сојузници, а не непријатели барем, туку си разговарал со нив дури кога се ќе биде спремно да оди на продукција. Дали отидовте кај нив со нешто и им рековте: погледнете каква апликација имаме, но дали можете да ја отворите оваа апликација? И сега целиот концепт на испорака се промени на подобро. Мислам, имаше оваа идеја дека можете брзо да ги протуркате промените. Можеме да ги ажурираме производите на лет. Секогаш се насмевнувам кога Firefox на мојот лаптоп ќе се појави и ќе каже, еј, го ажуриравме вашиот Firefox во заднина, и штом имате минута, дали ќе ви пречи да кликнете овде и ќе ви го дадеме најновото издание. И јас бев како: „О, да, душо!“ Додека спиев, тие работеа на тоа да ми достават ново издание директно на мојот компјутер. Ова е прекрасно, неверојатно.
Но, тука е тешкотијата: ја имате оваа функција со ажурирање на софтверот, но интегрирањето на луѓето е многу потешко. Она што сакам да го искажам на главниот говор на DevOops е дека сега имаме многу повеќе играчи отколку што сме имале. Ако само размислувате за сите вклучени во само еден тим…. Го мислевте како тим, и тоа е многу повеќе од само тим на програмери. Тоа се тестери, проект менаџери и еден куп други луѓе. И секој има свои ставови за светот. Менаџерите на производи се сосема различни од проект менаџерите. Администраторите имаат свои задачи. Станува прилично тежок проблем да се координираат сите учесници за да продолжат да бидат свесни за она што се случува и да не полудат. Неопходно е да се одделат задачите на групата и задачите што важат за сите. Ова е многу тешка задача. Од друга страна, мислам дека сето тоа е многу подобро отколку пред многу години. Токму ова е патот по кој луѓето растат и учат да се однесуваат правилно. Кога правите интеграција, разбирате дека не треба да има подземен развој, за во последен момент софтверот да не се извлече како џек-во-кутија: лајк, погледнете што направивме овде! Идејата е дека ќе можете да направите интеграција и развој, а на крајот ќе се проширите на уреден и итеративен начин. Сето ова ми значи многу. Ова овозможува да се создаде поголема вредност за корисниците на системот и за вашиот клиент.
Мајкл: Целата идеја на devops е да испорача значајни случувања што е можно порано. Гледам дека светот почна да се забрзува се повеќе и повеќе. Како да се прилагодите на таквите забрзувања? Пред десет години ова не постоеше!
Тим: Се разбира, секој сака се повеќе и повеќе функционалност. Нема потреба да се движите, само натрупајте повеќе. Понекогаш дури треба да успорите за следното постепено ажурирање за да донесете нешто корисно - и тоа е сосема нормално.
Идејата дека треба да трчате, трчате, трчате не е најдобра. Малку е веројатно дека некој сака да го живее својот живот така. Би сакал ритамот на испораките да го постави сопствениот ритам на проектот. Ако само произведете прилив на мали, релативно бесмислени работи, сето тоа нема никаква смисла. Наместо безумно да се обидувате да ги ослободите работите што е можно порано, она што вреди да се разговара со водечките развивачи и менаџерите на производи и проекти е стратегијата. Дали ова воопшто има смисла?
Шаблони и антишеми
Олег: Обично зборувате за шаблони и антишеми, а тоа е разликата помеѓу животот и смртта на проектите. И сега, deops рафали во нашите животи. Дали има некој од своите шаблони и анти-шеми кои можат да го убијат проектот на лице место?
Тим: Моделите и анти-шемите се случуваат постојано. Нешто за разговор. Па, има ова нешто што го нарекуваме „сјајни работи“. Луѓето навистина, навистина ја сакаат новата технологија. Тие едноставно се маѓепсани од сјајот на сè што изгледа кул и стилски, и престануваат да поставуваат прашања: дали е воопшто потребно? Што ќе постигнеме? Дали е ова нешто доверливо, има ли смисла? Често гледам луѓе, така да се каже, на врвна технологија. Тие се хипнотизирани од она што се случува во светот. Но, ако подобро погледнете какви корисни работи прават, често едноставно нема ништо корисно!
Само што разговаравме со нашите другари дека оваа година е годишнина, педесет години од слетувањето на луѓето на Месечината. Ова беше во 1969 година. Технологијата што им помогна на луѓето да стигнат таму не е технологија од 1969 година, туку 1960 или 62 година, бидејќи НАСА сакаше да го користи само она што има добри докази за доверливост. И така гледате и разбирате - да, и тие беа вистинити! Сега, не, не, туку запаѓате во проблеми со технологијата едноставно затоа што сè е премногу туркано, продадено од сите пукнатини. Луѓето викаат од секаде: „Види, каква работа, ова е најновото, најубавото нешто на светот, погодно за апсолутно сите!“ Па, тоа е тоа... обично сето ова се покажува како само мамка, а потоа сето тоа треба да се фрли. Можеби сето тоа е затоа што веќе сум стар човек и гледам на такви работи со голема доза на скептицизам, кога луѓето снемуваат и велат дека го нашле единствениот, најправилниот начин да ги создадат најдобрите технологии. Во овој момент во мене се буди глас кој вели: „Каков хаос!“
Мајкл: Навистина, колку често сме слушнале за следниот сребрен куршум?
Тим: Токму така, и ова е вообичаениот тек на работите! На пример... се чини дека ова веќе стана шега низ светот, но овде луѓето често зборуваат за блокчејн технологијата. И тие всушност имаат смисла во одредени ситуации! Кога навистина ви требаат сигурни докази за настани, дека системот работи и дека никој не нè измамил, кога имате безбедносни проблеми и сите тие работи измешани заедно - блокчејн има смисла. Но, кога велат дека блокчејн сега ќе го зафати светот, бришејќи сè што ќе му се најде на патот? Сонувајте повеќе! Ова е многу скапа и сложена технологија. Технички сложени и одземаат многу време. Вклучително и чисто алгоритамски, секој пат кога треба повторно да ја пресметате математиката, со најмали промени... и ова е одлична идеја - но само за одредени случаи. Целиот мој живот и кариера беа за ова: интересни идеи во многу специфични ситуации. Многу е важно точно да разберете каква е вашата ситуација.
Мајкл: Да, главното „прашање на животот, универзумот и сè“: дали оваа технологија или пристап е погодна за вашата ситуација или не?
Тим: Ова прашање веќе може да се дискутира со технолошката група. Можеби дури и донесе некој консултант. Погледнете го проектот и разберете - дали сега ќе направиме нешто правилно и корисно, подобро од порано? Можеби ќе одговара, можеби не. Но, што е најважно, не донесувајте таква одлука стандардно, едноставно затоа што некој избувнал: „Очајно ни треба блокчејн! Само што прочитав за него во едно списание во авионот!“ Сериозно? Не е ни смешно.
Митскиот „девопс инженер“
Олег: Сега сите имплементираат devops. Некој чита за devops на Интернет, а утре се појавува уште едно слободно работно место на сајт за регрутирање. „Девопс инженер“. Овде би сакал да го привлечам вашето внимание: дали мислите дека овој термин, „инженер за развој“ има право на живот? Постои мислење дека devops е култура и нешто не се собира овде.
Тим: Така-така. Нека веднаш дадат некое објаснување за овој термин. Нешто да го направи уникатен. Сè додека не докажат дека постои уникатна комбинација на вештини зад вакво слободно работно место, јас нема да го купам! Мислам, добро, имаме титула за работа, „инженер за развој“, интересна титула, да, што понатаму? Називите на работните места се генерално многу интересна работа. Да речеме „програмер“ - што е тоа сепак? Различни организации значат сосема различни работи. Во некои компании, висококвалитетните програмери пишуваат тестови кои имаат повеќе смисла од тестовите напишани од специјални професионални тестери во други компании. Па што, дали тие сега се програмери или тестери?
Да, имаме работни звања, но ако поставувате прашања доволно долго, на крајот ќе излезе дека сите ние сме решавачи на проблеми. Ние сме баратели на решенија, а некои имаат некои технички вештини, а некои имаат различни. Ако живеете во средина каде што DevOps има навлезено, вие сте ангажирани во интеграцијата на развојот и администрацијата, а оваа активност има прилично важна цел. Но, ако ве прашаат што точно правите и за што сте одговорни, излегува дека луѓето ги прават сите овие работи од памтивек. „Јас сум одговорен за архитектурата“, „Јас сум одговорен за базите на податоци“ и така натаму, што и да е, гледате - сето ова беше пред „девопс“.
Кога некој ќе ми го каже своето работно место, јас навистина не слушам многу. Подобро е да му дозволите да ви каже за што всушност е одговорен, ова ќе ни овозможи многу подобро да го разбереме проблемот. Мојот омилен пример е кога некое лице тврди дека е „менаџер на проекти“. Што? Тоа не значи ништо, се уште не знам што правиш. Проект-менаџер може да биде развивач, водач на тим од четири лица, кој пишува код, врши работа, кој станал лидер на тимот, кого самите луѓе го препознаваат меѓу себе како лидер. И, исто така, проект менаџер може да биде менаџер кој управува со шестотини луѓе на проект, управува со други менаџери, е одговорен за изготвување распореди и планирање буџети, тоа е сè. Ова се два сосема различни света! Но, нивното работно место звучи исто.
Ајде да го свртиме ова малку поинаку. Во што сте навистина добри, имате големо искуство, дали имате талент за? За што ќе преземете одговорност затоа што мислите дека можете да се справите со задачата? И тука некој веднаш ќе почне да негира: не, не, не, воопшто немам желба да се занимавам со ресурсите на проектот, тоа не е моја работа, јас сум технички пријател и ја разбирам употребливоста и корисничките интерфејси, не воопшто сакам да управувам со војски од луѓе, подобро да одам на работа.
И патем, јас сум голем поборник за пристап во кој ваквото раздвојување на вештините функционира добро. Каде што техничарите можат да ја растат својата кариера колку што сакаат. Сепак, сè уште гледам организации каде техничарите се жалат: ќе морам да одам во управување со проекти бидејќи тоа е единствениот начин во оваа компанија. Понекогаш тоа доведува до страшни исходи. Најдобрите техничари воопшто не се добри менаџери, а најдобрите менаџери не можат да се справат со технологијата. Ајде да бидеме искрени за ова.
Гледам многу побарувачка за ова сега. Ако сте техничари, вашата компанија може да ви помогне, но без оглед на тоа, навистина треба да го пронајдете вашиот сопствен пат во кариерата бидејќи технологијата постојано се менува и треба повторно да се измислите заедно со неа! За само дваесет години, технологиите можат да се променат најмалку пет пати. Технологијата е чудна работа...
„Експерти за сè“
Мајкл: Како луѓето можат да се справат со таквата брзина на технолошките промени? Нивната сложеност расте, нивниот број расте, вкупната количина на комуникација меѓу луѓето исто така расте и излегува дека не можете да станете „експерт за сè“.
Тим: Во право! Ако работите во технологија, да, дефинитивно треба да изберете нешто конкретно и да навлезете во него. Некоја технологија која вашата организација ја смета за корисна (а можеби всушност ќе биде корисна). И ако веќе не ве интересира - никогаш немаше да верувам дека ќе го кажам ова - добро, можеби треба да се преселите во некоја друга организација каде што технологијата е поинтересна или попогодна за проучување.
Но, генерално, да, во право си. Технологиите растат во сите правци одеднаш. Од друга страна, има сунѓери кои буквално го впиваат технолошкото знаење и лудуваат по него. Сум видел неколку такви луѓе, тие буквално дишат и живеат, корисно и интересно е да разговарам со нив. Тие го проучуваат не само она што се случува внатре во организацијата, туку генерално, зборуваат за тоа, тие се исто така навистина кул технолози, тие се многу свесни и намерни. Тие само се обидуваат да останат на врвот на бранот, без оглед на тоа која е нивната главна работа, бидејќи нивната страст е движењето на технологијата, промоцијата на технологијата. Ако одеднаш сретнете таква личност, треба да одите на ручек со него и да разговарате за разни кул работи за време на ручекот. Мислам дека на секоја организација и требаат барем неколку такви луѓе.
Ризици и неизвесност
Мајкл: Почесни инженери, да. Ајде да го допреме управувањето со ризик додека имаме време. Ова интервју го започнавме со дискусија за медицински софтвер, каде што грешките може да доведат до страшни последици. Потоа зборувавме за Лунарната програма, каде што цената на грешката е милиони долари, а можеби и неколку човечки животи. Но, сега го гледам спротивното движење во индустријата, луѓето не размислуваат за ризиците, не се обидуваат да ги предвидат, дури и не ги набљудуваат.
Олег: Движете се брзо и кршете ги работите!
Мајкл: Да, движете се брзо, кршете работи, се повеќе и повеќе работи, додека не умрете од нешто. Од ваша гледна точка, како просечниот програмер треба сега да пристапи кон учењето за управување со ризик?
Тим: Ајде да повлечеме линија помеѓу две работи: ризици и неизвесност. Тоа се различни работи. Неизвесноста се јавува кога немате доволно податоци во даден момент во времето за да дојдете до дефинитивен одговор. На пример, во многу рана фаза на проектот, ако некој ве праша „кога ќе ја завршите работата“, ако сте прилично чесна личност, ќе речете: „Немам поим“. Едноставно не знаеш, и тоа е во ред. Сè уште не сте ги проучувале проблемите и не сте запознаени со тимот, не ги знаете нивните вештини итн. Ова е неизвесност.
Ризиците се јавуваат кога веќе може да се идентификуваат потенцијалните проблеми. Такво нешто може да се случи, неговата веројатност е поголема од нула, но помалку од сто проценти, некаде помеѓу. Поради тоа може да се случи се, од доцнење и непотребна работа, но и до фатален исход за проектот. Исходот, кога велите - момци, да ги свиткаме чадорите и да ја напуштиме плажата, никогаш нема да ја завршиме, се е готово, точка. Направивме претпоставка дека оваа работа ќе функционира, но воопшто не функционира, време е да престанеме. Ова се ситуациите.
Честопати, проблемите најлесно се решаваат кога веќе се појавиле, кога проблемот се случува токму сега. Но, кога проблемот е веднаш пред вас, вие не правите управување со ризик - вие решавате проблеми, управување со кризи. Ако сте водечки развивач или менаџер, сигурно се прашувате што може да се случи што би довело до одложувања, губење време, непотребни трошоци или колапс на целиот проект? Што ќе не натера да застанеме и да почнеме од почеток? Кога сите овие работи функционираат, што ќе правиме со нив? Постои едноставен одговор кој важи за повеќето ситуации: не бегајте од ризиците, работете на нив. Погледнете како можете да решите ризична ситуација, да ја намалите на ништо, да ја претворите од проблем во нешто друго. Наместо да се каже: добро, ќе ги решаваме проблемите како што ќе се појават.
Неизвесноста и ризикот треба да бидат во првите редови на сè со што се занимавате. Можете да земете проектен план, да погледнете одредени критични ризици пред време и да кажете: треба да се справиме со ова сега, бидејќи ако нешто од ова тргне наопаку, ништо друго нема да биде важно. Не треба да се грижите за убавината на чаршафот на масата ако не е јасно дали можете да готвите вечера. Прво треба да ги идентификувате сите ризици од приготвувањето на вкусна вечера, да се справите со нив и дури потоа да размислите за сите други работи кои не претставуваат вистинска закана.
Повторно, што го прави вашиот проект уникатен? Ајде да видиме што може да го натера нашиот проект да излезе од шините. Што можеме да направиме за да ја минимизираме веројатноста да се случи ова? Обично не можете само да ги неутрализирате 100% и со чиста совест да изјавите: „Тоа е тоа, ова веќе не е проблем, ризикот е решен!“ За мене ова е знак на однесување на возрасните. Ова е разликата помеѓу дете и возрасен - децата мислат дека се бесмртни, дека ништо не може да тргне наопаку, се ќе биде добро! Во исто време, возрасните гледаат како тригодишните деца скокаат на игралиштето, ги следат движењата со очите и си велат: „оо-оо, оо-оо“. Стојам во близина и се подготвувам да фатам кога детето ќе падне.
Од друга страна, причината зошто толку многу ми се допаѓа овој бизнис е затоа што е ризичен. Ние правиме работи, а тие работи се ризични. Тие бараат возрасен пристап. Само ентузијазмот нема да ви ги реши проблемите!
Инженерско размислување за возрасни
Мајкл: Примерот со децата е добар. Ако сум обичен инженер, тогаш задоволен сум што сум дете. Но, како да се придвижите кон повеќе размислување за возрасни?
Тим: Една од идеите што работи подеднакво добро или со почетник или со воспоставен развивач е концептот на контекст. Што правиме, што ќе постигнеме. Што е навистина важно за овој проект? Не е важно кој сте на овој проект, дали сте практикант или главен архитект, на секого му треба контекст. Треба да ги натераме сите да размислуваат во поголем обем од нивните дела. „Јас го правам моето парче, и се додека моето дело функционира, јас сум среќен“. Не и повторно не. Секогаш вреди (без да се биде груб!) да се потсетуваат луѓето на контекстот во кој работат. Она што сите заедно се трудиме да го постигнеме. Идеи дека можете да бидете дете сè додека сè е во ред со вашиот дел од проектот - ве молам, не го правете тоа. Ако воопшто ја поминеме целта, ќе ја поминеме само заедно. Вие не сте сами, сите сме заедно. Ако сите луѓе во проектот, и стари и млади, почнаа да зборуваат за тоа што точно е важно за проектот, зошто компанијата инвестира пари во она што сите ние се обидуваме да го постигнеме... повеќето од нив ќе се чувствуваат многу подобро затоа што ќе види како нивната работа е во корелација со работата на сите други. Од една страна го разбирам делото за кое јас сум лично одговорен. Но, за да ја завршиме работата ни требаат и сите други луѓе. И ако навистина мислите дека сте готови, секогаш имаме работа во проектот!
Олег: Релативно кажано, ако работите според Канбан, кога ќе го погодите тесното грло на некое тестирање, можете да се откажете од она што го правевте таму (на пример, програмирање) и да одите да им помогнете на тестерите.
Тим: Точно. Мислам дека најдобрите техничари, ако ги погледнете внимателно, тие се некако свои менаџери. Како можам да го формулирам ова...
Олег: Вашиот живот е вашиот проект со кој управувате.
Тим: Точно! Мислам, вие преземате одговорност, го разбирате прашањето и доаѓате во контакт со луѓето кога ќе видите дека вашите одлуки можат да влијаат на нивната работа, такви работи. Не е само да седите на вашето биро, да ја работите својата работа, па дури и да не сфаќате што се случува околу вас. Не не не. Патем, една од најдобрите работи за Agile е тоа што тие предложија кратки спринтови, бидејќи на овој начин состојбата на сите учесници јасно се забележува, тие можат сето тоа да го видат заедно. Секој ден зборуваме еден за друг.
Како да влезете во управувањето со ризик
Олег: Дали постои формална структура на знаење во оваа област? На пример, јас сум развивач на Java и сакам да го разберам управувањето со ризик без да станам вистински проект менаџер по образование. Најверојатно прво ќе ја прочитам „Колку чини софтверскиот проект“ на Меконел, а потоа што? Кои се првите чекори?
Тим: Првиот е да започнете комуникација со луѓето во проектот. Ова обезбедува итно подобрување на културата на комуникација со колегите. Треба да започнеме со отворање на сè стандардно, наместо да го криеме. Кажи: ова се работите што ме мачат, ова се работите што ме одржуваат ноќе, се разбудив денес ноќе и ми беше: Боже мој, треба да размислам за ова! Дали и другите го гледаат истото? Дали како група треба да одговориме на овие потенцијални проблеми? Треба да бидете во можност да поддржите дискусија на овие теми. Не постои однапред подготвена формула со која работиме. Не се работи за правење хамбургери, туку за луѓе. „Направи чизбургер, продаде чизбургер“ воопшто не е наша работа, и затоа ја сакам оваа работа толку многу. Ми се допаѓа кога сè што правеа менаџерите сега станува сопственост на тимот.
Олег: Сте зборувале во книги и интервјуа за тоа како луѓето повеќе се грижат за среќата отколку за бројките на графиконот. Од друга страна, кога ќе му кажете на тимот: се префрламе на devops, а сега програмерот мора постојано да комуницира, ова може да биде далеку надвор од неговата комфорна зона. И во овој момент тој може, да речеме, да биде длабоко несреќен. Што да направите во оваа ситуација?
Тим: Не сум сигурен што точно да правам. Ако програмерот е премногу изолиран, тие не гледаат зошто работата се прави на прво место, тие само го гледаат својот дел од работата и треба да навлезат во она што јас го нарекувам „контекст“. Тој треба да сфати како сè е поврзано заедно. И, се разбира, не мислам на формални презентации или нешто слично. Зборувам за тоа дека треба да комуницирате со колегите за работата во целина, а не само за делот за кој сте одговорни. Ова е местото каде што можете да започнете да разговарате за идеи, заеднички договори за вашата работа добро да се вклопи и како заеднички да се справите со заедничкиот проблем.
За да им помогнат да се прилагодат, тие често сакаат да испраќаат техничари на обука и разговараат за обука. Еден мој пријател сака да каже дека тренирањето е за кучиња. Има обука за луѓе. Една од најдобрите работи за учење како развивач е интеракцијата со вашите врсници. Ако некој е навистина добар во нешто, треба да го гледате како работи или да разговарате со него за неговата работа или нешто слично. Некој конвенционален Кент Бек постојано зборуваше за екстремно програмирање. Смешно е затоа што XP е толку едноставна идеја, но предизвикува толку многу проблеми. За некои, правењето XP е како присилување да се соблече гол пред пријателите. Ќе видат што правам! Тие се мои колеги, не само што ќе видат, туку и ќе разберат! Страшно! Некои луѓе почнуваат да стануваат сериозно нервозни. Но, кога ќе сфатите дека ова е врвниот начин на учење, сè се менува. Тесно соработувате со луѓе, а некои луѓе ја разбираат темата многу подобро од вас.
Мајкл: Но, сето тоа ве принудува да излезете од вашата комфорна зона. Како инженер, мора да излезете од вашата комфорна зона и да комуницирате. Како решавач на проблеми, мора постојано да се ставате во слаба позиција и да размислувате што може да тргне наопаку. Овој тип на работа е инхерентно дизајниран да биде непријатност. Свесно се ставате во стресни ситуации. Обично луѓето бегаат од нив, луѓето сакаат да бидат среќни деца.
Тим: Што може да се направи, можете да излезете и отворено да кажете: „Се е во ред, можам да се справам! Не сум единствениот кој се чувствува непријатно. Ајде да разговараме за разни непријатни работи, сите заедно, како тим!“ Ова се нашите заеднички проблеми, мора да се справиме со нив, знаеш? Мислам дека идиосинкратските генијални програмери се како мамути, исчезнаа. И нивното значење е многу ограничено. Ако не можете да комуницирате, не можете да учествувате добро. Затоа, само зборувај. Бидете искрени и отворени. Многу ми е жал што некому ова е непријатно. Можете ли да замислите, пред многу години имаше студија според која главниот страв во САД не е смртта, туку погодете што? Страв од јавно говорење! Тоа значи дека некаде има луѓе кои повеќе би сакале да умрат отколку да кажат комплимент на глас. И мислам дека ти е доволно да имаш некои основни вештини, во зависност од тоа што правиш. Вештини за зборување, вештини за пишување - но само онолку колку што е навистина потребно во вашата работа. Ако работите како аналитичар, но не знаете да читате, пишувате или зборувате, тогаш, за жал, нема да имате што да правите во моите проекти!
Цената на комуникацијата
Олег: Зарем не е поскапо вработувањето на вакви работници кои заминуваат од разни причини? На крајот на краиштата, тие постојано разговараат наместо да работат!
Тим: Мислев на јадрото на тимот, а не само на сите. Ако имате некој кој е навистина кул во подесување бази на податоци, сака да ги подесува базите на податоци и ќе продолжи да ги подесува вашите бази на податоци до крајот на својот живот и тоа е тоа, кул, продолжете така. Но, зборувам за луѓе кои сакаат да живеат во самиот проект. Јадрото на тимот, насочено кон развој на проектот. Овие луѓе навистина треба постојано да комуницираат едни со други. А особено на почетокот на проектот, кога разговарате за ризиците, начините за постигнување глобални цели и слично.
Мајкл: Ова се однесува на сите вклучени во проектот, без оглед на специјализацијата, вештините или начините на работа. Сите сте заинтересирани за успехот на проектот.
Тим: Да, чувствувате дека сте доволно нурнати во проектот, дека вашата задача е да помогнете да се оствари проектот. Без разлика дали сте програмер, аналитичар, дизајнер на интерфејс, било кој. Ова е причината поради која доаѓам на работа секое утро и ова е она што го правиме. Ние сме одговорни за сите овие луѓе, без разлика на нивните вештини. Ова е група на луѓе кои разговараат за возрасни.
Олег: Всушност, зборувајќи за разговорливи вработени, се обидов да ги симулирам приговорите на луѓето, особено на менаџерите, од кои се бара да се префрлат на devops, на целата оваа нова визија за светот. А вие, како консултанти, треба да знаете за овие приговори многу подобро од мене, како програмер! Споделете што најмногу ги загрижува менаџерите?
Тим: Менаџери? Хм. Најчесто менаџерите се под притисок од проблеми, соочени со потреба итно да пуштат нешто и да направат достава и слично. Гледаат како постојано разговараме и се расправаме за нешто, а тоа го гледаат вака: муабети, муабети, муабети... Кои други муабети? Врати се на работа! Затоа што зборувањето не им изгледа како работа. Не пишувате код, не тестирате софтвер, се чини дека не правите ништо - зошто да не ве испратам да направите нешто? На крајот на краиштата, испораката е веќе за еден месец!
Мајкл: Оди напиши некој код!
Тим: Ми се чини дека тие не се загрижени за работата, туку за невидливоста на напредокот. За да изгледа дека сме се поблиску до успехот, треба да не видат како притискаме копчиња на тастатурата. Цел ден од утро до вечер. Ова е проблем број еден.
Олег: Миша, размислуваш за нешто.
Мајкл: Извинете, се изгубив во мислите и фатив флешбек. Сето ова ме потсети на еден интересен митинг што се случи вчера... Вчера имаше премногу митинзи... И сето тоа звучи многу познато!
Живот без плати
Тим: Патем, воопшто не е неопходно да се организираат „митинзи“ за комуникација. Мислам, најкорисните дискусии меѓу програмерите се случуваат кога тие само разговараат еден со друг. Влегуваш наутро со шолја кафе, а таму се собрани пет луѓе и бесно разговараат за нешто техничко. За мене, ако сум менаџер на овој проект, подобро е само да се насмевнам и да одам некаде за мојот бизнис, нека разговараат за тоа. Веќе се вклучени максимално. Ова е добар знак.
Олег: Патем, во вашата книга имаш еден куп белешки за тоа што е добро, а што лошо. Дали вие самите користите некој од нив? Релативно кажано, сега имате компанија, и компанија која е структурирана на многу неортодоксен начин...
Тим: Неправилно, но овој уред совршено ни одговара. Се знаеме долго време. Си веруваме еден на друг, многу си верувавме пред да станеме партнери. А ние на пример воопшто немаме плати. Ние само работиме, а на пример, ако заработував пари од моите клиенти, тогаш сите пари одеа кај мене. После тоа плаќаме членарина на организацијата и тоа е доволно за поддршка на самата компанија. Плус, сите ние сме специјализирани за различни работи. На пример, работам со сметководители, пополнувам даночни пријави, правам секакви административни работи за компанијата и никој не ми плаќа за тоа. Џејмс и Том работат на нашата веб-страница и никој не им плаќа. Сè додека ги плаќате своите давачки, никој нема да помисли да ви каже што треба да направите. На пример, Том сега работи многу помалку отколку што работеше некогаш. Сега тој има други интереси, тој прави некои работи не за еснафот. Но, додека тој ги плаќа своите давачки, никој нема да дојде кај него и да му каже: „Еј, Том, оди на работа!“ Многу е лесно да се справите со колегите кога меѓу вас нема пари. И сега нашата врска е една од основните идеи во однос на различни специјалитети. Работи и работи многу добро.
Најдобар совет
Мајкл: Да се вратиме на „најдобрите совети“, дали има нешто што им кажувате на вашите клиенти одново и одново? Постои идеја за 80/20, а некои совети веројатно се повторуваат почесто.
Тим: Еднаш мислев дека ако напишеш книга како Валцирање со мечки, тоа ќе го промени текот на историјата и луѓето ќе престанат, но... Па, види, компаниите често се преправаат дека се е во ред со нив. Штом ќе се случи нешто лошо, тоа за нив е шок и изненадување. „Видете, го тестиравме системот и тој не поминува ниту еден системски тест, а ова се уште три месеци непланирана работа, како може да се случи ова? Кој знаеше? Што може да тргне наопаку? Сериозно, веруваш ли во ова?
Се обидувам да објаснам дека не треба да се лутиш премногу поради моменталната ситуација. Треба да разговараме, навистина да разбереме што би можело да тргне наопаку и како да спречиме такви работи да се случуваат во иднина. Ако се појави проблем, како ќе се бориме со него, како ќе го задржиме?
Мене сето ова ми изгледа страшно. Луѓето се справуваат со сложени, вознемирувачки проблеми и продолжуваат да се преправаат дека ако само ги вкрстат прстите и се надеваат на најдоброто, навистина ќе се случи „најдоброто“. Не, не функционира така.
Вежбајте управување со ризик!
Мајкл: Според Ваше мислење, колку организации се занимаваат со управување со ризик?
Тим: Она што ме лути е тоа што луѓето едноставно ги запишуваат ризиците, ја гледаат добиената листа и одат на работа. Всушност, идентификувањето на ризиците за нив е управување со ризик. Но, ова ми звучи како причина да прашам: во ред, има список, што точно ќе промените? Треба да ги промените вашите стандардни секвенци на дејства земајќи ги предвид овие ризици. Ако има некој најтешкиот дел од работата, треба да се справите со него и дури потоа да преминете на нешто поедноставно. Во првите спринтови почнете да решавате сложени проблеми. Ова веќе изгледа како управување со ризик. Но, обично луѓето не можат да кажат што смениле откако составиле листа на ризици.
Мајкл: А сепак, колку од овие компании се вклучени во управувањето со ризикот, пет проценти?
Тим: За жал, мразам да го кажам ова, но ова е многу незначаен дел. Но, повеќе од пет, бидејќи има навистина големи проекти и тие едноставно не можат да постојат ако не направат барем нешто. Да речеме дека многу ќе се изненадам ако е барем 25%. Малите проекти обично одговараат на ваквите прашања на овој начин: ако проблемот нè погоди, тогаш ќе го решиме. Потоа тие успешно се впуштаат во неволја и се занимаваат со управување со проблеми и управување со кризи. Кога се обидувате да решите проблем, а проблемот не е решен, добредојдовте во управувањето со кризи.
Да, често слушам: „Ние ќе ги решиме проблемите кога ќе се појават“. Сигурно ќе? Дали навистина ќе одлучиме?
Олег: Можете да го направите тоа наивно и едноставно да напишете важни инваријанти во проектната повелба, а ако непроменливите се скршат, само рестартирајте го проектот. Излегува многу пиембаки.
Мајкл: Да, ми се случи кога се активираа ризиците, проектот едноставно беше редефиниран. Убаво, бинго, проблемот решен, не грижете се повеќе!
Тим: Ајде да го притиснеме копчето за ресетирање! Не, не функционира така.
Главен говор на DevOops 2019 година
Мајкл: Доаѓаме до последното прашање од ова интервју. Доаѓате на следниот DevOops со воведен говор, дали би можеле да ја подигнете завесата на тајноста на она што ќе го кажете?
Тим: Во моментов, шестмина од нив пишуваат книга за работната култура, неискажаните правила на организациите. Културата е одредена од основните вредности на организацијата. Обично луѓето не го забележуваат ова, но со години работејќи во консултантски услуги, навикнати сме да го забележуваме тоа. Влегувате во друштво и буквално за неколку минути почнувате да чувствувате што се случува. Ова го нарекуваме „вкус“. Понекогаш овој мирис е навистина добар, а понекогаш е, па, упс. Работите се многу различни за различни организации.
Мајкл: И јас со години работам консултантски и добро разбирам што зборуваш.
Тим: Всушност, една од работите за кои вреди да се зборува на воведниот говор е дека не е сè што го одредува компанијата. Вие и вашиот тим, како заедница, имате своја тимска култура. Ова може да биде целата компанија, или посебен оддел, посебен тим. Но, пред да речете, еве во што веруваме, еве што е важно... Не можете да ја промените културата пред да се разберат вредностите и верувањата зад конкретните постапки. Однесувањето е лесно да се набљудува, но барањето верувања е тешко. DevOps е само одличен пример за тоа како работите стануваат сè покомплексни. Интеракциите само стануваат покомплексни, воопшто не стануваат почисти или појасни, па затоа треба да размислите во што верувате и за што сите околу вас молчат.
Ако сакате да постигнете брзи резултати, еве добра тема за вас: дали сте виделе компании каде што никој не вели „не знам“? Има места каде буквално мачиш човек додека не признае дека нешто не знае. Секој знае се, секој е неверојатен ерудит. На секој човек му приоѓате, а тој веднаш треба да одговори на прашањето. Наместо да се каже „не знам“. Ура, вработија еден куп ерудити! И во некои култури генерално е многу опасно да се каже „не знам“ може да се сфати како знак на слабост. Има и организации во кои, напротив, секој може да каже „не знам“. Таму е сосема легално, и ако некој почне да ѓубре одговара на прашање, сосема е нормално да одговориш: „Не знаеш што зборуваш, нели?“ и сето тоа да се претвори во шега.
Идеално, би сакале да имате работа каде што би можеле да бидете постојано среќни. Нема да биде лесно, не е секој ден сончев и пријатен, понекогаш треба да се работи напорно, но кога ќе почнете да правите сметка, ќе испадне: леле, ова е навистина прекрасно место, се чувствувам добро што работам овде, и емотивно и интелектуално. И има компании каде што одите како консултант и веднаш сфаќате дека не сте можеле да издржите три месеци и дека ќе избегате во ужас. Ова е она за што сакам да зборувам во извештајот.
Тим Листер ќе пристигне со воведен говор на конференцијата DevOops 2019, која ќе се одржи на 29-30 октомври 2019 година во Санкт Петербург. Можете да купите билети . Ве чекаме на DevOops!
Извор: www.habr.com