Я тоже, кстати. Но я видел, как это делают другие!

выглядит как кастомный подход, про который врядли снимали книжки =)

Всем привет, уже когда-то был в этом чатике, пришел с вопросом :)
У меня в команде и на самом деле во всем отделе практикуют one-on-one management, планирований на команду нет, есть планирование руководителей, есть только стендапы команды, на которых все рассказывают чем занимались, но выглядит довольно бесполезным, так как никто до конца не имеет чужого контекста. Спринтов нет, целей на спринты нет, раз в неделю на 1-1 обсуждаются индивидуальные задачи и если остается время — фидбек.
Собсна, вопрос, есть ли какие-то внятные статьи / книжки про такой подход управления? Мне он абсолютно не понятен и я вижу узкие стороны, когда рассказываю руководству, им все кажется норм (но это люди, которые в контексте продукта 2+ лет). Хочу либо понять, чем же этот подход хорош, либо научиться указывать на его слабые стороны с хорошими аргументами, чтобы продать уже наконец в нашем отделе хотя бы планирования с командой и цели на спринт.
Сам я разработчик с бэкграундом скрам мастера в предыдущих командах. Размер отдела порядка 50 чел, 3 больших руководителя и еще 5-6 под ними в командах

Всем привет, уже когда-то был в этом чатике, пришел с вопросом :)
У меня в команде и на самом деле во всем отделе практикуют one-on-one management, планирований на команду нет, есть планирование руководителей, есть только стендапы команды, на которых все рассказывают чем занимались, но выглядит довольно бесполезным, так как никто до конца не имеет чужого контекста. Спринтов нет, целей на спринты нет, раз в неделю на 1-1 обсуждаются индивидуальные задачи и если остается время — фидбек.
Собсна, вопрос, есть ли какие-то внятные статьи / книжки про такой подход управления? Мне он абсолютно не понятен и я вижу узкие стороны, когда рассказываю руководству, им все кажется норм (но это люди, которые в контексте продукта 2+ лет). Хочу либо понять, чем же этот подход хорош, либо научиться указывать на его слабые стороны с хорошими аргументами, чтобы продать уже наконец в нашем отделе хотя бы планирования с командой и цели на спринт.
Сам я разработчик с бэкграундом скрам мастера в предыдущих командах. Размер отдела порядка 50 чел, 3 больших руководителя и еще 5-6 под ними в командах

я бы начал с книги Лебедь рак и щука
но если у них задача работать работу - то ничего вы не сделаете
нужно найти 3-4 человека которые хотят работать в команде и попробовать выбить для них новые условия работы
потом будут доводы и кпай и прочее
но могут из вас сделать козлов отпущения - забросать задачами и все

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

Он скорее кустарный и появившийся опытным путем за десятилетие, руководители в отделе это когда-то разработчики, скорее всего без глубокого понимания менеджерских практик

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

Всем привет, уже когда-то был в этом чатике, пришел с вопросом :)
У меня в команде и на самом деле во всем отделе практикуют one-on-one management, планирований на команду нет, есть планирование руководителей, есть только стендапы команды, на которых все рассказывают чем занимались, но выглядит довольно бесполезным, так как никто до конца не имеет чужого контекста. Спринтов нет, целей на спринты нет, раз в неделю на 1-1 обсуждаются индивидуальные задачи и если остается время — фидбек.
Собсна, вопрос, есть ли какие-то внятные статьи / книжки про такой подход управления? Мне он абсолютно не понятен и я вижу узкие стороны, когда рассказываю руководству, им все кажется норм (но это люди, которые в контексте продукта 2+ лет). Хочу либо понять, чем же этот подход хорош, либо научиться указывать на его слабые стороны с хорошими аргументами, чтобы продать уже наконец в нашем отделе хотя бы планирования с командой и цели на спринт.
Сам я разработчик с бэкграундом скрам мастера в предыдущих командах. Размер отдела порядка 50 чел, 3 больших руководителя и еще 5-6 под ними в командах

Кстати из-за того, что так построена вся система доверху, у руклей начиная с тимлидов уже почти нет времени на код и подумать, там 5-7 часов встреч в день

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

Даже если ты 100 проблем обозначишь, не факт, что они не будут проблемами только для тебя.

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

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

Проблема в очень медленной доставке, в низком уровне осведомленности о чужой работе у рядовых специалистов, не сеньоров или тимлидов

Проблема в очень медленной доставке, в низком уровне осведомленности о чужой работе у рядовых специалистов, не сеньоров или тимлидов

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