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

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

А описанное тут это просто безответственность. Советовать все могут, а вот нести за это ответственность мало кто.

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

В нормальных ИТ конторах платят по другому. В фирмах, где не брат-сват, а нужно делать деньги и директора не с 3 классами тоже платят по другому

Это сообщение отредактировал artivenom - 14.12.2018 - 11:43

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

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

Это сообщение отредактировал artivenom - 14.12.2018 - 12:37

Ну блядь. "Эффект немного предсказуем". Agile внедрили, а что это такое объяснить забыли.
Чтобы он заработал - надо убрать всех пиздаболов ваще. А вместо них ебануть кого-то типа аналитика. Что он делает? Он нихуя не креативит - в пизду. Он записывает что надо сделать и отдаёт дальше (копирайтеру и дизайнеру). Те короче прикидывают хуй к носу и говорят - так блэт. Слишком обще - давай-ка дядя аналитик, - декомпозируй ка нам эти задачки. мы их тогда оценим. Или давай-ка объясняй что конкретно надо сделать. Не как надо сделать, а именно что. Как - мы блядь без тебя разебёмся, не лезь. Потом кароч накидывают себе задач, чтобы например за две недели спокойно всё заебашить. И говорят - так пацаны управленцы, креативщики. Идите нахуй, нас нихуя не трогайте. Через две недели встречаемся, смотрим что получилось. (ладно ладно, давайте через неделю, покажем промежуточный вариант, может что-то подкорректируем). Список задач на две недели - отвественные, число, подписи: аналитика, дизайнера, копирайтера. И всё. Нихуя нового насыпать нельзя.
Пока эти двое ебашат, аналитик пишет задачи на следующие две недели, чтобы по окончанию спринта показать демо, сказать что получилось и спланировать работу на следующие две недели.
И всё заебись. Нахуй не нужен манагер (ну только всех собрать и кофейку заварить и печенек купить).
Как-то так.
Это я написал как оно в разработке бывает, но может и в медиа тоже прокатит, хотя хуй знает.
Это исключает некомпетентных долбоёбов на стадии производства. Потому что таких ребят аналитик с командой должен послать на хуй. Остудить их хотелки типа фоткать видос и потом ебашить оттуда картинки в продакшен. И прочее.
P.S. Короче без меня вам всем хуёво ))))

Это сообщение отредактировал IrishTippler - 14.12.2018 - 12:44

триз тут и рядом не стоял

Это опять же все для идеального коллектива. Где все пришли работать.
Система в этом случае абсолютно не мудако-устойчива. Достаточно двух мудаков, которые думают, что раз ответственность нигде не прописана, значит, можно делать любую чушь и забивать на сроки, и все накрывается медным тазом. Даже имея на руках кучу подписанных протоколов совещаний, где человек сам соглашался, что сделает это в такой-то срок, люди умудряются проебывать сроки или говорить "я это не сделал потому что.... <тысяча причин>"

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

Это сообщение отредактировал Angelberth - 14.12.2018 - 13:03

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

Мда....Мы в разных странах живем, судя по всему.
В России платят ровно столько, сколько в среднем ты стоишь по данной отрасли.
Есть понятие "средняя медианная зарплата", вот отсюда и толкаемся.

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

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

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

Если за 30 минут не пришли к ответу то ровно по тому же принципу в оставшиеся 10 минут пилятся задачи найти ответы на вопросы например запилить прототипы разной архитектуры и посмотреть что лучше и придти с этим на следующее совещание.


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

А может проблема была не в методологии? А в том, что в проект (рабочую группу) привлекли непрофессионалов, а пиздаболов.
Создание рабочих групп по отдельно взятым проектам практикуется во многих методиках управления бизнесом. Тот же доктор Ицхак Адизес, далеко не самый глупый человек рекомендует применять эту модель для решения рабочих вопросов. Только называется она в его школе по другому. А суть та же: привлечь в группу людей с разным складом ума и характера. Одни инициируют, другие скептически обсуждают, третьи занимаются бюрократией и делопроизводством по проекту, а четвертые (они называются "производители") непосредственно реализуют задумку. Но, нужно отметить, что чтобы это работало надо в корне менять мировозрение всех сотрудников и философию компании в том числе. А иначе получается как в поговорке: Гладко было на бумаге, да забыли про овраги. Т.е., каждый пытается перетянуть одеяло на себя и в итоге забывает свою роль в процессе.

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

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

А что не так?

Собирая требования я точно знаю что клиент долбоеб, потому что он не умеет выражать свои мысли и пожелания и это нужно делать за него. Он не знает нюансов автоматизации и возможности технологий поэтому не представляет как можно сделать хорошо. Простые дешёвые вещи часто воспринимаются как магия или технологии пришельцев. Поэтому часто нужно настойчиво показать что можно сделать быстрее дешевле и качественнее чем он хочет. До сих пор горжусь одним из своих первых самостоятельных проектов. убедил поменять бизнес процесс под возможности технологии. Вывернули его вообще на изнанку в итоге он сократился с 3х месяцев до недели. В 12 раз карл! Вместо 6 сотрудников 2. И сверху ещё всякие бонусные фишки.

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

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

Хотел бы, но как практика показывает заказчик просит менять требования во время процесса практически всегда и это затрагивает и меня, хотя я работаю только над малой частью огромной системы. Понятно, что если это не возможно и затратно, мы так и говорим - эти изменения дорогие и их не возможно уложить в данные проект, а дальше уже менеджеры решают этот вопрос. Если же изменения внести возможно, почему бы нет? Берем в итерации и меняем, итог - заказчик довелен.
Опять же, подобное сложно проделать в классическом "waterfall" когда все запроектировано в начале и раскидано по отделам и любые изменения катастрофичны. Конечно, можно всегда отказывать в подобных просьбах, ходит судится и выигрывать суды, мотивирую тем что этого нет в требований (ТЗ, еще где-то), где стоит подпись заказчика. Но потом не удивляйтесь непонятным плохим отзывам о компании в том же Интернете.
По поводу неадекватных клиентов - не имею опыта решения данной проблемы, т.к. с клиентами не работаю напрямую.

1) "Абсолютное неумение говорить" - это правда, любой специалист уходит в "свой язык" понятный узкому кругу таких же специалистов. Как раз принцип "Работающий продукт важнее исчерпывающей документации" и "Сотрудничество с заказчиком важнее согласования условий контракта" спасает от этого. Имея хоть что-то работающее, можно позвать заказчика и показать что уже есть. Плюсы, заказчик понимает, что хоть что-то делается и сразу может дать комментарии что ему не нравится. Это же решает проблему "Отсюда у вас и все время неправильные архитектуры, и ненужный клиенту функционал, и прочее.
2) "Клиент-долбоеб" это ваше все - оставлю без комментариев
3) "системы безопасности на обьекте" (если это information security) и IT не так уже и далеки как Вы думаете. Они умеют одного прародителя "Information and communications technology"
4) Как раз с безопасниками у меня наиболее печальный опыт. Т.к. безопасники думают, что IT это что абсолютно левое и не связанное с "безопасностью".
5) Все требования предъявляемые "безопасниками" практически всегда абсурдны. На сегодняшний день "безопасники" не когда этого не признают - сваливая на кого-то. Типа, я внедрил "СКУД" за недорого, а когда указываешь, что "карта" может быть скопирована любым китайским программатором и вешать доступ к любым ПК по СКУД небезопасно - всегда шлют куда подальше.

Про вторую проблему " Ну и вторая проблема - кто то должен заставить вас работать и квалифицированно спросить результат в сроки. " - рынок спросит, чуть ошибся и на дно.

Про "Но наилучший результат дают только два..." может дать хоть один пример из top 30 мировых компаний кто работает по этому принципу и успешен?

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

А что эти двоя расскажут и покажут каждый день, отвечая на вопросы: "что сделано за вчера", "что будешь делать сегодня" и "какие проблемы у тебя есть" ?
Заблокирован Васей? Говно вопрос. Вася тут, реши с ним побыстрому. А пока не решил, вот тебе список задач мелких, элементарных составляющих, давно разбитых и отсортированных. Бери следующую и выполняй.

Это сообщение отредактировал artivenom - 14.12.2018 - 21:42

Нет, я в России живу. А ещё в случае с ИТ есть отличный посыл нахуй зажравшихся бизнесменов. Называется он ласково - удалёночка. Там зарплаты от 2к начинаются и 6-7 достигают. И так работают многие

У нас таких креативщиков сразу обозвали "ИГИЛ"

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

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