Обсуждение инфраструктуры блокчейна часто вращается вокруг высокоуровневых концепций — мы говорим о идеях, архитектуре, техническом превосходстве, способности противостоять атакам. Всё это очень важно. Но когда эти идеи начинают реализовываться, попадают в комнату протокола, к тому, кто принимает окончательное решение, — картина резко меняется.
Выявляются более практичные вопросы: Мне это нужно? Я смогу это использовать? Могу ли я интегрировать это в ключевые бизнес-процессы?
В этот момент перед ответственным человеком стоит не только технический анализ. Ему нужно согласовать целую экосистему — инженерную команду, партнеров, аудиторов, инвесторов, сообщество, а иногда и регуляторов. И при этом — внутреннее давление: что делать, если выбрал неправильно? Кто несет ответственность, если проект столкнулся с проблемами? Как объяснить потерю средств? В конце концов, все эти «палки в колеса» ложатся на того, кто принимает решение.
Поэтому при выборе инфраструктуры первым, что приходит в голову ответственному, зачастую является не техническая оценка, а **затраты на объяснение**.
Что такое затраты на объяснение? Это способность ясно объяснить это решение. Объяснить, почему выбрали именно его. Объяснить, на каких доказательствах оно основано. Объяснить его границы и риски. Объяснить, как решать споры, если они возникнут. Объяснить, как распределены обязанности. И самое главное — показать, что решение не принято наугад.
Многие новые решения именно на этом этапе застревают. Не потому, что они технически плохие, а потому, что их сложно понять неспециалистам, трудно получить согласие людей с разными интересами.
Вы заметите, что руководитель протокола должен убедить не только инженеров, но и многих, кто не пишет код. Эти люди не интересуются техническими деталями, их волнует только один вопрос: если что-то пойдет не так, смогут ли они это объяснить? Могут ли доказать, что не принимали поспешных решений? Могут ли подтвердить, что их процесс принятия решений был достаточно осторожным?
Вот почему многие технически превосходные решения оказываются отложенными.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
8 Лайков
Награда
8
4
Репост
Поделиться
комментарий
0/400
CantAffordPancake
· 01-07 00:18
Это вопрос политики. Даже самая передовая технология должна пройти через человеческий фактор, проблема в том, что большинство руководителей вообще не разбираются в технологиях и только перекладывают вину.
Посмотреть ОригиналОтветить0
GasWaster69
· 01-04 19:49
Ха, вот почему хорошие вещи годами лежат в бумагах
Проще говоря, это игра в перекладывание ответственности за риск, при этом самые передовые технологии оказываются самыми опасными
Посмотреть ОригиналОтветить0
digital_archaeologist
· 01-04 19:42
Проще говоря, это политическая проблема, а не техническая. Самое крутое решение застряло на презентации PPT.
Посмотреть ОригиналОтветить0
ChainSauceMaster
· 01-04 19:37
Честно говоря, эта статья задела меня, некоторые технически более продвинутые вещи действительно умирают на этапе "как объяснить это заказчику"... Предположение, что ответственный должен взять на себя вину, определяет, что он выберет не лучший вариант, а тот, который легче оправдать.
Обсуждение инфраструктуры блокчейна часто вращается вокруг высокоуровневых концепций — мы говорим о идеях, архитектуре, техническом превосходстве, способности противостоять атакам. Всё это очень важно. Но когда эти идеи начинают реализовываться, попадают в комнату протокола, к тому, кто принимает окончательное решение, — картина резко меняется.
Выявляются более практичные вопросы: Мне это нужно? Я смогу это использовать? Могу ли я интегрировать это в ключевые бизнес-процессы?
В этот момент перед ответственным человеком стоит не только технический анализ. Ему нужно согласовать целую экосистему — инженерную команду, партнеров, аудиторов, инвесторов, сообщество, а иногда и регуляторов. И при этом — внутреннее давление: что делать, если выбрал неправильно? Кто несет ответственность, если проект столкнулся с проблемами? Как объяснить потерю средств? В конце концов, все эти «палки в колеса» ложатся на того, кто принимает решение.
Поэтому при выборе инфраструктуры первым, что приходит в голову ответственному, зачастую является не техническая оценка, а **затраты на объяснение**.
Что такое затраты на объяснение? Это способность ясно объяснить это решение. Объяснить, почему выбрали именно его. Объяснить, на каких доказательствах оно основано. Объяснить его границы и риски. Объяснить, как решать споры, если они возникнут. Объяснить, как распределены обязанности. И самое главное — показать, что решение не принято наугад.
Многие новые решения именно на этом этапе застревают. Не потому, что они технически плохие, а потому, что их сложно понять неспециалистам, трудно получить согласие людей с разными интересами.
Вы заметите, что руководитель протокола должен убедить не только инженеров, но и многих, кто не пишет код. Эти люди не интересуются техническими деталями, их волнует только один вопрос: если что-то пойдет не так, смогут ли они это объяснить? Могут ли доказать, что не принимали поспешных решений? Могут ли подтвердить, что их процесс принятия решений был достаточно осторожным?
Вот почему многие технически превосходные решения оказываются отложенными.