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

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

бля, как скучно я живу )))

а гном то зачем?

ИМХО: у шефа, который в итоге понял что всё это херь в принципе не могло такое произойти. Опытные руководители (технари) на дух не переносят (д) эффективных.

Отправлено с мобильного клиента YAPik+

Так про это уже давно сняли:

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

Это сообщение отредактировал Negodeay - 13.12.2018 - 18:23

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

Ага

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

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

Это сообщение отредактировал dbezz - 13.12.2018 - 18:44

ТРИЗ хорош в теории, как дело доходит до практического применения то него никакого выхлопа.

"Главный новый бич страны - высокомотивированные низкоквалифицированные люди" (ц)

Могу рассказать как в сфере проектирования. Есть компания - у нее куча объектов в реализации (стройка). Надо сделать новый проект. Для этого нужно нанять проектировщиков. Срок - год.

Руководятелы этого всего то ли в суматохе с другими проектами, то ли просто потому что раздолбаи отодвинули дело в ящик, авось рассосется. Спустя 9 месяцев кто-то наткнулся на папку, которая как куриное филе в панировке, покрыто пятнами от кофе, паутиной и пылью. Ебана, тут же проект! Надо делать! 3 месяца осталось!

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

Это лет 10 назад еще вся компания (архи/конструктора/проектировщики) сидели бы, открыв глаза и рты с выражением "да вы ебу дали, это нереально сделать нормально!". Сейчас все берут бумажки идут хреначить хоть что-то похожее на проект... потому что надо сдать заказчику,а руководство ниче слышать не желает, договор уже подписан. Не сделаем - штрафы. А в фирме итак типа бабок на ЗП не хватает, вот сделаете проект, нам дадут денег, мы вам заплатим.

А по факту все знают, что сделают за месяц, потом еще пол года будут переделывать все под замечания и доводить до ума.
Итог: По бумажкам все сделали вовремя, а по факту непонимающие "че это за УГ" заказчики, руководители, которые хотят бабок с заказчика и не понимают, почему нет денег + ко всему загнанные работники ожидающие ЗП, хотя фирме заплатят только после устранения всех замечаний, потому что Руководство заключило такой договор с такими условиями... Проект сделан через Ж и он будет в нормальном состоянии дай бог через несколько месяцев, а возможно и позже потому что мудрое руководство подписало новый договор на гениальный проект сроком в 3 недели, ибо в прошлый же раз за месяц успели, значит можно попробовать ускориться!

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

Майские указы? Не?

Пффф, про это уже давно решение придумано!

Это сообщение отредактировал КотМасквы - 13.12.2018 - 18:54

1) Определение Agile - это некий метод решать задачи (approach). Не очень верно говорить что это метод управления. Agile вообще не говорит, о том как формировать команду, например. Все что его описывается это некий манифест Agile - https://agilemanifesto.org/iso/ru/manifesto.html
На основе Agile уже пытаются вводить методы управления - Scrum например. Контрпример scrum - метод "водопада" (waterfall model). Scrum же грубо говоря "метод водопада" разделенный на более мелкие циклы (обычно 2 недели.)
2) Все идея, выражена в манифесте, состоящий из 4х пунктов:

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

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

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

*upd*

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

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

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

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

Это сообщение отредактировал airfly - 13.12.2018 - 19:00

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

Чем больше эджайла, тем больше платят за водопад :) Пущай эджайлятся побольше и почаще :)

Работал в компании-дочке занимающейся обслуживанием ИТ энергетической компании. У нас был отдел занимающийся АСКУЭ, но переодически материнская компания подбрасывала такие задачи, что мы, чистые айтишники, чесали затылки и склеивали рвавшиеся от непрофильных задач пуканы. Потому как считалось, что мы каждой бутылке связанной с цифрами затычка.
А теперь об эффективном менеджменте - до меня задачи решались по принципу, к какому отделу ближе.
Пришел я начальником управления развития. Предложил и переделал решение непрофильных задач по принципу "рабочих групп". Ввели понятие важного задания ВЗ и учет времени по нему. В итоге при получении задачи менеджер проектами собирал группу, которая могла, в теории, с этой задачей справиться. Определялось время и место встречи. Если нужно подтягивался "живой" устно говорящий заказчик. Чтобы не было долгой переписки ни о чем. Если в группе выяснялось прямо по факту встречи что не хватало еще кого-то, то вытягивали, но с извинениями.
Дальше в определенный срок, обычно 3 часа, искалось решение и разбрасывались задачи. После народ расходился по своим рабочим местам. В системе управления проектами проект менеджер разбрасывал задачи и указывал сроки исполнения. Народ работал над текущими делами и отдельно вкалывал над ВЗ. К сроку до дедлайна получали результат, проект манагер брал заказчика и тыкал его пошагово в результат. Если все ок, то до дедлайна занимались текучкой, если нет, то быстро переделывали нужные сегменты. Дальше сдача и счета об оплате с актами. Клиент получал результат мы оплату на юр лицо.
Все в итоге получали к з.п. + премия + оплата за ВЗ. За время работы никто не расстроился и время зря не терял. Наоборот иногда так "наворачивали" результаты, что приходилось остужать людей.
И ключевое - программеры интроверты + у двух конкретные закидоны, держали их в отдельном закрытом кабинете, АСКУЭшники любители по болтать, всегда знали, что время рассуждений в зачет не идет, проект менеджер имел финансовые рычаги... ну а я, если что нужно было пропихнуть, бегал к руководству выше чем мог проект менеджер.
Вот и все

Хотел бы только поправить, что бальшую задачу всегда можно разбить на маленькие и раздать рабочим группам. И у рабочих групп, которые:
1) Компетентны
2) Налажены нормальные связи между рабочими группами.
То это вполне может работать. Если грамотно разбить задачу на подзадачи и раздать. И даже без четкого описания, сами рабочие группы вполне в состоянии описать взаимодействие компонентов общаясь между собой.

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

Компетенция - это да. Дефективные манагеры новой формации - это пиздец.
Приходит чувак на лётное поле, в костюмчике. Подходит к Ми-8:
- Покажите мне ИЛС.
- Хде???
- В кабине, я руководитель проекта (чего-то там).
- Гхмм, а вам какой вертолёт нужен?
- Ми-28, тут у меня всё написано, я должен посмотреть.
- Это как бы восьмёрка. Вы их отличаете?
- Ну а какая разница?
- Пошёл нахуй отсюда, ущерб!!!
Сбежал, обиделся наверно походу))))

Мне прикольно наблюдать как новомодные манагеры, Agile пихают везде. :)
И потом мотивируют что его можно применять везде.
Как по мне Agile не подходит для фикс прайс проектов. А потом занятно наблюдать как все не то и все не там и вроде сделали, но себестоимость посчитали прослезились. Обычная водопадка на фиксе эффективнее в разы. И клиента мотивирует.
Для долго играющих проектов и оплате по ТМ - это как раз Agile лучше всего.

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

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

Вообще-то наоборот, работёнка грязноватая. Поэтому и такая форма организации - иначе просто не будет результата.

В космос, конечно, не вышли, но в принципе - можем.

Agile не возможно пихать, он может только сам придти. Как пример, если работники достаточно квалифицированные и хотят что-то делать - они сами будут избегать "бюрократии" и станет возможен первый пункт манифеста "Люди и взаимодействие важнее процессов и инструментов". Что невозможно при "неквалифицированных кадрах" - которых надо всегда контролировать и говорит что делать (тогда "процесс и инструменты" становится важнее).

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