Цім Лістэр - суаўтар кніг
- «Чалавечы фактар. Паспяховыя праекты і каманды» (у арыгінале кніга называецца «Peopleware»)
- "Вальсуючы з Мядзведзямі: кіраванне рызыкамі ў праектах па распрацоўцы праграмнага забеспячэння"
- «Якія чмурэюць ад адрэналіну і замбаваныя шаблонамі. Патэрны паводзін праектных каманд»
Усе гэтыя кнігі з'яўляюцца класікай у сваёй вобласці і напісаны разам з калегамі па . У Расіі найбольш вядомыя яго калегі. и , якія таксама напісалі мноства вядомых прац.
У Ціма 40 гадоў вопыту ў галіне распрацоўкі ПЗ, у 1975 годзе (ніхто з тых, хто напісаў гэты хабрапост у гэтым годзе яшчэ не нарадзіўся), Цім ужо быў выканаўчым віцэ-прэзідэнтам Yourdon Inc. Цяпер ён займаецца кансалтынгам, навучаннем і пісьменніцкай дзейнасцю, час ад часу наведваючы канферэнцыі па ўсім свеце.
Спецыяльна для Хабра мы зрабілі інтэрв'ю з Цімам Лістэр. Ён будзе адкрываць канферэнцыю DevOops 2019, і ў нас назапасілася мноства пытанняў, пра кнігі і не толькі. Інтэрв'ю вядуць Міхаіл Дружынін і Алег Чырухін з праграмнага камітэта канферэнцыі.
Міхаіл: Можна пару слоў аб тым, чым вы зараз займаецеся?
Цім: Я кіраўнік Atlantic Systems Guild. У Гільдыі нас шасцёра, мы завём сябе прынцыпаламі. Тры ў ЗША і тры ў Еўропе - вось таму Гільдыя і называецца Атлантычнай. Мы разам гэтулькі гадоў, што проста так і не палічыш. Ва ўсіх нас ёсць свае спецыяльнасці. Апошняе дзесяцігоддзе, ці нават больш, я займаюся працай з кліентамі. У мае праекты ўваходзіць не толькі кіраванне, але і пастаноўка патрабаванняў, праектнае планаванне, ацэнка. Здаецца, што праекты, якія дрэнна пачалі - звычайна і заканчваюць дрэнна. Таму варта пераканацца, што ўсе актыўнасці сапраўды добра прадуманы і ўзгоднены, што ідэі стваральнікаў спалучаюцца. Варта прадумаць, што вы робіце і чаму. Якія стратэгіі выкарыстоўваць, каб давесці праект да канца.
Ужо шмат гадоў я кансультую кліентаў разнастайнымі спосабамі. Цікавы прыклад – кампанія, якая робіць робатаў для хірургіі каленнага і тазасцегнавага суставаў. Хірург аперуе не цалкам самастойна, а выкарыстоўвае робата. Бяспека тут, прама скажам, важная. Але калі ты спрабуеш абмяркоўваць патрабаванні з людзьмі, якія накіраваны на рашэнне задач… Гэта прагучыць дзіўна, але ў ЗША ёсць (Federal Drug Administration), якая ліцэнзуе прадукты накшталт гэтых робатаў. Перш чым нешта прадаваць і выкарыстоўваць на жывых людзях, трэба атрымаць ліцэнзію. Адна з умоў - паказаць вашыя патрабаванні, у чым заключаюцца тэсты, як вы іх тэсціравалі, якія вынікі тэсту. Калі вы змяняеце патрабаванні - то трэба зноўку праходзіць увесь гэты велізарны працэс тэсціравання зноў і зноў. Нашы кліенты прымудрыліся ў патрабаванні ўключыць і візуальны дызайн прыкладанняў. У іх прама скрыншоты ішлі як частка патрабаванняў. Даводзіцца іх выдзіраць і тлумачыць, што па большай частцы ўсе гэтыя праграмы нічога не ведаюць аб каленях і сцёгнах, усіх гэтых штуках з камерай і г.д. Нам трэба перапісаць дакументы з патрабаваннямі так, каб яны не мяняліся ніколі, хіба што зменяцца нейкія па-сапраўднаму важныя асноўныя ўмовы. Калі візуальнага дызайну няма ў патрабаваннях, абнаўляць прадукт атрымаецца куды хутчэй. Наша праца ў тым, каб знайсці тыя элементы, якія маюць справу з аперацыямі на калене, сцёгнах, спіне, выдраць іх у асобныя дакументы і сказаць, што вось яны будуць фундаментальнымі патрабаваннямі. Зробім ізаляваную групу патрабаванняў пра аперацыі на калене. Гэта дазволіць пабудаваць больш устойлівы набор патрабаванняў. Мы будзем казаць аб усёй прадуктовай лінейцы, а не аб пэўных асобніках робатаў.
Шмат працы было зроблена, але яны ўсё ж дабраліся да месцаў, дзе раней яны праводзілі тыдні і месяцы паўторных тэстаў без сэнсу і неабходнасці, таму што іх патрабаванні, апісаныя на паперы, не супадалі з сапраўднымі патрабаваннямі, па якіх будаваліся сістэмы. FDA ім кожны раз казала: у вас памяняліся патрабаванні, зараз вам трэба ўсё правяраць з нуля. Поўныя пераправеркі ўсяго прадукта забівалі прадпрыемства.
Так што вось, бываюць такія цудоўныя задачы, калі ты аказваешся ў самым пачатку чагосьці цікавага, і самыя першыя дзеянні задаюць далейшыя правілы гульні. Калі вы зробіце так, што і з мэнэджарскага, і з тэхнічнага пункту гледжання гэтая ранняя актыўнасць пачне добра працаваць, ёсць шанец на выхадзе атрымаць выдатны праект. Але калі гэтая частка сышла з рэек і пакацілася кудысьці не туды, калі вы не можаце намацаць фундаментальныя дамовы… не, не тое, каб ваш праект абавязкова пацерпіць няўдачу. Але вы ўжо не зможаце казаць: "Мы малайцы, зрабілі ўсё сапраўды эфектыўна". Вось такімі рэчамі я і займаюся, маючы зносіны з кліентамі.
Міхаіл: Гэта значыць, запускаеце праекты, робіце нейкі кікоф і правяраеце, што рэйкі вядуць у правільным кірунку?
Цім: Яшчэ ў нас ёсць ідэі аб тым, як збіраць разам усе кавалачкі мазаікі: якія нам патрэбныя скілы, калі канкрэтна яны патрэбныя, як выглядае ядро каманды і іншыя такія асноўныя рэчы. Ці патрэбны нам штатныя супрацоўнікі ці можна набраць кагосьці на паўстаўкі. Планаванне, менеджмент. Пытанні нібыта: што для гэтага канкрэтнага праекта з'яўляецца самым важным? Як гэтага дасягнуць? Што мы ведаем пра гэты прадукт ці праект, у чым заключаюцца рызыкі і дзе ляжыць невядомасць, як мы збіраемся з усім гэтым справіцца? Вядома, хтосьці ў гэты момант пачынае крычаць "А як жа аджайл?!". Добра, вы ўсё з сябе гнуткія, але што з таго? Як менавіта выглядае праект, як вы збіраецеся яго вывезці так, каб гэта падышло праекту? Нельга проста сказаць, што "наш падыход нацягваецца на што заўгодна, мы скрам-каманда!". Гэта глупства і нонсэнс. Куды вы далей збіраецеся накіроўвацца, чаму яно павінна зарабіць, дзе тут сэнс? Я вучу сваіх кліентаў разважаць над усімі гэтымі пытаннямі.
19 гадоў аджайла
Міхаіл: У аджайле людзі часта спрабуюць нічога не вызначаць загадзя, а прымаць рашэнні як мага пазней, кажучы: мы занадта вялікія, я не буду думаць аб агульнай архітэктуры. Я не буду думаць яшчэ і аб кучы іншых рэчаў, замест гэтага прама зараз буду пастаўляць заказчыку нешта працуе.
Цім: Думаю, што гнуткія метадалогіі, пачынаючы з у 2001 годзе, адкрылі індустрыі вочы. Але, з іншага боку, нішто не зьяўляецца ідэальным. Я цалкам на баку ітэратыўнай распрацоўкі. Ітэрацыі маюць вялікі сэнс у большасці праектаў. Але вам трэба задумвацца над пытаннем: пасля таго, як прадукт выйшаў і пачаў выкарыстоўвацца, колькі яму жыць? Гэта такі прадукт, які працягне шэсць месяцаў, і потым яго заменяць іншым? Ці гэта такі прадукт, які будзе працаваць многія-многія гады? Вядома, я не постаці зваць імёнаў, але… У Нью-Ёрку і яго супольнасці фінансістаў найболей асноўныя сістэмы – вельмі старыя. Гэта дзівіць уяўленне. Ты глядзіш на іх і думаеш, вось бы вярнуцца назад у часе, у 1994 год, і сказаць распрацоўшчыкам: «Я прыйшоў з будучыні, з 2019 года. Проста распрацоўвайце гэтую сістэму столькі, колькі вам трэба. Зрабіце яе якая пашыраецца, прадумайце архітэктуру. Яе потым будуць паляпшаць больш за дваццаць пяць гадоў. Калі вы затрымаеце распрацоўку крыху даўжэй – у маштабах гісторыі гэтага ніхто не заўважыць!». Калі вы ацэньваеце рэчы ў далёкай перспектыве, трэба лічыць, колькі гэта будзе каштаваць цалкам. Часам добра распрацаваная архітэктура сапраўды таго варта, а часам - не. Трэба аглядацца і задаваць сабе пытанне: ці ў прыдатнай мы сітуацыі для такога рашэння?
Так што ідэя накшталт "Мы за аджайл, заказчык сам нам раскажа, што хоча атрымаць" — яна супернаіўная. Заказчыкі нават не ведаюць, чаго яны хочуць, і тым больш яны не ведаюць, чаго маглі б атрымаць. Нехта пачне прыводзіць у якасці аргументаў гістарычныя прыклады, я такое ўжо бачыў. Але тэхнічна прасунутыя людзі так звычайна не гавораць. Яны кажуць: "Цяпер 2019 год, вось такія ў нас ёсць магчымасці, і мы можам цалкам змяніць погляд на падобныя рэчы!". Замест таго, каб мімікрыраваць пад існуючыя рашэнні, робячы іх крышачку больш прыгожым і прычасаным, часам трэба выйсці і сказаць: «Давайце цалкам перавынайдзем тое, чым мы тут спрабуем займацца!».
І я не думаю, што большасць замоўцаў могуць думаць аб праблеме такім спосабам. Яны бачаць толькі тое, што ў іх ужо ёсць, і ўсё. Пасля чаго яны прыходзяць з запытамі накшталт "давайце зробім вось гэта крыху прасцей", ці што там яны звычайна кажуць. Але мы ж не афіцыянты і не афіцыянткі, каб прымаць замову па-за залежнасцю ад таго, наколькі тупым ён атрымаўся, і потым выпякаць яго на кухні. Мы - іх праваднікі. Мы павінны расплюшчваць ім вочы і казаць: гэй, тут у нас новыя магчымасці! Ці ўсведамляеце вы, што мы можам рэальна змяніць тое, як робіцца вось гэтая частка вашага бізнесу? Адна з праблем аджайла ў тым, што ён адхіляецца ад усведамлення таго, што з'яўляецца магчымасцю, што з'яўляецца праблемай, што нам увогуле трэба рабіць, якія з наяўных тэхналогій лепш за ўсё падыходзяць у гэтай канкрэтнай сітуацыі.
Магчыма, я тут перабраў са скепсісам: у аджайл-супольнасці адбываецца мноства цудоўных рэчаў. Але ў мяне ёсць праблема з тым, што замест вызначэння праекту людзі пачынаюць разводзіць рукамі. Я б тут спытаў - што мы робім, як мы гэта збіраемся зрабіць? І нейкай чароўнай выявай заўсёды атрымліваецца, што гэта кліент павінен ведаць лепш за ўсіх. Але ж кліент ведае лепш за ўсіх толькі тады, калі выбірае з ужо пабудаваных кімсьці рэчаў. Калі я хачу купіць аўтамабіль і мне вядомы памер сямейнага бюджэту, то і я хуценька падбяру машыну, якая падыходзіць да майго ладу жыцця. Тут я ўсё ведаю лепш за ўсіх! Але, дазвольце заўважыць, што машыны ўжо хтосьці зрабіў. Як вынайсці новы аўтамабіль, я паняцця не маю, я ж не эксперт. Калі мы ствараем кастамныя ці нейкія асаблівыя прадукты, голас замоўца павінен улічвацца, але гэта ўжо не адзіны голас.
Алег: Вы згадалі Agile Manifesto. Ці трэба нам яго неяк абнавіць ці перагледзець з улікам сучаснага разумення пытання?
Цім: Я б не стаў яго чапаць. Мяркую, гэта выдатны гістарычны дакумент. У сэнсе, ён - тое, чым з'яўляецца. Яму спаўняецца 19 гадоў, ён стары, але ў свой час ён зрабіў рэвалюцыю. Што ён зрабіў добра, дык гэта запусціў рэакцыю, пра яго пачалі перашэптвацца. Вы, хутчэй за ўсё, яшчэ не працавалі ў індустрыі ў 2001 годзе, а тады ўсё працавалі па працэсах. Software Engineering Institute, пяць узроўняў мадэлі паўнаты патэнцыялу ПЗ (CMMI). Не ведаю, ці гавораць вам нешта такое адданне даўніны глыбокай, але тады гэта быў прарыў. Спачатку людзі верылі, што калі правільна выбудаваць працэсы, тады праблемы самі сабой выпарацца. І тут з'яўляецца Маніфест і кажа: "Не, не, не - мы будзем грунтавацца на людзях, а не на працэсах". Мы - майстры распрацоўкі ПЗ. Мы разумеем, што ідэальны працэс - гэта міраж, так не бывае. У праектах занадта шмат ідыясінкразіі, ідэя аб адным-адзіным бездакорным працэсе для ўсіх праектаў не мае ніякага сэнсу. Праблемы занадта складаныя, каб сцвярджаць, што знойдзена адзінае рашэнне для ўсяго (прывітанне, нірвана).
Не бяруся зазіраць у будучыню, але скажу, што людзі зараз пачалі больш задумвацца над праектамі. Думаю, што Agile Manifesto вельмі добры, ён вырываецца наперад і гаворыць: «Гэй! Вы на караблі, і вы самі ведзяце гэты карабель. Вам давядзецца прымаць рашэнне – мы не падкажам універсальнага рэцэпта для ўсіх сітуацый. Вы - каманда карабля, і калі вы дастаткова добрыя, то зможаце знайсці шлях да мэты. Да вас былі іншыя караблі, і іншыя караблі будуць пасля вас, але тым не менш, у нейкім сэнсе, ваша падарожжа - унікальнае». Нешта такое! Гэта спосаб думаць. Па мне, нішто не нова пад месяцам, людзі плавалі раней і паплывуць зноў, але для вас гэта - ваша галоўнае падарожжа, і я не падкажу, што менавіта з вамі адбудзецца. У вас павінны быць навыкі скаардынаванай працы ў камандзе, і калі яны сапраўды ёсць, усё атрымаецца і вы прыйдзеце куды хацелі.
Peopleware: 30 гадоў праз
Алег: Peopleware таксама была рэвалюцыяй, як Маніфест?
Цім: Peopleware… Том і я напісалі гэтую кнігу, але не думалі, што так усё здарыцца. Нейкім чынам яна патрапіла ў рэзананс з ідэямі мноства людзей. Гэта была першая кніга, якая казала: распрацоўка софту - гэта вельмі чалавека-інтэнсіўная дзейнасць. Нягледзячы на нашу тэхнічную натуру, мы яшчэ і супольнасць людзей, якія будуюць нешта вялікае, нават вялікае, вельмі складанае. Ніхто не здолее ў адзіночку стварыць такія рэчы, праўда? Так што ідэя "каманды" стала вельмі важная. І не толькі з пункту гледжання менеджменту, але і для людзей тэхнічнага склада, якія сабраліся разам для вырашэння сапраўды складаных глыбокіх праблем з кучай невядомых. Асабіста для мяне, на працягу ўсёй кар'еры гэта было вялізным выпрабаваннем інтэлекту. І тут трэба ўмець сказаць: так, гэтая праблема больш, чым я магу здужаць сам, але разам мы зможам знайсці элегантнае рашэнне, якім мы зможам ганарыцца. І я думаю, што вось менавіта гэтая ідэя рэзанавала больш за ўсё. Ідэя, што мы частку часу працуем самі па сабе, частка – у складзе групы, і часта рашэнне прымаецца групай. Групавое вырашэнне праблем хутка стала важнай асаблівасцю складаных праектаў.
Нягледзячы на тое, што Цім правёў велізарную колькасць дакладаў, на YouTube іх выкладзена зусім няшмат. Можна паглядзець даклад "The Return of Peopleware" 2007 года. Якасць, вядома, вымушае жадаць лепшага.
Міхаіл: Ці змянілася штосьці за апошнія 30 гадоў, з моманту выхаду кнігі?
Цім: На гэта можна глядзець са мноства розных бакоў. Калі казаць сацыялагічна… калісьці, у прасцейшыя часы, вы з камандай сядзелі ў адным офісе. Вы маглі кожны дзень быць побач, разам распіваць каву і абмяркоўваць працу. Што сапраўды змянілася, дык гэта тое, што цяпер каманды могуць быць размеркаваны геаграфічна, у розных краінах і гадзінных зонах, але тым не менш яны працуюць над адной задачай, і гэта дадае цэлы новы пласт складанасці. Гэта можа прагучаць па-старэчаму, але няма нічога лепшага зносін тварам да твару, калі вы ўсе сабраліся разам, разам працуеце, можна падысці да калегі і сказаць: глядзі, што я выявіў, як табе гэта? Размовы тварам да твару даюць хуткі спосаб перайсці да нефармальных зносін, і я думаю, гэта павінна спадабацца аматарам аджайла таксама. А яшчэ я турбуюся таму, што ў рэальнасці свет аказаўся вельмі маленькім, і цяпер увесь ён пакрыты размеркаванымі камандамі, і ўсё гэта вельмі складана.
Усе мы жывем у DevOps
Міхаіл: Нават з пункту гледжання праграмнага камітэта канферэнцыі, у нас ёсць людзі ў Каліфорніі, у Нью-Йорку, Еўропе, Расіі… у Сінгапуры яшчэ нікога няма. Розніца ў геаграфіі даволі вялікая, і людзі пачынаюць размяркоўвацца яшчэ мацней. Калі ўжо пайшла гаворка пра распрацоўку, ці можаце вы падрабязней распавесці аб дэвопсе і аб разбурэнні перашкод паміж камандамі? Вось ёсць канцэпт, што ўсё сядзяць па сваіх бункерах, а зараз бункеры разбураюцца, як вам гэтая аналогія?
Цім: Мне здаецца, у святле апошніх тэхналагічных прарываў, дэвопс мае вялікае значэнне. Раней у вас былі каманды распрацоўшчыкаў і адмінаў, яны працавалі-працавалі-працавалі, і ў нейкі момант з'яўлялася штука, з якой можна было прыйсці да адмін і выкаціць яе на прад. І вось тут пачыналася размова аб бункеры, таму што адміны - яны як бы саюзнікі, не ворагі, прынамсі, але вы размаўлялі з імі толькі калі ўсё ўжо гатова было адпраўляцца на прод. Вы ішлі да іх з нечым і казалі: глядзі, якое ў нас прыкладанне, а не маглі б вы гэта дадатак выкаціць? А зараз уся канцэпцыя пастаўкі змянілася да лепшага. У сэнсе, зьявілася ідэя, што можна прасоўваць зьмены хутка. Мы можам абнаўляць прадукты на лета. Я заўсёды ўсміхаюся, калі ў мяне на наўтбуку Firefox паказвае ўсплывальнае акно і кажа: гэй, мы тут у фоне абнавілі ваш Firefox, і як толькі ў вас з'явіцца хвілінка, не маглі б вы пстрыкнуць сюды, і мы выдадзім вам свежы рэліз. І я такі: "О так, дзетка!" Пакуль я спаў, проста на маім кампутары яны вялі працы па пастаўцы мне новага рэлізу. Гэта ж цудоўна, неверагодна.
Але вось у чым складанасць: гэтая фіча з абнаўленнем софту ў вас ёсць, але інтэграваць людзей куды складаней. Што я хачу агучыць на кейнаўце DevOops - тое, што ў нас цяпер куды больш гульцоў, чым было калі-небудзь. Калі вы проста задумаецеся пра ўсіх, хто прымае ўдзел у працы ўсяго адной каманды…. Вы думалі аб гэтым як аб камандзе, а яно куды больш, чым проста каманда праграмістаў. Гэта і тэсціроўшчыкі, і менеджэры праектаў, і куча іншых людзей. І ва ўсіх свае погляды на свет. Прадуктовыя менеджэры зусім адрозніваюцца ад праектных. У адмінаў свае задачы. Даволі складанай праблемай становіцца скаардынаваць усіх удзельнікаў, так каб працягваць усведамляць тое, што адбываецца, і не з'ехаць са шпулек. Трэба падзяляць задачы групы і задачы, якія адносяцца да ўсіх. Гэта вельмі складаная задача. З іншага боку, я думаю, усё гэта стала значна лепшым, чым калісьці многія гады таму. Гэта менавіта тая дарога, на якой людзі растуць і вучацца паводзіць сябе правільна. Калі займаешся інтэграцыяй, разумееш, што не павінна быць ніякай падпольнай распрацоўкі, каб у самы апошні момант софт не вылазіў як чорт з табакеркі: кшталту, глядзіце, што мы тут зрабілі! Ідэя ў тым, што вы зможаце займацца інтэграцыяй і распрацоўкай, і ў канцы будзеце выкочвацца акуратным і ітэратыўным спосабам. Усё гэта мае вялікае значэнне для мяне. Гэта дае магчымасць ствараць для карыстальнікаў сістэмы і для вашага кліента больш каштоўнасці.
Міхаіл: Уся ідэя дэвопсу - аб тым, што дастаўляць значныя напрацоўкі як мага раней. Я бачу, што свет пачаў паскарацца ўсё больш і больш. Як адаптавацца да такіх паскарэнняў? Дзесяць гадоў таму такога не было!
Цім: Вядома, кожны жадае атрымаць усё больш і больш функцыянальнасці. Не трэба рухацца, проста навальвай пабольш. Часам вам нават даводзіцца запаволіцца, каб наступнае інкрыментальнае абнаўленне прынесла хоць нешта карыснае - і гэта зусім нармальна.
Ідэя аб тым, што трэба бегчы-бегчы-бегчы - не лепшая. Ці наўрад хтосьці жадае так пражыць жыццё. Хацелася б, каб рытм паставак задаваў уласны рытм праекту. Калі вы проста робіце паток дробных параўнальна бессэнсоўных рэчаў, усё гэта і ў суме не мае сэнсу. Замест таго, каб бяздумна імкнуцца выпускаць рэчы як мага раней, што варта абмеркаваць з вядучымі распрацоўшчыкамі і мэнэджэрамі па прадукце і па праекце - дык гэта стратэгію. Ці мае гэта ўвогуле сэнс?
Патэрны і антыпатэрны
Алег: Вы звычайна распавядаеце пра патэрны і антыпатэрны, і гэта розніца паміж жыццём і смерцю праектаў. І вось, у нашае жыццё ўрываецца дэвопс. Ці ёсць у яго нейкія свае патэрны і антыпатэрны, якія могуць забіць праект на месцы?
Цім: Патэрны і антыпатэрны адбываюцца вакол увесь час. Пра што б расказаць. Ну вось, ёсць рэч, якую мы завем "бліскучыя штукі". Людзям вельмі, вельмі падабаюцца новыя тэхналёгіі. Яны проста зачараваныя бляскам усяго, што выглядае крута і стыльна, і перастаюць задавацца пытаннямі: а яно ўвогуле трэба? Чаго мы збіраемся дасягнуць? Ці надзейная гэтая штука, ці мае яна хоць нейкі сэнс? Я часта бачу людзей, скажам так, на пярэднім краі тэхналогій. Яны загіпнатызаваны тым, што адбываецца ў свеце. Але калі пільней прыгледзецца, што ж карыснага яны робяць - часцяком, нічога карыснага проста няма!
Мы тут якраз абмяркоўвалі з таварышамі, што гэты год - юбілейны, пяцьдзесят гадоў з таго часу, як людзі высадзіліся на месяц. Гэта было ў 1969. Тэхналогія, якая дапамагла людзям дабрацца да туды - гэта тэхналогія нават не 1969 года, а хутчэй 1960 ці 62, таму што ў NASA хацелі выкарыстоўваць толькі тое, што мела добрыя доказы надзейнасці. І вось ты глядзіш на гэта і разумееш - так, і яны ж былі праўды! Цяпер не-не, ды ўліпаеш у праблемы з тэхналогіямі проста таму, што ўсё запар занадта цвёрда прапіхваюць, прадаюць з усіх шчылін. Адусюль крычаць: "Глядзіце, якая штука, гэта самая найноўшая штука, найпрыгажэйшая рэч на свеце, прыдатная зусім усім!". Ну-у такое… звычайна ўсё гэта аказваецца проста заманухай, і потым усё гэта давядзецца выкідваць. Магчыма, усё таму, што я ўжо стары і гляджу на такія рэчы з вялікай доляй скепсісу, калі людзі выбягаюць і расказваюць, што знайшлі Адзіны, Самы Правільны Шлях Ствараць Лепшыя Тэхналогіі. У гэты момант унутры мяне прачынаецца голас, які кажа: «Ну і лажа!».
Міхаіл: Сапраўды, як часта мы чулі пра чарговую срэбную кулю?
Цім: Менавіта і гэта звычайны ход рэчаў! Напрыклад… здаецца, гэта ўжо стала жартам па ўсім свеце, але тут людзі часта гавораць пра блокчэйн-тэхналогіі. І яны сапраўды маюць сэнс у пэўных сітуацыях! Калі вам сапраўды патрэбны надзейныя сведчанні падзей, што сістэма працуе і што нас ніхто не падмануў, калі ў вас праблемы з бяспекай і ўсё такое іншае, змяшанае разам - блокчэйн мае сэнс. Але калі кажуць, што Блокчейн зараз пранясецца па ўсім свеце, змятаючы ўсё на сваім шляху? Марыце больш! Гэта вельмі дарагая і складаная тэхналогія. Тэхнічна складаная, якая патрабуе часавых затрат. У тым ліку і чыста алгарытмічна, кожны раз вам трэба пералічваць матэматыку, пры найменшых зменах… і гэта выдатная ідэя - але толькі для пэўных выпадках. У мяне ўсё жыццё і кар'ера аб гэтым: цікавыя ідэі ў вельмі пэўных сітуацыях. Вельмі важна разумець, якая сытуацыя менавіта ў цябе.
Міхаіл: Так, галоўнае «пытанне жыцця, сусвету і ўсяго такога»: ці падыходзіць дадзеная тэхналогія ці падыход для тваёй сітуацыі ці не?
Цім: Вось такое пытанне ўжо можна абмяркоўваць з тэхналагічнай групай. Можа нават прывабіць якога-небудзь кансультанта. Зірнуць на праект і зразумець - ці зробім мы зараз нешта правільнае і карыснае, лепш, чым было раней? Можа быць яно падыдзе, а можа быць - не. Але галоўнае, не прымайце такое рашэнне па змаўчанні, проста таму што хтосьці ўзяў і ляснуў: «Нам да зарэзу патрэбен блокчейн! Я пра яго ў часопісе ў самалёце толькі што прачытаў!». Сур'ёзна? Гэта нават не смешна.
Міфічны "дэвопс-інжынер"
Алег: Цяпер усё ўкараняюць дэвопс. Хтосьці чытае ў інтэрнэце пра дэвапс, а заўтра на Рэкрутынгавае сайце з'яўляецца чарговая вакансія. «дэвопс-інжынера». Вось тут хацелася б засяродзіць увагу: як думаеце, гэты тэрмін, "дэвопс-інжынер", мае права на жыццё? Ёсць меркаванне, што дэвопс - гэта культура, і тут нешта не стыкуецца.
Цім: Так-так. Няхай яны тады адразу дадуць якое-небудзь тлумачэнне гэтаму тэрміну. Нейкае такое, каб яно было ўнікальным. Пакуль яны не дакажуць, што існуе нейкая ўнікальная камбінацыя навыкаў, якая стаіць за падобнай вакансіяй, я на гэта не куплюся! У сэнсе, ну вось у нас ёсць назва пасады, "дэвопс-інжынер", цікавая назва, так, што далей? Назвы пасад - наогул вельмі цікавая штука. Дапусцім, «распрацоўшчык» - гэта наогул, што такое? Розныя арганізацыі маюць на ўвазе зусім рознае. У нейкіх кампаніях высакакласныя праграмісты пішуць такія тэсты, якія маюць больш сэнсу, чым тэсты, напісаныя спецыяльнымі прафесійнымі тэсціроўшчыкамі ў іншых кампаніях. Ну і як, яны зараз праграмісты або тэсціроўшчыкі?
Так, у нас ёсць назвы пасад, але калі дастаткова доўга задаваць пытанні, то ў рэшце рэшт апынецца, што мы ўсе - решатели праблем. Мы шукальнікі рашэнняў, і хтосьці мае адны тэхнічныя навыкі, а хтосьці іншы - іншыя. Калі вы жывяце ў асяроддзі, куды пракраўся DevOps, вы займаецеся інтэграцыяй распрацоўкі і адміністраванні, і ў гэтай дзейнасці ёсць нейкая дастаткова важная мэта. Але калі вас спытаць, чым жа менавіта вы займаецеся і завошта адказваеце, тое апынецца, што ўсе гэтыя рэчы людзі рабілі спрадвеку. "Я адказваю за архітэктуру", "я адказваю за базы дадзеных" і гэтак далей, што заўгодна, бачыце - усё гэта было да "дэвопсу".
Калі нехта кажа мне назву сваёй пасады, я не тое, каб моцна прыслухваюся. Лепш няхай ён раскажа, за што адказвае насамрэч, гэта дазволіць зразумець пытанне куды лепш. Мой любімы прыклад - гэта калі чалавек сцвярджае, што ён "менеджэр праекта". Чаго? Гэта нічога не значыць, я ўсё яшчэ не ведаю, чым ты займаешся. Проджект-мэнэджарам можа быць распрацоўшчык, лідэр каманды з чатырох чалавек, пішучы код, які працуе працу, які стаў тымлідам, якога людзі самі прызнаюць сярод сябе як лідэра. А яшчэ, проджект-мэнэджарам можа быць кіраванец, кіраўнік шасцю сотнямі людзей на праекце, кіраўнік іншымі мэнэджэрамі, адказны за складанне раскладаў і планаванне бюджэтаў, вось гэта ўсё. Гэта два зусім розныя светы! Але пасада ў іх гучыць аднолькава.
Давайце павернем гэта неяк па-іншаму. У чым вы сапраўды разбіраецеся, маеце вялікі досвед, маеце талент? Завошта возьмеце адказнасць на сябе таму, што лічыце, што зладзіцеся з задачай? І вось тут хтосьці адразу пачне аднеквацца: не-не-не, я ў мяне наогул няма ніякага жадання займацца праектнымі рэсурсамі, не мая справа, я тэхнічны чувак і разбіраюся ў юзабіліці і карыстацкіх інтэрфейсах, мне зусім не жадаецца кіраваць войскамі людзей, давайце я лепш пайду працаваць працу.
І дарэчы, я вялікі прыхільнік падыходу, у якім нармальна працуе падобны падзел навыкаў. У якім тэхнічныя спецыялісты могуць кар'ерна расці так далёка, наколькі захочуць. Тым не менш, я ўсё яшчэ сустракаю арганізацыі, дзе тэхнары скардзяцца: мне давядзецца сыходзіць у кіраванне праектамі, таму што гэта адзіны шлях у гэтай кампаніі. Бывае, што гэта прыводзіць да кашмарных зыходаў. Лепшыя тэхнары бываюць зусім ніякімі мэнэджэрамі, і лепшыя мэнэджары могуць не зладзіцца з тэхналогіямі. Давайце будзем сумленнымі ў гэтым плане.
Я бачу зараз вялікі запыт на такое. Калі вы - тэхнар, то ваша кампанія можа дапамагчы вам, але па-за залежнасці ад гэтага, вам трэба, сапраўды трэба знайсці свой уласны кар'ерны шлях, таму што тэхналогіі працягваюць мяняцца, і вам трэба разам з імі перанаходзіць самога сябе! За якія-небудзь дваццаць гадоў тэхналогіі могуць змяніцца не менш за пяць разоў. Тэхналогіі - дзіўная штука…
"Эксперты па ўсім"
Міхаіл: Як жа людзям спраўляцца з такой хуткасцю змены тэхналогій? Іх складанасць расце, колькасць расце, агульная колькасць камунікацыі паміж людзьмі таксама расце, і атрымліваецца - нельга стаць "экспертам па ўсім".
Цім: Правільна! Калі ты займаешся тэхналогіямі - так, зусім дакладна трэба выбраць нешта канкрэтнае і паглыбляцца менавіта ў гэта. У нейкую тэхналогію, якая ваша арганізацыя лічыць карыснай (і магчыма, яна сапраўды акажацца карыснай). А калі вам яна больш не цікавая - ніколі б не паверыў, што скажу гэта - ну можа быць, варта перайсці ў нейкую іншую арганізацыю, дзе тэхналогіі цікавей або зручней для вывучэння.
Але ўвогуле так, вы маеце рацыю. Тэхналогіі растуць ва ўсіх кірунках адразу, ніхто не можа сказаць "я эксперт-тэхнолаг па ўсіх тэхналогіях, якія ёсць". З іншага боку, ёсць людзі-губкі, літаральна якія ўбіраюць тэхналагічныя веды, якія без розуму ад іх. Я бачыў пару такіх людзей, яны літаральна дыхаюць і жывуць гэтым, з імі карысна і цікава паразмаўляць. Яны вывучаюць не толькі тое, што адбываецца ўнутры арганізацыі, а ўвогуле, яны гавораць пра гэта, яны яшчэ і сапраўды з'яўляюцца крутымі тэхнолагамі, яны вельмі ўсвядомленыя і мэтанакіраваныя. Яны проста імкнуцца заставацца на грэбні хвалі, незалежна ад таго, у чым заключаецца іх асноўная праца, бо іх запал - гэта рух Тэхналогіі, прасоўванне тэхналогій. Калі вы раптам сустрэнеце такога чалавека, з ім варта разам хадзіць на абед і за абедам абмяркоўваць розныя крутыя рэчы. Думаю, любой арганізацыі патрэбна хаця б парачка такіх людзей.
Рызыкі і нявызначанасць
Міхаіл: Заслужаныя інжынеры, так. Давайце, пакуль ёсць час, кранем яшчэ кіравання рызыкамі. Мы пачалі гэтае інтэрв'ю абмеркаваннем медыцынскага софту, дзе памылкі могуць прывесці да сумных наступстваў. Далей мы казалі аб Месяцовай Праграме, дзе кошт памылкі - мільёны даляраў, і магчыма - некалькі чалавечых жыццяў. Але зараз я бачу ў індустрыі супрацьлеглы рух, людзі не думаюць аб рызыках, не спрабуюць іх прадказваць, нават не назіраюць за імі.
Алег: Move fast and break things!
Міхаіл: Так, прасоўвайся хутка, ламай рэчы, усё больш і больш рэчаў - і так пакуль не памрэш ад чаго-небудзь. З вашага пункту гледжання, як зараз звычайнаму распрацоўніку падступіцца да вывучэння кіравання рызыкамі?
Цім: Давайце правядзём тут рысу паміж дзвюма рэчамі: рызыкамі і нявызначанасцю. Гэта розныя штукі. Нявызначанасць узнікае, калі ў вас на нейкі абраны момант часу нядосыць дадзеных, каб прыйсці да дакладнага адказу. Напрыклад, на самай ранняй стадыі праекта, калі нехта спытае цябе, "калі вы скончыце працы", калі ты дастаткова сумленны чалавек, ты скажаш: "паняцця не маю". Ты проста не ведаеш, і гэта нармальна. Ты пакуль яшчэ не вывучыў праблемы і не знаёмы з камандай, не ведаеш іх навыкі, і гэтак далей. Гэта - нявызначанасць.
Рызыкі ўзнікаюць, калі ўжо можна вызначыць патэнцыйныя праблемы. Вось такая штука можа здарыцца, яе верагоднасць больш за нуль, але менш за сто працэнтаў, дзесьці паміж імі. З-за яе можа здарыцца што заўгодна, пачынальна ад затрымак і лішняй працы, але і аж да фатальнага зыходу для праекту. Зыходу, калі ты кажаш - хлопцы, згортваем парасоны і з'яжджаем з пляжу, мы ніколі не даробім, усё скончана, кропка. Мы зрабілі здагадку, што вось гэтая штука спрацуе, а яна ўвогуле ніяк не працуе, час спыніцца. Вось такія сытуацыі.
Часцяком праблемы прасцей за ўсё вырашаць, калі яны ўжо вылезлі, калі праблема адбываецца прама зараз. Але калі праблема проста перад табой, ты не займаешся кіраваннем рызыкамі - ты займаешся вырашэннем гэтай праблемы, крызісным кіраваннем. Калі ты вядучы распрацоўшчык або менеджэр, ты павінен задумвацца, што можа здарыцца такога, што прывядзе да затрымак, страты часу, лішніх выдаткаў або краху ўсяго праекта? Што прымусіць нас спыніцца і пачаць усё нанова? Калі ўсе гэтыя рэчы спрацуюць, што мы будзем з імі рабіць? Ёсць просты адказ, справядлівы для большасці сітуацый: не бяжыце ад рызык, працуйце над імі. Паглядзіце, як можна вырашыць рызыкоўную сітуацыю, звесці яе на нішто, ператварыць яе з праблемы ў нешта яшчэ. Замест таго каб казаць: ну, будзем вырашаць праблемы па меры іх паступлення.
Нявызначанасць і рызыкі павінны ісці наперадзе за ўсё, з чым вы маеце спраў. Можна ўзяць план праекта, загадзя паглядзець на пэўныя крытычныя рызыкі і сказаць: трэба з гэтым разабрацца зараз, таму што, калі нешта з гэтага бахне, усё астатняе ўжо не будзе мець значэння. Не варта клапаціцца аб прыгажосці абруса на стале, калі незразумела, ці зможаш ты прыгатаваць абед. Спачатку трэба вызначыць усе рызыкі прыгатавання смачнага абеду, разабрацца з імі, і толькі потым думаць пра ўсе астатнія рэчы, якія не ўяўляюць рэальнай пагрозы.
І зноў, у чым унікальнасць вашага праекту? Давайце паглядзім, што можа прымусіць наш праект з'ехаць з накатаных рэек. Што мы можам зрабіць для мінімізацыі імавернасці, што ўсё гэта адбудзецца. Звычайна вы не можаце проста ўзяць і нейтралізаваць іх на 100%, каб з чыстым сумленнем заяўляць: "Усё, гэта больш не праблема, рызыка рассмактаўся!". Для мяне гэта прыкмета дарослых паводзін. Гэта розніца паміж дзіцем і дарослым - дзеці думаюць, што несмяротныя, што нічога не можа пайсці наперакасяк, усё будзе выдатна! У той жа час, дарослыя глядзяць, як трохгадовыя дзеці скачуць на дзіцячай пляцоўцы, праводзяць вачыма рухі і гавораць пра сябе: "ох - ух, ох - ух". Я стаю непадалёк і рыхтуюся лавіць, калі дзіця ўсё-такі ўпадзе.
З іншага боку, прычына, чаму мне так падабаецца гэты бізнэс - таму што ён рызыкоўны. Мы робім рэчы, і гэтыя рэчы рызыкоўныя. Патрабуюць дарослага падыходу. Энтузіязм сам па сабе не вырашыць вашых праблем!
Дарослае інжынернае мысленне
Міхаіл: Прыклад з дзецьмі добры. Калі я звычайны інжынер, дык мне прыемна быць дзіцем. Але як рушыць наперад да больш дарослага мыслення?
Цім: Адна з ідэй, якія аднолькава добра працуюць хоць з пачаткоўцам, хоць з які адбыўся распрацоўшчыкам - паняцце кантэксту. Што мы робім, чаго мы збіраемся дасягнуць. Што па-сапраўднаму важна на гэтым праекце? Няважна, хто ты на гэтым праекце, хоць інтэрн, хоць галоўны архітэктар, усім патрэбен кантэкст. Трэба зрабіць так, каб усе думалі ў большым маштабе, чым іхныя ўласныя кавалачкі працы. "Я раблю свой кавалачак, і пакуль мой кавалачак працуе - я шчаслівы". Няма і яшчэ раз няма. Заўсёды варта (не пераходзячы на грубіянства!) нагадваць людзям аб кантэксце, у якім яны працуюць. Што мы ўсе разам імкнемся дасягнуць. Ідэі аб тым, што можна быць дзіцем да таго часу, пакуль з тваім кавалачкам праекта ўсё добра - калі ласка, не трэба такога. Калі мы ўвогуле пройдзем фінішную рысу, то мы пройдзем яе толькі ўсе разам. Не ты адзін, усе мы разам. Калі ўсе людзі ў праекце, і дзядкі, і моладзь, пачнуць казаць аб тым, што менавіта важна праекту, чаму кампанія інвесціруе грошы ў тое, што мы ўсе імкнемся дасягнуць… большасць з іх адчуюць сябе куды лепш, таму што ўбачаць, як іх праца суадносіцца з працай усіх астатніх. З аднаго боку, я разумею кавалак, за які адказваю асабіста я. Але каб скончыць працу нам патрэбны і ўсе астатнія людзі таксама. І калі ўжо ты сапраўды вырашыў, што скончыў, у нас у праекце заўжды ёсць праца, якой можна заняцца!
Алег: Умоўна кажучы, калі ты працуеш па канбане, калі ты ўткнуўся ў бутэлькавае рыльца якога-небудзь тэсціравання, можна кінуць чым ты там займаўся (напрыклад, праграмаваннем) і ісці дапамагаць тэсціроўшчыкам.
Цім: Дакладна. Думаю, самыя лепшыя тэхнары, калі вы ўважліва прыгледзіцеся да іх, яны як бы самі сабе мэнэджары. Як бы гэта сфармуляваць…
Алег: Тваё жыццё - гэта і ёсць твой праект, якім ты кіруеш.
Цім: Дакладна! У сэнсе ты ўзяў адказнасць, ты разбіраешся ў пытанні, і ты ўступаеш у кантакт з людзьмі, калі бачыш, што твае рашэнні могуць уплываць на іх працу, усё ў гэтым духу. Гэта зусім не аб тым, каб проста сядзець за сталом, рабіць сваю працу, і нават не здагадвацца, што адбываецца навокал. Не, не, не. Дарэчы, адна з лепшых рэчаў у Agile - гэта тое, што там прапанавалі кароткія спрынты, таму што так стан спраў усіх удзельнікаў добра назіраем, яны могуць назіраць гэта ўсё разам. Мы кожны дзень гаворым адзін пра аднаго.
Як укаціцца ў кіраванне рызыкамі
Алег: Ці ёсць нейкая фармальная структура ведаў у гэтай галіне? Напрыклад, я - Java-распрацоўшчык і хачу разабрацца ў рызыка-менеджменце, не становячыся сапраўдным мэнэджэрам праектаў па адукацыі. Напэўна, спачатку я прачытаю «Колькі каштуе праграмны праект» Маканэла, а далей што? Якія першыя крокі?
Цім: Першы - пачаць мець зносіны людзьмі ў праекце. Гэта дае імгненнае паляпшэнне культуры зносін з калегамі. Трэба пачынаць з таго, каб адчыняць усё вонкі па змаўчанні, замест таго каб хаваць. Кажы: вось такія рэчы мяне турбуюць, вось такія рэчы не даюць мне спаць па начах, я сёння прачнуўся ўначы і такі: бажачкі, гэта трэба абмазгаваць! Ці бачаць астатнія тое ж самае? Мы як група, ці павінны мы рэагаваць на гэтыя патэнцыйныя праблемы? Трэба ўмець падтрымліваць дыскусію на гэтыя тэмы. Няма ніякай загадзя нарыхтаванай формулы, па якой мы працуем. Гэта не вытворчасць гамбургераў, гэта ўсё пра людзей. "Зрабіў чызбургер - прадай чызбургер" - гэта зусім не пра нас, і менавіта таму я так люблю гэтую працу. Мне падабаецца, калі ўсё, чым раней займаліся мэнэджары, зараз пераходзіць ва ўласнасць каманды.
Алег: Вы расказвалі ў кнігах і інтэрв'ю аб тым, што людзі больш турбуюцца аб шчасці, чым аб лічбах на графіцы. З іншага боку, калі вы кажаце камандзе: мы пераходзім на дэвопс, і зараз праграміст павінен увесь час мець зносіны, гэта можа апынуцца далёка за межамі яго зоны камфорту. І ў гэты момант ён можа, скажам так, быць глыбока нешчасьлівым. Што рабіць у гэтай сітуацыі?
Цім: Я не ўпэўнены дакладна, што рабіць. Калі распрацоўшчык занадта ізаляваны, то не бачыць, чаму наогул робіцца праца, ён проста глядзіць на сваю частку працы, і яму неабходна ўглыбіцца ў тое, што я заву "кантэкстам". Яму трэба разабрацца, як усё разам узаемазлучана. Ну і вядома, я не маю на ўвазе фармальнае правядзенне прэзентацый ці нешта падобнае. Я кажу пра тое, што з калегамі трэба мець зносіны наконт працы ў цэлым, а не толькі пра тую яе частку, за якую ты адказваеш. І вось у гэты момант можна пачаць абмяркоўваць ідэі, агульныя дамовы, каб ваша праца добра спалучалася, і пра тое, як разам наваліцца на агульную праблему.
Для адаптацыі тэхнароў часта жадаюць яшчэ і накіраваць на трэнінгі, абмяркоўваюць трэніроўкі. Адзін мой сябар любіць казаць, што трэніроўка - гэта для сабак. Для людзей існуе навучанне. Адна з лепшых рэчаў для навучання распрацоўніка - гэта зносіны з калегамі. Калі хтосьці сапраўды атрымаў поспех у нечым, вам варта паглядзець, як ён працуе, ці абмеркаваць з ім працу, ці нешта такое. Які-небудзь умоўны Кент Бек увесь час казаў аб экстрэмальным праграмаванні. Пацешна, бо XP - гэта такая простая ідэя, але яна дастаўляе столькі праблем. Для кагосьці займацца XP - гэта, як калі б яго прымусілі распранацца дагала перад сябрамі. Яны ж убачаць, чаго я раблю! Яны ж мае калегі, яны не проста ўбачаць, але і зразумеюць! Жахліва! Некаторыя пачынаюць сур'ёзна нервавацца. Але калі вы ўсведамляеце, што гэта ўльтыматыўны спосаб навучання, усё мяняецца. Вы шчыльна працуеце з людзьмі, і сёй-той разбіраецца ў тэме моцна лепш за вас.
Міхаіл: Але ўсё гэта прымушае выйсці з зоны камфорту. Як інжынер, ты павінен выходзіць з зоны камфорту, размаўляць. Як чалавек, які вырашае праблемы, ты павінен увесь час ставіць сябе ў слабую пазіцыю і абдумваць, што можа пайсці не так. Падобная праца па сутнасці сваёй створана, каб дастаўляць нязручнасці. Ты свядома ставіш сябе ў стрэсавыя сітуацыі. Звычайна ж людзі бягуць ад іх, людзям падабаецца быць шчаслівымі дзецьмі.
Цім: Што можна зрабіць, можна выйсці і адкрыта сказаць: «Усё ў парадку, я зладжуся! Не я адзін адчуваю дыскамфорт. Давайце абмяркуем розныя некамфортныя штукі, усё разам, як каманда!». Гэта нашыя агульныя праблемы, мы павінны з імі спраўляцца, разумееце? Думаю, ідыясінкратычныя геніяльныя распрацоўшчыкі - яны як маманты, яны зніклі. Ды і значэнне яны маюць вельмі абмежаванае. Калі вы не можаце мець зносіны, вы не можаце нармальна ўдзельнічаць. Таму - проста кажаце. Будзьце сумленнымі і адчыненымі. Я вельмі шкадую, што камусьці гэта непрыемна. Уяўляеце, шмат гадоў таму было даследаванне, паводле якога ў ЗША асноўны страх - гэта не смерць, а адгадайце што? Страх публічных выступаў! Значыць, недзе ёсць людзі, якія хутчэй памруць, чым услых скажуць камплімент. А вам, думаю, дастаткова мець нейкія базавыя навыкі, у залежнасці ад таго, што вы робіце. Размоўныя навыкі, навыкі ліста - але настолькі, наколькі гэта сапраўды трэба ў вашай працы. Калі вы працуеце аналітыкам, але пры гэтым не можаце чытаць, пісаць і казаць, то на вялікі жаль, вам не будзе чым заняцца ў маіх праектах!
Кошт зносін
Алег: Ці не з'яўляецца выкарыстанне такіх таварыскіх супрацоўнікаў даражэйшым, па розных прычынах? У рэшце рэшт, яны ўвесь час балбочуць замест працы!
Цім: Я меў на ўвазе ядро каманды, а не ўвогуле ўсіх запар. Калі ў вас ёсць спецыяліст, які сапраўды крута настройвае базы дадзеных, любіць наладжваць базы дадзеных і збіраецца працягваць наладжваць вашыя базы дадзеных да канца жыцця, і гэта ўсё - крута, так трымаць. Але я кажу пра людзей, якія жадаюць жыць у самім праекце. Ядро каманды, накіравана якое развівае праект. Гэтым людзям сапраўды неабходна ўвесь час мець зносіны сябар з сябрам. І асабліва, у пачатку праекта, калі вы абмяркоўваеце рызыкі, спосабы дасягнення глабальных мэт і таму падобныя рэчы.
Міхаіл: Гэта адносіцца да ўсіх, хто заняты ў праекце, незалежна ад спецыялізацыі, навыкаў, спосабаў працы. Вы ўсё зацікаўлены ў поспеху праекта.
Цім: Так, ты адчуваеш, што дастаткова пагрузіўся ў праект, што твая задача - дапамагаць праекту ажыццявіцца. Будзь ты праграміст, аналітык, дызайнер інтэрфейсаў, хто заўгодна. Гэта прычына, чаму я прыходжу на працу кожную раніцу, і гэта тое, чым мы займаемся. Мы адказваем за ўсіх гэтых людзей, незалежна ад іх навыкаў. Гэта група людзей, якія вядуць дарослыя размовы.
Алег: Насамрэч, кажучы пра гаманкіх супрацоўнікаў, я паспрабаваў сімуляваць пярэчанні людзей, у асаблівасці, менеджэраў, якім прапануюць перайсці на дэвопс, на ўсё гэта новае бачанне свету. І вам, як кансультантам, гэтыя пярэчанні павінны быць вядомыя куды лепш, чым мне як распрацоўніку! Падзяліцеся, што больш за ўсё хвалюе мэнэджэраў?
Цім: Мэнэджараў? Хм. Часцей за ўсё менеджэры знаходзяцца пад прэсам праблем, перад неабходнасцю тэрмінова нешта зарэлізаваць і зрабіць пастаўку і да таго падобнае. Яны глядзяць, як мы ўвесь час нешта абмяркоўваем і спрачаемся, і бачаць гэта так: размовы, размовы, размовы… Якія яшчэ размовы? Вяртайцеся да працы! Бо размовы для іх не падаюцца нечым, падобным да працы. Вы не пішаце код, не тэстуеце софт, нічога, здавалася б, не робіце - чаму б не адправіць вас займацца справай? Бо пастаўка ўжо праз месяц!
Міхаіл: Ідзі пісаць код!
Цім: Мне здаецца, што непакояцца яны не аб працы, а аб адсутнасці бачнасці прасоўвання наперад. Каб ім падалося, што мы набліжаемся да поспеху, ім трэба бачыць, як мы націскаем кнопкі на клавіятуры. Цэлы дзень з раніцы да вечара. Гэта праблема нумар адзін.
Алег: Міша, чагосьці ты задумаўся.
Міхаіл: Прабач, я задумаўся, злавіў флэшбек. Усё гэта нагадала мне адзін цікавы мітынг, які адбыўся ўчора… Учора было зашмат мітынгаў… І ўсё гэта гучыць вельмі знаёма!
Жыццё без заробкаў
Цім: Дарэчы, зусім не абавязкова для зносін ладзіць менавіта "мітынгі". У сэнсе, самыя карысныя дыскусіі паміж распрацоўшчыкамі адбываюцца, калі яны проста размаўляюць паміж сабой. Ты заходзіш раніцай з кубкам кавы, а там людзі сабраліся ўпяцёх і нешта тэхнічнае люта абмяркоўваюць. Па мне так, калі я менеджэр гэтага праекту, тут лепш проста ўсміхнуцца і пайсці куды-небудзь па сваіх справах, няхай абмяркоўваюць. Яны ўжо ўцягнутыя як нельга мацней. Гэта добры знак.
Алег: Дарэчы, вось у вас у кнізе куча нататак аб тым, што добра і што дрэнна. А вы самі выкарыстоўваеце нешта з іх? Умоўна кажучы, вось у вас жа ёсць зараз кампанія, ды яшчэ і вельмі неартадаксальна ўладкованая…
Цім: Неартадаксальна, але такая прылада нам выдатна падыходзіць. Мы ведаем адно аднаго, даўно. Мы давяраем адзін аднаму, давяралі адзін аднаму моцна раней за тое, як сталі партнёрамі. І напрыклад, у нас увогуле няма заробкаў. Мы проста працуем, і напрыклад, калі я зарабіў грошай са сваіх кліентаў, то і грошы ўсё пайшлі мне. Пасля гэтага мы плацім у арганізацыю сяброўскія ўнёскі, і гэтага хапае на тое, каб утрымліваць саму кампанію. Плюс, усе мы спецыялізуемся ў розных рэчах. Напрыклад, я працую з бухгалтарамі, запаўняю падатковыя дэкларацыі, раблю ўсякія адміністрацыйныя рэчы для кампаніі, і мне ніхто за гэта не плаціць. Джэймс і Том працуюць над нашым сайтам і ім таксама ніхто не плаціць. Пакуль вы плаціце свае ўнёскі, ніхто і не падумае расказваць вам, што вам трэба рабіць. Напрыклад, Том зараз працуе значна менш, чым калісьці. Цяпер у яго ёсць і іншыя інтарэсы, сёе-тое ён робіць не для Гільдыі. Але датуль, пакуль ён плаціць свае ўнёскі, ніхто не падыдзе да яго і не скажа: "Гэй, Том, а ну-ка ідзі працаваць!". Вельмі проста мець справу з калегамі, калі паміж вамі не стаяць грошы. І зараз наша ўзаемасувязь - гэта адна з асноўных ідэй, у дачыненні да розных спецыяльнасцях. Гэта працуе, і гэта працуе вельмі добра.
Лепшая рада
Міхаіл: Вяртаючыся да «лепшай парады», ці ёсць нешта такое, што вы штораз паўтараеце сваім кліентам? Ёсць жа ідэя пра 80/20, і напэўна нейкая рада паўтараецца часцей.
Цім: Калісьці я думаў, што калі напісаць кніжку накшталт "Вальсуючы з мядзведзямі", гэта памяняе ход гісторыі і людзі перастануць, але… Ну вось глядзіце, часта кампаніі робяць выгляд, што ў іх усё добра. Як толькі здарылася нешта дрэннае - гэта для іх шок і сюрпрыз. «Глядзіце, мы пратэставалі сістэму, і яна не праходзіць ніякіх сістэмных тэстаў, а гэта ж яшчэ тры месяцы нечарговай працы, як жа такое магло здарыцца? Хто ведаў? Што магло пайсці не так?». Сур'ёзна, вы ў гэта верыце?
Я спрабую тлумачыць, што не варта злавацца на бягучую сітуацыю занадта моцна. Трэба абгаварыць яе, па-сапраўднаму зразумець, што магло пайсці не так, і як прадухіляць такія рэчы ў будучыні. Калі ўсё ж такі праблема выявіцца, як мы будзем з ёй змагацца, як стрымліваць.
Па мне так, усё гэта выглядае жахліва. Людзі маюць справу са складанымі, непрыемнымі праблемамі, і працягваюць рабіць выгляд, што калі яны проста скрыжуюць пальцы і будуць спадзявацца на лепшае - гэта самае "лепшае" сапраўды адбудзецца. Не, дык не працуе.
Займайцеся кіраваннем рызыкамі!
Міхаіл: З вашага пункту гледжання, як шмат арганізацый займаюцца мэнэджментам рызык?
Цім: Што мяне раз'юшвае, дык гэта тое, што людзі проста выпісваюць рызыкі, глядзяць на атрыманы спіс і ідуць працаваць. Па сутнасці, ідэнтыфікацыя рызык для іх і з'яўляецца мэнэджментам рызык. А для мяне гэта гучыць як нагода для пытання: добра, спіс ёсць, што менавіта вы будзеце мяняць? Трэба змяніць свае стандартныя паслядоўнасці дзеянняў з улікам гэтых рызык. Калі ёсць нейкая найболей складаная частка працы, трэба заняцца менавіта ёй, і толькі потым пераходзіць да прасцейшага. На першых жа спрынтах пачаць вырашаць складаныя праблемы. Вось гэта ўжо падобна на мэнэджмент рызык. Але звычайна людзі не могуць сказаць, што яны памянялі пасля складання спісу рызык.
Міхаіл: І ўсё ж, колькі такіх кампаній, якія займаюцца кіраваннем рызыкамі, працэнтаў пяць?
Цім: На жаль, мне непрыемна гэта казаць, але гэта нейкая зусім нязначная частка. Але больш за пяць, таму што ёсць сапраўды вялікія праекты, і яны проста не могуць існаваць, калі яны не робяць хаця б нешта. Скажам так, я моцна здзіўлюся, калі гэта хаця б 25%. Маленькія праекты звычайна так адказваюць на падобныя пытанні: калі праблема нас закране, тады і будзем яе вырашаць. Потым яны паспяхова ўляпваюцца ў праблему, і займаюцца кіраваннем праблемамі і антыкрызісным кіраваннем. Калі ты спрабуеш вырашыць праблему, а праблема не вырашаецца - сардэчна запрашаем у антыкрызіснае кіраванне.
Так, я часта чую, "будзем вырашаць праблемы па меры паступлення". Як будзем? А сапраўды вырашым?
Алег: Можна рабіць наіўна і проста ўпісваць у статут праекта важныя інварыянты, і калі інварыянты зламаліся - проста перазапускаць праект. Атрымліваецца вельмі па-піэмбучнаму.
Міхаіл: Так, у мяне такое было, што калі спрацоўвалі рыскі, праект проста перавызначаўся. Найс, Бінга, праблема вырашана, можна больш не турбавацца!
Цім: Давім кнопку перазагрузкі! Не, дык не працуе.
Кейноут на DevOops 2019
Міхаіл: Падыходзім да апошняга пытання гэтага інтэрв'ю. Вы прыязджаеце на наступны DevOops з кейнаўтам, не маглі б прыадчыніць заслону таямніцы над тым, што вы збіраецеся расказаць?
Цім: Прама зараз шасцёра з пішуць кнігу аб працоўнай культуры, нявыказаных правілах арганізацый. Культура задаецца асноўнымі каштоўнасцямі арганізацыі. Звычайна людзі гэтага не заўважаюць, але мы, працуючы ў кансалтынгу на працягу шматлікіх гадоў, абвыклі гэта прыкмячаць. Ты заходзіш у кампанію і літаральна праз некалькі хвілін пачынаеш адчуваць, што адбываецца. Мы называем гэта "водарам". Часам гэты водар сапраўды добры, а часам гэта ну, упс. У розных арганізацыяў усё вельмі па-рознаму.
Міхаіл: Я таксама гадамі працую ў кансалтынгу і добра разумею, пра што вы зараз.
Цім: Уласна, адна з рэчаў, пра якую варта пагаварыць на кейнаўце, што не ўсё вызначаецца кампаніяй. Вы і ваша каманда, як супольнасць - у вас ёсць уласная камандная культура. Гэта можа быць як уся кампанія, так і асобны дэпартамент, асобная каманда. Але да таго, як ты сказаў: вось у што мы верым, вось што важна… Ты не можаш змяніць культуру да таго, як былі ўсвядомлены каштоўнасці і перакананні, якія стаяць за канкрэтнымі дзеяннямі. Паводзіны назіраць лёгка, а шукаць перакананні - складана. DevOps - гэта як раз выдатны прыклад таго, як усё становіцца складаней і складаней. Узаемадзеянні становяцца толькі складаней, яны ўвогуле не становяцца чысцейшымі і зразумелымі, так што вам варта задумвацца над тым, у што вы верыце, і пра што ўсе вакол маўчаць.
Жадаеце дамагчыся хуткіх вынікаў, вось вам добрая тэма: ці бачылі вы кампаніі, у якіх ніхто не кажа "я не ведаю"? Ёсць месцы, у якіх трэба літаральна катаваць чалавека датуль, пакуль ён прызнаецца, што чагосьці не ведае. Усе ўсё ведаюць, усё запар неверагодныя эрудыты. Падыходзіш да любога чалавека, і яму даводзіцца імгненна нешта адказваць на пытанне. Замест таго каб сказаць "Я не ведаю". Ура, яны нанялі натоўп эрудытаў! А ў нейкіх культурах увогуле вельмі небяспечна казаць «Я не ведаю», гэта можа быць успрынята як праява слабасці. Ёсць і арганізацыі ў якіх наадварот, усе могуць казаць "я не ведаю". Там гэта цалкам легальна, і калі хтосьці ў адказ на пытанне пачне ўціраць дзічыну, зусім нармальна адказаць: "Ты ж не разумееш, пра што кажаш, дакладна?" і звесці ўсё на жарт.
У ідэале, хацелася б мець такую працу, на якой ты мог бы ўвесь час быць шчаслівы. Гэта будзе няпроста, не кожны дзень сонечны і прыемны, часам трэба напружана працаваць, але калі ты пачнеш падводзіць вынікі, то акажацца: вау, гэта сапраўды цудоўнае месца, мне добра тут працаваць, і эмацыйна, і інтэлектуальна. А ёсць кампаніі, у якія ты заходзіш як кансультант і імгненна разумееш, што і тры месяцы б не вытрымаў і збег бы ў жаху. Вось пра гэта я і хачу пагаварыць на дакладзе.
Цім Лістэр прыедзе з кейнаўтам на канферэнцыю DevOops 2019, якая адбудзецца 29-30 кастрычніка 2019 г. у Санкт-Пецярбургу. Набыць білеты можна . Чакаем вас на DevOops!
Крыніца: habr.com