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