Тим Листер — соавтор книг
- «Человеческий фактор. Успешные проекты и команды» (в оригинале книга называется «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