Это первая запись в блоге о том, как мы управляем техническими рисками и думаем о них в Corti. В этом разделе рассматриваются инструменты, позволяющие понять, что такое технический риск и как он влияет на решения и деятельность компании.

«… Вот почему мы должны отойти от Kaldi и встать на путь сквозного распознавания речи на основе глубокого обучения (ASR)». На этом я закончил свою 45-минутную лекцию. Я только что закончил красить всю стену одного из больших конференц-залов в одном из наших венчурных капиталов (Sunstone Capital) с помощью нейронных сетей, гибридных систем ASR и сквозных соединений и тонкостей функции потерь временной классификации Connectionist. Кристиан, наш партнер в Sunstone, повернулся к Ясину, одному из руководителей, и сказал: «Вы знаете, когда мы говорим о технических рисках? Так выглядит технический риск ».

Это было менее 6 месяцев назад. Сегодня у нас примерно месяц до того, как мы сможем запустить нашу систему прогнозирования остановки сердца на основе звонков в одной из датских служб экстренной помощи. За последние 6 месяцев мы эффективно снизили технический риск с «черт побери» до «среднего».

Но что такое технический риск?

Ментальная модель технического риска

Как и во всех ментальных дисциплинах, понимание и работа с чем-либо сводится к правильному построению ментальной модели. Итак, как мы можем создать общую ментальную модель технического риска?

При моделировании всех физических систем первым важным шагом является определение сил, действующих на то, что вы пытаетесь моделировать. Во-вторых, выяснить, как эти силы действуют на вещь и каковы их отношения.

Допустим, у вас был ящик с газом внутри, и вы хотели понять, как изменить давление, которое газ оказывает на внутренности коробки. Есть несколько способов сделать это: изменить температуру, изменить размер коробки, изменить тип газа и т. Д. В нашем случае у нас есть технический риск внутри коробки, и мы хотим выяснить, как мы можем повлиять на состояние технического риска. Как и в случае с давлением газа, у нас есть низкое, среднее и высокое давление. Аналогичные уровни технического риска у нас есть: низкий, средний и высокий. Как мы можем изменить состояние технического риска? Какие силы действуют на это?

Первый закон технического риска: закон предсказуемости

Технический риск обратно пропорционален предсказуемости вашего процесса разработки.

Первый закон говорит о том, как технический риск влияет на вашу компанию. Для этого давайте сначала посмотрим, что значит иметь низкий технический риск и высокий технический риск?

Что ж, если у вас низкий технический риск, ваш процесс разработки имеет высокую предсказуемость. А если у вас есть риск, связанный с высокими технологиями, ваш процесс разработки имеет низкую предсказуемость.

Возьмем пример. Когда SpaceX Илона Маска впервые попыталась посадить свою ракету на дрон, она потерпела неудачу. Почему не получилось? Это не удалось, потому что они не смогли предсказать риск. В одном случае в ноябре 2016 года это была деталь, касающаяся очень холодного кислорода. Я убежден, что если бы SpaceX знала об этой проблеме, они бы ее предотвратили. Но они этого не сделали. Следовательно, произошло то, что им пришлось вернуться, выяснить, что было не так, и исправить это. Что-то (отладка и исправление), что определенно не планировалось с самого начала (или это было так? Подробнее об этом позже). Дело здесь в том, что, поскольку у них был высокотехнологичный риск, они не могли предсказать (1) почему ракета выйдет из строя и (2) сколько времени потребуется на ее устранение, то есть высокотехнологичный риск, ведущий к низкой предсказуемости.

Второй закон технического риска: закон контроля

Технический риск обратно пропорционален степени вашего контроля.

Если вы сможете все контролировать, у вас будет нулевой технический риск. Если вы ничего не контролируете, вы подвергаетесь огромному техническому риску. Этот закон говорит нам, что, хотя на технический риск нельзя повлиять напрямую, «контроль» - это одно из средств воздействия на него.

Но что такое контроль на самом деле и «контроль» над чем?

Как технический руководитель или инженер в своей компании, единственный способ контролировать технический риск - решать проблемы. Но какие проблемы нужно решать? Чтобы определить это, очень полезно использовать модель «Неизвестные неизвестные, известные известные» в качестве ментальной модели, чтобы подумать об управлении своими техническими рисками.

Классическая модель «Рамсфельда» для этого гласит, что «Известно-Известное» - это то, что вы знаете, что вы знаете, а Неизвестно-Известное - это то, о чем вы не знаете, что знаете. В нашем случае мы собираемся немного направить его на решение проблем. So Known Known становится проблемой, о которой вы знаете и которую вы знаете, решить. Точно так же неизвестно известное - это проблема, о которой вы не знаете, но знаете, как ее решить. Давайте назовем эту фигуру Квадратом Технического Контроля для дальнейшего использования.

Если все ваши проблемы находятся в (1) (Known Known), то у вас есть полный контроль. Все, над чем вы работаете, можно спланировать, запланировать и выполнить = вы можете предсказать почти все = у вас очень низкий технический риск (согласно первому закону).

Но для каждой проблемы, расположенной в (2) (Известные неизвестные): проблемы, о которых вы знаете, но не знаете, как решить, вы теряете контроль и, следовательно, снижаете предсказуемость вашей работы над проблемой. Поскольку каждая проблема в (2) несет в себе риск того, что она содержит скрытые проблемы, которые фактически находятся в (3) или (4). Это просто потому, что если вы не знаете, как что-то решить, значит, вы явно не поняли масштаб проблемы должным образом, следовательно, там может быть какая-то проблема, о которой вы не знали и не знаете, как решить ((3) Неизвестное Неизвестное).

Цифра Square of Tech Control также может использоваться для количественной оценки вашего технического риска. Попробуйте сопоставить каждую из ваших проблем / этапов либо квадратом (1), либо (2). Большинство в квадрате (1) или квадрате (2)? Чем больше у вас в (2), тем выше технический риск.

В следующем посте из этой серии мы поговорим гораздо больше о том, как можно контролировать свои технические риски.

Третий закон технического риска: закон восприятия

Воспринимаемый технический риск субъективен для человека, который его просматривает.

Вот где приходит ваша команда. Потому что, если вы провели анализ своего технического риска с помощью Square of Tech Control исключительно с вашей точки зрения, то количественная оценка вашего технического риска вашей командой может выглядеть иначе. Может быть, есть даже несколько ваших проблем / вех, которые вы лично не знаете, куда направить, но ваша команда действительно знает, куда их направить. У вас их много?

При количественной оценке технического риска вам необходимо делать это вместе со своей командой - в конце концов, мы стремимся сопоставить технический риск всей команды, а не только ваш собственный. Вы можете полностью недооценить или переоценить сложность чего-либо, если будете делать это сами.

В качестве примера: недавно мы добавили в нашу команду нашего первого опытного разработчика программного обеспечения, а это означает, что до него я был единственным, кто занимался разработкой программного обеспечения «полный рабочий день», поэтому мне пришлось возложить каждую из задач разработки программного обеспечения на Square of Tech Control. Один из пунктов заключался в том, чтобы выяснить, как выполнять наши модели машинного обучения, не загружая их каждый раз, поскольку загрузка обычно занимает больше времени, чем их выполнение. У меня было лишь смутное представление, как это сделать, поэтому в нашей дорожной карте я выделил для этого 5 дней. Наш новый разработчик программного обеспечения исправил его на второй день. Это был тот случай, когда элемент из (2) (Known Unknown), к счастью, снова оказался в (1) (Known Known), и я не смог бы сделать это без команды - уф.

Вторая сторона этого состоит в том, что вам нужно постоянно общаться со своей командой о том, чего вы пытаетесь достичь и как вы планируете это делать. Вы делаете это, чтобы проверить, не кричит ли кто-нибудь: «Ты не можешь этого сделать!». Если они так кричат, то, надо надеяться, ошибаются, но то, о чем вы говорите, вероятно, совершенно очевидно (2) (Известно, неизвестно).

Ваша команда должна участвовать в подробном планировании дорожной карты. В нашем случае мы используем функцию Ганта в Asana (технически Instagantt), чтобы каждый руководитель группы (вместе со своей командой) оценивал, сколько времени занимает их работа. Если я когда-нибудь слышу, как руководитель группы говорит: «Я не уверен, сколько времени это займет из-за XYZ», эта проблема сразу же переходит в (2), и я особенно стараюсь решить эту проблему.

Четвертый закон технического риска: закон событий

Правило умножения вероятностей справедливо и для технических рисков, поскольку существует соотношение 1: 1 между техническим риском и предсказуемостью.

Вероятность 101. Допустим, вам нужно завершить этапы A, B и C, чтобы добиться успеха в создании продукта. И предположим, что все A и B находятся в (1) (Known Known), а C находится в (2) (Unknown Known). Поскольку A и B находятся в (1), они должны быть на 100% предсказуемыми (я знаю, что ничего не предсказуемо на 100%). Но вероятность того, что ваш запланированный подход к проблеме сработает, составляет 50–50%. Каковы ваши совокупные шансы на то, что ваш проект будет успешным, как и планировалось? Легкий. 50% Почему? Из-за правила умножения, которое гласит, что для событий A, B, C, если они независимы, объединенная вероятность того, что произойдет A, затем B, а затем C, будет P (A, B, C) = P (A) * P (B) * P (C) = 1 * 1 * 0,5 = 50%

Поскольку вы никогда не можете оценить точную вероятность того, что данный подход будет успешным, почему это важно? Это важно, потому что:

  1. Он показывает, какое влияние оказывает наличие всего одного шага внедрения в вашем продукте, имеющего риск неудачи, на совокупный шанс того, что продукт будет успешно построен в срок.
  2. Он показывает влияние добавления большего количества шагов, чем было изначально запланировано для вашего продукта. Допустим, вы построили этапы A, B, C и планировали D, который был в (1) (Known Known), но вместо этого вы решили добавить E и F? Если один из них (Известный Неизвестный), вы фактически ставите под угрозу шанс того, что продукт будет успешно построен вовремя.

Так что будьте осторожны с материалами в (2) и всегда дважды думайте, прежде чем добавлять что-то новое в свою дорожную карту.

Так что ты с этим делать? Ясно, что вы не сдаётесь только потому, что один этап реализации не удался или прошел не так, как планировалось? Это тема следующего поста.

TL;DR:

Подводить итоги:

  1. Осознайте, что технический риск изменяет предсказуемость вашего процесса разработки. Знайте, что если вы рискуете, вам, возможно, придется исправить это позже или быстро придумать план Б (или Н).
  2. Думая о технических рисках, важно понимать, насколько вы контролируете ситуацию. Используйте Square of Tech Control, чтобы количественно оценить, какой у вас контроль и, следовательно, технический риск, и используйте это, чтобы сосредоточиться на решении правильных проблем.
  3. Используйте всю свою команду при оценке технических рисков. Вы наняли людей, которые помогут вам решать проблемы, поэтому они, вероятно, знают, как решить многие из вещей, которые вас беспокоят. Будьте открыты и четко изложите план действий и остерегайтесь людей, у которых есть возражения по поводу выполнимости чего-либо.
  4. Поймите, что происходит каждый раз, когда вы добавляете дополнительные шаги / проблемы, которые нужно решить в своем продукте. Каждая проблема потенциально увеличивает технический риск.

Как вы относитесь к техническим рискам? Я что-то упускаю? Пишите мне с любыми идеями.