[mplata 9]

Коллеги, кто какие системы использует? Что дало внедрение системы? Кто против систем управления проектами и почему? 

[dxp 65]

"Огласите весь список, пожалуйста"  ©

Что вы понимаете под "системами управления проектами в электронике"? Какие знаете? Если что, то SCRUM -- это не система управления проектами вообще и уж точно не в электронике. 

Система управления проектами -- это, например, Redmine. Альтернативная связка Jira+Confluence. Хотя я бы не назвал это именно "системой" управления, это просто багтрекер + вики.

[mplata 9]

17 hours ago, dxp said:

"Огласите весь список, пожалуйста"  ©

Что вы понимаете под "системами управления проектами в электронике"? Какие знаете? Если что, то SCRUM -- это не система управления проектами вообще и уж точно не в электронике. 

Система управления проектами -- это, например, Redmine. Альтернативная связка Jira+Confluence. Хотя я бы не назвал это именно "системой" управления, это просто багтрекер + вики.

Скрам вполне себе система. 

Вики также со мной согласна, и прекрасно работает далеко не только в программировании. 

Самые основные для нас преимущества:

1. Не даёт лодырничать

2. Повышает вовлечённость всей группы в проект

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

4. Соблюдение сроков и ощущение ответственности каждого

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

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

Разумеется скрам для одного человека это мягко говоря странно. 

[dxp 65]

1 час назад, mplata сказал:

Скрам вполне себе система. 

 

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

1 час назад, mplata сказал:

Вики также со мной согласна, и прекрасно работает далеко не только в программировании. 

Конечно. Логистика, закупки, отлаженные производственные процессы -- да. Где всё более-менее предсказуемо и поддаётся адекватному прогнозированию. Но не в разработке нового.

1 час назад, mplata сказал:

1. Не даёт лодырничать

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

Не даёт лодырничать никакой не скрам. Вообще, никакая методология или система управления не решает сама по себе эту задачу. Её решает конкретный человек -- руководитель. Если он на своём месте, он прекрасно видит, кто что стоит, кто чем занимается, где есть толк, а где пустота (имитация). Потому что принцип "Кадры решают всё!" применим не только к исполнителям, но и (в первую очередь!) к руководителям.

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

Далее по пунктам.

1 час назад, mplata сказал:

2. Повышает вовлечённость всей группы в проект

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

Вовлечённость в проект может поднять тот же самый человек, который руководит процессом, применяя три рычага (это известная тема из психологии):

1. поднять интерес подчинённого сотрудника-коллеги, правильно выбирая для него задачи -- далеко не все задачи интересны всем, поэтому тут надо внимательно и чутко подходить. Будет интерес -- будет результат. Интерес -- это самый главный мотиватор;
2. помочь с пониманием трудных моментов (сам или привлекая других, более квалифицированных в вопросе людей). Когда человек имеет хорошее понимание того, что он делает, это тоже прилично мотивирует (повышает вовлечённость), позволяет работать эффективнее, что поощряет исполнителя, который видит позитивный результат своей работы;
3. довести важность дела до сотрудника-коллеги: нужность результата, ответственность перед заказчиком, уважение товарищей и т.п.

Всё это -- живая работа с людьми. Только она и даёт результат. А пустая говорильня на дейликах -- просто трата времени и сил.

2 часа назад, mplata сказал:

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

За счёт чего? Что такого уникального даёт скрам для этого? Что собрались и поговорили? Ну, собрались и поговорили. Наговорились, устали, ничего не решили -- это сколько угодно. Даже более того -- это обычный результат, когда толпа пытается что-то решить. "Лебедь, рак и щука". И эта говорильня продолжается из раза в раз без всякого результата. 

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

2 часа назад, mplata сказал:

4. Соблюдение сроков и ощущение ответственности каждого

Соблюдение сроков обеспечивается грамотным разбиением работы на этапы и контролем выполнения работы по этим этапам. А коллективная ответственность -- это миф! За исключением крайних случаев: типа, все мегасознательные и ответственные как главный герой из советского фильма "Коммунист", или когда в случае неуспеха всех расстреляют (лишат премии, уволят и т.п.). Во всех других случаях коллективная ответственность проявляет себя как коллективная безответственность. Всегда в группе (статистически) находятся раздолбаи, тормоза, рукожопы, эгоисты-индивидуалисты и т.п. И без присмотра и персональной ответственности всё это приводит к тому, что результат провальный, с спросить не с кого.

Итого, опять всё сводится к компетенции и квалификации управляющего процессом конкретного человека.

2 часа назад, mplata сказал:

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

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

Пример из реальности: пилим командой ПЛИСовый проект, я занимаюсь PCIe DMA (на TLP), а коллега -- поиск паттернов в потоке сетевого трафика. У нас задачи не пересекаются вообще никак! И каждая из них требует глубокого погружения. В итоге, все скучают, когда я что-то бубню запросы чтения памяти хоста, проблемы негарантированного порядка прихода CplD от разных запросов, про кредиты non-posted запросов и подобное, а когда коллега говорит про свою работу, я из его рассказов понимаю только, что у него там какие-то блум-фильтры, перфектные таблицы кукбука и ещё какая-то хрень, названия которой я не запомнил. Чтобы мне понимать, о чём он говорит, мне нужно серьёзно погружаться в тематику его работы, но я не могу этого делать -- у меня своей выше крыши. И у него ровно та же ситуация. И у всех в группе. Получается, что все сидят и тупо ждут, чтобы отчитаться, и когда это пустое мероприятие закончится. Скрам-мастер не понимает вообще ничего из того, что там говорят, т.к. он не специалист ни в ПЛИС, ни в тематике проекта. Ну, по скраму он и не должен. Его задача -- быть секретарём заседания.

И вот в итоге проектом занимается 8 человек, но задачи у всех перпендикулярные, какие-то общие места есть только на стыковках, а это очень небольшая часть проекта. В итоге, на общие темы мы можем поговорить только про какое-нить CDC FIFO, проблемы с STA, нюансами использования общего инструментария (симулятор, синтезатор и т.п.) и другими общими вопросами, которые к непосредственно проекту имеют опосредованное отношение.

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

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

2 часа назад, mplata сказал:

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

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

Где тут рулящая роль скрама? Да без него это сто лет делалось и делается. Он сюда вообще не вписывается. Что же касается корректировки ТЗ по ходу дела, то и это возможно, но не так огульно как это делается со скрамом. Если заказчик предлагает (просит) что-то поменять, это рассматривается, и если принимается, то выпускается специальные документ: дополнение к ТЗ. Все эти доп. хотелки отражаются там. И всегда видно, что было исходно, а что изменилось по ходу дела. Отдельный документ позволяет хорошо видеть, сколько чего, когда и как изменилось. И это позволяет эффективно пресекать излишнюю тягу заказчика к фантазиям .

При разработке софта эти изменения реализуются ещё как-то более-менее безболезненно. При разработке железа -- это как правило боль, и часто оказывается неприемлемым. Иначе разработка затягивается на годы. Это проблема, когда софтовая контора берётся делать железо: тематика и средства радикально другие, а подходы те же самые. Я работал в софтовой IT комании, которая взялась разрабатывать железо (для себя, для своего продукта), в итоге 6 лет хардварному отделу, объём работы проделан колоссальный, сами разработки технически очень достойные (специалисты высокого уровня там трудятся -- контора может себе таких позволить), но в серии и у клиентов по истечении этого срока нет ни одного из полудюжины разрабатываемых изделий.

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

Подводя итог

Скрам, возможно, неплохо себя проявляет при разработке, например, веб-приложений, когда результат работы можно сразу предъявить, и заказчик видит его, может попросить что-то поменять или откорректировать -- вот тут спринты, как контрольные точки,  помогают. Но когда ведётся разработка материнской платы сервера (со 128-ядерным процессором и 16 планками DDR4), где работа схемотехника и конструктора ПП  занимает по полгода, какие нафиг спринты?! То же самое и с ПЛИС: тот же PCIe DMA я пилил несколько месяцев, и эта работа почти никак не пересекалась с другими -- она несмотря на известную сложность, является локальной, законченной в себе -- ни вводные никакие снаружи тут не нужны, ни результат показать в конце спринта невозможно (вряд ли кому будет интересно смотреть на очередной добавившийся тест того или иного модуля).

По итогу пристального наблюдения за этой темой и невольного участия в ней, для себя я сделал следующий вывод: скрам -- это вредная иллюзия управляемости процесса, которая проникла глубоко в сфере IT. Секрет успеха этого внедрения состоит из двух частей:

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

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

Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.

 

[mplata 9]

14 minutes ago, dxp said:

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

 

 

А какая у вас система?

[dxp 65]

Если речь про инструментарий, то Jira+Confluence+Gitlab.

[Mplata_DEV 1]

Quote

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

Что в разработке софта, что в разработке железа, что даже при изменении бизнес-процессов или любом другом проекте - без ТЗ результат ХЗ.

Если нет ТЗ, этапности работы(наверное, имелся в виду План-График) - то и скрам бесполезен. В таком случае надо менять руководителя.

Ни разу не видел успешного проекта с таким подходом.

 

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

Корректировки ТЗ предусмотрены любой методологией ведения проектов.

 

Quote

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

А Вы при разработке железа по факту готовности КД сразу отдаёте в производство всю партию?

А как же описанные даже в ГОСТах (не говоря о здравом смысле) этапы предварительных испытаний опытных образцов на соответствие требованиям ТЗ? ОК, срок релиза новой версии ПО 2-3 дня(максимум по всей DEVOPS процедуре). Срок изготовления и сборки новых образцов печатных плат у нас 2 недели. Пока ждём новые образцы плат, команда разработчиков занимается другими задачами и тоже не простаивает. Вся разница релизов софта и железа.

Ошибки, например, в банковском софте могут стоить дороже хардварных ошибок.

 

Quote

Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.

Вы хотите сказать, что все руководители топовых ИТ компаний не компетентны?

А Вы из какой компании?

[Maksim_2444 13]

В 19.05.2024 в 15:40, dxp сказал:

Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.

 

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

 

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

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

[selax 20]

ips, лоцман?

Но мне проще без них.

[mantech 53]

21 час назад, Mplata_DEV сказал:

Если нет ТЗ, этапности работы

 

21 час назад, Mplata_DEV сказал:

Ни разу не видел успешного проекта с таким подходом.

Ну разумеется, поди сделай то, не знаю что...

[kpv 12]

On 5/19/2024 at 3:40 PM, dxp said:

Работает только в случае простых задач.

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

для разработки железа им в 99% случаев подойдёт какая-нибудь навороченная development плата. и человек, который научится писать нормальное ТЗ 🙂

[kpv 12]

On 5/19/2024 at 3:40 PM, dxp said:

Всего этого нет в теме разработки железа, там всё эти ошибки стоят дорого. Поэтому там этот подход не работает совсем.

agile - это узаконенный беспорядок для embedded железа. Agile, это когда "Хуяк-хуяк, и в продакшн".

Оно тоже работает для простых проектов. 

[Mplata_DEV 1]

Quote

agile - это узаконенный беспорядок для embedded железа.

К сожалению, бездарные SCRUM мастера и Agile коучи совершенно исказили восприятие Agile подхода к разработке.

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

Под это и построены методологии типа SCRUM со спринтами, когда руководитель разработки(он же владелец продукта) максимально четко ставит разработчикам актуальные именно на данный момент задачи. Это не значит, что руководитель не следует верхнеуровневому плану-графику проекта. И уж тем более не снимает ответственности за результат в срок.

SCRUM работает на уровне управления одной командой.

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

 

Шлите лесом SCRUM мастеров, которые отрицают на корню использование планов-графиков для управления проектом.

Выгоняйте сразу любого, кто скажет "разработчики не могут отвечать за сроки".

Я много раз видел эти ошибки в выстраивании процессов разработки (и даже в очень серьёзных ИТ компаниях). Всегда это приводило к провалу.

 

Quote

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

И не только. Мы работаем с любыми заказчиками.

Есть проекты разработки серьёзных устройств. Есть запатентованные изобретения.

Есть сложные проекты внутренней модернизации компании под цели стратегии.

[one_eight_seven 6]

16 hours ago, kpv said:

agile - это узаконенный беспорядок для embedded железа. Agile, это когда "..., и в продакшн".

Нет, скорее сегодня - это взять только понятное из Scrum (оно же - плохое и перечислено ниже), криво его применять и пользоваться JIRA.

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

Кстати, сам scrum - весьма неплох, даже хорош, надо всего лишь убрать из него спринты, скрам-мастера, продакт овнера, бэклог, спринт ревью, упоминания подотчётности (accountability) и обязательств (commitment), ну и сертификацию. Что тогда плохого останется в скрам?

Изменено 23 мая пользователем one_eight_seven

[mplata 9]

On 5/19/2024 at 3:40 PM, dxp said:

 

Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.

 

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

 

On 5/19/2024 at 3:40 PM, dxp said:

Ну, собрались и поговорили. Наговорились, устали, ничего не решили

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

 

On 5/21/2024 at 10:02 PM, Maksim_2444 said:

Scrum - по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности.

тому прямое подтверждение. 

При нормально выстроенной системе такой мысли не возникает.