Представьте, что вы сформулировали требование: «Поднять производительность системы N». Ваша команда в ответ отключила половину функций, чтобы оставшиеся работали быстрее. Задача выполнена? Технически, «де-юре» — да, «де-факто» же получилась катастрофа. Этот разрыв между буквой и духом, между сказанным и услышанным — вечная головная боль любого инженера, менеджера и вообще любого участника команды проекта. Это та самая точка, где заканчивается техника и начинается философия, а безответственность в формулировках маскируется под «творческий подход».
Сказочные мотивы
А между тем, даже юные читатели сказок знают, что надо быть очень осторожным при формулировании желаний у джинов, золотых рыбок и прочих подобных волшебных персонажей. Те желания, конечно, выполнят. Но строго буквально и так, что тысячу раз пожалеешь.
Неполнота требований и отсутствие критериев успеха наглядно продемонстрировано в сказке про царевну-лягушку. Вот, что значит указание сыновьям «пустить стрелы в разные стороны, кто найдёт стрелу, станет их женой»? Разумная лягушка — это еще не самый плохой вариант, между прочим. Она, хотя бы женского рода.
Игнорирование ограничений и способов достижения целей легко может привести к тому, что какой-то цветик-семицветик на просьбу сделать прохладнее перенесет персонажа на Северный полюс.
В английской сказке «Три желания» жена дровосека, встретившего до того фею, в сердцах пожелала, чтобы кровяная колбаса, полученная в результате исполнения первого требования, приросла к носу. Ну типа, нашел, что желать старый дурень. Желание было исполнено буквально. Наглядно продемонстрировав ошибку двусмысленности и отсутствия однозначной трактовки.
«Хочу быть богатым!» — просит путник у Вселенной. И вот через некоторое время он случайно выигрывает в карты золотой рудник, расположенный на диких далеких землях, где добыча невозможна.
Из жизненных наблюдений — это так и работает. Вот жена загадала как-то, чтобы меньше работать и больше проводить дома. Так оно и случилось, на самом деле — неожиданно ушла в декрет. А до этого она в детстве мечтала просыпаться от крика чаек. Просыпается, но почему-то не на берегу теплого ласкового моря, как ожидала, а вот тут — на берегу холодной Невы.
Знаю я одного мужика, что на Новый Год загадал не нуждаться в деньгах. И действительно, не нуждается — посадили его туда, где они хоть лишними не будут, но не особо нужны.
Что сказать: бойтесь своих не сформулированных четко желаний, они иногда имеют свойство сбываться.
Кто виноват, что тебя неправильно поняли?
Риторический вопрос, при условии, что на той стороне искренни старались. На военной кафедре курсах лейтенантов запаса по этому поводу всегда повторяли: поставил задачу подчиненному, заставь повторить, как он ее планирует исполнять. Можешь узнать много нового и интересного. Ну а не получил обратную связь, то кто тебе доктор?
Проблема проклятия «полного знания»: тот, кто ставит задачу, уже обладает всем контекстом, а исполнитель — нет. И этот контекст выветривается из расплывчатых формулировок.
Нейросеть: идеальный солдат, выполняющий приказ буквально
Нейросеть — это квинтэссенция проблемы формулировок. Это не разумный собеседник, а статистическая модель, настроенная на буквальную интерпретацию вашего запроса (промта).
Примеры:
- Запрос: «Сделай изображение более профессиональным».
- Результат: Нейросеть может добавить гигантский водяной знак «PROFESSIONAL» или превратить деловую графику в стоковую картинку с улыбающимися менеджерами. Она не знает, что для вас значит «профессиональный».
- Запрос: «Напиши код для подключения к базе данных».
- Результат: Вы получите общий шаблон, возможно, с устаревшей библиотекой, без обработки ошибок и комментариев. Задача «написать код» выполнена, но ценность его близка к нулю.
Но зато если составил хороший промт на одну или даже две страницы, то может начаться полезная магия. Это и есть техническое задание для искусственного интеллекта ИИ. Вы задаете:
- Роль: «Ты инженер-конструктор, проектирующий подстанцию для...»;
- Контекст: «Проект использует российские нормативные документы, следующую элементную базу, стандарты организации, вот требуемые документы, вот схема таблицы, вот прайс-лист...»;
- Задача: «Подготовь подробный расчет себестоимости, составь техническое предложение по шаблону (шаблон прилагается)»;
- Ограничения: «Не используй естественную вентиляцию, не используй переменный ток в системе собственных нужд».
И нейросеть выдаст результат, который можно использовать. Потому что вы построили для нее однозначную модель мира и задачи.
Технические задания, как особый вид искусства вводить в заблуждение
Всех, кто пишет в задании (ТЗ): «определить при конструировании/ проектировании», следует отправлять в ад. В управлении это называется перекладыванием ответственности (не путать с делегированием). И резко ставит вопрос о компетенции руководителя.
Но в случае с инженерами, почему-то прокатывает.
Нет, на той стороне, скорее всего достроят контекст, ибо привыкли. Но сиюминутная выгода в долгосрочной перспективе принесет проблемы: проект рискует пойти не туда, будет затрачена куча ресурсов на согласования, переделки. И еще потеряна мотивация: когда понимаешь, что тут тебя все-равно ждет неопределенность и куча проблем, работается совершенно иначе, чем когда единственный вопрос — как сделать все качественно.
Как-то была задача разработать кронштейн для крепления гидроцилиндра, конкретный способ крепления определить при конструировании. Инженер без задней мысли понимает это, как необходимость самому выбрать решение. Нет, для приличия спросил, что и как. Ответа не получил, указал, что крепление сваркой.
Кронштейны изготовили и везли через пол страны. Объект, как положено от ближайшего промышленного центра и даже магазина крайне далеко. И, естественно, оказалось, что так делать нельзя. Не помню точно — они там на бетонной крыше здания размещались. В общем, пока ругались, пока искали выход и крайнего — сорвали сроки, так как задерживали еще и смежников. Разработчика показательно лишили премии за непроявленную настойчивость в сборе исходных данных, хотя всем было понятно, что проблема была в ТЗ.
В чем проблема?
Корень проблемы — в недостатке системного мышления и адекватности.
- Системное мышление — это способность видеть не только свою деталь, но и весь механизм, понимать связи и последствия.
- Адекватность — это честный взгляд на практические реалии и человеческие отношения. Нужно понимать, что исполнитель — не джинн и даже не нейросеть, а человек со своим контекстом и ограничениями. И относиться к его времени и интеллекту надо с уважением, давая четкий вектор движения.
Именно к этому я и призываю: инвестируйте в качество формулировок. Это самая доходная инвестиция в ваших проектах.
Технологии точных формулировок
Уже рассказывал про SMART, однако существуют и другие.
- USER-STORIES: «Как [роль], я хочу [функция], чтобы [ценность/выгода]». Этот формат заставляет думать о цели, а не только о реализации. «Как пользователь этого объекта, я хочу иметь возможность получить проектный доступ к этому механизму для обслуживания, а не пользоваться левитацией».
- INVEST: Хорошая пользовательская история должна быть Независимой (Independent), Negotiable (Обсуждаемой), Ценной (Valuable), Оцениваемой (Estimable), Небольшой (Small), Тестируемой (Testable).
- 5W2H: What (Что?), Why (Зачем?), Where (Где?), Who (Кто?), When (Когда?), How (Как?), How much (Сколько стоит?). Простой и эффективный чек-лист для проверки полноты задачи.
Смысл тут в том, чтобы иметь для разных задач перечень (чек-лист) вопросов, проходя через которые получаешь максимально точную формулировку. Ну а если чего-то не знаешь, надо привлечь экспертов. Или указать путь, где необходимо получить информацию.
Как с тем кронштейном. Что стоило в ТЗ написать — «способ крепления согласовать с инженером-конструктором здания»?
Никогда ничего не проси – в 80% случаев это заблуждение
Не раз натыкался на авторские мнения, которые восхваляли цитату из романа Михаила Булгакова «Мастер и Маргарита», которую произносит Воланд.
«Никогда и ничего не просите! Никогда и ничего, и в особенности у тех, кто сильнее вас. Сами предложат и сами всё дадут!»
Звучит гордо и мистически. Но в реальном мире, особенно в инженерии и бизнесе, это опаснейшее заблуждение. Это ведь тоже про требования.
Всегда я вспоминал в этот момент свой личный опыт, когда, будучи молодым, только назначенным руководителем подошел к своему начальнику с предложением: «надо бы поднять талантливому подчиненному заработную плату на всякий случай». И в ответ: а он тебя просил? Нет? Ну так значит ему все хватает — ничего повышать не надо, вопрос закрыт.
В общем случае эта фраза Воланда — не стратегия успеха, а защитная психология человека, который боится отказа. Она работает только в одном случае — когда вы обладаете эксклюзивной, критически важной компетенцией и вас пытаются удержать. Да, тогда «сами предложат». Но это ситуация рыночной монополии, а не норма рабочего процесса. В 99% случаев правило звучит иначе: «всегда аргументированно проси и предлагай». Не подошел к начальнику с жалобой «мало платят», а пришел с анализом рынка, списком своих достижений и обоснованием, как твоя повышенная зарплата повлияет на успех проекта. Это язык, на котором говорят взрослые дяди профессионалы.
Итак, философия инженера должна быть противоположной: всегда всё просите однозначно и четко формулируйте требования необходимого вам для достижения успеха нужного результата. Требуйте того же от других. Превратите размытые пожелания в измеримые параметры, сказки о золотых рыбках — в рабочие протоколы, а монологи в стиле Воланда — в предметные диалоги.
Ознакомиться с содержанием журнала.
Уважаемые коллеги, желаю хорошего дня. Подписывайтесь, чтобы иметь возможность обсудить со мной вашу задачу в комментариях. Буду рад лайку, альтернативному мнению или истории по теме статьи. При желании вы можете поблагодарить автора чашкой кофе для стимулирования мыслительного процесса и блогерского энтузиазма.
ПРЕДУПРЕЖДЕНИЕ №1: Оценки, суждения и предложения по рассматриваемым вопросам являются личным мнением автора.
ПРЕДУПРЕЖДЕНИЕ №2: Техническая информация, представленная на сайте, не является официальной и предоставлена только в целях ознакомления. Владелец сайта не несет никакой ответственности за риски, связанные с использованием информации, полученной из данного источника.
Все изображения, если не указано иное, либо выполнены автором, либо взяты из открытых источников.