Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Гребцы и капитаны

Разница в мышлении бизнеса и программиста. Типичные ошибки с обеих сторон и как их исправить?

Бизнес держит в голове деньги, сроки, фичи, качество. Программисты — долговременное качество кода, поддерживаемость, актуальность.

— Я плачу вам деньги, а вы должны работать так же, как я сам © бизнес
— Я пишу код, а вы должны обо мне заботиться © программист
— Если нужно сделать к сроку — значит нужно сделать к сроку © бизнес
— Говнокод писать не буду. И эстимейтов тоже не дам © программист

Вроде всем всё понятно, и никто ни о чем не спорит. А потом приходит нежданчик, обычно в виде «классный код написали, а теперь удалите его» от бизнеса и «эта задача заняла больше времени по объективным причинам» от программистов.

Какие ошибки совершили обе стороны, и что можно сделать лучше?

Чужая проблема

Что думает заказчик? «Я им плачу зарплату, свою часть договора выполняю. Пусть они просто выполняют свою. Договор — это важно, вся жизнь выстроена на договорах». Программисты думают: «я пишу код, а для планирования — есть заказчик (бизнес) и менеджеры. Как можно ждать от меня четкого эстимейта, если я эту задачу еще не делал? Если надо, могу рассказать подробно, что может пойти не так — ТЗ, третьесторонние библиотеки, интеграция и т. д.». Что думают менеджеры — обычно зависит от того, откуда они пришли в менеджмент. Если из программистов — то как программисты, если от бизнеса — то как бизнес... Про игры с компенсацией и компенсацией компенсации сегодня не будем.

На размышления еще здорово влияет рынок труда — про «рынок перегрет, программисты зажрались» все слышали. Когда кругом тебя райский сад в виде долларовой зарплаты, а под боком — война, то заокеанские проблемы с запуском стартапа сложно воспринимать всерьез.

Если программисты думают, что это проблема исключительно заказчика, то бизнес рано или поздно заканчивается, приходится срочно и внезапно искать новую работу, да и резюме портится.

Если заказчик думает, что это проблема исключительно программиста — рано или поздно все активные уходят, а остаются пофигисты и нытики.

Что делать?

  • Думать, что именно я могу сделать для решения проблемы другой стороны.
    • Это прибавляет не только головняк, но и visibility. Что в свою очередь ведет к росту зп и звания.
    • Именно я, а не начальник, заказчик и т. д. Переложить ответственность на МВФ других очень просто и очень плохо.
  • Не вешать на себя ответственность за то, на что не могу повлиять. Если провтык в маркетинге, то, скорее всего, это за моей областью знаний. Если я придумаю что-то — круто! Если нет — ну ок. Граница между «что я могу сделать?» и «это не моя зона ответственности» очень тонка и уходит в освоение смежных областей.

Пара слов про «узкий специалист» vs. «широкий профиль». Давайте сравним двух условно одинаковых людей, с одинаково развитой памятью, IQ, умением учиться, силой воли и т. д. Узкая специализация даст плюсы при работе в большой организации, широкий профиль — при работе в стартапе или на топовых позициях. Узкая специализация позволит найти лучшую работу, широкая — найти работу быстро. Как пример — можно быть спецом по Коболу. Если есть такая вакансия — возьмут за любые деньги. Если нет — можно ждать вакансии годами.

Круг общения

Свойство у человека — мерять всех по своему кругу общения и думать, что все остальные +/- такие, как ты. Если кругом все программисты — думаешь, как программист: фреймворки, исследования, хитрые глюки, гаджеты и т. д. Если кругом безработные — думаешь, какой пипец на рынке труда происходит и как это несправедливо. Если кругом бизнесмены — от всех кругом ждешь проактивности, умения быстро учиться и решать самые неожиданные проблемы. Если кругом все депутаты

Для бизнеса многие действия программистов выглядят чушью — достаточно просто сказать, поговорить, быть более настойчивым, сделать стратегическое планирование. И в своем кругу они время от времени это обсуждают — «ну какого ты мне не сказал, что не успеваешь? Я бы отменил презентацию, это дешевле, чем провалиться, показывая лежащий сайт».

Для программистов многие действия бизнеса выглядят чушью — достаточно следовать КЗоТу, арендовать нормальный офис, нанять девопса и офис-менеджера. И само собой нужно платить зарплату, как в LA.

Что делать?

  • Понимать, как выглядит ситуация с другой стороны. Для этого — больше общаться, затрагивая нерабочие темы: детей, политику, путешествия, культурные отличия. Меньше говорить, больше слушать. Последнее для многих сложно реализовать, так как говорить приятнее.

Личный контакт

Если нет личного контакта, то другая сторона превращается в юнитов компьютерной игры. Их легко обманывать, их интересы можно игнорировать, да и пожертвовать ими тоже легко. «Ну развалится его бизнес — а нефиг было лезть, не зная броду» и «выйдут на выходных — нефиг было косячить».

Что делать?

  • Менеджерам: помогайте видеть людей, а не юнитов!
  • Программистам: почаще общайтесь с бизнесом. Перейдите из «еще один безликий программист в зарплатной ведомости» в «это Вася, мы с ним составление отчетов обсуждали. Толковый конструктивный парень».

Разная детализация


бизнеc> Выдержит ли наша система стократный рост количества пользователей?
прогр> Я провел нагрузочное тестирование. У нас сервер падает при 300 запросах на авторизацию в минуту.
бизнеc> А сколько сейчас запросов?
прогр> Не знаю, но можно добавить балансировщик.
бизнеc> Мы собираемся делать рекламную кампанию. Мы можем это делать? Или серверы лягут?
прогр> Ну, если будет 300 запросов в секунду...
бизнеc> Если серваки упадут, то первое впечатление нельзя сделать дважды. Может быть конфуз.
© утрированный диалог. Даже не диалог, а два монолога.

Что видит капитан? Штурвал, острова на горизонте, макушку гребца. Бизнес видит KPI, ROI, инвестиции, стратегическое видение, переговоры, конкурентов, бюджет и макушку программиста. Если он начнет уделять всё своё время вниканию в задачи и проблемы программиста — он сдохнет. Времени на всё не хватит, бизнес и так обычно живет в диком ритме. Поэтому как в шутерах — железо не тянет? Снижаем детализацию!

Что видит гребец? Весло, чуть-чуть штурвал, иногда — капитана по пояс. Снизу. В смысле — фреймворки, криво написанные задачи в тасктрекере, тормозящий комп, любимые совещания, иногда — совещания с заказчиком на непонятном языке: мало того, что английский, так еще и бизнес-терминология. Программист концентрируется на мелочах и мельчайших подробностях. Чем выше детализация — тем меньше багов.

Сверху не видны мелкие детали, снизу видны только мелкие детали.

Попытка увидеть на другом уровне — трудоемка. Ну то есть хорошо бы, но «пиши код!» — так что только в свободное от работы время.

Менеджеры не видят ни деталей, ни больших целей одновременно. Менеджеры просто быстро переключаются. Кстати, менеджеров в кризис увольняют первыми, и это еще одна совсем другая история.

Что делать?

  • Балансировать и нырять туда-сюда. Смотрите на ситуацию со всех точек зрения. Предугадывайте реакцию обеих сторон.
  • Не ждать, что бизнес поймет очевидные вещи без детальных объяснений. «А почему нельзя просто скопипастить этот модуль? Зачем тратить время на написание общего класса?»

Конфликт ценностей

Что думает бизнес?

Что думает программист?

Ну-у-у... Так, наверное, бывает... В сказках... В этих сказках еще толковое ТЗ и идеальный процесс разработки... Всё-таки установка «эта работа — самое важное в моей жизни» чаще бывает у собственников. Или у тех, кто сильно влияет на ход проекта. Долгую историю про то, как эджайл дает такое ощущение — тоже отложим на потом. А пока — для программистов работа — это инструмент для зарабатывания денег и кучи других мотивационных штук. И очень редко «этот проект — самое важное для меня».

Что делать?

  • Знайте, что важно для другой стороны. Максимальная эффективность? Бог? Деньги? Семья? Если у вас для всех получается один ответ, значит, что-то не так. Люди разные.
  • Уважайте чужие ценности и требуйте уважения к своим. Чужие ценности не нужно принимать, их достаточно уважать. «Ты веруешь, а я атеист. Ок, я не смеюсь над купанием в проруби, а ты не проповедуй мне без моего запроса».
  • Уважение к чужим ценностям имеет ограничение — если для другого важно «я отжимаю, что хочу», то я это уважать не буду. Правила для сотрудничества и правила для войны разные. Можно перечитать про овертаймы.

Вместо выводов

Этот сайт для программистов, поэтому выжимка из статьи тоже только для программистов.

  • «Какую проблему бизнеса я могу решить?»
  • Общайтесь с бизнесом больше.
  • Бизнесу некогда вникать в детали.
    • Если сможете его от этого избавить — будет хорошо.
    • Если сможете говорить на его уровне детализации — будет еще лучше.
  • У бизнеса — другие ценности. Уважайте их и требуйте уважения к своим.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Менеджерам: помогайте видеть людей, а не юнитов!

для начала надо перестать назывть ресурсами. не человек — ресурс, а человек обладает трудовым ресурсом

Прочитал статью и комменты. Тема бизнес-аналитиков не раскрыта. ))
Для тех программистов которым нужно понимать зачем нужна зеленая кнопка и почем именно зеленая — нужен БА.
Для тех менеджеров которым нужно понимать почему зеленая кнопка будет стоить овер-доф..га денег и пилится 3 месяца — нужен БА.

129 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Всі перелічені проблеми від браку знань у менеджера в менеджменті :(

1) — Я плачу вам деньги, а вы должны работать так же, как я сам © бизнес
2) — Я пишу код, а вы должны обо мне заботиться © программист
3) — Если нужно сделать к сроку — значит нужно сделать к сроку © бизнес
4) — Говнокод писать не буду. И эстимейтов тоже не дам © программист

Репліка 1 вирішується стандартами до роботи, що закладаються в трудовому договорі та в договорі з клієнтом.
Репліка 2 це умови трудового контракту
Репліка 3 та репліка 4 — то є проблема невизначеності з стандартами до роботи.

Якщо програміст знає, що пан директор, а тим більше клієнт розуміють ризики вибору швидкого / недосконалого варіанту виконання робіт, то питання якості коду та естімейтів на нього знімається як дурне :)

От одного клиента:

В бизнесе есть всего две проблемы: misunderstanding и miscommunication, и фиг его знает чем они отличаются

Всё это хорошо, но только в теории. Единственное место, где это все реализуется в жизни — стартапы, и то не все.

Почему же? При хорошем менеджменте и не опофигевших рабочих — бывает. Когда народ сидит на проекте потому что приятно и интересно.

...продолжая апать резюме и при любой возможности беря подработки. Знаем, проходили.

Бывают зарплаты, при которых нет смысла апать. И проекты, с которых не хочется уходить, потому что уже многого другого насмотрелся.

Не спорю. Значит, для таких проектов подобрана правильная команда, мои почет и уважение менеджеру.

Интересная статья и выводы.

Для этого и придумали методологии разработки, чтобы сместить акценты с весел и штурвалов на бизнес цели, сделать их общими целями команды? Приблизить бизнес к команде, а команду к бизнесу. У методологий есть правила и ограничения, а внутри них — свобода самовыражения в достижении общих целей, чтобы не говорить, что все потому, что ты думаешь неправильною

А если ни одна метология не подходит по каким-то причинам, или что-то идет не так, то может захотеться объяснить как есть. Кажется, вот скажу правду — и все поймут). И звучит это как какая-нибудь черная книга менеджера или подобная приятная статья. Про то, что нужно думать как-нибудь не так и все изменится.

В лучшем случае, что нужно быть ближе друг к другу, одной командой, разработчикам просто думать и о бизнес целях и что бизнес — это не самодуры, как правило, у них есть потребности и они готовы платить за пользу, которую мы приносим бизнесу, но не больше минимума, который они смогут запратить. А менеджерам — что команда — не только ресурсы, а личности, которые стараются сделать как лучше. Сам сначала пойми правила и помоги понять кому-то еще, не мешая при этом.

Потом можно что получится экспериментальным путем, назвать новым фреймверком разработки, если получится найти что-то новое и если получится сформулировать правила.

Спасибо.
Заставь дурака <любое правило>, так он <тяжелые последствия>.
© два года назад
Заставь <творческая профессия>, так он <сопротивление, саботаж, низкая производительность>. Зона ближнего роста и наводящие вопросы — наше всё.
© современный апдейт
Так что цикл самосовершенствования через ретро — наше всё.

А можно публиковать этого автора БЕЗ ТЕКСТА? Ну ладно, немножко текста можно, как в комиксах. Но вот этой вот «воды» — не надо совсем, когда сказать нечего и просто наливаются буквы.

Трудовые отношения — огромная система, очень традиционная, со своими правилами, и меняющаяся очень медленно, столетиями. И тут приходит афтор и говорит «больше апщяйтесь». Как в анекдоте про кур и рабиновича.

Рабинович приходит к ребе:
— У меня куры дохнут.
— А чем ты их кормишь?
— Просом.
— Попробуй гречкой.
Через некоторое время снова приходит:
— Я попробовал кормить гречкой — они все равно дохнут.
— А как ты им сыплешь корм?
— Кучкой.
— Попробуй треугольничком.
Через некоторое время:
— Ребе, я попробовал сыпать корм треугольничком, а они все равно дохнут.
— Попробуй квадратиком.
Наконец сообщает:
— Ребе, все мои куры сдохли.
— Жаль! У меня было еще столько вариантов!

Прочитал статью и комменты. Тема бизнес-аналитиков не раскрыта. ))
Для тех программистов которым нужно понимать зачем нужна зеленая кнопка и почем именно зеленая — нужен БА.
Для тех менеджеров которым нужно понимать почему зеленая кнопка будет стоить овер-доф..га денег и пилится 3 месяца — нужен БА.

А они вообще наблюдаются вне энтерпрайза?

Должны бы. Но если даже в энтерпрайзе бывает так что БА зовут в крайнем случае, когда уже немного «поздновато пить боржоми», то за его пределами думаю поле не паханое работы для аналитиков. И думаю, это часть проблемы поднятой в статье.

У нас в Fundseeder есть. При этом мы аж не разу не энтерпрайз, а стартап.

Здесь много чего не раскрыто ))
Либо так, либо получается скучный лонгрид, в котором тоже многое не раскрыто. Лучше отдельная статья, если пойму что мне есть об этом рассказать.

Кстати, менеджеров в кризис увольняют первыми, и это еще одна совсем другая история.

Я бы послушал эту историю.

Болтается у меня в черновиках «почему люди хотят стать менеджерами и почему это не всегда хорошая идея». Такой коммент повышает приоритет этого драфта)

Просим! Просим! ;-)

Первыми в кризис увольняют дорогих работников с целью нанять с улицы дешёвых

Это только если бизнес-модель «галеры» позволяет извлекать прибыль, нанимая дешёвых людей с улицы.

Дешёвых людей нанимают не чтобы извлечь прибыль а чтобы сохранить.

Заблуждение. На обучение кого-то надо потратить 6+ месяцев и Х денег. Что запросто может быть больше чем платить кому-то нормальную ЗП.

Им не надо обучение им надо «не платить нормальную з.п. покак кризис».

А какой выхлоп будет от такого сотрудника?

Заказчик оплачивает почасовку. 2 средних новичка выгоднее для компании, чем один опытный. Так как они вдвоем будут делать работу одного в 2 раза медленнее. Профит в 4 раза для работодателя.
А заказчику как-то объяснят про бас-фактор, необходимость ввести код ревью и парное программирование. Что затормозит работу всех остальных на проекте, и сгенерит добавочный профит из-за растягивания сроков.

Это сработает, если заказчик совсем идиот.
В противном случае — заказчик уйдет и фирма окажется в попе.

Есть ещё софт скиллы.

так это вроде известная истина — только не всех увольняют а большую часть

Что видит гребец? Весло, чуть-чуть штурвал, иногда — капитана по пояс. Снизу.

Хорошая завуалированная метафора

Вечная дилемма — больше фич в релизе vs качество. Мы хотим меньше да лучше, чтобы было все красиво, структурировано, и повторно-используемое. А они (менеджеры отвечающие за развитие продукта) хотят больше , ну и хрен что работает кое-как или написано на коленке. Поэтому идет постоянная борьба. Мое мнение в том что заказчик прав, если он хочет что-то пусть получит — решение зарелизить за менеджером продукта , но наша обязанность предупредить о том что оно толком не протестировано и возможны баги (иногда их можно задокументировать в релиз нотес и оставить до лучших времён)

Спасибо за статью, как всегда, на уровне!

Еще неплохая метафора про игры и уровень детализации. На самом деле и разработчики и менеджеры могут работать в разных режимах и в каждом будут свои плюсы/минусы.

Конечно. Черно-белый мир — это для детей.

Неплохая заметка (на статтью не тянет из-за поверхностности), но все выводы одни и те же и сводятся к повторяемому «смотрите с другой стороны». Всё вроде как верно, но под капотом этого решения — множество подводных камней, по которым многие гуру менеджмента написали не одну книгу.

Одно верно — умение вникать больше в детали бизнеса и стремление решить его проблемы — бесценно.

Какая замечательная комбинация комплиментов и гадостей. Причем многослойная, это не классический bullshit-гамбургер! Прочитал с удовольствием )

Come on ;) вы ведь наверняка мечтаете довести качество статей до уровня HBR. Просто тема эта настолько обширная, что впору запускать серию статей.

Это хобби, от которого я получаю удовольствие в свободное время. Если это сделать hard work — кайф потеряется. Так что пока нет)

Я читаю ваши статьи с удовольствием, но в данном случае есть но.
При чтении любых статей я стараюсь выделить главную мысль. В меру своих способностей к восприятию, разумеется. По ходу чтения данной статьи её резюме свелось к «будьте не только специалистом в своей области». Или «не забывайте быть людьми». Прочее — примеры, иллюстрации, разные формы при повторении той же мысли, от констатации до призывов.
Для самостоятельной статьи маловато.

Менеджерская выжимка разрослась, эта — не дотянула. Ок, в следующий раз посмотрим.

Бизнесмен ожидающий овертаймов и прочих жертв — либо должен определять схему вознаграждения, делая ключевых технических специалистов совладельцами, либо систему бонусов которая бы в разы покрывала риски для здоровья исполнителя, либо стать перед зеркалом и признаться себе что он идиот. Сама статья и близко не раскрывает многообразия возможных конфликтов интересов, учитывая тот факт что у нас преимущественно аутсорс и аутстаф (испорченный телефон, аутсорсинг ответственности, конфликты между onshore и offshore командами, конфликты между бизнес юнитами заказчика, заказчик в стадии поглощения другим бизнесом). И это всё один проект кстати.
Я не припомню что бы платили за код, всегда за фичи, майлстоуны (вернее их оценку переведенную во время). Все нормальные разработчики что мне знакомы стараются делать на совесть, использовать лучшие практики- это вопрос проф пригодности через пару лет.

Спасибо за статью ... буквально вчера нечто подобное пыталсо донести.

Что делать?

— практически 100% согласен.

Добавлю мыслю, которую автор не озвучил возможно как само собов разумеющуюся. Понимание ценностей партнера приходит куда быстрее, если вы поваритесь в его шкуре и пройметесь его проблемами. Нет, я не за то, чтобы ПМ в свободное время :8) писал код или занимался QA, а сейлз по совместительству менеджил персонал — тогда конфликт интересов переносится в одну голову и быстро прогрессирует шизофрения :8) Но попробовать себя в рамках некоего «горизонтального» перемещения бывает очень пользительно; спустя год-два приходит понимание, почему ваш партнер в той или иной ситуации поступил именно таким образом, и почему это таки не было маразмом :8)

Ух, писал я что-то по этой теме — dou.ua/...​lumns/tips-for-pm-part-3

Правильно я понял, что автор хотел написать статью о правильном целеполагании, проектном управлении и планировании, мотивации, разделению труда и ответствености, а написал о том что все люди в проекте делятся на бизнес и програмистов и при этом они должны понимать друг друга?

Вы так говорите, как будто это что-то плохое :)

Постою-послушаю. Очень интересно узнать о своих мотивах)

Между программистом и бизнесом должна быть прослойка — менеджеры. Только вот толковых менеджеров днём с огнём...

А затем начинается испорченный телефон и гадюшник.
ИМХО связка ПМ от бизнеса — ТЛ от программистов лучше.

Это у тебя просто хорошего менеджера не было :)
Но вообще да, можно и такую связку использовать, главное дать программистам сосредоточиться на деталях.

Замечательная тема для срача. Про испорченный телефон написали, дальше ждем пока напишут про проедание зарплатного фонда)
PS: менеджеры действительно нужны во многих случаях. Не берусь подсчитать процент.

Это верно! Вот если еще «менеджера» переименовать в старорежимного «приказчика» на службе у «заводчика» — то все становится на свои места :)

Раскрою страшную тайну: это наказуемо. Гребцы должны грести. А если Вася строит из себя сильно умного — наказать, ещё наказать, и так пока не уйдёт или не уверует в «мы — команда» (в смысле «я начальник — ты дурак»).

В результате всем оставшимся на все пофиг, и все нафиги в релизе.

Споры об эффективности охлохолакратии всё так же ж более чем актуальны и ведуться людьми более чем серьёзными в вопросах организации прямого и простого решения всё так же ж нет.

выводы очень правильные, но многие программисты на такие вещи говорят — «нам платят за код, а не вот за это все»

И это вполне себе выбор каждого специалиста. То, что такое отношение с большей вероятностью приводит к проблемам бизнеса (который и платит ему за код), вопрос другой.

Опять же, человек, мыслящий категориями команды, всегда ценнее человека, который привык отвечать «not my job», независимо от того, программист это или менеджер.

То, что такое отношение с большей вероятностью приводит к проблемам бизнеса (который и платит ему за код), вопрос другой.

просто в итоге могут перестать платить, и это станет проблемой программиста. но да, дело сугубо личное

Именно. И то, волнует ли это человека, является принципиальным вопросом. Точно так же, как менеджер, которого не заботят проблемы программиста, далеко не уплывет, потому что без программиста нет deliverable, за которое дадут кушать.

Потому что программисту таки платят за код. Поэтому нужен менеджер. Но не такой, что просто перекидывает таски и суммирует эстимэйты, а такой, который будет отвечать за результат. Вот он должен спросить у программиста мелочи и по ним сделать вывод для бизнеса. А программист должен педалить код.

Это уже даже вопрос философский. Между технически-исполнительной частью и бизнес-управленческой должна быть налажена координация. Тащить на себе эту координацию может как программист, так и бизнес. Но тут как в любви — без обоюдного желания ничего крутого не получится.

Согласен, но тогда программисту должны платить не только за код.

Рискую быть забросанным какашками, но код, написанный без единой мысли о том, ради какой бизнес-задачи за него платятся деньги клиентом, является говнокодом. А говнокод высоко не оценивается.

Девелопер должен девелопить, и никто не должен ему мешать. Бизнес должен рулить бизнес-аспектом, и никто не должен ему мешать. Но любой проект летит высоко и долго тогда, когда все учасники процесса думают друг о друге в рамках своих компетенций.

Я всё же думаю, что это джуну платят за исключительно за код, а все остальное делают за него. Чем выше уровень разработчика, тем выше компетенций самоменеджмента от него ожидают. И в зависимости от этих компетенций те же технические навыки можно продать гораздо дороже.

Таки да, джунов я упустил. Но у джуна при отсутствии компетенций все равно желательны вопросы (к начальству или хотя бы к себе), что и зачем ему сказали делать.

То самое чувство, когда читаешь комментарии, а только потом обращаешь внимание на то кто их пишет :)

Тогда как тут выдержать грань, когда ты «человек, мыслящий категориями команды, всегда ценнее человека» и вариант, когда на тебе начинают за это ездить и причём безпрофитно для тебя(бесплатно + овертаймы)?

когда на тебе начинают за это ездить и причём безпрофитно для тебя(бесплатно + овертаймы)?

никто не говорит что надо овертаймить. не бесплатно — а в рабочее время — то есть оплачиваемое

«Мыслить категориями команды» != «позволять на себе ездить». Нужно сообщать команде/руководству, что «моё время стоит N денег и приносит X пользы». Если вас не слышат — вы не обязаны овертаймить.

Как вы сами сказали, нужно выдерживать грань.

Дело не в овертаймах, а скорее в бизнес-мышлении. Например, попросили тебя сделать большую зелёную кнопку прямо по центру страницы, которая открывает другую страницу. На эту же страницу можно перейти, выбрав в другом контроле чекбокс и нажав уже имеющуюся синюю копку. Есть 2 варианта:
1). Сказано — сделаем. Прифигачили кнопку.
2). Подумать, а надо ли терять время на запедаливание уже имеющейся функциональности. Может быть, достаточно сделать чекбокс выбранным по умолчанию, тогда для перехода куда нужно будет тратиться столько же действий, сколько при наличии зелёной кнопки (1).

Для 2-го варианта достаточно задать себе (или при недостаточности знаний предметной области заказчику) вопрос: а зачем тебе нужна эта кнопка? Чем её наличие облегчит жизнь заказчику или его пользователям?
Именно умение находить оптимальные решения и отличает человека, мыслящего категориями гребца, от человека, мыслящего категориями команды.

Для 2-го варианта достаточно задать себе (или при недостаточности знаний предметной области заказчику) вопрос: а зачем тебе нужна эта кнопка? Чем её наличие облегчит жизнь заказчику или его пользователям?

«Мне» эта кнопка уж точно не нужна. А вот тому человеку, который сказал её сделать (представитель заказчика, я так понимаю) — явно нужна, иначе бы не говорил.

достаточно задать себе (или при недостаточности знаний предметной области заказчику) вопрос: а зачем тебе нужна эта кнопка? Чем её наличие облегчит жизнь заказчику или его пользователям?

Прихожу я такой к программистам «надо сделать зелёную кнопку» (к) (тм) а они мне такие «нет ты сперва скажи а зачем тебе нужна эта кнопка? чем её наличие облегчит жизнь тебе твоим пользователям и общей гармонии мира?»

А ну ок.

ЗЫ: простите что «придираюсь к тайтлам» но вот тут как раз уже старый добрый советский подход «кухарка должна управлять государством» (к) (тм) вот в данном конкретном случае Senior QA Automation Engineer следует полагать он должен по команде «сделать зелёную кнопку» продумать процесс как сделать её качественно как проверить что стоит она правильно что кнопка достаточно зелёная и возможно остаётся такой же ж зелёной при передаче как через VGA так и HDMI (здесь да утрировано) и что кнопка эта правильно взаимодействует с чекбоксом по умолчанию и совместно они работают никому ничего не ломая и отражая реакции друг друга и вообще вот это всё включая регресс-тесты на будущее речь ведь об автоматизации...

Но вместо этого я (здесь обобщение) получу «в ответ» некое «умение находить оптимальное решение» но тут нюанс что вовсе не в той компетенции которую я от человека ожидаю а #внезапно в какой-то другой о которой я не только не спрашивал но и неинтересно мне потому как на эту «зелёную кнопку» вложено уже +100500 ресурсов «свыше» и её надо просто сделать.

Вопрос здесь именно в том что люди не умеют работать именно своими категориями и не умеют строить взаимодействие именно из своих компетенций здесь «насяльника» будет стараться влезть поглубже в процессы программистов «а правильно ли вы делаете зелёную кнопку именно как процесс? что? вы в блокноте код пишете!? запретить!» (здесь утрировано но мысль каждый сможет найти на примерах собственного опыта 146%) а с другой стороны «условные программисты» стараются «влезть поглубже в бизнес и насяльника» ну типа же ж «не тварь дрожащая право имею!» (к) (тм) но в результате просто толпа случайных людей просто хаотично занимаются не своим делом не более того и более того и что таки самый цимес:

— при этом таки _не_ занимаются таки _своим_.

но и неинтересно мне потому как на эту «зелёную кнопку» вложено уже +100500 ресурсов «свыше» и её надо просто сделать.

правда исключительно для ентерпрайза.

вообще в менеджменте различают два подхода к принятию решения:
1) идеи/решения выходят из анализа низкого уровня
2) идеи/решения выходят из анализа на высоком уровне

корпоративный мир в основном следует второму принципу, а правда в том что эти два подхода надо совмещать, следование одному из них крайне глупо и не дальновидно. естественно корпорации еще живут, тем самым давая возможность новым/маленькм спокойно давать им прикурить, ну по крайне мере в сфере B2C, ибо в B2B зачастую выигрывает не тот кто лучше делают свою работу — а знакомства (игра в гольф), откаты и другие такого рода вещи. но если появится несколько таких B2B игроков они просто похоронять конкурентов, ведь все B2B в конце замыкаются на C

И да в каком однорогом из 3 человек еще нижний уровень может быть полезен со своими идеями, но в конторе из 100 человек уже нет.

вообщето, на низком уровне можно колосально оптимизировать и улучшить работу, если бы вы интересовались менеджемнтом как наукой или дисплинной то там как раз это подробно разбирается. самый тупой и старый пример — топка печей углем — в ХХ веке получилось улучшить производительность топки углем на 60% путем уменьшения на несколько сантиметров площади совковой лопаты — людям было тяжело большой лопатой работать. эту историю по моейму всем рассказывают когда разбирают тейлоризм. проблем-солверы как раза помогают тем что анализирует на всех уровнях, а не только на высоком.

вообще именно анализ на всех уровнях дает самые охренительные результаты, и чем больше фирма тем как правило сильнее влияет оптимизация на низком уровне — ибо в маленькой конторе по умолчанию директору доступен и низкий и высокий уровень, а в большой нет.

можно предположить, что если программист напишет на 2 строчки кода меньше, то производительность на конторе увеличиться.

не верное утверждение, используя мою аналогию может быть так что предлагаемая зеленая кнопка создаст жесткий ботл нек, из за чего все будет тормозить (но даже это не обязательно), но возможно что ту кнопку и делать не надо, а после того как станет известна цель кнопки — может можно поменять одну строчку в конфиге и для конечного клиента это будет лучшее решение. и такие ситуация встречаются, а те кто вверху не имеют ни малейшего понятия о том как устроена система внизу, в отличие от того кто сидит внизу

Этим аналогиям и басням уже 30 лет, а воз и ныне там.

они действуют, и еще как, это даже не вопрос оптимизации эффективности а вопрос оптимизации усилий для достижения реальной цели

Тут имеется ввиду вопрос- начиная с какого уровня- можно начинать открывать рот со своими оптимизациями бизнесс-процессов? Alex Fogol , например, считает, что если QA, даже если

Senior QA Automation Engineer

то все равно не имеет право лезть в калашный ряд программистов с оптимальными решениями, ибо QA- это видимо для него самая низшая каста. Виктор Чижденко считает, что в принципе- любой нижний уровень в компании не имеет права на идеи, пока не вылезет по карьерной лестнице на верхний уровень.
А как вы считаете, с какого места в команде уже можно начинать подавать голос?

Говорить может каждый, главное чтобы это было конструктивно, а не расплыватся мысл по древу. Джун тоже может говорить просто скорее всего это не будет конструктивно, это то чему учатся, так что если не начнет говорить то никогда и не научится

И утонете в митингах
главное чтобы это было конструктивно, а не расплыватся мысл по древу

а вот это

Очень часто наиболее оптимальное решение — просто приказать делать так, а не иначе.

начало деградации

Деградации чего или кого?

системы управления

за месяц переписать всю систему и начальство ему разрешило

и опять все придумывают свое по поводу того что я писал

я уже все описал выше.

вообще в менеджменте различают два подхода к принятию решения:
1) идеи/решения выходят из анализа низкого уровня
2) идеи/решения выходят из анализа на высоком уровне

может не совсем корректно использовал понятие «принятие решений» — но думаю общая мысль понятна.

суть в том — что по факту следование только одному принципу ущербно. да, в долгосрочной перспективе скорее всего подход 2 лучше чем подход 1. но идеальный вариант это совмещение двух подходов. 1 вариант намного лучше действует для реализации тактических целей, а второй для стратегических.

зачастую, правильное тактические действия могут капитально повлиять на стратегических действий, ибо тактические победы являются фундаментом стратегических.

изоляция стратегии верный признак деградации системы управления ибо она становится оторванной от реальности, соотвественно реализация стратегии становится не эффективной ввиду отсутствия базы

Опять вода и умные словеса.

просто чтобы эту темы разобрать на примерах — надо как минимум серию статьей накатать, вот и пытаюсь обобщать чтобы сократить мысль

Посмотри на Раду.

кстати, Рада отличный пример деградировавшей системы, но они деградировали немного по другим причинам.

Ну и твою гипотезу о двух направлениях нужно доказывать

ну какбы это ныне самая актуальная тема в менеджменте, по сути это сильно раскрывается в Ситуационном менджменте который отвечает современным реалиям

Пока же большей частью примеров в жизни она опровергается.

я ее пробую продвигать с тем с кем работаю — результаты положительные.

А да в СССР в пятилетних планах такое же говорили о движении и снизу и сверху.

СССР идеальный пример односторонего движения сверху-вниз с эмуляций обратного движения — по сути была настоящая корпорация монополист

И получается, что нужна группа людей, что будут придерживаться этой идеологии и продвигать ее, борясь с противниками.

так вообще с любыми изменениями, а тут мы говорим по сути о сдвиге мышления которое сформировывалось веками -
рабовладельческий строй, крепостное право, капитализм — всегда было «я начальник — ты дурак», а условно недавно это все стало менятся.

часто владельцам фирм важнее статус и тешить собственное самолюбие (хотя как мы видим, месные программисты в большинстве такие же) нежели продолжать быть конкурентоспособными

А какую армию берём за аналогию — (пост)советскую или западную? А то во второй самостоятельность действий небольших тактических групп вполне поощряется.

Чтобы не быть голословным: www.realcleardefense.com/...​itary_command_111267.html

и как это может применяться в IT:
gaperton.livejournal.com/37721.html

«Я кричу направо, а нужно налево, меня не слушать» © А. Суворов (который полководец)

Ребята я понимаю вы в армии не разбираетесь не надо «применять по аналогии» действие «самостоятельных групп» равно как и вообще любых подразделений подразумевает возможность и способность полностью самостоятельных действий включая на случай потери командования в т.ч. непосредственного командования но в рамках этого принципа прямо полагается самостоятельное исполнение _непосредственных_ функций подразделения а никак не «возможность и способность принимать участие в высшем командовании».

Сержант может командовать полком при условии единственного оставшего в живых (либо доступного в конкретных полевых условиях) среди рядового состава полка но это вовсе не означает что «самостоятельность действий» взвода распространяется на командование ротой и «самостоятельность понимания приказов прямого командования».

При всём при этом таки да младший состав таки обязан доносить до командования свои возражения по _сути_ и по _Уставу_ если таковые имеются если таковых не имеется никаких «требований донесения высшей задачи до низшего состава» нет равно как и нет необходимости именно в виду прямо полагаемость способности каждого подразделения _самостоятельно_ выполнять _поставленную_ задачу в рамках его подразделения функций.

какую армию берём за аналогию

— в данном контексте как раз иллюстрация непонимания принципов устройства но желание иметь право голоса и участия в обсуждении не более того но и не менее очень правильная и очень качественная иллюстрация в контексте общего вопроса.

Вот только армию, в принципе, только с очень огромной натяжкой можно приводить как аналогию менеджмента в IT.

IT-компании с жёсткой иерархической структурой менеджмента постепенно отмирают, как динозавры.

Ещё раз споры и дискуссии об эффективности и применимости вообще охлохолакратии ведутся активно и успешно в том смысле что несмотря на наличие и даже продуманность принципа реального «просто совета гарантирующего результат» так и нет.

Вот скажим вы в компании какие принципы и практики холакратии используете? Есть ли в применении оных отличие от бюрократии?

ЗЫ: в данном контекст «ответ за армию» имел другой контекст как «по аналогии ИТ» и ставил конкретную цель показать пример некомпетентности «элемента нежёсткой неиерархии».

Да! Есть еще пример, когда маршал Жуков послушал сержанта насчет тростниковых лыж-мокроступов для наступления через болота (было так всамделе или нет — не так уж и важно).
Пример из моей личной практики — в одной фирме производительность труда девелоперов повысилась за счет того, что всем желающим — после моего рац-предложения, дали второй монитор. (Пусть тут повышение было не на 60%, а едва ли на 6% — но ведь тоже неплохо).

Другое дело, что-таки да: один инициативный дурак столько «рац-предложений» внесет, что и сотни начальников не хватит обдумать. Поэтому надо так: рационализаторство поощрать, но сверхэнтузиазм ограничивать.

а знакомства (игра в гольф), откаты и другие такого рода вещи.

Ну ок приехал заказчик и заказал программистам поле для игры в гольф и угостил всех пивов и даже выписал премию авансом по $100 дальше что какие «знакомства»?

Всё это исключительно комплекс маленького человека маленькому человеку непременно хочется «чтобы со мной считались!» (к) (тм) выхлопа там не просто 0,0 там в более практичных реализациях всё сугубо отрицательно.

ЗЫ: но при этом не путать совершенно сюда не менее классический «грибной менеджмент».

а знакомства (игра в гольф), откаты и другие такого рода вещи.
Ну ок приехал заказчик и заказал программистам поле для игры в гольф и угостил всех пивов и даже выписал премию авансом по $100 дальше что какие «знакомства»?

перечитайте еще раз мой комент — я вообще не о том писал

Именно! Никто же ж не играет в гольф с программистами чтобы «знакомства и откаты» программистам обидно а объяснить им это не получается потому что они уверены что уж они то придумали бы лучшую альтернативу.

ЗЫ: при этом равно и обратное уж бизнес то уверен что «а что там его программировать?» и вопрос весь в том что обе стороны совершенно уверены что уж они то на стороне другой да легко но диалога и реальной системы взаимодействия на этой уверенности не построишь и реальный сдвиги начинают только те кто от такой «уверенности» отступает.

даже не знаю что вам написать.... не, я знаю что я так пишу что меня сложно понять, но первый раз вижу чтобы ктото прочитал то что я вообще не писал и даже не думал

Смотри, есть 2 варианта:
1). Писать код.
2). Предлагать решение задачи.
Вариант 1 — это миддл. Ему сказали сделать — он сделал. Качественно, с применением best practices, но бездумно.
Вариант 2 — это синьор. В его задачи кроме тупо написать код, входит ещё и подумать, зачем этот код писать и предложить оптимальное решение задачи.

Так Дмитрий именно и предлагает поинтересоваться у заказчика, какая бизнес-задача стоит за просьбой «запедалить зелёную кнопку».

И, да, с заказчиками, которые с исполнителями работают по принципу «сказано копать от забора и до обеда — вперёд!», это не сработает. Но таких, в моём лично опыте — меньшинство. Многие заказчики, наоборот, ценят, что проектная команда — не тупые «гребцы»-исполнители, а думающие ребята, которые стараются понять бизнес и решить задачу оптимальным способом.

А самые опытные из заказчиков уже хорошо усвоили, что хочешь, чтобы педалили бездумно и точно по спецификации — это к индусам. А если хочешь проактивную думающую команду — это в восточную Европу.

А если хочешь проактивную думающую команду — это в восточную Европу.

Это такой миф большой и толстый но решается очень просто «если вы такие умные то почему у вас нет миллиона долларов» (к) (тм) #немоё

От заказчика до программиста обычно 5 менеджеров в прослойке (утрирую).
....
Или ты речь ведешь только про конторы до 10 человек размером?

По-вашему, в более крупных компаниях не может быть более-менее независимых подразделений, владеющих определённым продуктом, продакт-менеджер которого постоянно на прямом контакте с командой разработки? У нас в Сигме достаточно немало клиентов, которые работают с нами именно по такой схеме.

Как ты себе представляешь в данном случае (типичном для большой конторы) интересоваться у заказчика?

Если в наличии действительно пять прослоек менеджеров — то никак. Но я бы не сказал, что это такой уж типичный случай. За 17 лет работы в IT видел такое всего несколько раз, и, что, с...ка, характерно — ни один из этих проектов не был особо успешным.

Сказки про глупых индусов и умных восточноевропейчев оставь верующим.

Это не сказки, а обобщение опыта. Понятно, как и в восточной Европе есть некомпетентные разработчики с ментальностью «винтика», так и среди индусов есть очень толковые ребята. Но, в среднем по палате, разница именно такая, как я написал. Вон у нас сейчас один из крупных заказчиков отдал часть поддержки и допиливания продуктов в Индию, хотели косты сэкономить, ага. Теперь сами не рады тому днищу некомпетентности и низкой производительности, которые в итоге получили. «Не гонялся бы ты, поп, за дешевизной» ©

видимо, у нас разный опыт «больших контор».
может, подразделение разработки в банке выглядит именно так.
аутсорс — до представителя заказчика максимум один менеджер.
да, это не СЕО заказчика, но СЕО заказчика и не занимается решениями типа «нужна нам дополнительная зеленая кнопка или заюзаем существующую»

Ну это же не так. Тот до кого 5 менеджеров он и не знает ни о каких кнопках в принципе. Решение о кнопке приняли на гораздо более низком уровне, вот совсем рядом.

Тут всё очень просто

вариант 1 это миддл он умеет писать код но маленький и несамостоятельно
вариант 2 это синьор он умеет писать код но побольше в идеале полностью справиться со всем самостоятельно и может даже немного «употребить помощь миддлов»

Это всё нет никаких «зачем писать и предложить оптимальное» таки да есть «предложить оптимальное как писать код» но тут именно об том и речь что если спросить «типа синьора в соотв. с этими письменами» (к) (тм) «как оптимальнее писать код?» он захочет «ещё и подумать зачем этот код писать» (к) но «как писать оптимальнее» таки не сможет он тупо подменит понятия это классика.

Ровно то же ж сделает и «менеджер типа насяльника» он не сможет таки _руководить_ он будет «думать как оптимально писать код» (к) и заниматься прочим микроменджментом читай ровно так же ж тупо подменит понятия и это тоже классика.

потому как на эту «зелёную кнопку» вложено уже +100500 ресурсов «свыше» и её надо просто сделать

Здесь, вероятно, стоит уточнить, каких именно ресурсов? Скажем, если проектная команда с самого начала в курсе, что у заказчика сидит толпа бизнес-аналитиков и экспертов по проектированию взаимодействия с пользователем — то сомнений по поводу целесообразности именно зелёной кнопки и именно в указанном месте попросту не возникнет. Так как, все знают, что над этим решением работали люди, которые хорошо понимают бизнес и потребности конечных пользователей.

Но нередко же бывает совсем по-другому, когда менеджер со стороны заказчика — возможно, даже сам не подозревая об этом — пытается протолкнуть проектной команде возникшее в его голове уже готовое решение бизнес-задачи. И, при этом, нет никаких гарантий, что это решение оптимальное, и что команда не сможет придумать более удачную альтернативу, если ей объяснить потребности бизнеса. В таком сценарии, надо быть тем ещё самодуром, чтобы не прислушиваться к мнению мозговитых ребят, которых ты сам нанял.

Скажем, если проектная команда с самого начала в курсе

«Ох ты ж а с нами то и не посоветовались!» (к) (тм)

все знают, что над этим решением работали люди, которые хорошо понимают бизнес и потребности

Ну ок возьмём более реалистичный (и реальный) вариант «все знают что на этим решением работали люди которые мало что понимают и вообще вот это всё» дальше что?

и что команда не сможет придумать более удачную альтернативу, если ей объяснить потребности бизнеса.

Так весь цимес же ж в том и есть что «команде» платят деньги _конкретно_ за _реализацию_ а не за «придумать более удачную» и весь вопрос тут в первой фразе «а с нами и не посоветовались!» и ничего более.

Ну да обидно конечно «условный заказчик» отбашлял кучу бабла левым хренам каким-то с горы и вообще не поставил даже в известность а «команда» в этой цепочке даже не вторая по счёту а вообще где-то там в самом конце и даже от этого левого хрена с горы за кучу бабла уже сама по себе отстоит на 7 (семь) каких-то невнятных слоёв-уровней-насяльника-передаст «а ведь можно всё придумать более удачную альтернативу!» (к) (тм)

Но мир жесток и работает именно таким образом и вот да обычная практика:

не прислушиваться к мнению мозговитых ребят, которых ты сам нанял.

Но тут ещё и неловкий нюанс что на самом деле «прислушиваться» чаще приходится к «белому шуму» и нет там никаких «мозговитых ребят» а тех которых есть скупают отдельными компаниями вместе с экспертизой и уже реальной мозговитостью и вот они то потом и строят те самые «корпоративные отделы» которые далее по цепочке таки да часто через индусов и ещё кого немало и спускают:

возникшее в его голове уже готовое решение бизнес-задачи

Хотите «придумать более удачную альтернативу» и чтобы вам «объясняли потребности бизнеса»? (и здесь нет «если» обратите внимание это важно) — станьте ими!

Не можете ими стать? Ну простите...

Ну, есть еще не затронутая область дискуссии на границе двух выше описанных.
Иногда мелкая (с точки зрения бизнеса) фича может затянуть недели работы, и наоборот — крупную фичу можно сделать в 10 строчках кода, если компоненты и архитектура уже есть.
Вот о таком программисты вполне себе могут думать и предупреждать: «большую круглую зеленую кнопку посреди страницы мы будем 2 недели делать, и по дороге что-то разломаем, так что еще неделя уйдет на тестирование, и в продакшн лучше сразу не пихать. А вот если кнопка будет желтой и квадратной и чуть-чуть сверху, то можем вотпрямщас» или там «если вы реально собираетесь пользоваться зелеными кнопками, то нам надо заложить 2 месяца рефакторинга на то, чтобы вынести цвет кнопок из кода в отдельный интерфейс»

Виктор, ну правда, может, хватит уже тянуть свою личную боль во все дискуссии? По-моему все уже прекрасно поняли, что лично у вас был печальный опыт работы с большой и негибкой управленческой иерархией.

Вот только подобный подход к менеджменту уверенно отмирает в тех компаниях, которым приходится активно шевелиться, чтобы конкуренты не отобрали долю рынка. В монополистах же, прочно и надолго засевших в своей нише — там да, беда-печаль.

Соответственно, как тут любят выражаться, «галере» нужно подбирать команду, исходя ещё и из специфики заказчика. Если это кровавый энтерпрайз с прослойкой из пяти менеджеров — ставим туда именно «гребцов», которые гребут, куда сказал «насяльника», и не задают лишних вопросов. А если это стартап или продуктовая компания на высококонкурентном рынке — подобные «гребцы» там будут не только бесполезны, но даже и вредны.

а «команда» в этой цепочке даже не вторая по счёту а вообще где-то там в самом конце

вот это ключевое.
понятно, откуда ноги растут у суждений

Ну ок возьмём более реалистичный (и реальный) вариант «все знают что на этим решением работали люди которые мало что понимают и вообще вот это всё» дальше что?
«команде» платят деньги _конкретно_ за _реализацию_ а не за «придумать более удачную» и весь вопрос тут в первой фразе «а с нами и не посоветовались!»

Возможно, мне кажется, но у меня стойкое ощущение, что что у Виктора, что у вас, простите, какой-то травматичный опыт работы с идиотским менеджментом со стороны заказчика. Если «на той стороне» сидят дубы, которые считают себя умнее всех, а проектную команду кем-то вроде бесправных и бессловесных рабов — понятное дело, что не стоит и пытаться со своей стороны что-то улучшать в продукте. Но, только, ИМХО нужно обладать уж очень специфичным складом характера (или полным отсутствием опыта), чтобы работать хоть сколько-нибудь долго на таком проекте.

Собственно, повторюсь — на такие проекты, как раз, очень хорошо брать индусов, т.к. у них в массе психология именно такая — «делай, что сказал насяльника, и не умничай»

Но тут ещё и неловкий нюанс что на самом деле «прислушиваться» чаще приходится к «белому шуму» и нет там никаких «мозговитых ребят»

Так тут зависит от «галеры». Если в штате — только «гребцы», которые только и умеют, что грести под зорким взглядом погонщика — то кровавый энтерпрайз с пятью прослойками менеджеров — таки да, их клиент.

Более того, сейчас крамольную вещь скажу — это вполне себе бизнес, только в Украине его становится делать всё сложнее, т.к. индусы-пакистанцы-вьетнамцы готовы предлагать подобных «гребцов» пачками за гораздо меньшие рейты.

Хотите «придумать более удачную альтернативу» и чтобы вам «объясняли потребности бизнеса»? (и здесь нет «если» обратите внимание это важно) — станьте ими!

Знаете, есть такое слово — симбиоз. Нередко в IT он работает так — есть заказчик с бизнес-идеей и пониманием рынка, но без компетенции в разработке софта. И есть подрядчик, который полностью берёт на себя «под ключ» все техническое решение. При этом — ключевой момент — заказчик не то, что не против, но даже и ожидает, что подрядчик будет вникать в нюансы бизнеса и предлагать оптимальные решения.

Если вам лично не доводилось работать на таких проектах, то это не значит, что их нет...

Менеджерам: помогайте видеть людей, а не юнитов!

для начала надо перестать назывть ресурсами. не человек — ресурс, а человек обладает трудовым ресурсом

Точно! Надо больше политкорректоности. Пусть будут афроевропейцы с вёслами. И не «раб», а «менеджер по гребле».

Это не вопрос политкоректности а восприятия и следующими за ним взаимоотношениями

Долго обдумывал эту фразу. Очень давно её не слышал вживую.
Если человеку сказать «ты — ресурс», человек часто обижается. Это конфликтоген, не надо так.

Підписатись на коментарі