-
Образовательно-развлекательный блог про управление разработкой. Личный опыт, рефлексия прочитанных книг, ссылки на исследования.
Структурированный подход к оценке кандидатов на интервью
Я уже писал про бесполезность стандартных интервью для оценки навыков кандидатов (хотя они по-прежнему имеют смысл в воронке найма, об этом будет в другой серии). Давайте посмотрим, какие подходы к интервью используют в структурах с высоким уровнем критичности — армия и государственные службы.
В 1950х молодой студент-психолог исследовал, как можно повысить качество отбора офицеров в армии государства Израиль. Студента звали Даниэль Канеман (тот самый, который впоследствии получил Нобелевскую премию и написал книгу “Думай медленно... Решай быстро”).
Канеман обнаружил, что нет никакой корреляции между оценкой, полученной на собеседовании, и последующими результатами в обучении будущих офицеров. Он также отметил, что в из-за отсутствия измеримых критериев отбора, вопрос “Насколько кандидат подходит для данной роли?” в голове интервьюера был близок к вопросу “Насколько мне нравится этот кандидат?”.
На замену существовавшему тогда подходу Канеман предложил использовать подход структурированных интервью, когда каждый кандидат оценивается по заранее определенному набору компетенций. Каждому из кандидатов задаются одни и те же вопросы, в одном и том же порядке, на основании ответов интервьюер оценивает компетенции кандидата по шкале от 1 до 5. Далее оценки по компетенциям суммируются, решение относительно кандидата принимается на основании “проходного балла”. Звучит как бред и бездушная машинерия? Соглашусь. Вот только результаты оценки на интервью начали устойчиво коррелировать с дальнейшей успеваемостью курсантов. Со статистикой было трудно спорить и, несмотря на большое сопротивление, структурированные интервью начали использовать в израильской армии.
Этот случай дал толчок многочисленным исследованиям процесса интервью, в результате которых подтвердилась эффективность структурированного подхода.
Структурированные интервью также используются при найме на госслужбу в Штатах. Кстати, управление кадровой службы США выложило в свободный доступ материалы о том, как готовить и проводить структурированные интервью.
Ссылка: https://www.opm.gov/policy-data-oversight/assessment-and-selection/
#найм #история
Две вещи, о которых забывают при выборе технологий
Выбор технологий зачастую является предметом вкусовщины: “angular стрёмный, react молодец!”, “react сложо, vue.js огонь!”, “Rust или C++”. Несомненно личные предпочтения важны, когда работаешь с технологией каждый день. Однако, вкусовщина не должна быть решающим фактором. Понимание, каким образом технология позволит снизить сложность проекта, и опыт работы с ней — ключевые факторы.
Помимо этого, есть ещё пара аспектов, которые часто забывают оценить при выборе технологий:
Время жизни технического решения
Сколько времени предполагается поддерживать кодовую базу? Месяц? Год? 5 лет? 10? Согласитесь, от этого многое зависит. Есть ли у технологии предсказуемый релизный цикл, гарантия обратной совместимости при обновлении? Проживет ли вообще технология тот срок, в котором вы рассчитываете ее использовать? Можно вспомнить массу плохих примеров из 2010х, когда абсолютно всё было принято делать на Ruby on Rails или Django, а потом бороться с обновлениями версий. Rust и GO — хорошие примеры, где при выходе новой версии языка можно обновить toolchain, не внося изменений в кодовую базу.
Возможности найма
Как мы будем нанимать людей для работы с этой технологией? Сколько их на рынке? В случае бурного роста, сможем ли мы в разумные сроки привлечь нужное количество людей? Возможно, действительно, closure, erlang или rust — это идеальные технологии для вашего проекта. Вот только сколько этих людей на рынке? А кого на них можно быстро переучить? Матерых плюсовиков с опытом 10+ лет? А где они работают? А к вам пойдут? Осилите по зарплатам?
Выбор технологий для ключевых компонентов может быть стратегическим решением, так как во многом будет определять размер и структуру команд разработки, а также подход к обучению людей.
#менеджмент
Игры в архитекторов на старте проекта
В нашей молодой индустрии инженеры не умеют проектировать системы. Почему так происходит? Давайте возьмем разработчика с опытом работы 5 лет. Сколько новых проектов он начинал с нуля? Один? Три? Пять? А на скольких проектах он почувствовал на себе результаты принятых технических решений? Один или два максимум. Это не камень в сторону разработчиков, это просто состояние индустрии – скорее алхимия, чем инженерия.
Старт нового проекта — это всегда волнующий момент для разработчиков. Столько идей: какие технологии использовать, какой должна быть «архитектура», в каком формате хранить конфиги. За всеми этими прекрасными занятиями легко упустить вещи, которые реально могут повлиять на успех проекта. Например:
Понимание нужд стейкхолдеров
К сожалению, этот термин используют, не зная определения, называя «стейкхолдерами» важных боссов, которых непременно нужно удовлетворить своим проектом. А, тем временем, стейкхолдеры — это лица, которые могут влиять на проекты или подвержены влиянию со стороны проекта. Биг боссы, конечно же, стейколдеры. Вот только ребята из оперирования, которые дежурят по ночам и следят за стабильностью сервисов — тоже стейкхолдеры. И даже поддержка пользователей, в которую будут прилетать заявки от новой классной фичи, — тоже. Проектировать систему без понимания потребностей — это путь к успеху.
Договориться об атрибутах качества
Reliability, availability, scalability — вот это всё; на Википедии их под сотню (см. List of system quality attributes). Без явного решения относительно конфликтующих атрибутов качества, во время активной разработки будет трудно принимать технические решения. Без них же трудно определить, что такое технический долг. В результате появляется вкусовщина: «Я инженер, я так вижу».
Составить план релиза и стратегию отката
Какие действия необходимо выполнить перед релизом? Кого уведомить об изменениях? Как мы поймём, что что-то идёт не так? Что будем делать, если потребуется откатываться? На все эти вопросы следует ответить заранее, а не когда уже пригорело и нужно срочно действовать.
Важным является то, что влияет на успех проекта в коротком и долгосрочном периоде. Это зависит от контекста конкретного проекта, конкретной команды, конкретной компании. Никто, кроме людей внутри, не может знать ответов. Важно дать людям знания и инструменты, чтобы они начали искать ответы. Знание методологии и умение объяснить критерии выбора важнее знания ответов на конкретные вопросы. У нас же инженерия, а не шаманизм.
#архитектура #рассуждения
Масштабирование разработки: что мы оптимизирует?
В период бурного роста компании масштабирование разработки обычно происходит по следующей схеме:
Надо выпускать фичи быстрее — давайте добавим людей в команду! Давайте сделаем больше команд!
Хаоса от этого становится больше, забот тоже. А так как time to market никто толком не измеряет, то на фоне общего шума появляться ощущение, что вроде бы стало быстрее.
В действительности увеличение пропускной способности редко приводит к уменьшению t2m. Почему так?
Разработка находится в середине процесса
Мы пытаемся масштабировать узел в середине процесса, не оценив, сколько предыдущий узел может производить и сколько следующий узел способен принять на вход. С упрощением деплоя и CI/CD, разработка зачастую — последний этап, но так ещё не везде. А вот с pre-production лучше не становится, и даже agile не помогает (миллион одновременных инициатив, непредсказуемое время поставки требований).
Параллельная работа требует синхронизации
Про оверхед на синхронизацию программистам хорошо известно. Это же применимо и к процессам. Ну будет 100500 фичей в разработке одновременно. Мерджить-то их все равно по очереди! Тестирование и коммуникация усложняются на порядок.
Приведу бытовой пример. Канализационная труба такая толстая, чтобы справляться с резким возрастанием объема входящего трафика, не создавая заторов, а не потому, что каждый запрос занимает весь канал.
Наращивать пропускную способность имеет смысл в том случае, когда специфика работы предполагает резкое увеличение объема работы, которую нужно выполнить, не создавая задержек (Правда для этого требуется, чтобы существенная часть людей была НЕ занята, но об этом как-нибудь потом).
Добавить людей — это не универсальное решение всех проблем. Ускориться за счёт расширения команды получится только в очень редких случаях (когда не требуется дополнительной синхронизации). Перед тем, как что-то менять, следует определиться с целью. Мы хотим увеличить пропускную способность или сократить время выпуска? Скорее всего, второе — time to market. В этом случае, в первую очередь, следует думать не о расширении команд. Тогда о чём же?
Проведите мысленный эксперимент: При текущих процессах, сколько времени потребуется на выпуск тривиальной фичи (однострочное изменение в коде)? Где теряется время? Каких задержек можно избежать?
Вот там и следует оптимизировать.
#менеджмент
Ошибки менеджера: не строить отношений
Рефлексируя свой опыт, хочется подумать над ошибками. Первое, что приходит на ум — не строить доверительных отношений. С кем? С людьми в команде, с другими руководителями, с ключевыми стейкхолдерами.
Почему это плохо?
Трудно проводить изменения
Без поддержки в команде даже хорошие начинания могут плохо закончиться: внедрение CI, code-review, ретроспективы. Всё это может встретить сопротивление. Имея хорошие отношения с людьми в команде, у вас появляются агенты изменений, которые помогают их «продать».
Отношения с командой деградируют
Слышали фразу «Люди приходят в компанию, а уходят от руководителя»? — отчасти из-за этого. Существуют и обратные примеры, когда целые департаменты уходили вслед за руководителем в другую компанию. Бывали в ситуации когда к вам приходит сотрудник с предложением другой компании на руках и говорит: “Я ухожу”. А почему он раньше не пришел, когда только задумался по сторонам посмотреть?
Перестаешь получать обратную связь
Конечно приятно думать, что делаешь всё хорошо, раз никто не утверждает обратного. Скорее всего это самообман, и вы просто не замечаете своих косяков. Без обратной связи происходит отрыв от реальности, и начинаешь работать в стиле «я так вижу». Так и появляются старожилы в компании, которые рьяно защищают свое наследие. На эту тему есть отдельный пост.
Счастье, если среди подчинённых окажется человек, способный называть вещи своими именами, но ведь и его можно проигнорировать. Розовые очки — надежный фильтр.
Слабая позиция в организации
Давайте будем честны: корпоративная среда — тот ещё «клубок змей». Можно уйти в отпуск, вернуться и не обнаружить своего департамента. Независимо от того, насколько вы хороший менеджер, в организации есть своя политика.Чем больше людей на разных уровнях понимают, что вы делаете и почему это важно, тем лучше для вашей команды.
Конечно IT индустрия богата интровертами, но не следует путать личные предпочтения с умением разговаривать.
Коммуникация — это навык, ему можно научится и он будет работать на вас.
Отношения — это хорошая инвестиция, и она начинает приносить «проценты» очень быстро.
#ошибкименеджера #менеджмент
Сколько стоит технический долг?
«Что мы получим, сделав эту задачу?» — на этом вопросе заканчиваются многие диалоги разработчиков с product manager’ами о технических задачах. Иногда кажется, что каждый из них говорит на своём языке. При этом слова одного языка, похоже, не имеют прямого перевода на другой.
При аргументации разработчики склонны апеллировать к профессионализму и тому, что считается хорошими практиками в индустрии, упуская экономику вопроса, а именно она и интересна другой стороне.
Есть две метрики технического здоровья, которые легко трансформируются в деньги и позволяют приоритизировать технический долг.
MTTR – mean time to repair, среднее время восстановления. Иными словами — если мы упали, как долго мы чинимся?
MTBF – mean time between failures, среднее время между отказами. Как часто мы падаем?
Эти два показателя позволяют оценить влияние технического долга в деньгах. Мы же знаем, сколько мы теряем если сервис не работает? (Этот вопрос стоит задать product manager’у).
Зачем увеличивать покрытие тестами? С текущим покрытием 50% релизов откатывается обратно из-за ошибок. Есть данные по прошлым релизам, по времени простоя в результате этих релизов (например логи), знаем сколько стоит минута простоя, можем выразить потери в деньгах.
Зачем рефакторить модуль? Когда у нас случается баг в этом модуле, у нас уходят часы, чтобы подготовить фикс. Как часто возникали баги, связанные с этим модулем? Как долго мы их фиксили? Сколько пользователей пострадало? Знаем потери.
Вроде понятная логика — технический долг не приносит денег, но позволяет их не терять. Однако без промежуточных рассуждений связь с деньгами не очевидна. Ошибка разработчиков, на мой взгляд, заключается в том, что основным аргументом они приводят сокращение времени на разработку новых фичей в будущем, правда не уточняют, когда именно оно наступит. Безусловно, хорошее техническое здоровье влияет на время выпуска, но есть и другие факторы (например, качество требований, внешние зависимости), так что трудно предсказать, сократится ли время на разработку. А вот MTTR и MTBF основаны на прошлом, они про то, что мы уже потеряли и теперь знаем, как уменьшить потери.
В разговорах о техническом долге не переоценивайте способность людей выстраивать причинно-следственные связи, сделайте домашнюю работу и донесите ценность на понятном языке.
#techdebt
Исследование об эффективности интервью
На заре карьеры, когда я начал участвовать в процессе собеседования как интервьюер, я совершенно не знал, что делать, и просто начал копировать то, что делают другие люди. Обучение, тренинги и собственные мысли пришли гораздо позже.
В каждой компании уверены, что они умеют проводить собеседования, нанимают “правильных” людей, а “неправильных” фильтруют через воронку собеседований.
Так ли это? Уже много лет исследования говорят — нет, это не ошибка! Тот процесс, который принят в бизнес-среде (когда кандидату задаются произвольные вопросы), не работает! Неструктурированные интервью значительно подвержены влиянию когнитивных искажений. Мы нанимаем тех, кто нам симпатичен как человек, но это не всегда говорит о способности выполнять работу.
В исследовании “Belief in the unstructured interview: The persistence of an illusion” от 2013 года авторы поставили следующий эксперимент: каждого из респондентов просили предсказать средний балл студента в текущем семестре, основываясь на его биографических сведениях и среднем балле за прошлый семестр. Исследователи дали вводную, что наиболее значимым фактором для предсказания является прошлое значение среднего балла студента.
Далее респондентов поделили на две группы: первая группа делала предсказания на основании предоставленной информации, во второй группе респонденты, в дополнение к имеющейся информации, проводили интервью со студентом перед тем, как сделать свой прогноз.
Кто был более точен в оценках? Прогнозы респондентов из второй группы (где было интервью) имели большее отклонение от реальной оценки, чем прогнозы, данные на основании биографии и среднего балла за прошлый семестр. Все статистические выкладки см. в исследовании.
Мало того, несмотря на вводную от организаторов, что прошлая оценка точнее всего предсказывает текущую, участники второй группы утверждали, что именно интервью дало им наибольшее количество информации для принятия решения (респондентов сначала опрашивали, а потом раскрывали, насколько совпал прогноз с оценкой).
Какие выводы?
1. Следует с большим скепсисом относиться к качеству отбора в процессе собеседования и оценивать людей на основании результатов работы.
2. В компании, где испытательный срок закрывается у 100% кандидатов, скорее всего работают случайные люди.
Ссылка на исследование: http://journal.sjdm.org/12/121130a/jdm121130a.pdf
#найм #менеджмент
Граница в отношениях руководитель — подчиненный
«Нам менеджер сказал не писать тесты и запилить эту фичу по-быстрому.»
«Мне сказали делать так, вот я и делаю»
Мне часто доводилось слышать такое, особо в случаях, когда руководитель без технического опыта управляет технической командой.
Получается, что авторитет и позиция в иерархии важнее компетентности в принятии решений. С другой стороны, понимаю такую покладистость со стороны разработчиков: ведь обычно мы не проверяем на собеседовании навыки переговоров, умение аргументировать, конфликт-менеджмент...
Если случайный разработчик завтра уйдет с проекта, сколько времени потребуется, чтобы найти нового? В моем опыте — 3 месяца от открытия вакансии до выхода человека, для синьоров — 6. Это только найти, а надо еще в специфику проекта вникнуть, понять как всё устроено. Это говорит о том, что у рядового разработчика достаточно много критических знаний о деталях работы системы, связях, рисках. Не обесценивайте их, проявляйте понимание, сдержанность и настойчивость. Не ходите туда, куда вас посылают, но и не посылайте в ответ. Не надо пугаться слова «менеджер» в названии позиции, как минимум, потому, что, когда ночью развалится продакшен, чинить его вам, а не вашему менеджеру.
Если вы менеджер, понимайте различие в том, кто несет ответственность за решения, и кто обладает необходимой экспертизой, чтобы принимать это решение. Это почти всегда разные люди! RACI-матрица в помощь.
Тут стоит привести контр-пример из западной разработки, где есть позиции principal и staff engineer. Это такие разработчики, которые принимают технические решения на уровне всей компании, участвуют в разработке стратегии, зачастую репортят напрямую CTO, и при этом пишут код. Они разработчики, у них нет подчиненных, но при этом могут сказать: «Директор? Да пошел ты в жопу директор!».
#корпоративнаякультура #менеджмент
Ценность и цель управленческих решений
Как менеджеры, мы выстраиваем процессы, измеряем метрики, стремимся выполнять KPI. А для чего? Я говорю в практическом смысле: какая цель за этим стоит?
Я часто слышал ответ на этот вопрос — “Деньги!”. Это отчасти верный ответ, но в нем кое-что упущено. Цель продуктовой разработки — максимизация ценности генерируемой за жизненный цикл продукта. Не просто деньги, а деньги, которые продукт принесет за всю свою жизнь, lifetime value. Интеграл денег по времени, получается.
Держа эту цель в голове принимать многие решения становится проще:
Нужно ли нанимать больше людей? Это увеличит lifetime value?
Нужно ли вкладывать в R&D? Как это повлияет на lifetime value?
Нужно ли вкладываться в engineering excellence и повышать качество? Как низкое качество и отказы влияют на lifetime value?
Нужно делать следующую фичу или устранять технический долг? Ну вы поняли.
Это не волшебная палочка, многие из упомянутых вещей трудно численно измерить. Однако, если вы можете выстроить связь планируемого изменения с конечной целью, то вы можете критически осмыслять плюсы и минусы решения, вы можете сравнивать решения между собой, вы можете попросить коллег поискать дыры в ваших рассуждениях.
Понимание конечной цели позволяет критически осмыслять ваши решения, последствия которых станут видимы очень нескоро, возможно, вы уже будете не на этой позиции и не в этой компании. И что останется после вас?
#менеджмент #рассуждения
Метод идеализированного проектирования систем
Улучшая существующую систему эволюционно, мы начинаем мыслить в рамках текущей реализации системы и забываем о цели, для которой эта система создавалась.
Перекладывая на архитектуру: что в текущей реализации ваших сервисов реально помогает достигать бизнес-целей, а что лишь привносит дополнительные сложности и ограничения?
Помните телефоны с дисковым номеронабирателем? Этот способ набора номера существовал почти сотню лет. Менялась форма, менялись материалы, но принцип действия оставался тем же – серия импульсов для каждой цифры.
В этом видео Russell Ackoff рассказывает, как в 1951 году группа ученых в Bell Labs придумала телефон с кнопками. Группа руководствовалась следующей предпосылкой: Представим, что телефонов больше не существует и нам требуется изобрести технологию заново. Какой она должна быть? У них было два ограничения: решение должно быть технически реализуемо и операционно прибыльно.
Где-то в то же время, благодаря Idealized design подходу, родились идеи беспроводной связи, определителя номера, видеоконференций и многого из того, что мы сейчас воспринимаем как данность.
Ссылка: https://www.youtube.com/watch?v=spm2HUxgI30
#история #архитектура #видеопотеме
C4 model для визуализация архитектуры
Основная проблема с архитектурой в том, что одно дело задизайнить классное решение, и совсем другое — сделать так, чтобы понимание этого решения появилось в головах других людей, а изменения в системе были согласованными.
Архитектура случайно взятой системы выглядит как квадратики со стрелками, и только БД почему-то рисуют как цилиндр. Глядя на это современное искусство трудно понять: где границы системы? Какие основные компоненты? Как компоненты коммуницируют между собой? Какие протоколы используются? Попробуйте взять диаграммы из одной команды и попросить другую команду ответить на вопросы, описанные выше по этой диаграмме.
Конечно, есть стандарты документирования архитектуры ISO 42010. Кто-нибудь видел это вживую? Есть UML, у которого одна проблема: он слишком технический для нетехнических людей и недостаточно технический — для технических.
В итоге, имеем устаревшие фотографии досок с квадратиками и стрелками. А когда в команду приходит новый человек, мы рисуем новую версию и обновляем фоточку в wiki.
Simon Brown предложил 4C model для визуализации архитектуры: context-container-component-code. Simon приводит аналогию с зумом на карте, чтобы начать ориентироваться на местности, требуется посмотреть карту на разных уровнях детализации. Всего 4 диаграммы, у каждой конкретная задача и цель моделирования. Для каждого уровня есть рекомендации как оформлять квадратики и что писать на стрелках. Сложность поддержки минимальная, время на вхождение в проект снижается драматически. Для внедрения нужно только научить команды пользоваться нотацией, а чтобы показать что проблема существует прекрасно подходят architecture katas.
Ссылка: https://c4model.com/
#инструменты #архитектура
Если вам не интересно как Боб Мартин (который написал Clean Code и Clean Architecture) рассказывает сотрудникам CERN (где адронный коллайдер; там ещё html и www придумали), почему вода липкая, как с помощью стакана воды, спичек, соли и батареек показывать фокусы детям, а также получить оксид дейтерия, можете пропустить первые 5 минут видео.
Если вам не интересна история компьютеров, что изобрёл Алан Тьюринг, и история профессии программиста, можете пропустить ещё 20 минут.
Однако непременно посмотрите последние 30 минут, где он рассказывает про technical leadership и этику разработки софта:
- Почему «и так сойдёт» не надо выпускать в прод
- Всегда быть готовыми к релизу
- Возрастающая продуктивность разработки
- Высокое качество софта
Ссылка: https://youtu.be/LmRl0D-RkPU
#видеопотеме
Основные принципы Continuous delivery
Dave Farley, автор термина “continuous delivery” и одноименной книги, рассказывает про цели CD и основные принципы построения deployment pipeline:
- Цель continuous delivery – иметь софт, всегда готовый к релизу.
- Основный принцип, на котором следует строить CD pipeline — всеми проверками стремиться доказать, что текущий коммит нельзя выпускать в продакшен. (Да-да, не сказать, что всё хорошо, а сказать что что-то не работает)
- Примеры визуализации процесса, которая позволяет понять сколько времени занимает текущий процесс, включая время на передачу артефактов из рук в руки.
- О том, какие проверки включать в пайплайн, и best practices по его организации.
Видео на 18 минут по ссылке: https://youtu.be/kgYhZOzb6EM
#техническийкругозор #инструменты #видеопотеме
Разочарования разработчиков от перехода в архитекторы
Я несколько раз видел как в компании открывали новую роль “архитектор”, на нее назначались наиболее опытные разработчики и зачастую это заканчивалось разочарованием, в первую очередь, для новоиспеченных архитекторов, а иногда и для компании.
Для начала хочется порассуждать, кто такие архитекторы, и как появляется потребность в такой роли.
Потребность в роли появляется тогда, когда техническое решение перестает помещаться в одной голове, и начинают вырисовываться отдельные компоненты системы. Роль архитектора появляется вместе с потребностью вносить согласованные изменения в различные компоненты и следить за общей картиной всей системы. Зачастую архитектором становится разработчик, который хорошо знает систему, возможно сам написал существенную её часть. И тут начинаются сюрпризы новой роли:
Нет формальных полномочий.
Зачастую у архитектора нет формальных полномочий прийти и сказать разработчикам, как надо делать. Оказывается, надо сначала авторитет завоевать, отношения выстроить, а потом, возможно, начнут слушать и приходить за советом. Таким образом, архитектор может превратиться в номинальную роль, изолированную от процесса разработки. Несколько раз наблюдал, как в эту ловушку попадали разработчики, рвущиеся в архитекторы, потому что знают “как надо делать правильно” и, будучи архитекторами, смогут транслировать свое видение.
Высокие технологии нужны не всегда.
Наблюдал несколько раз, как люди шли в архитекторы с ожиданием, что они будут решать более сложные задачи, устали “json в базу складывать”, хочется настоящих технических челленджей. А не факт, что они в компании есть. Хорошо, если компания имеет план развития технологий – внедрение нового языка, миграция в облако, реплатформинг. А вот если нет, то такой “архитектор” может найти себе взрослые игрушки: придумать, почему срочно нужно прикрутить Kafka, переписать ключевой компонент на новый язык и обязательно задеплоить в Kubernetes. Такие игры могут дорого обойтись компании. Не следует повышать людей просто для того, чтобы оставить их в компании, если такая роль не помогает бизнесу.
Становится больше рутины.
Количество коммуникаций возрастает значительно, а времени в сутках больше не становится. На первое место для новоиспечённого архитектора выходит умение приоритизировать активности, говорить “нет” инициативам и фокусироваться на важном. Иначе попадаешь в режим «белки в колесе» – каждый день занят, а посмотришь, что сделано за полгода, и ничего конкретного назвать не можешь. Это может демотивировать.
На мой взгляд, это ошибка, воспринимать роль архитектора как следующую ступень в карьере разработчика. Архитектор — это комплексная роль, которая требует понимания бизнеса, широкого кругозора в технологиях и личностной зрелости. Таких людей в индустрии мало, вот и выкручиваемся инжиниринг менеджерами.
#ошибкименеджера #карьерныйпуть
О влиянии когнитивных искажений или как нанимают в оркестры
Я как-то писал, что привычный нам процесс интервью не работает. Отчасти это вызвано тем, что нет прямой связи между тем, что кандидаты делают на интервью и тем, что им предстоит делать на работе (таким образом, прохождение интервью превращается в самостоятельный навык). Ещё одним фактором являются когнитивные искажения, влияющие на процесс принятия решения. Вот о них сегодня и поговорим.
В некоторых сферах деятельности в процессе найма кандидаты оцениваются исключительно на основании навыков, необходимых для успеха в работе. Один из примеров — симфонические оркестры. Процесс собеседования состоит из серии прослушиваний. На каждом из этапов происходит отсев, дошедших до финала принимают в оркестр. Казалось бы, хорошо владеешь инструментом, играешь лучше других претендентов, получаешь место в оркестре. Однако, не всё так просто.
В 1970х годах руководители симфонических оркестров США озадачились вопросом: «Почему в музыкальных академиях учатся и мужчины и женщины, а в симфонических оркестрах играют только мужчины? Из-за чего мы теряем таланты?». На тот момент доля женщин в оркестрах была меньше 5%.
Что придумали руководители оркестров: они начали проводить «слепые» прослушивания. Перед комиссией стояла ширма, и члены жюри не могли видеть, кто играет на сцене. Там ещё был прикол с тем, что по звуку шагов можно определить пол, так что претенденты выходили на сцену босиком. Короче, постепенно процесс отладили.
Что оказалось в результате: количество женщин, проходящих первичные прослушивания, значительно возросло; постепенно гендерное распределение в оркестрах начало изменяться.
Про это в 2000 году вышло исследование “Orchestrating Impartiality: The Impact of “Blind” Auditionson Female Musicians”, в котором исследователи попытались определить, являлись ли «слепые» прослушивания или что-то другое причиной этих изменений. У статьи много и поддержки и критики, профессора статистики говорят: «В данных много шума, нельзя сказать достоверно». А, тем временем, «слепые» прослушивания до сих пор продолжаются и сейчас гендерное распределение выглядит иначе. Например, в New York Philharmonic теперь 46% женщин.
А вообще эта статья не про гендерное неравенство, феминизм и прочие “-измы”, а про то, что даже в тех случаях, где мы полагаем, что принимаем решения на основании одного критерия, на нашу оценку существенно влияют другие факторы, которых мы можем даже не замечать.
#найм #история
Математика продуктовой разработки
Как принимать экономически оптимальные решения для продукта? Какими метриками измерять команды и успех продукта? Сколько денег теряется из-за того, что задачи накапливаются в очереди?
Об этом и многом другом пишет Donald Reinertsen в своей книге “The principles of product development flow”.
Однако есть проблема. Дело в том, что, помимо умных мыслей, в книге еще интегралы, производные, статистика, распределения Пуассона, Марковские процессы — вот это вот всё.
То ли дело скрам: беклог, спринт, стори поинты и побежали.
В этом интервью автор на простых примерах рассказывает основные идеи книги:
- Чем отличается разработка софта от конвейерного производства.
- Что такое cost of delay и как эта метрика помогает приоритизации.
- Почему сокращать время цикла разработки не всегда полезно.
- Почему важно уделять внимание управлению очередями.
- Почему, несмотря на повальный agile, классическое проектное управление по-прежнему имеет ценность.
А также масса аналогий из других областей, которые могут быть применимы к процессу разработки.
Ссылка на интервью: https://www.youtube.com/playlist?list=PLTfbQtksxe-LBUdxuNR6cGG6Ve8Rx9D5L
#инструменты #менеджмент #видеопотеме
О вреде работать «больше»
— Рядовой Иванов!
— Я!
— Возьмите кирпич. Сбейте самолёт!
— Кирпичом?!
— Вы же коммунист!
Иванов ломает кирпич об колено:
— Я собью два самолёта!
В нашей культуре принято много работать. Однако «много» не значит «продуктивно». Хотя IT сектор весь такой прогрессивный, культурный код остается неизменным. В управлении разработкой это приводит к реактивному реагированию на проблемы с попытками быстро их решить, не особо вникая в причины, которые привели к этим проблемам. Это дает менеджерам иллюзию улучшения, но если копнуть глубже, то делает только хуже.
У реактивного подхода есть следующие минусы:
Основная причина (root cause) проблемы упускается
Люди склонны искать причину проблемы «где-то рядом» с проблемой (во времени и/или пространстве). Произошла критическая ошибка во время обновления, и инфраструктура вышла из строя? Так это человек, выполнявший действия — дурак, не досмотрел.
Случилась утечка корпоративной информации? Так это безопасники не работают. Большой релиз откладывается? QA не успевают!
А где на самом деле лежит основная причина? Когда система покатилась не туда? Где в наших процессах дыры, которые позволяют этим проблемам происходить? Обучение? Отсутствие автоматизации? Низкое качество кода? Где и когда эти проблемы надо было решать, чтобы не страдать от последствий?
В итоге имеем: «Давайте отменим ретроспективу, а то баги не успеем разгрести до конца недели». На этой фразе умирает менеджмент.
Срочность становится нормой работы
Были на полном стадионе? — все кричат, шум, эмоции через край, чувствуешь задор. Так же и в корпоративной среде — драйв, дедлайны, героизм. Люди подсаживаются на это ощущение и начинают искать его во всем: Роадмап составить — срочно! Подготовить план развития сотрудников — срочно! Логотип на сайте поменять — срочно! Сесть, собраться, подумать о системных проблемах — это как-то без огонька.
Однако, некоторые вещи просто невозможно делать в режиме «горящей жопы»: 1-1 встречи, долгосрочные планы, посчитать затраты на железо, спланировать изменения к GDPR.
Конечно, если продакшен лежит, надо всех поднимать и чинить, как можно скорее. Однако, важно договориться, что считается срочным и когда нужно включать авральный режим — какие финансовые и репутационные риски требуют подобных действий? Ну уж точно не замена логотипа.
Проблемы не в людях, проблемы в системе. Процессы, которые мы строим (или игнорируем), со временем аккумулируются и создают устойчивые улучшения (или хаос).
#рассуждения #корпоративнаякультура
Распределенные системы для менеджеров
Менеджеру необходим технический кругозор.
Чтобы пояснить ценность кругозора, я проведу аналогию. Если вы закончили среднюю школу, то вам наверняка известно, как связаны занятие сексом и беременность, зачем мыть руки перед едой и так далее. Нет, мы не понимаем деталей этих чрезвычайно комплексных процессов, однако, кругозор позволяет понять верхнеуровневые связи, что на что влияет и чего не следует делать.
С технологиями так же: не надо знать в деталях, как работает kubernetes, но понимать, какие проблемы он решает, а главное какие НЕ решает – очень полезно.
Важная часть технического кругозора – представление о распределенных системах. Понимание, что может пойти не так, когда у вас больше одного компьютера, позволяет оценивать риски и планировать ответные действия.
Осознание таких концепций как доступность, масштабируемость, отказоустойчивость помогает понять, что делают архитекторы, и почему иногда разработчикам на “простую” фичу действительно требуется много времени.
Книга “Distributed systems for fun and profit” – хорошее введение в предмет, она бесплатная.
Да, это не Клеппман и не Таннебаум, зато тут отсылки к Симпсонам.
Ссылка: http://book.mixu.net/distsys/single-page.html
#архитектура #техническийкругозор
Dave Thomas, один из авторов the manifesto for agile software development, рассказывает как идеи заложенные в манифест, были похоронены индустрией по продаже agile-тренингов.
- О разнице между спецификацией и имплементацией.
- О выборе из множества альтернатив: из задач с одинаковой ценностью выбирай ту, что легче изменить в будущем.
- O том, что общего у PID-контроллера и agile команды.
- О том, что правила зависят от контекста и не следует копировать их «в лоб», если они работают для кого-то другого.
Видео: https://youtu.be/a-BOSpxYJ9M
#история #видеопотеме
Ценность и смысл архитектуры
На этом 15 минутном видео Martin Fowler простым языком, с юмором, разбивая в пух и прах существующие определения software architecture, рассказывает почему архитектура важна. Два тезиса:
1. Суть архитектуры — единое понимание людьми, ведущими проект, относительно того, что является важным.
2. Её ценность — внутреннее качество продукта, которое не видно пользователям, однако позволяет развивать продукт быстрее и дает ускорение в долгосрочной перспективе.
У Фаулера говорить получается лучше, чем у меня писать, так что смотрите видео.
Ссылка: https://youtu.be/DngAZyWMGR0
#архитектура #видеопотеме
Синдром Vasa
Шведский боевой корабль Vasa — самый большой, дорогой и красивый — летом 1628-го года должен был стать флагманом флота и гордостью нации, но вместо этого бесславно затонул, перевернувшись от легкого порыва ветра прямо в гавани Стокгольма.
Причины фиаско Vasa при ближайшем рассмотрении кажутся подозрительно знакомыми:
1. Король несколько раз менял требования к кораблю в процессе строительства: сначала захотел сделать его длиннее, затем — достроить дополнительную орудийную палубу (who said “feature creep”?)
2. Мастер-кораблестроитель, руководивший постройкой, скоропостижно скончался в ходе строительства, не передав никому знания о конструкции корабля (‘cause fuck documentation!)
3. Vasa чуть не опрокинулся при проверке на устойчивость, но его все равно спустили на воду (who would ever deploy a build when tests fail? o_O)
4. Постоянные незапланированные мелкие инновации, и это притом, что никто уже толком не знал, как это все должно работать (well, it wouldn’t hurt… I think)
В результате корабль оказался слишком узким для своей незапланированной длины, центр тяжести — слишком высоко (привет, дополнительная орудийная палуба), а балласт — недостаточным. Итог известен.
Если будете в Стокгольме, то сходите в музей Vasa на острове Юргорден. Корабль можно рассмотреть в деталях и он действительно впечатляет: Vasa подняли на поверхность весной 1961-го года и полностью восстановили.
А пока не пожалейте 6 минут времени и посмотрите искрометный доклад Пита Чеслока про историю Vasa и то, почему мы зачастую плохо управляем нашими проектами ;)
#история #архитектура #менеджмент
https://vimeo.com/95284690
Лотерейные билеты, быстрый цикл обратной связи и разработка софта
Давайте проведем мысленный эксперимент.
Я разыгрываю лотерею: есть 100 билетов с номерами от 00 до 99. Выигрышный номер известен заранее и получает $100. Вы можете купить случайный билет за $1.
При таком раскладе в 99 случаях вы теряете $1 и лишь в одном случае получаете $99 (приз минус цена билета). Нет смысла играть в такую игру, чистый выигрыш — 0. Говоря языком статистики, математическое ожидание равно нулю.
Давайте чуть-чуть изменим условия игры: вы можете заплатить 50 центов, чтобы узнать первую цифру билета, а затем, если она совпала с выигрышной, купить вторую цифру ещё за 50 центов. Что изменилось?
В 9 из 10 случаев вы теряете 50 центов, на второй итерации вы снова теряете 50 центов в 9 из 10 случаев, и в одном — получаете $99. А в такую игру будете играть? Всё те же 100 билетов и только один выигрышный, но теперь игра стала выгодной.
Причём тут разработка софта? Стоит ли полировать код в своей ветке до идеала, чтобы на код-ревью узнать, что это в принципе неправильный подход к решению задачи? Может стоит показать незавершенный черновик? Не для того, чтобы узнать, что он хороший, а чтобы понять, стоит ли дальше прикладывать усилия в этом направлении.
Как и в нашем примере с лотереей, мы не увеличиваем вероятность успеха, мы уменьшаем ресурсы, затрачиваемые на неуспешные попытки.
#менеджмент
Data-driven хайп
Сейчас модно быть data-driven компанией. Это же здорово принимать решения на основании данных, а не «я так вижу».
Однако, этот модный тренд привёл к тому, что к data scientist’ам ходят за советом как к шаманам, а любые численные метрики начинают восприниматься как доказательство того, что наши решения data-driven.
И не важно, что с точки зрения описательной статистики эти цифры не имеют смысла.
Под лозунгом data-driven я видел такие чудесные метрики как: среднее количество багов на фичу, среднее время завершения задачи, средний процент скидки. Ну и прочие средние температуры по больнице.
На уровне троллинга у меня два вопроса к data-driven компаниям:
1. Сколько людей, принимающих решения go/no go по проектам и инициативам, понимает отличие среднего от медианы и когда что использовать?
2. Если мы такие data-driven, то почему перед презентацией топам все обеспокоены шрифтом и шаблоном презентации, а не проверкой данных?
Я это к чему? Data-driven работает только тогда, когда в компании умеют считать ценность продукта и стоимость разработки. В деньгах.
Без этого весь data-driven — это эзотерика и спекуляция прокси-метриками.
#корпоративнаякультура #рассуждения