Комментарии 9
С тем, что исследование всегда успешное, я не соглашусь. Сам автор выше говорит, что исследование должно быть направлено на решение какой-либо бизнес-задачи. Если исследование не закончилось успехом, например, решено такую-то технологию/инструмент не внедрять, то разве бизнес-задача решена? Не-а. Отмести один из N вариантов - это не решение.
Я бы в целом чуть отодвинул R&D от решения конкретных задач. Как по мне, такие проекты существуют на более концептуальном уровне.
Согласен с вами, наверное стоило упомянуть что цель исследования может звучать по-разному, например: оценить применимость технологии или оценить какая технология подойдет для решения задачи лучше. Во втором случае мы так или иначе найдем одну которая лучше остальных, пусть она и не идеально подходит.
Расскажите, какие концептуальные исследования вы проводили? Каким был их сценарий и цели?
Исследование не обязательно равно в результате решению бизнесовой задачи. Главное что оно закончилось и из него извлекли пользу. Бизнесу да, необходимо чтобы его задача была решена, но что делать исполнителям, которые замкнуты в бесконечном круге решения только бизнесовых задач? Любое исследование новой технологии на пальцах и вымышленных примерах мало полезно. Этому помогает данный процесс. Возможность попробовать что-то нестандартное или какую-то новую технологию для решения реальной задачи и получить результат самого исследования, таким образом и приблизить решение бизнес задачи (отсеивая неподходящие способы и технологии для этой задачи) и разбавить рутину, используя что-то новое.
Автор говорит, что не успешность в решении одной бизнес задачи не мешает вам использовать результат для решения другой. Т.е. само по себе исследование обогащает ваш опыт вне зависимости от полученного результата в определенном контексте и т.о. исследование в конечном счёте успешно.
Для исследователя да, но если смотреть на это в контексте всей организации, то бизнес оплачивает эти исследования. Росто компетенций это хорошо, но какая отдача от этого для бизнеса? В статье какраз о том как посчитать и обосновать.
Рост компетенций это хорошо, но какая отдача от этого для бизнеса?
Как я написал тут https://habr.com/ru/companies/yoomoney/articles/777596/comments/#comment_26246028, есть два измерения этого вопроса.
Один. Сбросив миксер с крыши (исследовав ударную прочность) вы (как исполнитель) будете уверены что вам не будет больно когда миксер при старте ракеты развалится. А как компания вы будете уверены, что узколобость отдельного исполнителя не повлияет на успешность доставки миксера на орбиту. Т.е. думать что исполнители хорошие добросовестные ребята это конечно приветствуется, но почитайте сборник законов Мёрфи...
Два. Это момент по поводу того, что никакая "задача" не может быть выбита в граните так, чтобы её нельзя было скоректировать под воздействием реальности, и вашего понимания этой задачи в этой реальности. Вы должны быть открыты ко всему, что может изменить эту задачу на основе обратной связи, тем более если она не имеет смысла.
Проблема с утверждением про вечный успех связана с тем, что это попытка выдать самому себе индульгенцию. Что бы ты не делал - ты молодец. Если компании нужно отправить спутник на орбиту и ты просто скинул с крышы офиса миксер - окей, ты выяснил, что миксеры не летают. Успех? Успех.
Исследование должно создавать ценность, которая неким значимым образом приближает компанию к решению бизнес-задач. В примере с миксером реальная польза максимально близка к нулю.
И это нас приводит ещё к одной интересной мысли. У исследования есть заказчик? Кто-то извне команды исследования. Если так, то получается это он решает, успешно завершилось исследование или нет. Заказчик решает, а не сама команда.
Есть такое измерение успеха, но я бы приписал его не отдельному исследованию, а исследовательской деятельности в компании в целом. Дело в том, что нет наверное такой отрасли, где бы количество "успешных" по вашему определению исследований было бы 100%. Мы всегда имеем дело с каким-то отношением. В своём докладе на эту тему (посмотрите его по ссылке в статье) я рассматриваю организацию процесса исследования, одна из целей которого — повысить качество исследований и долю исследований, результаты которых можно внедрять.
Если исследование окончилось выводами, что технология или решение не подходит, эти результаты всё ещё можно использовать. Во-первых, как руководство не использовать технологию, во-вторых — как материалы к анализу, можем ли мы на ранних этапах планирования исследований такие моменты заранее определять. В этом заключается полезность таких исследований.
Действительно "неудачными" исследованиями в этой статье я называю исследования, результаты которого не ясны, не формализованы, не пригодны для интерпретации.
Если компании нужно отправить спутник на орбиту и ты просто скинул с крышы офиса миксер - окей, ты выяснил, что миксеры не летают.
Дело в том, что всё что отправляется в космос на ракете действительно скидывают с крыши офиса)). На современно этапе это называется испытанием (исследованием) ударной прочтности, которое делаю чтобы быть уверенным что ваш миксер не развалится при стартовой перегрузке. На уровне физики это (исследование ударной прочности) тоже что скинуть миксер с высоты h n раз.
Технологи на производстве тоже постоянно занимаются исследованиями. Просто эти исследования стандартизованы и могут называться калибровкой, или ещё как. Но само по себе это и есть исследование. И на производстве чего бы то нибыло его постоянно делают возможно под другими названиями.
Исследование должно создавать ценность, которая неким значимым образом приближает компанию к решению бизнес-задач. В примере с миксером реальная польза максимально близка к нулю.
На этот счёт припоминается что-то из менеджмента по поводу того, что само по себе формулирование бизнес-задачи зависит от вашего понимания много чего и никак не должно быть выдолблено в камне, именно потому что некоторые аспекты задачи вы начинаете воспринимать как "польза максимально близка к нулю", хотя на самом деле это польза от вашей задачи близка к нулю. Как в примере, когда вам ставят задачу всунуть квадратную втулку в треугольное отверстие.
R&D-проекты в IT: как убедить руководителя проводить исследования и зачем это бизнесу