Чтобы не зарыться в оптимизации, можно держать в голове старое правило интеграторов: "не следует одновременно менять процесс и инструмент".
Типичная ошибка состоит в том, что с рукописных заметок или списка заметок в блокноте хочется перейти в "систему" в Obsidian, т. е. менять и процесс и инструмент сразу, и получается когнитивная перегрузка и плохой результат.
Так как обычно до перехода на Obsidian используют более простые или менее гибкие инструменты, можно сначала перенести текущий процесс, даже если это просто список заметок по папкам. В моем случае это были заметки + списки дел, т. е. сменился инструмент.
Теперь можно менять процесс. У любого инструмента есть свои типичные сильные фишки. Можно смотреть гайды, но мне помогло просто открыть топ-20 плагинов по популярности: в любой такой экосистеме топ плагинов закрывает самые типичные недостатки инструмента. За счет нескольких плагинов удалось поменять процесс и упростить навигацию, но понадобилось время на адаптацию, которое не всегда есть.
И так можно повторять до бесконечности, с минимальной когнитивной нагрузкой и максимальным эффектом.
Т. к. внешние ресурсы по трансформации, это скорее одноразовые (или хотя бы не постоянные) расходы, их бы оставил за скобками.
Про "15% от команды", попробую немного утрированный пример для иллюстрации
Вариант 1. Представим, что у нас нет команды вообще, а просто 10 человек в кабинетах получают задачу в Jira, делают и отдают дальше, и так 8 часов в день.
Вариант 2. "10 человек час в день общаются, а 7 часов в день делают задачу, зная, как это влияет на другого коллегу и как выглядит результат в целом, и получают ответы на вопросы сразу".
1/8 это 12.5% времени, но я не верю, что по первому сценарию результат будет лучше второго. И даже если добавить в Вариант 1 11го человека - тоже.
По сути, любой адекватный коллектив будет общаться и тратить на это некоторое не нулевое время, но если пустить на самотек - тот, кто стесняется говорить или задавать вопросы - рискует закопаться и пойти не туда (опять же, будучи прекрасным специалистом). И все эти "ритуальные" точки синхронизации - дают площадку, помогающую всем вовремя получить ответы на вопросы и скорректировать курс. Т. е. не являются потерями, эти коммуникации так и иначе бы случились, только без расписания были бы рыхлыми, менее структурными и несвоевременными.
Так что, прирастить команду на 40% без хорошей культуры взаимодействия внутри и вовне - как по мне, может вообще дать отрицательный прирост поставки ценных результатов, зато будет распыление фокуса и велосипедостроение.
А в команде с хорошей коммуникацией - и Scrum мастер будет ролью, а не должностью, и дейлики по 15 минут, и демо будут укладываться в 45-60, и ретро будут продуктивными как коллективная деятельность, а не пустая коммуникация.
При этом, я, субъективно не очень хорошо отношусь конкретно к Scrum из-за ригидности подхода (излишняя ритуализация, вырождение "целей спринта" во многих случаях), и по факту в жизни для меня лучше работали гибриды Kanban-а и классического проектного управления.
Все разговоры про scrum, kanban,... и ускорение от них, они скорее про 2 простых момента:
Не переставать делать того, что нам нужно и полезно (краткосрочно и долгосрочно)
Не делать того, что нам вредно (краткосрочно и долгосрочно)
Если не следить за этими 2 вещами, поразительно быстро может оказаться, что 90-100% времени команда делает не то, ради чего она существует (несмотря на то, что продуктивность каждого формального хорошая), все от этого демотивируются, падает продуктивность и пр.
Тот же Scrum это просто вариация короткого цикла обратной связи и качественного фокуса на задаче, который помогает не распыляться и быстро выводить на рынок новые продукты или функции продуктов.
Поэтому полезность этих 15% стоит оценивать именно в этом ключе. Я видел ситуации, когда команда продуктивно работала над демкой полгода, позвала заказчика на демо, и оказалось, что 80% сделано неверно, т. е. 80% времени фактически было потрачено впустую, и несколько % на демки заказчику каждые 2 недели спасли бы ситуацию, и в итоге был значительно лучший результат.
В идеальном процессе разработки в вакууме, классическая разработка по лекалам PMBoK в до-Agile редакции дает оптимальную скорость и результат. Однако по факту, если вот так ритуалами не сгонять вместе бизнес и команду, обычно оказывается та самая 10-20% эффективность, поверх которой Scrum может писать про 800% улучшения.
Если условный Scrum дал 10% прирост (потребляя дополнительное время на себя) - это зачастую означает, банально, что люди в команде уже достаточно хорошо общались и адекватно работали с целеполаганием, и уже до этого показывали хорошую продуктивность.
Мне кажется, в описанном сценарии несколько упускается фактор роста и постепенного дрифта команды. Каждый новый член команды добавляет что-то свое и приносит уникальные знания. Если решение принимают 1-2 человека (притом, именно они, обычно, и принимают решение о найме новичка), они будут открыты к его мнению, и будет легко привнести новое. С другой стороны, переубедить пачку коллег новичку сложнее, и выше шанс, что его голос не услышат и он будет демотивирован, в результате команды с полностью коллегиальным принятием решений часто скатываются в ригидность, вытесняя "не таких, как мы" еще на старте.
Получается вопрос "как не демотивировать новичка и улучшать экспертизу с каждым наймом".
У Рэя Далио в "Принципах" есть хорошая концепция "idea meritocracy", которая в описанной ситуации находится между вариантами 2 и 3, упрощенно сводящаяся к тому, что голос тех, кто может привнести конкретные подтверждения аргументов, экспертизу плюс брать на себя ответственность за принятие решений - весит больше, и это правильно. Есть разные формальные и неформальные способы это измерять, главное, чтобы было прозрачным для команды (для команд человек по 10, по моему опыту, можно еще держать на ручном приводе, дальше надо немного формализовать, либо дробить команду, чтобы оставлять ручной вариант)
В результате, обычно получается примерно следующая стабильная схема:
Решение по каждому вопросу принимают 2-4 человека, не больше. Для разных тем - это разные люди. Поэтому скорость не сильно хуже единоличных решений. Т. е. "коллегий" - несколько, а не одна, и решает не "сеньорность", а знания по конкретной теме
Обычно один из них - тимлид или техлид, чей голос по умолчанию весит "как у всех", но который имеет право выбирать решение при прочих равных, чтобы избегать затягивания и споров. И здесь как раз помогает формальная иерархия, чтобы это не вызывало сопротивления
При найме новых членов команды сразу думаем, в каких зонах принятия решений они претендуют на участие в процессе (если "никаких", то зачем нанимать?), и представляем другим членам команды сразу в этом аспекте. Любой новый член команды по умолчанию включен в принятие каких-то решений, если это не стажер. Для джуна его наставник выявляет будущую роль в рамках плана развития
При росте и делении команд сразу используем эти знания, чтобы сохранить хороший баланс экспертизы и не замкнуть на тимлиде/техлиде все решения в новой команде
тимлид — это руководитель команды сотрудников с одинаковой ролью
Нормой, по ощущению, сейчас являются, скорее, кросс-функциональные команды в стиле Team Topologies, т. е. типичный тимлид и в небольшой, и в крупной компании будет руководить командной инженеров (разработчики разных специализаций, тестировщики, иногда аналитики). Как следствие, техлидом он может быть в одной из этих специализаций, но не всех.
самый распространенный и правильный путь в тимлиды — сначала дорасти до уровня сеньора и только потом метить на руководящую должность
Хороший senior часто I-shaped специалист - очень крутой в своей области. Делать его тимлидом = снижать продуктивность команды, потому что самый лучший специалист не будет работать по специальности большую часть времени. Когда мы переключаемся с individual contributor на management трек, важна насмотренность и адекватный (middle и выше) уровень владения технологиями в сочетании с навыками коммуникации и управления. А для роста дальше - важно принимать, что в твоей команде по какому-то вопросу всегда найдется кто-то круче тебя, и если такого человека в команде нет - слишком много замкнуто на тимлида и расти не получится.
Поэтому, оптимально в районе миддла уже понимать целевую траекторию роста, чтобы смотреть на то, что делаешь, шире, чем просто "код и технологии".
Мне кажется, очень многое "в командах есть" тут принято за константу. В большинстве знакомых мне команд, где есть аналитики - нет ни продакт овнера, ни платформ овнера. Есть тимлиды, разработка-тестирование, бизнес-заказчики и архитекторы в объеме 1 штука на 5-10 команд. При этом, большинство бизнес-сценариев охватывает несколько команд, и требуют trade-off анализа, кросс-анализа с другими задачами других бизнес-заказчиков и т п. В таком кейсе аналитик становится неким представителем от архитектора + бизнеса на уровне задач конкретной команды, и при этом по совсем сложным задачам - идет к архитектору. И в этом слое (кросскомандное взаимодействие для реализации бизнес-сценариев) не очень понимаю, как эту роль заменять. Если постоянно бегать к архитектору - он станет сразу бутылочным горлышком. Ну и аналогично, если есть product owner на несколько команд в дополнение к тимлиду - да, скорее всего он будет носить шапку аналитика и выделенной роли не будет нужно. Какая конфигурация оптимальнее - скорее всего зависит от конкретной организации и процессов.
Мне кажется, точнее будет сформулировать тезис в том виде, что существует целый ряд классов задач в разработке ПО, который требует определенной подготовки, опирающейся на математический аппарат уровня, как минимум, типичного 1-2 курса вуза, без которой они решены не будут или будут решены неоптимальным образом (сроки, потребляемые системные ресурсы, качество).
Нюансы в том, что:
Начиная с 3-4 курса доля этой "базы" становится существенно меньше, и различие между отчисленным с 3-4 курса и закончившим вуз по специальности, не сфокусированной на разработке ПО - в моей практике полностью в пользу отчисленных, если они получали стаж в то время, когда другие доучивались;
Замещающие даже 1-2 курс вещи все-таки есть, но это уже не краткосрочные курсы, а достаточно большие по объему и длительности (сотни часов);
В зависимости от проекта, 50-90% разработчиков сталкиваются с такими классами задач настолько редко, что этот фильтр для них избыточный;
Как сложность, так и самостоятельность исполнения курсовых работ и дипломов, как мне кажется, переоценена. Однажды, имея 3 недели свободного времени, написал другому человеку треть диплома по абсолютно не профильной для себя специальности с которой столкнулся впервые в жизни, и весь этот текст дошел до защиты без правок и изменений. ВУЗ очень способствует поиску решений, где социальный интеллект имеет преимущество перед изучаемыми навыками, что может не соответствовать ожиданиям к компетентному исполнителю.
"Обычно продакт начинает гадать, какие части можно отрезать, и узнавать, сколько это будет стоить" - здесь стоит определиться в ожиданиях от всех членов команды. Если есть ожидание, что каждый участник команды вовлечен в действия других, то и от продакта логично ожидать общего понимания технологических возможностей и ограничений в той мере, что это не будет гаданием. Если же вся экспертность переносится на разработку (высокоуровневые продуктовые задачи спускаются на автономную команду разработки) - есть высокая опасность, что продукт будет создан не на основании ожиданий и потребностей пользователей, а на основании интерпретации этих потребностей людьми, которые с пользователями не общаются или почти не общаются. Долгосрочно, результат становится, обычно, все более оторванным от реальности.
Применял во взаимодействии с заказчиками BPMN, он существенно выигрывал в том числе на таких сценариях по нескольким причинам. Во-первых - лучше визуализируется ветвление процессов на основные и ошибочные пути, и можно показать все типовые ошибки. На диаграмме последовательности так сделать сложнее в силу линейности. Во-вторых - бизнесу схемы понятнее, и как только понимают иконки шлюзов (включающий, исключающий,....) - такая диаграмма очень легко становится понятной и нетехническому бизнес-заказчику, и технической команде. Для крупных сложных процессов - вне зависимости от типа схемы надо отделять блоки и подпроцессы, иначе схема будет размером с лист A1. В упомянутом кейсе с 4-6 сторонами, обычно оказывается, что есть 2-3 стороны основного процесса, а остальные живут в подпроцессах с четкими входами и выходами.
Чтобы не зарыться в оптимизации, можно держать в голове старое правило интеграторов: "не следует одновременно менять процесс и инструмент".
Типичная ошибка состоит в том, что с рукописных заметок или списка заметок в блокноте хочется перейти в "систему" в Obsidian, т. е. менять и процесс и инструмент сразу, и получается когнитивная перегрузка и плохой результат.
Так как обычно до перехода на Obsidian используют более простые или менее гибкие инструменты, можно сначала перенести текущий процесс, даже если это просто список заметок по папкам. В моем случае это были заметки + списки дел, т. е. сменился инструмент.
Теперь можно менять процесс. У любого инструмента есть свои типичные сильные фишки. Можно смотреть гайды, но мне помогло просто открыть топ-20 плагинов по популярности: в любой такой экосистеме топ плагинов закрывает самые типичные недостатки инструмента. За счет нескольких плагинов удалось поменять процесс и упростить навигацию, но понадобилось время на адаптацию, которое не всегда есть.
И так можно повторять до бесконечности, с минимальной когнитивной нагрузкой и максимальным эффектом.
Т. к. внешние ресурсы по трансформации, это скорее одноразовые (или хотя бы не постоянные) расходы, их бы оставил за скобками.
Про "15% от команды", попробую немного утрированный пример для иллюстрации
Вариант 1. Представим, что у нас нет команды вообще, а просто 10 человек в кабинетах получают задачу в Jira, делают и отдают дальше, и так 8 часов в день.
Вариант 2. "10 человек час в день общаются, а 7 часов в день делают задачу, зная, как это влияет на другого коллегу и как выглядит результат в целом, и получают ответы на вопросы сразу".
1/8 это 12.5% времени, но я не верю, что по первому сценарию результат будет лучше второго. И даже если добавить в Вариант 1 11го человека - тоже.
По сути, любой адекватный коллектив будет общаться и тратить на это некоторое не нулевое время, но если пустить на самотек - тот, кто стесняется говорить или задавать вопросы - рискует закопаться и пойти не туда (опять же, будучи прекрасным специалистом). И все эти "ритуальные" точки синхронизации - дают площадку, помогающую всем вовремя получить ответы на вопросы и скорректировать курс. Т. е. не являются потерями, эти коммуникации так и иначе бы случились, только без расписания были бы рыхлыми, менее структурными и несвоевременными.
Так что, прирастить команду на 40% без хорошей культуры взаимодействия внутри и вовне - как по мне, может вообще дать отрицательный прирост поставки ценных результатов, зато будет распыление фокуса и велосипедостроение.
А в команде с хорошей коммуникацией - и Scrum мастер будет ролью, а не должностью, и дейлики по 15 минут, и демо будут укладываться в 45-60, и ретро будут продуктивными как коллективная деятельность, а не пустая коммуникация.
При этом, я, субъективно не очень хорошо отношусь конкретно к Scrum из-за ригидности подхода (излишняя ритуализация, вырождение "целей спринта" во многих случаях), и по факту в жизни для меня лучше работали гибриды Kanban-а и классического проектного управления.
Так считать в лоб - слишком грубое упрощение.
Все разговоры про scrum, kanban,... и ускорение от них, они скорее про 2 простых момента:
Не переставать делать того, что нам нужно и полезно (краткосрочно и долгосрочно)
Не делать того, что нам вредно (краткосрочно и долгосрочно)
Если не следить за этими 2 вещами, поразительно быстро может оказаться, что 90-100% времени команда делает не то, ради чего она существует (несмотря на то, что продуктивность каждого формального хорошая), все от этого демотивируются, падает продуктивность и пр.
Тот же Scrum это просто вариация короткого цикла обратной связи и качественного фокуса на задаче, который помогает не распыляться и быстро выводить на рынок новые продукты или функции продуктов.
Поэтому полезность этих 15% стоит оценивать именно в этом ключе. Я видел ситуации, когда команда продуктивно работала над демкой полгода, позвала заказчика на демо, и оказалось, что 80% сделано неверно, т. е. 80% времени фактически было потрачено впустую, и несколько % на демки заказчику каждые 2 недели спасли бы ситуацию, и в итоге был значительно лучший результат.
В идеальном процессе разработки в вакууме, классическая разработка по лекалам PMBoK в до-Agile редакции дает оптимальную скорость и результат. Однако по факту, если вот так ритуалами не сгонять вместе бизнес и команду, обычно оказывается та самая 10-20% эффективность, поверх которой Scrum может писать про 800% улучшения.
Если условный Scrum дал 10% прирост (потребляя дополнительное время на себя) - это зачастую означает, банально, что люди в команде уже достаточно хорошо общались и адекватно работали с целеполаганием, и уже до этого показывали хорошую продуктивность.
Мне кажется, в описанном сценарии несколько упускается фактор роста и постепенного дрифта команды. Каждый новый член команды добавляет что-то свое и приносит уникальные знания. Если решение принимают 1-2 человека (притом, именно они, обычно, и принимают решение о найме новичка), они будут открыты к его мнению, и будет легко привнести новое. С другой стороны, переубедить пачку коллег новичку сложнее, и выше шанс, что его голос не услышат и он будет демотивирован, в результате команды с полностью коллегиальным принятием решений часто скатываются в ригидность, вытесняя "не таких, как мы" еще на старте.
Получается вопрос "как не демотивировать новичка и улучшать экспертизу с каждым наймом".
У Рэя Далио в "Принципах" есть хорошая концепция "idea meritocracy", которая в описанной ситуации находится между вариантами 2 и 3, упрощенно сводящаяся к тому, что голос тех, кто может привнести конкретные подтверждения аргументов, экспертизу плюс брать на себя ответственность за принятие решений - весит больше, и это правильно. Есть разные формальные и неформальные способы это измерять, главное, чтобы было прозрачным для команды (для команд человек по 10, по моему опыту, можно еще держать на ручном приводе, дальше надо немного формализовать, либо дробить команду, чтобы оставлять ручной вариант)
В результате, обычно получается примерно следующая стабильная схема:
Решение по каждому вопросу принимают 2-4 человека, не больше. Для разных тем - это разные люди. Поэтому скорость не сильно хуже единоличных решений. Т. е. "коллегий" - несколько, а не одна, и решает не "сеньорность", а знания по конкретной теме
Обычно один из них - тимлид или техлид, чей голос по умолчанию весит "как у всех", но который имеет право выбирать решение при прочих равных, чтобы избегать затягивания и споров. И здесь как раз помогает формальная иерархия, чтобы это не вызывало сопротивления
При найме новых членов команды сразу думаем, в каких зонах принятия решений они претендуют на участие в процессе (если "никаких", то зачем нанимать?), и представляем другим членам команды сразу в этом аспекте. Любой новый член команды по умолчанию включен в принятие каких-то решений, если это не стажер. Для джуна его наставник выявляет будущую роль в рамках плана развития
При росте и делении команд сразу используем эти знания, чтобы сохранить хороший баланс экспертизы и не замкнуть на тимлиде/техлиде все решения в новой команде
Нормой, по ощущению, сейчас являются, скорее, кросс-функциональные команды в стиле Team Topologies, т. е. типичный тимлид и в небольшой, и в крупной компании будет руководить командной инженеров (разработчики разных специализаций, тестировщики, иногда аналитики). Как следствие, техлидом он может быть в одной из этих специализаций, но не всех.
Хороший senior часто I-shaped специалист - очень крутой в своей области. Делать его тимлидом = снижать продуктивность команды, потому что самый лучший специалист не будет работать по специальности большую часть времени. Когда мы переключаемся с individual contributor на management трек, важна насмотренность и адекватный (middle и выше) уровень владения технологиями в сочетании с навыками коммуникации и управления. А для роста дальше - важно принимать, что в твоей команде по какому-то вопросу всегда найдется кто-то круче тебя, и если такого человека в команде нет - слишком много замкнуто на тимлида и расти не получится.
Поэтому, оптимально в районе миддла уже понимать целевую траекторию роста, чтобы смотреть на то, что делаешь, шире, чем просто "код и технологии".
Мне кажется, очень многое "в командах есть" тут принято за константу. В большинстве знакомых мне команд, где есть аналитики - нет ни продакт овнера, ни платформ овнера. Есть тимлиды, разработка-тестирование, бизнес-заказчики и архитекторы в объеме 1 штука на 5-10 команд. При этом, большинство бизнес-сценариев охватывает несколько команд, и требуют trade-off анализа, кросс-анализа с другими задачами других бизнес-заказчиков и т п. В таком кейсе аналитик становится неким представителем от архитектора + бизнеса на уровне задач конкретной команды, и при этом по совсем сложным задачам - идет к архитектору. И в этом слое (кросскомандное взаимодействие для реализации бизнес-сценариев) не очень понимаю, как эту роль заменять. Если постоянно бегать к архитектору - он станет сразу бутылочным горлышком. Ну и аналогично, если есть product owner на несколько команд в дополнение к тимлиду - да, скорее всего он будет носить шапку аналитика и выделенной роли не будет нужно. Какая конфигурация оптимальнее - скорее всего зависит от конкретной организации и процессов.
Мне кажется, точнее будет сформулировать тезис в том виде, что существует целый ряд классов задач в разработке ПО, который требует определенной подготовки, опирающейся на математический аппарат уровня, как минимум, типичного 1-2 курса вуза, без которой они решены не будут или будут решены неоптимальным образом (сроки, потребляемые системные ресурсы, качество).
Нюансы в том, что:
Начиная с 3-4 курса доля этой "базы" становится существенно меньше, и различие между отчисленным с 3-4 курса и закончившим вуз по специальности, не сфокусированной на разработке ПО - в моей практике полностью в пользу отчисленных, если они получали стаж в то время, когда другие доучивались;
Замещающие даже 1-2 курс вещи все-таки есть, но это уже не краткосрочные курсы, а достаточно большие по объему и длительности (сотни часов);
В зависимости от проекта, 50-90% разработчиков сталкиваются с такими классами задач настолько редко, что этот фильтр для них избыточный;
Как сложность, так и самостоятельность исполнения курсовых работ и дипломов, как мне кажется, переоценена. Однажды, имея 3 недели свободного времени, написал другому человеку треть диплома по абсолютно не профильной для себя специальности с которой столкнулся впервые в жизни, и весь этот текст дошел до защиты без правок и изменений. ВУЗ очень способствует поиску решений, где социальный интеллект имеет преимущество перед изучаемыми навыками, что может не соответствовать ожиданиям к компетентному исполнителю.
"Обычно продакт начинает гадать, какие части можно отрезать, и узнавать, сколько это будет стоить" - здесь стоит определиться в ожиданиях от всех членов команды. Если есть ожидание, что каждый участник команды вовлечен в действия других, то и от продакта логично ожидать общего понимания технологических возможностей и ограничений в той мере, что это не будет гаданием. Если же вся экспертность переносится на разработку (высокоуровневые продуктовые задачи спускаются на автономную команду разработки) - есть высокая опасность, что продукт будет создан не на основании ожиданий и потребностей пользователей, а на основании интерпретации этих потребностей людьми, которые с пользователями не общаются или почти не общаются. Долгосрочно, результат становится, обычно, все более оторванным от реальности.
Применял во взаимодействии с заказчиками BPMN, он существенно выигрывал в том числе на таких сценариях по нескольким причинам. Во-первых - лучше визуализируется ветвление процессов на основные и ошибочные пути, и можно показать все типовые ошибки. На диаграмме последовательности так сделать сложнее в силу линейности. Во-вторых - бизнесу схемы понятнее, и как только понимают иконки шлюзов (включающий, исключающий,....) - такая диаграмма очень легко становится понятной и нетехническому бизнес-заказчику, и технической команде. Для крупных сложных процессов - вне зависимости от типа схемы надо отделять блоки и подпроцессы, иначе схема будет размером с лист A1. В упомянутом кейсе с 4-6 сторонами, обычно оказывается, что есть 2-3 стороны основного процесса, а остальные живут в подпроцессах с четкими входами и выходами.