12 причин неудач в аналитике и бизнес-аналитике
Число 9 может вас удивить
В аналитике и бизнес-аналитике многое может пойти не так. Ведь мы ищем единственную версию правды. Будь то отчет или проект, чтобы данные и результаты были согласованными, поддающимися проверке, точными и, что наиболее важно, принятыми конечным пользователем, в цепочке должно быть много звеньев, которые должны быть правильными. Практика непрерывной интеграции, придуманная разработчиками программного обеспечения и заимствованная сообществом аналитиков и бизнес-аналитики, представляет собой попытку отловить ошибки на ранней стадии.
Тем не менее, ошибки закрадываются в конечный продукт. Почему это неправильно? Вот некоторые предлоги причины, по которым приборная панель неверна или проект провалился.
- Это будет быстрее. Да, это, наверное, правда. Это вопрос компромиссов. Какой ты предпочитаешь? Вы хотите, чтобы это было быстро или вы хотите, чтобы это было сделано правильно?
Честно говоря, иногда мы оказываемся в таком положении. Мне нужно к пятнице. Мне это нужно сегодня. Нет, мне это нужно было вчера. Начальник не спросил, сколько времени это займет. Он заявил нам, как долго мы должны были это сделать. Потому что именно тогда отделу продаж это нужно. Потому что именно тогда этого хочет клиент. - Этого будет достаточно. Совершенство невозможно и, кроме того, совершенство — враг добра. изобретатель РЛС раннего предупреждения о воздушных налетах предложил «культ несовершенного». Его философия заключалась в следующем: «Всегда стремитесь дать военным третье место, потому что лучшее невозможно, а второе всегда слишком поздно». Оставим культ несовершенных для военных. Я думаю, что момент гибкого, постепенного продвижения к конечному результату здесь упущен. В методологии Agile есть понятие минимально жизнеспособного продукта (MVP). Ключевое слово здесь жизнеспособный. Это не мертво по прибытии, и это не сделано. То, что у вас есть, — это путевая точка на пути к успешному пункту назначения.
- Это будет дешевле. Не совсем. Не в долгосрочной перспективе. Это всегда стоит больше, чтобы исправить это позже. Дешевле сделать это с первого раза.
За каждый шаг, удаленный от начального кодирования, стоимость на порядок выше. Эта причина связана с первой, скоростью доставки. Тремя сторонами треугольника управления проектом являются объем, стоимость и продолжительность. Вы не можете изменить одно, не затрагивая других. Здесь действует тот же принцип: выберите два. Хорошо. Быстро. Дешевый. https://www.pyragraph.com/2013/05/good-fast-cheap-you-can-only-pick-two/ - Это всего лишь ПОС. Мы ведь не собираемся запускать Proof of Concept в производство, верно? Это о правильном установлении ожиданий. POC обычно ограничен по времени с определенным набором целей или вариантов использования для оценки приложения или среды. Эти варианты использования представляют собой обязательные или общие шаблоны. Таким образом, оценка POC, по определению, представляет собой кусок большого пирога, на котором мы можем основывать дальнейшие решения. это редко никогда не стоит запускать POC в производство, будь то программное или аппаратное обеспечение.
- Это временно.
Если результаты неверны, он плохо работает или просто уродлив, он не должен был уйти в производство. Даже если это промежуточный результат, он должен быть презентабельным. Конечные пользователи и заинтересованные стороны не примут это. Предупреждение, однако, может быть приемлемым, если это ожидания, которые были установлены как часть процесса. «Цифры правильные, но мы хотели бы узнать ваше мнение о цветах на приборной панели». Тем не менее, это не должно быть в производстве; это должно быть в более низкой среде. Слишком часто «это только временно» становится благими намерениями постоянной проблемы. - Это единственный известный мне способ. Иногда существует более одного правильного ответа. И иногда есть более одного пути, чтобы добраться до пункта назначения. Иногда мы приносим с собой наши старые привычки. Они тяжело умирают. Используйте это как обучающий момент. Учитесь правильно. Не торопитесь. Попросить помощи.
- Так мы всегда это делали. Это трудно исправить, и с этим трудно спорить. Для изменения процессов и людей, которые их выполняют, требуется реальное управление организационными изменениями. Часто новый проект, новое программное обеспечение, обновление или миграция выявляют давно скрытые проблемы. Время меняться.
- Ой, я сделал это снова.
Я плотник, и у нас есть девиз, потому что мы делаем много ошибок: дважды отмерь и один раз отрежь. Я знаю этот афоризм. Я повторяю это про себя. Но, к моему стыду, бывают случаи, когда моя доска оказывается слишком короткой. Это невнимательность? Возможно. Однако чаще всего это просто что-то быстрое и простое. Мне действительно не нужен план. Но вы знаете, что? Если бы я потратил время, чтобы нарисовать это на плане, велики шансы, что цифры были бы рассчитаны. Слишком короткая часть могла быть на бумаге, и ее можно было бы исправить ластиком. То же самое относится к аналитике и бизнес-аналитике: план — даже для чего-то быстрого и простого — может уменьшить количество подобных ошибок. - Отвлечение. Глядя, но не видя. Невнимательная слепота. Возможно, вы видели видео где вам дается задание, например, подсчитать количество баскетбольных передач для одной команды. Пока вы отвлекаетесь, выполняя эту простую задачу, [ВНИМАНИЕ, СПОЙЛЕР] вы не замечаете гориллу, идущую по луне. Я знал, что должно было случиться, и все равно стал бы ужасным свидетелем, если бы было совершено преступление. То же самое происходит и при разработке отчетов. Требования требуют идеального выравнивания до пикселя, логотип должен быть актуальным, должна быть включена юридическая оговорка. Не позволяйте этому отвлекать вас от проверки достоверности расчетов.
- Вы намеревались.
Или, как ожидается. По крайней мере, это всегда был вариант. Знаменитое высказывание Томаса Эдисона: «Я не потерпел неудачу. Я только что нашел десять тысяч способов, которые не работают». Его философия заключалась в том, что с каждой неудачей он был на шаг ближе к успеху. В каком-то смысле он планировал потерпеть неудачу. Он исключал возможности. Он прибегал к методу проб и ошибок только тогда, когда у него заканчивались теории. У меня нет более тысячи патентов на мое имя, как у Эдисона, но я думаю, что у нас могут быть лучшие подходы к разработке аналитики или отчетов. (Заявка Томаса Эдисона на патент на электрическую лампу накаливания, 1882 г.) - Глупость. Не отрицай этого. Это существует. Глупость находится где-то между «Ты собирался» и «Ой». Этот тип эпического провала — разновидность «смотри-держи-мое-пиво», премия Дарвина. Так что, возможно, иногда замешан алкоголь. К счастью, в нашей профессии, насколько я знаю, пьяная приборная панель еще никого не убивала. Но, если вам все равно, если вы работаете на атомной электростанции, пожалуйста, сделайте свою аналитику трезвой.
- Успех не имеет значения.
Легендарному каскадеру Эвилу Книвелу платили за выполнение смертельных трюков. Успех или неудача — застрял ли он на посадке или нет — он получил чек. Его целью было выжить. Если вы не получите компенсацию за сломанные кости — Книвель попал в Книгу рекордов Гиннесса по количеству сломанных костей за всю жизнь — успех имеет значение.
