Пишу обо всем, что только взбредет в мою нездоровую голову
Всем ку
Уже больше полугода прошло с момента выхода уникального в плане пользования механик тест challenge? от Etern. Более того, он
Еще полгода назад я грезил возможностями, но уперся в ограничения редактора, однако за последние две недели я очень сильно продвинулся в сием мероприятии, потому поделюсь своими открытиями с вами.
Я скажу прямо - я CSS не знаю, и я слишком ленив, чтобы учить полноценный язык программирования для каких-то тестиков на пикуко, потому техническую часть от меня не ждите, я вайбкодер. Тем не менее, общие технические принципы я понимаю и поясню, так что у вас будет два пути - или по моему объяснению самостоятельно написать код, или же отдать все клоду, гпт или дипсику с подробным описанием принципов, чтобы они язык слов перевели в язык слова.
Итак, прежде чем начинать разбор некоторых механик, необходимо вообще понять, с чем мы имеем дело - как вообще работают челленджи на пикуко.
Первое, что нам нужно понимать - это что такое svg в принципе, а это векторный формат изображений. У него много отличий от растровых, но для нас важно другое - по сути такое изображение и не изображение в полном смысле слова, по крайней мере в том смысле, в котором мы говорим про растр. Данный формат не задает цвет пикселя в каждой точке, как делают изображения. Что же делает свг? Грубо говоря, это очень большая инструкция по тому, что и как нужно будет нарисовать.
Для нас это принципиально важно, потому что это означает, что свг по-хорошему - это текстовый файл, а в текстовый файл можно вносить свои приколы при большом желании. По сути, мы можем задавать правила интеракции и анимации в самом файле свг.
И тут важно уточнить - в свг можно прописать код на языке HTML и на языке CSS (ну и собственные свойства свг тоже можно прописывать, естественно). И очень важно запомнить - Пикуко съедает HTML. Ничего, что вы напишете через HTML, работать на сайте не будет (это во многом просто защита пользователей), и единственный способ сохранить какие-то данные - это не пользоваться HTML от слова совсем и обходиться альтернативными методами.
Теперь нужно вообще понять, как работает закраска на пикуко. Итак, в svg имеются объекты - по сути те самые кляксы, которые вы рисуете. Сервер пикуко берет эти элементы и присваивает им CSS-правило, по которому какой-то элемент будет выглядеть - в котором с пометкой !important прописан конкретный серый цвет. При вводе правильного ответа идет обращение к серверу, который находит то, какой объект был привязан к данному ответу и какой цвет нужно присвоить, и просто накидывает поверх серого правила новое правило (дальше буду называть стилем для простоты) с уже нужным цветом.
В данном случае нам важно запомнить две вещи - обработка изображения идет таким образом, что заданный сайтом стиль имеет строгий приоритет над тем, что задают стили свг. Также важно - цвет прописан именно в стиле и с пометкой !important (эта пометка значит, что правило, прописанное под ним важнее всего, что мы пытается сделать дальше, и он никак не поменяется). И наконец - правило стиля нашего объекта не меняется, а просто создает новое на странице вашего браузера.
Также уточню еще один важный момент - описанное выше актуально не для всего. Данный стиль не применяется к объектам ellipse (эллипс), line (линия), polyline (ломаная) и, внезапно, image (встроенное изображение). Другими словами, эти объекты сохранят тот же цвет, что вы задали в свг. Дополнительно отмечу, что обводке прямо указано сохранять цвет, так что в теории можно обойтись с помощью нее, но по моему опыту это работает кривовато. Можно исхищряться и делать все через эллипсы, если вам нужно будет, например, понизить вес картинки и сохранить цвета (хотя на практике проверено - пнгшки более чем успешно сохраняются в свгшках на пикуко)
Итак, вот мы узнали, как работают челленджи. Представим, что мы уже знаем нужные языки и знаем, что это делать, и готовы работать с нашим изображением. Какие проблемы у нас возникают?
Самое первое, что нас беспокоит - сложность покраски. Поскольку суть челленджей заключена в покраске свг-карты, все правила, связанные с цветами заданы очень строго, потому придется исхищряться (хотя никто не запрещает вам все-таки передать покраску на пользователей). Тем не менее, есть сразу несколько способов задать цвета насильно (уточняю - через фотошоп не проверял, смотрел в фигме):
1) Описал еще Etern в своем посте и я же упоминал выше - нарисовать все нужные элементы с помощью ellipse, line и polyline. Для меня это выглядит как какая-то лютая дрочь, но тем не менее метод более, чем рабочий. Но тоже важно учитывать - если вы выгрузите идеальный круг (ширина и высота одинаковые), то при экспорте данная фигура будет помечена как circle, а на него правило покраски идет как на обычные объекты. Поэтому делайте ширину или высоту хотя бы на 1 десятую пикселя больше (фигма поддерживает дробные значения).
2) Использовать пнг-картинку. Для этого можно просто закинуть пнгшку в какую-нибудь фигму и сделать экспорт в svg. На самом деле, для всех сложных неинтерактивных элементов это лучший вариант. НО! Очень важный момент. Картинку лучше вставить в первородной форме, т.е. не делать заливку изображением, а именно засунуть само изображение. Заливку пикуко съест.
Из-за этого есть 2 проблемы. Во-первых, у нас все еще есть ограничение в 512КБ, а пнгшки довольно жирные по памяти, так что придется ужиматься (к слову, при добавлении в свг пнг еще и жирнее станет примерно на треть). Вторая проблема - к сожалению, графические редакторы вроде фигмы делают именно заливку, так что придется поработать ручками с кодом свг. Дальше задроченное описание, можете скипнуть:
Открываете файл, например, через блокнот. В начале файла у вас прописываются все объекты, которые если в вашем файле с помощью, в нашем случае интересует <rect> (если мы встраиваем изображение, чаще всего оно вписывается в прямоугольник). При выгрузке из фигмы он будет ссылаться на какой-то pattern, сможете найти дальше по файлу. Проверяет, что данный паттерн (запись начинается с <pattern id= *ваш айди*) ссылается на изображение (должно быть <use xlink:href= и какой-то #image)
Когда это нашли, удаляем строку <rect, ссылающуюся на наше изображение. После удаляем и все, начиная с соответствующего <pattern>, заканчивая </pattern>. В конце берем наше изображение - все, что начинается с <image id= и вставляем на то место, где стоял rect. Таким образом мы меняем логику изображения - вместо того, чтобы делать прямоугольник, у которого добавлена заливка изображением, мы вставляем само изображение. Также изображение будет окружено строками <defs> и </defs>. Они нам не нужны, так что можно их удалить, но в целом, если вы их оставите, ничего не поменяется - картинка все так же отобразится, важно вынести само изображение из этих строк
Еще важный момент. Пикуко определяет, какой объект находится выше на свг-карте, чтобы определить область закрашивания. Так, вы можете просто поместит обычные элементы свг поверх картинки, и спокойно выбирать его для закрашивания. Ну и рекомендую заранее в графическом редакторе задавать размеры и координаты, иначе придется их править ручками в файле.
3) Для каждого объекта вручную прописать пометку !important. Опять же, для этого нужно открывать код, но зато вариант дает полный контроль над свгшкой - находите ваши объекты (например, rect) и ищете свойство style ="fill: . Дальше будет прописан цвет - либо цветовым кодом, либо просто словом (red). Внутри этих же кавычек сразу после цвета пишете !important и вуаля - все готово (еще нюанс - если style= не был прописан, пропишите его, а fill внесите в кавычки)
Для кода помните правило - объект, написанный ниже, находится выше. По сути первая часть - это ваши слои с обозначением, кто за кем идет, к которым потом добавляются какие-то правила заполнения
Как видите, все три способа дают цвет без необходимости его закраски.
Второй вопрос, который у нас возникает - как нам взаимодействовать с ответами, введенными на пикуко? Тыкаться в картинку - это, конечно, круто, но хотелось бы, чтобы и сам смысл челленджа был сохранен (как вот в этом моем тесте или в этом моем тесте)
Что ж, есть у меня ответ и на это. Есть в CSS такая функция - :has(). По сути он проверяет наличие какого-то элемента на странице в данный момент. И у нас есть два варианта - в котором нам неважно, в каком порядке введут ответы (как в 100 к 1) и тот, где мы точно знаем порядок (как в тесте про уток)
Разница между ними минимальна. Поскольку в первом мы не знаем, какой элемент пользователь впишет первым, нам нужно точно увериться, что нужный нам триггер сработает на конкретный ответ, а не на любой. Это мы делаем с помощью задавания определенного цветового кода в проверке. Во втором случае достаточно просто написать количество введенных ответов и триггерить действия в зависимости от номера ответа
Важно! Если вы используете первый вариант, нужно обязательно, чтобы цвет на пикуко совпадал с цветом в вашем свг-файле. Если цвет будет отличаться хоть на 1 последнюю цифру, все перестанет работать.
Дальше немного по коду, можете пропустить, но если хотите прописывать это самостоятельно или дать пояснения нейронке, можете почитать (или скопировать)
Пример такого кода:
.challenge__window:has( - запускаем проверку в рамках окна челленжа на наличие css-правила
.challenge__answer[style*="border-color: rgb(255, 202, 40)"] span style - в данном случае проверяет появление правила на конкретный цвет. По возможности желательно и hex-код прописать, но и ргб в целом хватает (если что, проверяется не сам цвет, а запись, так что лучше задать явно)
)
#my-pikuco-game .your-object {} - в фигурных скобках прописываем, что должно произойти. Любая анимация, движение, изменение размеров, изменение прозрачности и тд
</style> - закрываем блок.
Второй вариант реализуется примерно так
.challenge__window:has(
.challenge__answer:nth-child(
3 of .challenge__answer[style*="border-color"]
) span style и дальше как в прошлом коде - грубо говоря, проверь, чтобы css-правил стало три. По сути, можно применять, если до этого вы итак счетчик сделали
Картинка жабы для разгрузки
Следующий возможный вопрос - как нам выполнить запоминание какого-то значения? HTML и JS обрезаются, а CSS и SVG не дают памяти в явном виде. Тут нам на помощь придет такая вещь, как фокус.
Что такое фокус. По сути мы можем задать какую-то анимацию любому объекту. Но проблема будет в том, что мы не контролируем ее запуск - она может начаться с момента запуска теста. Однако мы можем прописать условие, при котором анимация запустится только в момент взаимодействия с объектом - и делаем это с помощью :focus:
В чем хитрость - мы заранее прописываем какую-то анимацию (например, понижение прозрачности) и времени, за которое событие должно произойти. А потом, когда мы как-то с ним взаимодействуем, запускаем необратимую анимацию. Пример кода под спойлером
<style>
#my-pikuco-game #focus-object {
opacity: 1; - задаем начальное состояние (100% непрозрачно)
transition: opacity 0.3s; - задаем время анимации (для мгновенного можно 1ms поставить)
}
#my-pikuco-game #focus-object:focus { - пишем, что при фокусе должно что-то произойти
opacity: 0.4; - задаем конечное состояние
}
</style>
<rect - находим нужный нам объект
id="focus-object" - в айдишник
tabindex="0" - получаем фокус при клике
И остальные свойства оставляем как есть
Второй вопрос - что делать, если мы хотим обратить анимацию вспять (как в этом моем тесте). Тут все несколько сложнее, но вполне реализуемо. Значится, помимо времени перехода мы также можем задать и время действия анимации. По сути мы просто создаем два фокуса в одной области - и в каждом запускает анимацию на срок больше, чем идет тест (например, миллиард лет). Настраиваем кнопку переключения режима, которые присваивают определенное значение заданной переменной, которая, в свою очередь, определит, какая из областей будет активна в данный момент. А затем каждой из них задаем анимацию на фокус. Пример кода:
.flaghit, .erasehit { - переменные
pointer-events: none; - начальное состояние, не взаимодействуем с ними
}
#flagmode:target ~ #main #assembly .flaghit {
pointer-events: all; - при активации принимаем все действия
}
#erasemode:target ~ #main #assembly .erasehit {
pointer-events: all; - то же самое, но со вторым режимом
}
<a href="#flagmode">...</a>
<a href="#erasemode">...</a> - задаем кнопки преключения режимов
.flaghit, .erasehit { - переменные
pointer-events: none; - начальное состояние, не взаимодействуем с ними
}
#flagmode:target ~ #main #assembly .flaghit {
pointer-events: all; - при активации принимаем все действия
}
#erasemode:target ~ #main #assembly .erasehit {
pointer-events: all; - то же самое, но со вторым режимом
}
.flagState {
visibility: hidden; - пишем, что в конце флаг должен оказаться скрыт
transition: visibility 1000000000s step-end; - указываем, что событие должно произойти после конца анимации через миллиард секунд
}
Картинка жабы для разгрузки
Последний вопрос - как сделать счетчик очков. Тут все просто. Мы должны явно прописать все варианты очков на экране, а после проверять, какой из них мы должны показывать в данный момент. Делаем длинную вертикальную ленту со всеми вариантами количества и перемещаем их вниз-вверх в зависимости от количества очков (допустим, для 10 очков сдвигаем ленту вниз на 100 пикселей, на 20 - на 200 пикселей вниз и тд)
Отлично, но как понять, что настало время показывать определенное количество очков? А вот тут интересно. Сначала мы задаем анимацию движения - например, начисляя 10 очков, сдвигаем ленту на 100 пикселей вверх, а на 5 очков - на 50 пикселей вверх. После мы привязываем каждой кнопке соответствующее действие. И дальше главный прикол - мы создаем группу для первой анимации, затем кладем ее внутрь группы второй анимации, и так вкладываем до конца.
Зачем это делать именно так? Из-за того, что мы пользуемся фокусом, мы по сути просто создаем заранее все возможные варианты действия. Мы не запускаем анимацию одну за другой, а просто запускаем другую анимацию. И тут важный момент - фокус в данном случае переходит с одной кнопки на другую, почему же данные сохраняются? Ответ прост - фокус просто запускает воздействие (анимацию, в данном случае), которая не была зациклена, она постоянно назначена группе с момента, как проигралась, а потеря фокуса просто ставит анимацию на паузу, сохраняя ее в том же финальном состоянии. Это значит, что при потере фокуса все тупо зависнет в финальном состоянии, как и было
В итоге, вкладывая все эти перемещения внутрь друг друга, мы не будет последовательно двигать кнопку сначала на одну высоту, а потом с начальной же точки на вторую высоту, а сначала на первую высоту, а потом уже от новой стартовой точки. Код ниже:
<style>
#my-pikuco-game .points10 { - задаем правила работы анимации
animation: plus10 1ms step-end both paused; } - изначально на паузе, после конца застывает в новом состоянии
#my-pikuco-game .points5 { - то же самое, но для другого объекта (points5)
animation: plus5 1ms step-end both paused; }
@keyframes plus10 { - описываем анимацию plus10, которую задавали для объекта points10 выше
from { transform: translateY(0); } - изначальное положение - 0 по Y
to { transform: translateY(-100px); } - новое положение на 100 пикселей выше
}
@keyframes plus5 { - то же самое для 5 очков
from { transform: translateY(0); }
to { transform: translateY(-50px); }
}
#my-pikuco-game #add10:focus ~ #counter .points10 { - прописываем, что переключении фокуса (например, при клике) на кнопку add10 запускаем анимацию из группы points10 внутри группы counter
animation-play-state: running; }- собственно, описываем, что нужно запустить при фокусе
#my-pikuco-game #add5:focus ~ #counter .points5 { - то же самое для 5 очков. Прописывать весь путь необязательно, сверху главную группу, затем ту, на которую ссылаемся
animation-play-state: running; - запускаем анимацию}
</style>
<g id="counter"> - создаем главную группу
<g class="points10"> - внутрь этой группы вложили группу для 10 очков
<g class="points5"> - внутрь предыдущей группы вложили группу для 5 очков
</g>
<!-- Здесь числовая лента --> просто последовательный набор числе друг под другом на фиксированном рассторянии друг от друга. Например,
<text x="0" y="8">0</text>
<text x="0" y="18">1</text>
<text x="0" y="28">2</text>
<text x="0" y="38">3</text>
</g>
</g> - закрываем все 3 группы.
Важно, чтобы у всех групп был одинаковый родитель (в данном случае counter). И еще - такие кнопки одноразовые. То есть дважды нажать кнопку и прибавить еще очки не получится. Вы можете переместить на то же место другую кнопку, но такое ограничение важно учитывать
Мда, жаловаться на то, что пост Etern был непонятным и написать еще более задроченное чтиво - это я умею. Ну, а чего вы еще ожидали? На самом деле, я сомневаюсь, что кто-то будет прописывать это самостоятельно. Это очень большая дрочь, даже когда ты понимаешь, что делаешь, а большинство этого не будут понимать, потому что в их жизни есть что-то кроме программирования. Но 26 год - год нейрослопа, а нейронки очень хорошо умеют повторять задачи. Так что вам достаточно просто прислать нейронке описание действий, и она все пропишет сама. В общем, надеюсь, этот гайд кому-то что-то даст, а я за сим откланиваюсь
Прощальный ку
Я затупок
Я был свято уверен, что подал заявку в кандидаты в судьи. Причем я видел комментарий Фельдшера и подумал, шо это какой-то странный локальный прикол и забил. Даже когда писать об этом начали другие челики, я не смутился
Ну штош. Похоже, без судейства в этот раз. Ну в целом и похуйс все равно не особо планировал. Пару рандомных видео напоследок
Всем ку
Кажется, это произошло. Я наконец-то готов стать судьей. Без нытья о том, что мне что-то не нравится, без внутренних переживаний о том, правильно я поставлю оценки или нет - просто отсужу, как следует.
![Предвыборный пост [Пёс кошачий]](/upload/test_stable/5e9/5e90596a57b3f0105ae1063b069770f5.webp "Предвыборный пост [Пёс кошачий]")
Я - Пёс кошачий. Пользователь Пикуко уже как пять лет. Бывший модератор. Участник почти всех официальных конкурсов, начиная с осеннего 2021 года, до того, как они временно ушли на паузу. Судья первого конкурса, когда вообще появилась такая механика (т.е. весеннего 2023 года) и судья весеннего конкурса 2026 года. Короче говоря, что-то в контенте я немного я понимаю
![Предвыборный пост [Пёс кошачий]](/upload/test_stable/2d4/2d4a48add9fe3e6cd8ccb809b63d40ce.webp "Предвыборный пост [Пёс кошачий]")
Сейчас я расскажу несколько своих преимуществ, которые, если не убедят вас в том, что я лучше других кандидатов, то по крайней мере могу рассматриваться как кандидат:
Так называемый нейрослоп
Если вы хоть как-то за мной следили, вы могли узнать, что судейство мне не было сильно интересно что в 23, что в 26 году. Что же поменялось?
Во-первых, из-за того, что я полноценно отошел от пикуки из-за работы, я в какой-то степени заскучал по всем этому. Какие-то ностальгические вайбы пробиваются, и хочется попробовать себя в этом деле полноценно, с энтузиазмом
Более того, раньше, будучи судьей, я решал судьбу финансового вопроса. Грубо говоря, неправильная оценка могла лишить какого-то пользователя заслуженных денег. Теперь же идет розыгрыш пикукоинов, так что внутренне я чувствую меньшую ответственность - и это не значит, что я буду судить на отвали, а то, что я смогу смелее выставлять то, что думаю.
Ну и наконец - хочется все-таки стать трехкратным судьей. На данный момент такого достижения нет вообще никого, и судя по кандидатам потенциал есть только у Антона и В9 (ибо Глюконат решил не баллотироваться). Стоять в таком ряду или вообще единолично занять такое место было бы прикольно
* * *
В заключении хочется сказать. Мне кажется реклама самого себя бессмысленной. Выбор должен быть добровольным и осмысленным. Я просто решил напомнить, что я существую, чтобы вы держали в голове возможность выбора меня. В любом случае, вы сами знаете, что будет правильнее сделать для вас, и в этом вопросе я вам не советчик.
Засим все. Голосуйте или проиграете
Прощальный ку
Всем ку
Так уж вышло, что по нынешней своей должности мне приходиться взаимодействовать с людьми. И что еще страшнее - мне приходится работать с задачами, которые эти люди мне ставят. Да, я работаю в так называемой тех.поддержке.
Но не стоит думать, что я буду писать исключительно про душниловские документики с описанием задачи. На самом деле, именно юридического вопроса я вообще касаться не буду, а буду говорить про бытовой сия мероприятия, ибо, сюрприз-сюрприз, почти любую вашу просьбу кому угодно можно подвести под эти правила.
Отвечу, зачем это лично вам. Какая разница, как вы будете формулировать задачи другим людям? Разница большая, потому что чем точнее вы передадите, что вы хотите от исполнителя, тем быстрее и лучше получите желаемый результат. Так что, сюрприз-сюрприз, вы наравне с исполнителем заинтересованы в том, чтобы поставленная вами задача была как можно лучше оформлена. В общем, водолействовать не буду, перейду к делу.
Сразу обозначу - не всегда этот пункт обязателен. Условно, если вы просите маму приготовить себе котлеты по-киевски, вам не нужно говорить, что вы ее чадо, что вы хотите есть и прочая.
Так что конкретизирую: обозначьте себя в случае, если исполнителю неочевидно, кто вы.
То есть данный пункт атуален для случаев, когда исполнитель не знает вас лично. Конкретные примеры - вы работаете с какой-то компанией-посредником или просто у вас есть задачи, отданные на аутсорс. Если вы обращаетесь к кому-то из данной компании, первое, что вам нужно обозначить - какую именно компанию вы представляете (поскольку почти наверняка клиентов у этой компании предостаточно, и почти наверняка по контексту вашего обращения никто не поймет, кто вы конкретно) и какую должность занимаете (потому что одна и та же задача от лица бухгалтера, администратора, юриста или директора будет восприниматься и решаться по-разному).
Да-да, школьники-тунеядцы, я дам пример и для вас, чтобы вы тоже могли прочувствовать это: представьте, то ваш провайдер решил по приколу (или обоснованно, что совершенно невозможно) отключить ваш домашний интернет. Что же нужно сказать бедолаге на линии в первую очередь? Вашу жалобу на интернет? Ан нет, товарищи-господа. В первую очередь надо локализировать задачу для оператора - говорите адрес, где возникла проблема, и имя при необходимости. В таком случае многие бесполезные минуты разговора отвалятся сами собой
Почему это важно? Смотрите, какая штука. Вы, вероятно, сами не обращаете на это внимание, но вы сами в ответ на любую просьбу прикидываете, собственно, кто именно интересуется вашими услугами. И на практике это действительно важный момент, потому что нередко поставленная задача решается по-разному для разных людей. Поэтому, если вы сразу говорите, кто вы, вы пропускаете этот этап - поверьте, рано или поздно вам все равно придется представиться, но вот потраченное на это время вам никто не вернет. Если вам не жалко исполнителя, пожалейте хотя бы свое время
Собственно, данный пункт касается жалоб на какие-то ошибки, проблемы и прочая. Проще говоря, багрепортов.
Товарищи-господа, фраза "Дублируется сквад" (условный пример, из того, что я вспомнил) исполнителю говорит примерно ничего. Вы не говорите ни того, где сквад дублируется, ни то, что вы вообще имеете в виду под дублированием сквада, ни сообщаете, как вы получили результат. Если вы жалуетесь на конкретный баг, желательно описать достаточно подробно для понимания, что вы имеете в виду и как вы такой результат получили. На данном примере - условно "При загрузке топа сквадов происходит подзагрузка списка сквадов, то последний сквад из предыдущей пачки загруженных карточек может продублироваться в топе, занимая сразу два места".
Возвращаясь к примеру с интернетом - фраза "Нет интернета" в общем и целом уже дает какую-то информацию, но с огромной вероятностью у вас начнут уточнять. Потому в идеале превентивно ответить на все вопросы - как давно отключился интернет, его нет вообще или он прерывается, повторялась ли ситуация ранее и если да, то при каких условиях она наблюдается (например, каждый вечер) и пр.
Большинство проблем решается уже в момент постановки конкретной проблемы, так что обозначайте задачу полно. Чем больше будет понимание вашей проблемы, тем быстрее ее удастся ее устранить.
А, и да, важное уточнение: от вас не требуется техническое понимание проблемы. Вы для того и обращаетесь к исполнителю, так как он больше разбирается в озвученном вопросе. Вам нужно лишь описать свои наблюдения о том, как ошибка появляется, а в идеале (если получится - это вообще идеальный вариант) привести конкретный пример четких воспроизводимых действий, чтобы повторить ошибку. Если в вашем пути будут лишние шаги - это не страшно, исполнитель сможет их отмести, но так он уже сможет сам воспроизвести ошибку и обнаружить, на каком этапе возникают проблемы.
Это касается в принципе и жалоб с багрепортами, но в случае с предложениями это еще актуальнее. Смотрите какое дело: вы обращаетесь к другому человеку, вы это делаете из-за того, что почему-то не можете сделать этого сами. И, как бы то ни было удивительно, выполнять задачу также будет этот человек-исполнитель.
Потому самое важное, что вы можете сделать при составлении просьбы - оперировать в первую очередь тем, какую задачу нужно решить, а не тем, как вы видите решение этой задачи.
Возьмем конкретный пример. Если вы попросите исполнителя, условно, отключить дизлайки на его сайте, это будет вполне конкретная задача с вашим конкретным решением проблемы. Суть в том, что есть немаленькая вероятность, что вы не решаете поставленную задачу, а просто озвучиваете то, что пришло вас в голову. Озвучивать свои предложения - это нормально, но суть работы исполнителя в том числе заключается в том, чтобы выполнить поставленные задачи оптимальным для вашей ситуации способом, включая технические ограничения и свой опыт.
Потому важно озвучивать не просто то, как вы видите метод решения проблемы, а саму проблему. На нашем примере вы хотим не просто, чтобы дизлайки исчезли как явление, а чтобы пользователи не использовали как инструмент гандикапа для неугодных людей, и потому мы можем предложить в исключительных случаях не учитывать их влияние.
Но у нашей проблемы есть еще множество других решений: не отключать их полностью, а просто уменьшить эффект; исключить систему оценивания из уравнения продвижения; ставить палки в колеса тем, кто бездумно (или наоборот, целенаправленно) проставляет дизлайки - вариантов решения множество. И потому, чтобы не зацикливаться на одном пути решения проблемы, нужно четко обозначить проблему (тем более, что хороший работник так или иначе у вас спросит, какую проблему вы решаете)
И важно: я не говорю, что предлагать свои методы решения проблемы не нужно. Можно, а в некоторых случаях даже нужно. Просто нужно всегда держать в голове, что это вторично (кроме случаев, когда это критически важно и в этом заключается суть, но в таком случае форма решения задачи также является частью самой задачи), а потому нужно не забывать прямо проговаривать, какую задачу вы пытаетесь решить.
Тут, опять же, нужно немного включать голову. Не все нужно проговаривать. Если вы жалуетесь официанту на муху в супе, вам не нужно объяснять, что вы этот суп едите. Но давайте опишу на примере, о чем я говорю.
Вернемся к отключению интернета. Самого факта того, что интернет был отключен, все еще недостаточно для полной картины (в случае, если нет какой-нибудь уже известной провайдеру аварии, но так как вы заранее этого знать не можете, лучше на такой вариант не полагаться и прописывать все, а в устном разговоре до этого просто не дойдет). Желательно описать, как вы к нему подключаетесь (через WiFi или провод), сколько устройств сейчас использует интернет, на всех ли устройствах наблюдается проблема и прочая. Вся эта информация важна, потому что она локализует проблему, что значительно ускоряет ее решение.
Если же уходить в чуть большую абстракцию, то вы должны понимать, что человеческий мозг настроен не просто адаптироваться, но адаптировать окружающую среду под себя. Зачастую заложенная функциональность в продукт гораздо уже, нежели ее делают пользователи (на одной Пикуке вы можете увидеть, сколько всего коммьюнити понаделало своими силами). А иногда люди просто делают первое, что увидели или до чего догадались, что не соответствует задуманному взаимодействию. Если вы понимаете, что вы попадаете в какой-то сценарий, очень важно этот контекст обозначать, потому что исполнитель находится в парадигме стандартного использования до тех пор, пока не будет объявлено обратного.
Короче говоря, при любом отклонении от нормы (да и даже при нормальном использовании, если есть равнозначные альтернативы) важно обозначать эти детали, потому что они также могут повлиять на решение вашей проблемы
Я уже касался этого ранее, но обозначу это отдельным пунктом, чтобы в голове отложилось. Если в решении задачи у вас есть критически важные аспекты его выполнения, проговаривайте их, не стесняйтесь. Зачастую переделывать косяки гораздо труднее, чем писать с нуля (у самого опыт был что того, что другого, можете мне поверить), и это всегда без исключений дольше.
Поверьте мне на слово, пусть лучше исполнитель обматерит вас при постановке задачи, чем при правках. Но, опять же, важный момент, который хочу вам напомнить - не путайте рекомендации и обязательные условия - это буквально самый важный навык при постановке задачи. Чаще всего обязательные условия проистекают из постановки самой проблемы, которую вы решаете, так что мысленно попробуйте убрать какую-то деталь из уравнения и проверьте, останется ли проблема решенной - если нет, то это обязательная деталь, и ее важно уточнить пользователю.
Вот тут уже больше рекомендательный пункт, так как, в отличие от всего до этого, нарушение этого пункта не повлечет за собой прямых проблем при решении задачи, но при этом может помешать взаимопониманию и замедлит решение проблемы.
А формула простая: перечитываете свою задачу и по кускам исключаете из нее смысловые куски и перечитываете задачу без нее. Если ни контекст, ни постановка задачи, ни обязательные условия, ни ваши предложения от удаления этих смысловых частей никак не меняется - просто их полностью удаляете. Краткость - сестра таланта, а в данном случае еще и отличный способ сэкономить время что самому себе, что исполнителю
Первое, что вам надо уяснить - да, в мире существуют тупые люди. А бывают умные. И сходу сказать, какой человек находится перед вами, мягко говоря нелегко, особенно если вы не видите его лично. Но что можно сказать наверняка - повторять одни и те же вещи не имеет смысл в любом случае.
Поймите одну вещь: если вы выстроили отношения с исполнителем, то он тоже заинтересован в решении вашей задачи (неважно, потому что он хочет помочь лично вам как человеку или потому что он деньги за это получает) - потому предпочтительно исходить из принципа, что человек не ставит ваши интеллектуальные способности под сомнения, что хочет вас в чем-то уличить или подколоть. Он хочет решить ту проблему, которую вы ему озвучили.
И вот тут то, о чем я говорю. Непринципиально, почему исполнитель задает вам уточняющий вопрос - потому ли, что он тупой и не понимает, что вы ему пишете, или потому что умен достаточно, чтобы увидеть неоднозначность формулировок. Важно то, что у вас в общении возникло недопонимание из-за того, что вы сообщили информацию определенным образом. Как вы думаете, что будет, если вы тупо повторите то же самое, возможно даже другими словами?
Правильно, человек просто не поймет вас второй раз. Потому, пожалуйста, читайте именно сам вопрос и старайтесь отвечать на него, а не повторять уже то, что вы говорили. Старайтесь заходить с других сторон, искать подходы, возможно объяснять на пальцах - бывают люди, которые медленно включаются, и это нормально.
А, ну и так, добавлю очевидную вещь, хотя она, скорее всего, на практике будет бесполезна (ибо эмоции - это сильная штука): недопонимание задачи для исполнителя - это стресс, потому что его выбили из привычного стиля жизни, где тот может существовать почти инстинктивно. А стресс в том числе характерен тем, что многие действия становятся значительно импульсивнее и менее вдумчиво. И худшее, что вы можете сделать в такой ситуации - это добавить исполнителю этого самого стресса оскорблениями, руганью, криком, пассивной агрессией и прочим. Потому вежливость и холодная голова полезны не только из базовых правил этикета, но и с точки зрения получаемой выгоды
Еще один пункт рекомендательного характера. Опять же, правило не универсальное - если вернемся к прошлым примерам, в случае пропавшего интернета, например, сообщать, как должно быть, близится к бессмысленному, так как желаемый результат очевиден (интернет должен стабильно работать), как и в случае каких-нибудь багов.
Но в целом структура полезная. Она позволяет исполнителю сразу увидеть воочию, с чем он работает, и, что еще важнее, поймет, как считать работу завершенной.
Это можно использовать как текстовое клише, которого даже можно не стесняться - например, если брать за пример прошедшую ситуацию с пикуко, можно сформулировать что-то такое:
"Сейчас наблюдается проблема, когда судейские оценки очень слабо влияют на расположение конкурсных работ в топе. Должно быть так, чтобы влияние судей было ощутимым, и чтобы не все определялось сугубо рейтингом от пользователей".
Таким образом у нас будет четкое понимание того, когда можно считать задачу решенной - если влияние судей будет значимым, и не все будет решаться сугубо рейтингом на конкурсе, можно будет сказать, что задача была решена. Как мы помним, на конкурсах теперь действительно судьи оказывают влияние, из чего можно сделать вывод - задача была решена.
По сути DLC к 5 пункту. Смотрите, есть некоторые вещи, которые у вас уже есть, и вы не хотите их терять в процессе. Но при этом к самой задаче они могут иметь косвенное отношение или, например, заменяться новой фишкой. Такие вещи важно тоже проговаривать в слух, а не оставлять на усмотрение исполнителя, потому что ваши видения могут отличаться, и это нормально.
Допустим, вы решили обновить пк. И, условно, ваш системный блок вам дорог (хз, наклеечки какие-то красивые на нем висят). К самой задаче это прямого отношения не имеет (к такому я могу отнести конкретные детали новые, которые вас интересуют, или минимальные требования к ним), но если у вас есть какая-то важная деталь, ее нужно обозначить как минимум потому что это сузит пулл решений, которые вам сможет предложить исполнитель.
Знаете мем "Базовый минимум - Роскошный максимум"? А это нихрена не мем. Просто учтите, что так или иначе приоритезация ваших задач у исполнителя будет в любом случае. И в то же время лично вы можете повлиять на этот процес, прямо проговорив, что является более срочной, а что - более второстепенной задачей. А, и да, всегда обозначайте сроки, в которые вам требуется решение поставленных задач - причем желательно четкие границы (это кстати и по жизни полезно. Выражения "скоро", "в течение месяца", "в ближайшее время" могут и не быть задуманы, как обман или способ слиться, но психологически так и воспринимаются. Потому установление четких временных рамок - дедлайна - для чего угодно непроизвольно вызовет у исполнителя большую мотивацию заняться каким-то делом, нежели более общие понятия. Просто вспомните, как вы готовитесь к экзаменам, которые будут когда-то там в июне и когда они через 3 дня - ну или по крайней мере, как вы начинаете париться, что не готовитесь)
* * *
Собственно, это все. Спонсором сия поста послужили товарищи, которые обращались ко мне на работе и персонально Кофа, которые иногда меня просто убивали.
Если вы мне скажете, что я пишу очевидные вещи - по сути да, так и есть. Но в том и ловушка: из-за того, что эти вещи кажутся очевидными, обыденными, у вас создается ложное ощущение, что все это формируется само собой. Не формируется. Очень трудно разговаривать четко и грамотно. Я это говорю с уверенностью, потому что я этого не умею, хотя и стремлюсь к этому. Поэтому иногда лучше потратить чуть-чуть больше времени, чуть задуматься над тем, что обычно происходит подсознательно, чтобы в конечном итоге сэкономить значительно больше времени, чем вы потратили.
Прощальный ку
