В первом посте этой серии я представил ментальную модель, которую можно использовать для анализа и количественной оценки технического риска в вашей компании. Часть 2 делает шаг к восхитительному прагматизму, рассматривая, какие инструменты у вас есть для снижения технических рисков.
В этом посте я буду ссылаться на Известные известные (KnKn), Известные неизвестные (KnUn), Неизвестные неизвестные (UnUn) и Неизвестные известные (UnKn) из Квадрата технического контроля из Части I.
Снижение технического риска
Теперь, когда вы, надеюсь, лучше понимаете, как думать о своем технологическом риске, давайте выясним, как им управлять. В целом снижение технического риска заключается в следующем:
- Сведение к минимуму вероятности того, что у вас есть какие-то вещи в Unknown Knowns (UnKn) и Unknown Unknowns (UnUn)
- Ограничение объема вещей, которые вы могли бы иметь в UnKn и UnUn, чтобы вы могли спланировать, что с этим делать, если это произойдет.
- Убедитесь, что у вас достаточно времени, чтобы исправить то, что вы обнаружите в UnUn и UnKn.
Вышеупомянутые пункты можно разделить на 3 подробных указателя ниже.
#1: Ограничьте свои переменные
Почему вещи попадают в UnUn и UnKn?
Думайте о своем процессе разработки как о химическом эксперименте, который вы проводили в старшей школе. Вам нужно установить правильную температуру. Вам нужно смешать нужное количество вещества А и вещества Б. Вам нужно смешать А и Б в нужное время и т. д.
Думайте о своем процессе разработки как о химическом эксперименте.
Оказывается, контролирующие переменные (температура, объем, давление и т. д.) в химических экспериментах чрезвычайно важны. Настолько важно, что на всех фабриках, производящих что-то химическое, существует чрезвычайно строгий процесс ограничения того, насколько переменная может варьироваться. У них есть специальное оборудование, персонал, процедуры и т. д. Что, если на заводе узнают, что их сотрудники случайно немного встряхнули флакон с веществом А, потому что им нужно перенести его через большую комнату, и это встряхивание случайно испортит материал? Я могу заверить вас, что управляющий фабрикой переместит резервуар с веществом А ближе к оборудованию, чтобы предотвратить это — другими словами, чтобы ограничить вероятность переменной того, что вещество А было встряхнуто. Ваша задача — сделать то же самое для вашего процесса разработки. Ограничьте его таким образом, чтобы единственным результатом был большой успех.
Какие процессы, технологии, изменения вы можете внести, чтобы ограничить переменные в процессе разработки?
В нашем случае. Когда инженеры по машинному обучению проводят эксперименты, они выполняют предварительную обработку большого количества данных, затем выбирают инструмент для использования (может быть, Keras, Tensorflow или аналогичный), затем реализуют его, затем тестируют, отлаживают и, наконец, проводят эксперимент. Если вы оцениваете разные модели для аналогичной работы, каждый из этих шагов создает риск того, что у вас есть вещи в UnUn и UnKn. Например, предположим, что один из ваших инженеров по машинному обучению каким-то образом предварительно обработал данные, так что задача стала слишком простой, поэтому он получил наилучший результат. Но когда вы исследуете дальше, вы обнаружите, что не было возможности воссоздать этот этап предварительной обработки в производстве, следовательно, его модель должна быть дисквалифицирована с самого начала?
Вместе команда обнаружила, что если мы не будем строго контролировать этот процесс, то рискуем в конечном итоге потратить много времени на оценку моделей и нахождение всевозможных удивительных вещей в UnUn и UnKn. Итак, что мы сделали, так это создали собственный пользовательский API поверх Tensorflow, который в основном ограничивал наших инженеров по машинному обучению всегда использовать одну и ту же предварительную обработку, один и тот же способ создания моделей и один и тот же способ отчетности о результатах. Следовательно, мы исключаем ряд переменных из уравнения и теперь можем вместо этого сосредоточиться на общих, которые не могут быть исключены так просто. Например, достаточно ли у нас данных и т. Д. Благодаря этому наш процесс разработки машинного обучения становится чрезвычайно оптимизированным, быстрым и безопасным. (Подробнее об этом API в следующем сообщении в блоге.)
Подумайте о своем процессе разработки. Как люди работают? Что на самом деле делают? И каков риск каждого шага, который они делают? Мог ли исход быть другим, если бы у них был плохой день? Сможете ли вы это заметить?
#2 Прозрачность прозрачность прозрачность
Как основатель или технический руководитель в своей компании, вы, вероятно, постоянно думаете и говорите о своей компании и ее продукте. Это постоянно в вашем уме. К сожалению, это может означать, что многое из того, что вы считаете понятным для всех, на самом деле не так.
Итак, если один из вас, инженеров, подойдет к вам и скажет: «Ну, я добился 100% точности в обнаружении собак на изображениях, если мы специально посмотрим на изображения, на которых также есть хомяки». И ты такой: «Что, черт возьми, за хомяки?» Тогда явно произошел какой-то разрыв связи — и это на вашей совести.
Вы, как менеджер, должны четко и ясно говорить о подобных вещах. И единственный способ сделать это — если вы вместе со своей командой определите метрики, которые они оптимизируют вместе с ними, прежде чем они начнут работу. Привлекая всех на борт и инвестируя в эту метрику, никто не будет заботиться об этой глупой хомячьей метрике.
В Corti мы недавно внедрили аналогичную Kata board, которую Spotify использует, чтобы сделать метрики и успех чрезвычайно явными. Это не только обеспечивает прозрачность всей команды в отношении того, чего мы пытаемся достичь, но также помогает избавиться от тщеславных показателей и согласовывает команду с тем, чего мы на самом деле пытаемся достичь.
Наша версия доски Ката состоит из 4 частей:
- Статус: каков текущий статус этой конкретной функции и какую проблему она не решает на сегодняшний день?
- Определение потрясающего: Какую цель мы преследуем?
- Следующая цель: Какова следующая ощутимая цель, которую мы должны выполнить?
- Следующие шаги: Какие следующие конкретные шаги можно предпринять, чтобы приблизиться к следующей цели?
Вы не можете видеть наши следующие шаги выше, потому что мы интегрируем Ката непосредственно в Асану, поэтому задачи просто определены там.
# 3 Повысьте свою ловкость
Если все ваши вещи не находятся в KnKn, вам нужно быть готовым к тому дню, когда вы найдете вещи в UnKn или UnUn. Когда это происходит, вы на часах. Вот как различные ситуации, с которыми вы можете столкнуться, выглядят на диаграмме Ганта:
Ваша красивая диаграмма Ганта разлетелась на куски. Чтобы добиться успеха, когда это произойдет, вам нужно убедиться, что ваша технологическая организация и ваш выбор технологий позволяют вам оставаться гибкими. Я не говорю здесь о Kanban и Scrum, но я говорю о том, что когда вы проектируете архитектуру своей системы, выбор технологий, который вы делаете, должен позволить вам очень быстро все изменить. Это, очевидно, необходимо только в том случае, если у вас есть вещи в KnUn (и, таким образом, возможны UnUn и UnKn). Проблема с этими элементами в UnUn заключается в том, что они могут потребовать редизайна, переосмысления и большого рефакторинга.
Выбор технологий, который вы делаете, должен учитывать гибкость
Приведу пример из нашей жизни: мы заранее решили использовать набор инструментов для распознавания речи с открытым исходным кодом Kaldi, чтобы получить преимущество в распознавании речи. Kaldi показал очень хорошие результаты во всех общедоступных тестах, так что это казалось очевидным выбором. Через несколько месяцев после начала проекта стало ясно, что Kaldi недостаточно эффективен с точки зрения получения как можно большего количества наших данных так быстро, как мы хотели, а также было чрезвычайно сложно нанять людей для работы с ними и их изменения. Кроме того, нам также нужно было поэкспериментировать с другими типами архитектур нейронных сетей для распознавания речи, кроме тех, которые поддерживала Kaldi. Поэтому, чтобы оставаться гибкими и иметь возможность быстро нанимать нужных людей, мы решили отказаться от Kaldi и заменить ее нашей собственной системой, построенной на Tensorflow. Это позволяет нам быстро вносить изменения в новые модели и, следовательно, снижает риск того, что у нас не хватит времени, если и когда мы обнаружим что-то в UnUn или UnKn. Если бы мы этого не сделали, сегодня мы были бы в верхней правой части изображения выше.
Какой технологический выбор вы сделали? И они ограничивают вашу ловкость?
Резюме:
- Как вы можете ограничить свои переменные? Посмотрите, как ваша команда пишет код сегодня. Каковы основные риски, с которыми они работают каждый день? Какие разные вещи, которые они делают каждый день, каждый раз, когда они их делают, вносят какую-то непредсказуемость в ваш процесс разработки?
- Как вы можете повысить прозрачность и подотчетность в процессе разработки?
- Какие технологические решения ограничивают вашу гибкость? Вы в курсе, что они этим занимаются? Есть ли другая технология, которую вы могли бы использовать для выполнения той же работы, но с большей гибкостью?
