Никто же не запрещает сказать: "я сделаю, если отложить вот это и это и выделить мне дополнительную команду".
Вы слишком утрируете. То что вы написали - первый этап дискуссии, но если оппонент не договороспособен (не хочет менять объем работ, сроки, бюджет, качество исполнения, требования к внешнему виду...), то есть он встал в позиции НАДО (пообещал топу, что все будет, а ресурсов и бюджета нет). Это самый часто встречающийся случай.
И вот тут мы упираемся в процессы, если ваш вышестоящий менеджер отказывается включаться в процесс, согласования (обычно так и есть, ибо он не хочет портить отношения с заказчиком - он же продажник)
Даже на уровне внутренних продуктов это делается. Это вообще может спасти даже от причины использовать данные фразы.
Я не говорил, что эскалировать надо этой фразой.
Вообще появление причины использовать эти фразы это сигнал, что что-то не так в процессах работы с заказчиком. И даже, можно сказать, что это не совсем проблема менеджера проекта, которого приперли к стенке: решай, думай, ты ответственный, им надо.
По 1му пункту полезно иметь в договоре правила, регламентирующие скорость принятия решения и то как отсутствие решения должно трактоваться. Если вы отправили минутки после митинга, в которых изложены все решения с этого митинга, то игнор со стороны заказчика чика может выйти ему боком.
По поводу 2й фразы: странно когда говорят не заказчику. Но если способы договориться уже испробованы, а заказчик уже пообещал эту фичу кому-то и не хочет платить больше или сдвинуть сроки?
Паузу надо брать и думать, но и хвататься решать проблемы шефа/заказчика. Обычно такие фразы это эпилог переговоров (в рамках текущего бюджета и сроков проекта, добавить доп функциональность не возможно). Лояльность заказчика весит ровно ничего, следующий проект он отдаст любой компании, которая предложит лучше условия на тендере. Загнать команду и бюджет в минус ради потенциальных проектов? Учтите та модель поведения, которую использовал заказчик повторится с вероятностью 99%.
И самое интересное, зачастую, менеджер общается с представителем заказчика который НЕ ИМЕЕТ ПРАВА ПРИНИМАТЬ решение об изменении сроков, или бюджета, или объема работ. И скорее всего, если дойти до непосредственно лица, принимающего решение, то они будут приняты или пересмотрены. Но это уже другая история. Поэтому эскалируйте проблему выше, не пытайтесь решать ее в одиночку.
К сожалению, не все сложности прохождения зависят только от поведения кандидата. Квалификация интервьюеров тоже играет важную роль. Частая проблема, заключается в том что у интервьювера есть своя внутренняя боль и он ее вываливает на кандидата и пытается заставить его пройти его путь. Или интервьювер знает только одно шаблонное (принятое в его компании решение) и не воспринимает альтернативу. Так же удивление у них вызывают предложения использовать готовые решения и построение дизайна вокруг этого решения.
Использую 2 монитора Dell 24" с разрешением 2к. По специфике работы работаю по rdp. Поэтому удобно на одном мониторе развернуть на весь экран, а на другом все остальное. Долго смотрел на большой монитор и понял, что он должен быть 5к, чтобы иметь тот же уровень комфорта (а это уже весьма приличный ценник). А ещё на всяких совещаниях, где надо что-то показать или отладить отдельный монитор это плюс (не все инструменты умеют грамотно показывать часть экрана).
Придется уходить с Билайна на другого оператора. Вроде 4g есть и сигнал сильный, но интернета нет. То есть 4g, работающий в режиме можно только звонить. Принудительно выставил настройки только 3g в телефоне, чтобы интернет был. Теперь 3g уберут...
(мое субъективное мнение исходя из опыта). Хотелось бы уточнить про какой тип дизайнера статья. Если речь про UX дизайнера, то это отдельная категория, оторванная от действительности. Зачастую они создают очень странные решения, на имплементацию которых тратиться очень большое время, а бизнес value очень маленькое (или даже ниже чем простое решение). Этот тип дизайнеров очень обидчив и считает что их не понимают. Особенно когда их критикуют в самую суть, например система процессинга входящих отчётов. Задача пользователя быстро просмотреть много данных на экране и поправить ошибки. Дизайнер рисует красивый мокап с кучей ui компонентов, пустого места. Когда ему говоришь, что 90% операций надо делать без переключения клавиатура/мышь и максимум данных на экране - получаешь в ответ: Олд скул и ничего не понимаешь в современном дизайне.
Если речь о ui дизайнере, то это must have, особенно если он умеет не только figma, но ещё может предоставить design system. А если он ещё и прототипы умеет делать, то это просто сказка и ни у одной команды не будет с ними проблем.
Во многом проблема в том как ui дизайнер входит в команду. Если он партнёр product owner, то дизайн это часть требований и он подготовлен до того как история уходит в девелопмент. Лёгкие корректировки возможны, если что-то не учли или реализация стоит дорого.
В моей практике идеальная схема ui дизайнер, design system и парт-тайм (не факт, что будет 100% загрузка) верстальщик для того, чтобы чистить вёрстку время от времени.
Сама постановка вопроса, звучит очень странно. Как будто вы хотите сломать существующую design system или доказать свою значимость. Зачастую разработчикам не интересно как и почему создан такой дизайн. Но если он не ложится на бизнес требования, или требует много времени на реализацию компонента или компоненты с одинаковыми требованиями имеют разный дизайн на разных экранах (вопросы консистентности дизайна), то тогда да, к дизайнеру будут вопросы.
В основном это проблемы процессов на проекте и если вы начинаете выстраивать процессы в команде это красный флаг - ваш SM/PM/TM/TL что-то упустил.
Вы слишком утрируете. То что вы написали - первый этап дискуссии, но если оппонент не договороспособен (не хочет менять объем работ, сроки, бюджет, качество исполнения, требования к внешнему виду...), то есть он встал в позиции НАДО (пообещал топу, что все будет, а ресурсов и бюджета нет). Это самый часто встречающийся случай.
И вот тут мы упираемся в процессы, если ваш вышестоящий менеджер отказывается включаться в процесс, согласования (обычно так и есть, ибо он не хочет портить отношения с заказчиком - он же продажник)
Даже на уровне внутренних продуктов это делается. Это вообще может спасти даже от причины использовать данные фразы.
Я не говорил, что эскалировать надо этой фразой.
Вообще появление причины использовать эти фразы это сигнал, что что-то не так в процессах работы с заказчиком. И даже, можно сказать, что это не совсем проблема менеджера проекта, которого приперли к стенке: решай, думай, ты ответственный, им надо.
По 1му пункту полезно иметь в договоре правила, регламентирующие скорость принятия решения и то как отсутствие решения должно трактоваться. Если вы отправили минутки после митинга, в которых изложены все решения с этого митинга, то игнор со стороны заказчика чика может выйти ему боком.
По поводу 2й фразы: странно когда говорят не заказчику. Но если способы договориться уже испробованы, а заказчик уже пообещал эту фичу кому-то и не хочет платить больше или сдвинуть сроки?
Паузу надо брать и думать, но и хвататься решать проблемы шефа/заказчика. Обычно такие фразы это эпилог переговоров (в рамках текущего бюджета и сроков проекта, добавить доп функциональность не возможно). Лояльность заказчика весит ровно ничего, следующий проект он отдаст любой компании, которая предложит лучше условия на тендере. Загнать команду и бюджет в минус ради потенциальных проектов? Учтите та модель поведения, которую использовал заказчик повторится с вероятностью 99%.
И самое интересное, зачастую, менеджер общается с представителем заказчика который НЕ ИМЕЕТ ПРАВА ПРИНИМАТЬ решение об изменении сроков, или бюджета, или объема работ. И скорее всего, если дойти до непосредственно лица, принимающего решение, то они будут приняты или пересмотрены. Но это уже другая история. Поэтому эскалируйте проблему выше, не пытайтесь решать ее в одиночку.
К сожалению, не все сложности прохождения зависят только от поведения кандидата. Квалификация интервьюеров тоже играет важную роль. Частая проблема, заключается в том что у интервьювера есть своя внутренняя боль и он ее вываливает на кандидата и пытается заставить его пройти его путь. Или интервьювер знает только одно шаблонное (принятое в его компании решение) и не воспринимает альтернативу. Так же удивление у них вызывают предложения использовать готовые решения и построение дизайна вокруг этого решения.
Использую 2 монитора Dell 24" с разрешением 2к. По специфике работы работаю по rdp. Поэтому удобно на одном мониторе развернуть на весь экран, а на другом все остальное. Долго смотрел на большой монитор и понял, что он должен быть 5к, чтобы иметь тот же уровень комфорта (а это уже весьма приличный ценник). А ещё на всяких совещаниях, где надо что-то показать или отладить отдельный монитор это плюс (не все инструменты умеют грамотно показывать часть экрана).
Придется уходить с Билайна на другого оператора. Вроде 4g есть и сигнал сильный, но интернета нет. То есть 4g, работающий в режиме можно только звонить. Принудительно выставил настройки только 3g в телефоне, чтобы интернет был. Теперь 3g уберут...
(мое субъективное мнение исходя из опыта). Хотелось бы уточнить про какой тип дизайнера статья. Если речь про UX дизайнера, то это отдельная категория, оторванная от действительности. Зачастую они создают очень странные решения, на имплементацию которых тратиться очень большое время, а бизнес value очень маленькое (или даже ниже чем простое решение). Этот тип дизайнеров очень обидчив и считает что их не понимают. Особенно когда их критикуют в самую суть, например система процессинга входящих отчётов. Задача пользователя быстро просмотреть много данных на экране и поправить ошибки. Дизайнер рисует красивый мокап с кучей ui компонентов, пустого места. Когда ему говоришь, что 90% операций надо делать без переключения клавиатура/мышь и максимум данных на экране - получаешь в ответ: Олд скул и ничего не понимаешь в современном дизайне.
Если речь о ui дизайнере, то это must have, особенно если он умеет не только figma, но ещё может предоставить design system. А если он ещё и прототипы умеет делать, то это просто сказка и ни у одной команды не будет с ними проблем.
Во многом проблема в том как ui дизайнер входит в команду. Если он партнёр product owner, то дизайн это часть требований и он подготовлен до того как история уходит в девелопмент. Лёгкие корректировки возможны, если что-то не учли или реализация стоит дорого.
В моей практике идеальная схема ui дизайнер, design system и парт-тайм (не факт, что будет 100% загрузка) верстальщик для того, чтобы чистить вёрстку время от времени.
Сама постановка вопроса, звучит очень странно. Как будто вы хотите сломать существующую design system или доказать свою значимость. Зачастую разработчикам не интересно как и почему создан такой дизайн. Но если он не ложится на бизнес требования, или требует много времени на реализацию компонента или компоненты с одинаковыми требованиями имеют разный дизайн на разных экранах (вопросы консистентности дизайна), то тогда да, к дизайнеру будут вопросы.
В основном это проблемы процессов на проекте и если вы начинаете выстраивать процессы в команде это красный флаг - ваш SM/PM/TM/TL что-то упустил.