ППЦ как элегантно скинули вину за бардак в компании на конечного исполнителя.

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

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

Мне эта ситуация у AEP очень напоминает наши гос.учреждения ))

Начальство попустительствует

Удваиваю этого защитника. Проблема не в разработчике, а в том что CEO выдал указание, которое не выполняется, но за это не наказывают.

Как я понимаю, CEO решил вводить это ограничение числа участников не как жесткое ограничение, а как «это не приветствуется». Поэтому и наказания особого нет.

Это не задача разработчика.

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

У нас как раз имеет право критиковать задание. Делать по своему без спроса и без уведомления - не имеет, не делать вообще - имеет.

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

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

Возьмите меня, буду регулярно выносить мозг всей иерархии за бестолковые тикеты. 8)

т.е. разработчику следовало (обоснованно) послать СЕО с его хотелками? фигасе у вас демократия.

ы. ынтырпрайз

Тогда почему задание глупое то?

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

P.S. формулировку «заказчик не согласен на две группы» я достал из разговора с одним из координаторов. Возможно, есть что-то еще.

Я не могу понять у вас можно собирать группы больше 6и человек или нет? Если запрещено, то почему бы вам не побеседовать с теми, кто продал онлайн курсы на большее число человек чем необходимо? Сейчас у вас есть сведенья кто именно и как часто нарушал правила.

Я уже сказал - «не приветствуется», т.е. полного запрета нет.

Сейчас у вас есть сведенья кто именно и как часто нарушал правила.

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

Тогда у вас проблема административная, техническими средствами её не решить.

Когда СЕО придумывал глупость он наверное думал что от неё будет толк. Может прогер, когда реализовывал глупость тоже думал что от неё будет толк.

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

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

Собственно - как, не обидев разработчика, указать ему, что в общем-то от него в данном случае ожидалась критика, а не слепое выполнение глупого задания?

Тогда разработчик будет ломать голову, как указать, что ваш СЕО ненужен, стараясь никого не обидеть.

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

Можно дать ему прочитать ОП этой темы, и навряд ли можно ещё что лучше придумать.

Но факт такой: от других прогеров слышно больше критики, и большей частью по делу

Может быть, а может быть нет, у тебя пример неудачный - по нему сложно судить.

Кстати мне тут грешным делом подумалось, что у вас доход преподавателей прямо пропорционален числу учеников, нет?

По ситуации вообще.

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

Исходов ситуации будет два
1) Выполнение указания о дроблении групп.
2) Менеджеры начнут ворчать на снижение и увольняться.
Тут надо будет думать, то ли СЕО хочет не возможного, то ли менеджеры у вас имеют трудности с межличностным общением(тоже возможная причина).

В прочем последнее легко лечится увеличением зарплаты.

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

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

И это не первый раз, когда он делает ровно то, что просят

На кол его!

К сожалению, курсов по чтению мыслей у нас в каталоге нет

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

понимаешь к чему я веду? всё очень плохо.

Это уже не столько критичность сколько «планирование». Оно не у всех разработчиков есть, да и не все его приветствуют.

Короче, поговори с девелопером, и попроси «анализировать (моделировать) последствия», но не писать их куда-то в отчёт. А просто ходи и спрашивай его, что он думает по этому поводу.

Если увидишь, что он не думает, в принципе, то всё. Если он просто не хочет напрягаться, то ищи как его мотивировать (это практически не выполнимо).

Зачем ты аватарку сменил?

Щас бы на разработчиков взваливать стратегические менеджерские задачи, лол. За что CEO и сам ОП едят свой хлеб, если от разработчиков ожидается заниматься не технической реализацией, а бизнес-планированием?

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

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

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

Это у вас задача к чуваку, занимающемуся бизнес логикой.

Как я понимаю у вас нет стадии бизнес анализа и у вас программист должен уметь понять, сформулировать и решить бизнес задачу. Для это программист

1. Должен уметь это делать :-). Это уже не программист, а разработчик и попадаются они мягко скажем не очень засто и за ними нужно побегать.

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

3. Задачи должны формулироваться от проблемы. Т.е. в постановке должна быть описана проблема, а не способ её решения. Решение можно пометить «Для примера» в конце или как-нить так.

Обычно все проблемы от не понимания, если «не понимание» устранить, то проблемы рассасываются самим собой.

Старая всем надоела.

Спасибо за комментарий по делу.

У нас действительно нет отдельной стадии бизнес-анализа. По договорам, и у меня, и у него в обязанностях есть совсем не разработческий пункт «оптимизация бизнес-процессов в компании».

Скрама как такового у нас тоже нет, поэтому отдельной роли product owner тоже нет. Т.е. если CEO сморозит глупость в тикете, то поправлять его, кроме разработчиков, некому.

Насчет формулировки задач «от проблемы» - согласен, в понедельник переговорю с CEO.

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

<Мы захотели глупость, обошли ее контртупостью, потом дали ТЗ разработчику, а он потратил время и сделал ровно то, что просили. Как не обидев разработчика, указать ему на его неправоту?>

Вот это шитшоу, шел же мимо магазина, че попкорн не взял?

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

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

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

Все просто - ведите курсы для разработчиков «как на самом деле надо выполнять задачи заказчика»

Ещё (и со мной всякие gentle management такое проделывал), можно спросить у разработчика, а не показалась ли ему эта задача глупой и неуместной, потому, что тебе так кажется, но ему, разработчику, конечно виднее, и ты хочешь его экспертного мнения. А после получения утвердительного ответа, уже эскалировать выше.

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

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

Собственно - как, не обидев разработчика, указать ему, что в общем-то от него в данном случае ожидалась критика, а не слепое выполнение глупого задания?

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

2. Постановление на местах исполняется из рук вон плохо

Люлей исполнителям.

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

Все правильно делает.

Иначе, можно говорить и невыполнении ТЗ и несоответствии занимаемой должности.

Как задачи ставятся, так они и выполняются.

Собственно - как
указать ему, что в общем-то от него в данном случае ожидалась критика, а не слепое выполнение глупого задания

Русским языком в тексте ТЗ.

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

Лорчую адеквата! Теория игр в помощь!

Он все правильно сделал. Инициатива наказуема хехе.

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

А если бы ты не нашел логики, то разработчик бы пострадал? То есть его рабочее место зависит от степени тупости вышестоящего?

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

Так что все таки проблема не в разработчике, и не в интеллектуальном потенциале каждого из участников. А просто в совести.

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

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

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

Перечитайте комментарий выше: делать по-своему без обсуждения нельзя, но можно критиковать и можно не делать вообще. Смысл, как я понимаю, такой. Задачи не назначаются, а берутся добровольно из кучи одобренных. Если у тебя есть вопросы, значит, скорее всего, или ты что-то не понял (и можешь сделать неправильно), или задача неправильная. В первом случае задачу, скорее всего, возьмет кто-то другой, кто лучше понимает, как ее правильно «дорисовать» (и, как правило, дорисует правильно). Во втором случае ожидается критика.

Я уже представляю прорабов обрывающих телефон инженеру-проектировщику... %)

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

а если вопросов нет?

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

А уж если на это есть прямая директива от руководства... Фидбек с низу крайне мощный инструмент в умелых руках.