Форум OlegON > Разговоры на отвлеченные темы > Беседка

Новомодные принципы организации работы : Беседка

29.03.2024 11:51


17.10.2020 14:07
OlegON
 
Недавно проходил собеседование в одной крупной организации, и вот руководитель задал вопрос, как я отношусь к эджайлу... Я так внутренне напрягся, поскольку про Agile Manifesto читал неоднократно, и многое так и не понял, а еще больше считаю достаточно спорными и натягивание совы на глобуступую кальку западного подхода на наш менталитет считаю глупостью.

Небольшая заминка с просьбой перейти на конкретику, особенно в свете того, что я не разработчик, и вот диалог начался с вопроса руководителя:
- Как Вы относитесь к тому, чтобы подразделение имело единый показатель оценки и премию получали именно по этому показателю.
- Я против такого подхода, поскольку мотивация сотрудников падает. Условно говоря, если в коллективе подразделения есть Вася, который не хочет работать, то даже если я буду на 5+ работать, то премию не получу, хотя никаких средств воздействия на Васю у меня нет.
- Но ведь если он не справляется, а у Вас есть время, то Вы можете помочь Васе.
- Оборотная сторона медали в том, что если Вася не хочет работать, а я не могу его заставить, то я в итоге буду вкалывать за двоих, чтобы вытащить общий KPI, а Вася, что называется "сядет и ножки свесит". Я бы предпочел, чтобы ответственность была на руководителе, как и задача распределения нагрузки между сотрудниками.

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

Я не верю в лозунги: "мы - команда", если сотрудники не получают бесплатных обедов, бесплатного такси в случае задержек на работе и их рабочие места не устраивают их с какой-либо точки зрения на комфорт и здоровье. Это означает, что руководители думают только о себе, собственных интересах. Это не команда, а вот это говно в уши, вроде "вместе мы победим и будем жить еще лучше", я успел уже оценить и на личном опыте, и на опыте коллег. Работают эти лозунги только в одну сторону - мотивация сотрудников на текущий момент.

Я не прав?
19.10.2020 22:24
baggio
 
Ну это чуть больше в сторону коммунизма...
Кто как может работает, каждому по премии...
Схема работает пока всех устраивает премия и хватает ресурсов...
20.10.2020 06:19
OlegON
 
Какой ещё коммунизм 🤔 чистой воды соковыжималка с попыткой рабства за идею... Сначала "вы работаете, чтобы мы вместе победили", потом "денег нет, но вы держитесь"
20.10.2020 08:59
baggio
 
Ну... А я что говорю? Точно коммунизм))))
20.10.2020 09:06
Mtirt
 
Скорее речь идет о круговой поруке.
Вы всем коллективом должны долбить Васю и заставлять его работать.
Мотивируя - если ты не будешь работать, то вся команда не получит своих денег.
20.10.2020 10:10
OlegON
 
Цитата:
Mtirt Вы всем коллективом должны долбить Васю и заставлять его работать.
Как контролировать Васю, если я вообще не в курсе планов его работы и, возможно, вообще не в моей компетенции разбираться, что он делает? Сразу возникает вопрос "кому должны и почему" и "для чего тогда руководитель"... Я пришел на работу, например, базу поддерживать, а не Васю-программера мотивировать, которого я, кстати, не нанимал.
20.10.2020 20:40
DEeMON
 
Цитата:
baggio Ну... А я что говорю? Точно коммунизм))))
Ага, точно.
Люди должны больше работать и меньше получать (а лучше вообще одной идеей питаться), тем самым увеличивая прибыль собственника.
Это коммунизм и есть, точно.
И появилась эта методика в США, самом коммунистическом государстве на земле !!!

ЗЫ. Если серьезно, то сами идеи, лежащие в методике Agile здравые, вопрос как их повернуть и в чьих интересах.
21.10.2020 19:43
sh00r00p
 
Цитата:
DEeMON сами идеи, лежащие в методике Agile здравые, вопрос как их повернуть и в чьих интересах.
Ну знаете, в наших реалиях можно любую здравую идею повернуть так, что потом уже не отмоешься. И более того, это не просто "можно сделать", а будет сделано обязательно)
06.10.2021 12:59
OlegON
 
Сейчас у меня идет что-то типа вводной лекции в этот Agile и прочий Kanban. Испытываю непреодолимое отвращение.

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

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

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

"Сотрудничество с заказчиком важнее согласования условий контракта" - да-да, если у вас оплата за проект, то разоритесь вы, а если почасовая - заказчик :) На фоне миллиона историй о том, как бы переделать все по другому при подходе к финишу проекта, этот пункт выглядит очень весело. Может, это у нас не будет работать, а работает где-то с другими сферическими конями в вакууме, но у нас если не обозначить четко условия и поэтапные сроки, а потом не вздрючивать команду за соблюдение графика, то работать ни хрена не будет.

"Готовность к изменениям важнее следования первоначальному плану" - аналогично предыдущему пункту нюанс по разорению. Компетентность заказчика, как правило, такова, что он не хочет возиться и изначально сформулировать все, что он хочет. Он хочет поговорить и чтобы наступило счастье. Так не бывает. Изначально необходимо понять, к чему мы идем. Зафиксировать это и дать понять заказчику, какую цель мы хотим достичь. Согласовать и уточнить, что заказчик вкладывается именно в эту цель, путь к которой оплачивается поэтапно с ценностью и оплатой каждого этапа, возможно, в разных размерах. Заказчик может забыть итоговую цель, может отменить ее, может метаться, как в проруби, команда исполнителя не дожна поддаваться такому разрушающему фактору и идти в своем графике, а не бегать по потолку, потому, что цель кардинально меняет локацию. Любые стрессы и внеплановые изменения влияют на качество результата и перегорание людей. Дробить можно на какой-то разумной длины этапы, по прошествии которых общаться с заказчиком, убедиться, что цель актуальна и идти дальше, либо переназначать цели, если выясняется, что что-то изменилось.

Среди прочего от этого всего - ежедневные "дейли", чтобы "каждый из команды понимал, что в ней происходит и кто чем занят". Ну я понимаю еще еженедельные планерки, чтобы действительно как-то поделиться новостями... Но, &^$#, полуторачасовые голосовые марафоны каждый день с одним и тем же перемыванием одного и того же! Да нахрен мне вообще, расскажите, что там делает вебер в заголовке сайта, если у меня в этот момент DoS на базу идет?

Еще убило, что в соответствии с этой хренью начальника-то и нет. Есть лидер. А команда должна самоорганизовываться. Ну надо же было изобрести что-то, чтобы совсем дерьмом не казаться :) То есть вот команда с лидером, на нее накидывают задачки, а ее лидер "смотрит в будущее" и "собирает и анализирует метрики успешности выполнения". Какой-то самообман вообще. Вот именно подчеркивается, что лидер задачи людям не раздает. "Уот так уот" (с). Вся теория управления в виде, что руководитель должен понять задачу, найти исполнителя и проконтролировать выполнение идет лесом. Теперь у нас лидер команды, который для команды ничего не значит. Дескать лидер "может быть не в курсе каких-то деталей, чтобы оценить задачу". Эти изобретатели аджайлов вообще думали чем-то? А нахрена тогда задача в команду прилетает, если лидер не в курсе?

Еще веселые утверждения с этими шариками. Выстраивают несколько потерпевших в ряд, дают им один шарик, чтобы передали из руки в руку, потом несколько конвеером, дескать, смотрите, насколько вы стали продуктивнее... Сразу вспомнился шедевр от Чаплина. Даже и объяснять много не надо.




Глубокое мое убеждение, что это все - бредовая мода, которая дает рабочие места ее внедренцам за счет умения вливать в уши руководителям. Любое управление должно быть прежде всего разумным, предсказуемым и контролируемым. А вот эта малоэффективная и тем раздражающая болтовня с рисунками и перекладыванием шариков не нужна.
08.10.2021 11:38
grannie
 
+1
Ровно такое же отношение к Agile'у.
Часовой пояс GMT +3, время: 11:51.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.