Почему так важно правильно задавать вопросы (читай: ставить задачи)?
Потому что при плохой постановке исполнитель может:
- С презрением ответить: «Как попросили, так и сделали»
- Закопаться в вопросе и, потратив немало времени, найти причины не делать задачу.
Если с первым пунктом все ясно, такое поведение распространено и предсказуемо (работу выполнили для галочки), то второй случай встречается реже и эффект от него более сильный.
Сверхопытному сотруднику поручили выбрать операционную систему для сборки образов Docker как стандарт на долгосрочную перспективу. И хотя работа ведется для российских компаний с отечественными дистрибутивами, на данный момент ни один клиент не сообщил свою версию (переход еще не состоялся, либо планируется очередная замена ОС, так как первый опыт импортозамещения оказался неудачным).
С нашей стороны, как вендора ПО, для первого этапа и внутренней разработки хотелось бы использовать стабильную ОС с долгим сроком поддержки. Предварительно выбор пал на ОС Z.
Сотрудник был выбран исходя из его компетенций и способности выходить за рамки, чтобы заранее предвидеть возможные ошибки выбранного решения. Но именно это качество загнало задачу в тупик. Он смог найти столько блокирующих ограничений, что под эти критерии ни одна ОС не подошла бы. И вместо ожидаемого предложения получен длинный ответ, что:
- Java такой-то версии скоро перестанет поддерживаться в этой линейке ОС
- Количество уязвимостей зашкаливает
- Вот вам еще информация для размышления
Информация была найдена из открытых источников. Ну что ж. А по остальным 100% российских дистрибутивам вообще нет такой информации. И что там предложит ФСТЭК в качестве проходных критериев? А местные безопасники? В конце концов инженер по закупкам решит за всех, какой дистрибутив будет в проде и других средах.
Почему задача забуксовала? Потому что я ее плохо поставил и понес в сыром виде (как «обычно»). Как в случае с ИИ, я не сформировал четкий промпт, то есть не ограничил человека в направлениях исследования. Туда можно отнести совместимость с Кошмарским и балансировщиками, поддержку оборудования ядром и т.д.. Иногда нужно просто принять решение и взять его в работу. Понимая что затрачено допустимое количество времени оттого это не замылило глаз ненужными пока вещами. И следовательно в таком состоянии легко будет расстаться с выбранным решением в пользу альтернативного.