Эффективный менеджмент и очередной Эджайл

На самом деле могут быть исключения вызванные степенью зарегулированности конечного продукта. Если это к примеру какой-нибудь медицинский прибор. По законодательству США медицинский прибор от которого зависит жизнь человека должен быть разработан с такими строгими требованиями, что если вдруг произойдёт какая-нибудь проблема и неисправность этого прибора нанесёт вред здоровью или причинит смерть, то должна быть возможность отследить всех участников разработки и кто и над чем конкретно работал и какие отчёты сохранил. Соотвественно и процесс построен таким образом что каждое движение документируется. Тут уже бывает не до Agile. То же может касаться любых изделий или систем, которые могут причинить невозместимый ущерб. И тут уже документация и процесс важнее. Поэтому в частности всякие фирменные медицинские приборы и лекарства так дорого стоят, а разработку ПО для АЭС поручают исключительно сертифицированным организациям, а не кому попало.

Друже, это ЕВРОПЕЙСКИЙ КАПИТАЛИЗМ!
Году так в 2005, я устаивалсяна работу, и попал на собеседование во всем известный C...Y BANK. Так вот там был конкус на не самую лучшую должность под сомнительную зарплату, но собеседование проводилось по твоему сценарию.
Н втором этапе я вылетел. Но тот поток маразма, что услышал от других кадидатов, это поный пэ...
Попросился остаться дальше, что бы больше поугорать посмотреть, дальше было еще хуже. Но вот все было по сценарию, как ты и написал. Выбрали тех, кто больше орал, пусть даже не по делу и вообще не разбираясь в сути вопроса.
Проще говоря, балаболов и пустозвонов. Именно те люди им нужны тогда и нужны сейчас! Больше лапши навешать клиенту это главная здача любого банка! С тех пор я не ведусь ни на чьи предложения!

А, так тут хеппи енд.

Такая хрень происходит при приходе к власти эффективных руководителей прошедших курсы МВА. Ранее на ЯПе было, особенно понравилось про Мегафон. Сам в прошлом году столкнулся со сменой директора организации, тоже укушенного курсами МВА. Посмотрел на это месяц и свалил из ставшей за 18 лет уже родной организации. Все один в один, как и описано выше. Вместо начальников отделов, выросших из рядовых проектировщиков, ставших начальниками групп а затем и начальниками отделов-просто менагеры. Они умеют все, но ничего не понимают. Вот такой абсурд. Администратор вместо специалиста, готового руководить и понимать свою работу. Ничего удивительного в этой истории, кроме общих принципов "организации" процессов производства, главное графики правильно строить и язык подвешенный. У нас тоже предложили собирать из нескольких отделов спецов, всех в кучу. В следующем проекте будет другая команда спецов, зависит от направлений проектирования. Вот только не всегда это выполнимо, вот так собрать людей из разных отделов и заставить их работать разобщенно со своими коллегами. В общем чушь это полная, не должно быть никаких менеджеров, это просто блохи во многих процессах организации производства. Попробуйте заменить главного инженера, энергетика, начальника цеха или участка менеджером-получите красивые нисходящие графики. Все ИМХО, просто пришлось это наблюдать.

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

Это сообщение отредактировал SergeM - 13.12.2018 - 20:20

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

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

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

старо как мир.

О, бля, так вот как этот бардак называется, в котором я уже который год работаю! Среди мудаков, которые не считают нужным не то что следовать RFC, а даже читать их....

Это сообщение отредактировал NickelOdeon - 13.12.2018 - 20:51

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

Это сообщение отредактировал cybermx - 13.12.2018 - 20:42

К сажелению на сегодня сложно RFC следовать, на текущий момент - это некий набор "рекомендаций", им часто сложно следовать. Например, найдите RFC для протокола QUIC который реализован на сегодняшний день в том же chromium.
И не понял, как это относится к "agile"? Опять же, какие специалисты, такой и результат.

Это сообщение отредактировал cybermx - 13.12.2018 - 20:38

Агил работает, если в команде специалисты, а не пиздаболы

Фуф, еле дочитал, как будто опять на работе побывал

Размещено через приложение ЯПлакалъ

Agile пришел из программирования
Но нихуя и там не работает
То есть существует, но не работает

Из затейливых формулировок я все же понял, что эффективного менеджера отправили в лес, а работягу дизайнера откачали. Ну так счастливый конец-начало.

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

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

Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального внедрения у клиента). Это приводит к снижению качества продукта и накоплению дефектов.

[*] Работающий продукт важнее исчерпывающей документации
[*] Готовность к изменениям важнее следования первоначальному плану

Вот это вот иначе как педерастией и не назвать.... Разверните сеть на несколько тысяч рабочих мест и парой сотен серверов на таких условиях в отсутствие вообще какой-либо топологии и ТЗ, без документации и закупленного единообразного ПО и ОС. А хуйли, по ходу дела придумаем. Ну-ну....

Это сообщение отредактировал NickelOdeon - 13.12.2018 - 20:57

Никто не спорит о важности документации. Но важна только полезная документация.
В манифесте есть также фраза: "То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева."
И дергать два пункта из четырех и ... Это уже игра фактами.
А так, да не выложил последнию фразу тут моя вина. Надо было полностью публиковать, раз с копипастил.

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

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

Вы абсолютно не правильно трактуете agile, некоторые мои коментарии:
1) «дорожной карты» всегда важна и без нее ни как (при чем тут Agile?)
2) "возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования" - к сожалению это реальность. Заказчик всегда будет менять требования. Скажите пусть идет лесов, отвечу - тогда все уйдут в лес. Кто Вам будет платить и что либо заказавать? Вам придется меняться под современный мир, либо вы не конкурентноспособны.
3) "массовым рефакторингом и переделками практически на каждой очередной итерации." - по опыту скажу, лучше найти проблему раньше и поправить как можно раньше. Чем по окончанию длительного цикла, понять что 3 года пилили не то и переделывать все. И короткий цикл дает возможность провезти "мелький рефакторинг" после окончания. Почему это минус вообще не понимаю. Также в IT есть методы Continuous Integration, которые позволяют проводить рефакторинг более безбоязненно.
4) "Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы" - это вообще игра слов. Скажу только, нужны квалифицированные кадры, которым надо платить зарплату и создавать атмосферу. Опять же, Вы менее скованы в формальных процедурах - значит легче провести рефакторинг и подчистить "последние" изменения.

Agile - действительно не панацея, но позволяет пересмотреть методы решать задачи.

Это сообщение отредактировал cybermx - 13.12.2018 - 21:29

Вот поэтому такое дерьмовое ПО сейчас и получается!
Похуй на оптимизацию: будет тормозить - пусть железо обновляют!
Говнокод продакшн...
У мобил 6-8-10 гигов памяти, гигагерцовые процы! А тормозят хуже 386 с 4-мя мегами и винтом на 80 мегов под вин-95. Не говорю уж про ДОС.

При грамотном манагере все как раз так и есть. Нет бумажной работы а работа на результат. И при этом заказчик доволен. Основная работа хорошего манагера это работа на результат И обеспечить чтоб результат БЫЛ. И более того чтоб грамотный коллектив не разбежался и работал эффективно и в удовольствие. И при этом еще и клиент был доволен...до определенного состояния. Потому что клиенты есть наглые. Те хитрожопые - заплатить меньше - получить больше, обмануть исполнителя. Один из распространенных способов- молодой, амбициозный ПМ который знает Agile и готов лизать клиента, иначе ж никак, клиента потерять можно (он его потеряет, клиент его поимет и пойдет искать нового мазохиста с модной технологией) И все это за фикс прайс цену.
Я с опытом 15 лет прогером и 10+ лет ПМ и 50+ проектов законченных. Старый стал :) заипало руководство в прогеры назад подался. Спокойно и когда все есть уже чуть больше чуть меньше побоку. За то спокойно. :)

Вы капец как глубоко ошибаетесь! Этой вашей "конкурентно способностью" вы собираете ВСЕХ НЕАДЕКВАТНЫХ клиентов. А нормальных забирают другие,
Обычно так ведут себя молодые и меленькие команды/компании. Они бросаю на все контракты которые пробегают мимо. Ну как практика показывает это потом либо заканчивается постоянной "как белка в колесе" и на "расходы хватает". Или закрывается.

Agile - название набора методов гибкого управления проектами в условиях часто меняющихся требований

Такого метода Аджайл нет. Есть Scrum, есть Kandban (у нас называется "точно в срок". Митсубиши, конечно долбоёбы, что у себя это придумали четверть века используют.

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

1. саботаж работников, не знающих как работает методика и какие их роли, обязанность, ответственность. Каждый понял как ему удобно. Видать, даже тренинг на простом примере не удосужились провести.
2. привычка находить крайнего, в то время как за проёб виновата вся команда, а не один манагер. Вот её всю и надо было нахуй слать
3. наличие самого манагера. Это походу дела был типа "Скрам"? Какой в жопу манагер в скраме?! Учите матчасть.

Итог типичный: аджигайл, вместо аджайла. Это когда мы хотим, чтобы все можно было поменять, но правилам следовать не хотим, менять хотим бесплатно. Это, кстати, тичино для российского закостенелого бизнеса.

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

Это сообщение отредактировал artivenom - 13.12.2018 - 22:49

Вообще не то.