Сохраняйте доверие пользователей
Не теряйте расположение пользователей, выставляя нереалистичные ожидания
Ранее я обсуждал важность поддержания доверия со стороны клиентов и пользователей, используя эти термины в самом широком смысле. В предыдущем обсуждении я писал о поддержании доверия путем создания максимально прозрачной модели - модели, которая наиболее проста для понимания. Есть еще один аспект, который, хотя и менее напрямую связан с построенной вами моделью, имеет такой же потенциал подорвать ваше доверие в глазах клиентов, и это дает надежную оценку сроков проекта - также известную как выполнение обещаний.
Как и многие другие вещи в жизни, этот совет дать гораздо легче, чем кому-либо следовать, главным образом потому, что он гарантирует, что кто-то захочет знать, когда вы собираетесь что-то закончить - и чем сложнее задание, а, следовательно, тем труднее. чтобы оценить точно, тем более они будут заинтересованы услышать вашу оценку.
Предприниматель Илон Маск представил несколько прекрасных примеров этой проблемы. Чтобы дать небольшой контекст, г-н Маск зависит от чужого капитала для завершения своего амбициозного списка проектов, включая вывод Telsa 3 на рынок при заявленном им уровне производства.
Я видел, как это происходило в тех местах, где я работал, когда невыполнение требований привело к снижению доверия, но публичное присутствие Маска дает две возможности. Во-первых, он на виду у публики и не знает меня, поэтому я не могу потерять друзей, говоря о нем. Во-вторых, благодаря тому, что он находится в поле зрения общественности и собственному анализу Маском того, как о нем сообщают в различных СМИ, мы можем проследить изменение этого настроения.
Маск, будучи Маском, есть по крайней мере шанс, что эта относительная потеря доверия не будет иметь дальнейших последствий. Однако я уверен, что, если бы я таким образом рискнул своим авторитетом, я бы потерял сторонников. Если бы я управлял Tesla, это, вероятно, означало бы, что инвесторы либо ушли бы, либо прекратили вкладывать капитал. Поскольку на момент написания Tesla не имеет положительного денежного потока, это ставит под угрозу жизнеспособность бизнеса.
В контексте проектов по науке о данных существует риск того, что либо ваш текущий проект будет закрыт, либо ваше следующее предложение не будет одобрено.
Есть два пути попасть в эту ситуацию. Во-первых, для завершения вашего проекта требуется слишком мало времени, а во-вторых, не удается эффективно управлять проектом. Как сообщалось здесь, например, есть много людей, которые считают, что Маск попадает в первую группу, и это тот аспект, который мы собираемся рассмотреть сейчас. Множество структур управления проектами и советов по управлению проектами - это отдельная отрасль - обсуждения способов оценки времени, необходимого для завершения проектов, встречаются гораздо реже.
Параллельно с этим недостатком внимания к оценке затраченных на завершение проектов - или, по крайней мере, к публичным обсуждениям вокруг - есть отсутствие данных о типичном времени, которое требуется для выполнения каких-либо задач. Для многих инженерных проектов существуют стандартные методы проектирования затрат, включая оценки времени первого сокращения и контрольные списки для определения необходимости добавления дополнительного времени (в этом контексте мы имеем в виду проекты физического мира, так что это такие вещи, как труднодоступные участки или материалы, вероятно будет отложено).
В контексте интеллектуального анализа данных не хватает исследований и достоверных данных о том, сколько времени занимает все, даже если это не в такой степени, как в марсианских путешествиях. Один метод, DMCoMo, дает начало тому, что следует учитывать, но его критиковали за отсутствие полезности за пределами узкого рабочего диапазона.
Возможное решение - начать сбор собственных данных, используя списки потенциальных драйверов затрат, предложенные DMCoMo или аналогичной документацией, в качестве руководства о том, что следует учитывать и о чем собирать данные. Вы по-прежнему можете использовать структуру для быстрой оценки времени начала на основе ваших завершенных проектов, их вовлеченности и количества человеко-часов, затраченных на них.
Группы DMCoMo
- Исходные данные, например сколько, какое качество
- Модель интеллектуального анализа данных, например сколько, какого типа
- Платформа разработки
- Инструменты, например уровень обучения, полученный существующим персоналом
- Проекты, например, количество задействованных различных отделов
- Персонал проекта, например уровень знания предметной области.
Если вы единственный, кто записывает эту информацию, вы внезапно превратите слабость в своей презентации, которая создает пробел в доверии, в преимущество перед другими, предлагающими проекты. Если у вас есть наибольшее доверие, у вас есть преимущество, которое поможет вам преодолеть черту, которую сложно убедить заинтересованным сторонам, и вместо того, чтобы столкнуться с мусорной корзиной, ваш проект увидит зеленый свет.
Роберт де Грааф является автором книги «Ленивый ученый, занимающейся данными» на LeanPub, а также одноименной записи в блоге. Его последняя статья на Medium была «Magpie Data Science».
