Тім Лістер - співавтор книг
- "Людський фактор. Успішні проекти та команди» (в оригіналі книга називається «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