Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 9
Хороших постановщиков задачи крайне мало. За пару десятков лет в IT лишь 1-2 таких встречал. В плохих постановщиках раздражает не столько неуважение/пренебрежение к исполнителю, сколько то, что потом приходится переделывать. Пример из статьи «Спроектируй раздел клиентов в CRM‑системе» можно исполнить на своем видении задачи и это даже интересно, простор для творчества по причине размытости формулировки. НО видение постановщика задачи наверняка отличается от моего и потом заставят переделывать и не соглашаются с твоим мнением.
Спасибо! Про переделку это вы попали в то, что я в статье недокрутил. Там акцент на «исполнитель сделает мимо», а ведь обиднее всего именно ваш сценарий: задача размытая, ты честно вложился в своё видение, оно живое и осмысленное, а потом выясняется, что у постановщика в голове было другое, и всё в корзину. Причём формально к тебе не придраться, ты сделал «как понял».
Похоже, тут напрашивается шестой пункт – про сверку картинок на старте. Не молча "я понял задачу", а проговорить вслух: вот как конечный результат вижу я, вот как его видит постановщик — и убедиться, что это одна картинка, до того как вложено время. По сути это пятый урок про критерий, но повёрнутый: критерий мало записать, его надо ещё и сверить — понимаем ли мы с постановщиком его одинаково.
И да, по поводу "1-2 за двадцать лет" – грустно, но похоже на правду. Подозреваю, отчасти потому, что навык невидимый, хорошая постановка выглядит так, будто задача "сама была простая", и заслуги не видно. А плохую замечаешь только на этапе переделки, когда уже поздно.
Продолжая рассуждать на данную тему отметил бы еще две вещи:
1) В качестве оправдания плохой постановки привожу фактор занятости постановщика, который, как правило, занимает руководящую должность, ему все время некогда и его голова работает более масштабно.
2) Про сверку - верный тезис. Полезно сверять видения в самом начале. Я, когда получаю размытую задачу и подозреваю, что мы с постановщик мыслим по-разному, просто пишу мини-ТЗ за него и отсылаю ему с начальной фразой "Итак, я делаю..." и по нумерованным пунктам перечисляю свое видение.
Соглашусь про занятость. Но цена этой сэкономленной минуты просто перекладывается на исполнителя, причём с процентами: переделка стоит дороже, чем нормальная постановка с самого начала. То, что недосформулировано наверху, всё равно будет досформулировано – только ниже и дороже.
Про мини-ТЗ – отличный приём. По сути вы делаете сверку картинок: своё видение задачи и решения кладёте перед постановщиком, и он сразу видит несоответствие – если оно есть – и поправляет на этапе, который дёшев для вас обоих. Плюс мягко приучаете постановщика, что у задачи есть форма.
Мне кажется, что в статье не учтено два режима: "Делегирование задачи" и "делегирование ответственности". И перому можно научиться у промпт-инженеров, вот только это нифига не высвобождает ресурсы, а заставляет все перепроверять и исправлять, плюс бесконечно заботиться о количестве делегированных задач. А второе, что является истинным дзеном управленца, уж очень далеко от промптинга...
Очень точное разграничение, и вы правы – в статье оно не проговорено, это её честная граница. Соглашусь по первой части полностью: делегирование задачи ресурс не высвобождает, а перекладывает в другую форму — с "придумать решение" на "проверить и поправить" плюс держать в голове список поручений. Проверка становится явным шагом процесса. Облегчение тут не в том, что работа испаряется, а в том, что она перестаёт быть невидимой.
А вот вторая часть, на мой взгляд, не столько "не учтена в статье", сколько в принципе лежит вне её темы – и вы сами на это указали. Делегирование ответственности – это не приём формулировки, это про доверие и про то, что человек растёт и может отвечать за результат. Его нельзя "хорошо сформулировать", его можно только дать тому, кто способен нести. ИИ сюда не помещается не из-за плохого промпта, а потому что ответственность предполагает субъекта, который ею рискует.
Так что да – промптинг даёт язык для первого режима и честно молчит про второй. Спасибо, что подсветили это.
Однако, если я скажу LLM сделай на свое усмотрение, я дальше пойму как правильно - он не будет на меня обижаться и сделает пусть не всегда с первой попытки правильно, но все равно приблизит меня к нужному результату. С людьми такое проходит крайне редко.
Что касается "постарайся получше" - да, в такой формулировке не сработает, но "сделай проще" уже вполне работает с LLM и он предложит более простые правки в коде, не уточняя в чем же простота. Сработает ли такое с людьми? Тоже крайне редко и только если человек достаточно высокой квалификации.
Да, человеку не скажешь: "Мы с тобой сделали мусор, стирай всё, будем писать по новой". Нейронка же даже не морщиться.
Я так одну систему четыре раза переписывал, пока понял, как она выглядеть должна
Вы поймали место, где аналогия честно ломается – и не в пользу статьи. Я веду к "делегируй ИИ так же тщательно, как человеку". А вы показываете обратное: с ИИ можно позволить себе небрежность, которую человек не простит. Итерация ничего не стоит, эго нет, на "сделай на своё усмотрение, дальше разберусь" он не обижается.
С людьми так не очень хорошо – у них итерация не бесплатна: каждый заход стоит времени, труда и капельки самолюбия. Так что да ИИ прощает постановщику то, чего не прощает человек.
Про "сделай проще" против "постарайся получше" – точное наблюдение, оно уточняет мой первый урок. Обе формулировки расплывчатые, но "проще" задаёт вектор, а "получше" – нет, это просто "сделай хорошо" другими словами. Дело не в расплывчатости, а в том, есть ли в формулировке направление. И с человеком даже вектор сработает только при высокой квалификации – ему ещё нужно знать, что в этом контексте считается "проще"
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делегирование, которому можно научиться у промпт‑инженеров