Рано или поздно любая организация начинает выдавать в качестве продукта свою организационную диаграмму, и Windows не исключение. У open source нет такой проблемы.
Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
На самом деле, в статье очень много анти-паттернов управления продуктами и проектами.
Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
В моем случае это было порядка 10 лет назад.
Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.
Причем, для некоторых проблем я не вижу решения даже сейчас.
Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
И за что минусуете человека? Имеете опыт безболезненного переписывания драйверов под Vista? В статье же не зря упоминаются судебные процессы — очень похоже было на зачистку поля под Security Essentials.
Очень полезный экскурс в историю и отличный перевод!
Не имею отношения к MS, но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.
Амбициозные планы, от которых отваливаются громадные куски на 2-м или 3-м году…
Промежуточные релизы текущих версий, на которые оттягивается половина команды…
Интеграция, требующая в 3-е больше ресурсов, чем разработка…
Процедура апдейта и миграции данных пишется в последний момент…
Впихивание мега-фич ближе к концу (все равно уж опаздываем)…
Ностальгия :-)
Как раз фейлы таких мега-проектов и способствовали развитию Agile — они объективно перестали срастаться.
Я бы пошел во вторую — выстраивать процессы.
А разработчикам посоветовал бы идти в первую. Т.к. по моим внутренним убеждениям, при прочих равных она выиграет в долгосрочной перспективе. Технический долг сказывается на дистанции, я бы предположил, что во второй команде он выше.
Предлагаю сходу не слушать Scrum консультантов и прочих паразитирующих на профессии людей
На всякий случай, я не отношусь к консультантам, но понимаю, как они позволяют экономить время и деньги, избегая «детских» ошибок и разочарования (конечно, речь идет о достойных).
Если Ваша компания готова спонсировать эксперименты по внедрению Скрама своими силами (или любые другие) — отлично!
Много знаете спортсменов-профессионалов, которые обходятся без тренера? А любители вполне себе могут.
P.S.
Видео и в самом деле интересное, спасибо за ссылку.
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама.
Отлично, если Вы ее достигли (с точки зрения читателей).
Я просто обозначил свой интерес и обратил внимание на пару моментов:
1. Ваша интерпретация Скрама отличается от канонической версии (которая изложена в Скрам Гайде). Это включает понимание ролей и взаимодействия между ними в Скрам-команде.
2. Большое внимание уделено тому, как «продать» Скрам менеджменту, но очень мало внимание уделяется команде (только про преодоление сопротивления). Если проблемы, обозначенные в начале, были решены, команда должна быть счастлива. Разве нет?
В первой наделал много ошибок, потом исправлял, набил шишки. Во второй, где работаю по сей день, внедрил скрам вполне успешно...
Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать. С моей точки зрения, было бы гораздо интереснее и полезнее.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Можно ссылочку на такого рода исследования?
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.
У меня нет оснований сомневаться, что Вы успешно внедрили скрам в своей компании.
Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики. Вероятно, у них тоже не зашел vanilla-scrum… Но наверняка есть все ритуалы, чтобы считать скрам внедренным.
Признаться, я не по почувствовал, что это личный опыт — больше похоже на конспект книги или тренинга.
В небольших компаниях(до 50 человек) я предпочитаю идти вплоть до директора.
Это какой-то тиражируемый опыт внедрения Скрама в разных компаниях? И каждый раз мы приходим как технарь? При наличии компетенций, знаний и практического опыта внедрения скрама?
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
скрам-мастер — это менеджер
Скрам-мастер — это лидер, а не менеджер. И рычагами влияния он должен пользоваться как лидер.
И на одном из стендапов этот техлид заявляет, что он занимается задачей с низким приоритетом, хотя по доске видно, что есть задачи и поважнее в спринте. Согласно правилам, вы должны попросить его переключиться на более приоритетную задачу.
Да ладно? Вот так прямо скрам-мастер начал распределять задачи в команде?
Да, и если уж вы решили внедрять скрам самостоятельно, в дополнение к чтению книг и просмотру курсов:
К сожалению, у меня нет MS Project на домашнем ноутбуке и нет желания его ставить только для того, чтобы посмотреть на этот проект.
Поэтому сужу только по картинкам.
Да, согласен, что вопрос был не о бюджете проекта, а ФОТ на разработку.
Мое мнение, что выделенный прожект менеджер на команду такого размера — избыточен.
Я бы сказал, что максимум он должен быть утилизирован на четверть (если у него ставка на уровне ведущего разработчика).
Если предполагать, что во время «простоев» люди заняты на других проектах, то возникают «паразитные зависимости» между проектами и переключения контекста.
По сути, нарушается ограничение Work in progress для команды.
Там погрешность в 10% уже становится существенной (скажем, +10% на фазу разработки в одном проекте, -10% во втором, и фазы тестирования в них наложились; или на оборот — фазы разбежались и тестировщики простаивают).
Синхронизовать несколько параллельных проектов, особенно если у каждого из них свой менеджер, гораздо более творческая задача, чем оптимизировать загрузку на одном так, чтобы сократить общее время проекта и снизить накладные расходы.
Я не спорю, возможно кому-то этот темплейт проектного плана и принесет пользу (благо в самом начале четко описан контекст). Просто обращаю внимание на то, что я пытался бы оптимизировать.
Я правильно понимаю, что на прожект менеджера уходит примерно треть бюджета проекта?
При том, что риски проекта 10% — т.е. он достаточно линейный и корректирующих действий особо не требуется?
Фазы проектов не пересекаются (скажем, составление и ревью тест-планов/ПМИ может идти параллельно с разработкой при наличии спецификаций).
Т.е. план не оптимален с точки зрения загрузки ресурсов и сроков поставки, а значит и бюджета проекта.
Автор статьи тоже ценит своих сотрудников, и поэтому не делает контр-офферов.
При работающих механизмах оценки и пересмотра компенсаций, зарплаты команд находятся в равновесном состоянии — т.е. соответствуют «пользе», которую приносят сотрудники.
Оффер на большую з.п. — это может быть не рынок, а аномалия (ну вот не получит Ася такое предложение от любых других компаний, только здесь и сейчас).
Повышая Асе зарплату, мы выводим систему из равновесия — несправедливость по отношению к команде.
Был у меня такой случай.
Собеседовали кандидата, сделали оффер, но он остался на старом месте — зарплату повысили заметно. А через 3 месяца платить перестали — у компании деньги кончились. Это рынок или демпинг?
Не имею отношения к Яндексу и не знаю его внутренней «кухни», но предполагаю (экстраполируя другие крупные комании):
— зарплаты всех сотрудников пересматриваются минимум раз в год (не всем повышают, но обсуждают со всеми);
— кроме зарплаты компании есть что предложить сотруднику (бренд, стабильность, не декларативная, а реальная возможность обучения, развития и карьерного роста и т.п.).
Т.ч. думаю, что с учетом всех факторов Яндекс платит справедливые (т.е. рыночные, а не максимальные) зарплаты сотрудникам. И даже если кого-то берут по «двойному тарифу» то через пару лет оно приходит в равновесие с остальными сотрудниками.
Неужели другое отношение где-то сильно распространено?
Да, в компаниях со зрелыми процессами оценки персонала может быть даже двойной контроль:
Раз в 6-12 месяцев руководитель спрашивает напрямую о желаемом размере компенсации
Анонимный опрос сотрудников о возможных причинах ухода из компании
Конечно, речь о рынке труда с высокой конкуретностью и достаточно крупных компаниях (скажем, IT компания в Москве с достаточным ФОТ от 100 человек). Иногда предлагают сток-опции вместо зарплаты (но это, опять же, компенсационный пакет).
В противном случае так и бывает — повышение зарплаты через контр-офферы («чел получал 600, написал заяву, ему предложили 800»).
Я полностью согласен с основной мыслью статьи: в компаниях с конкурентными зарплатами, грамотными пипл-менеджерами, зрелыми процессами оценки персонала и моделью компенсации, привязанной к этой оценке и анализу рынка труда (приоритеты каждый расставит самостоятельно) необходимость контр-офферов возникает редко.
Есть ровно один вопрос — если вы готовы хантить по «двойным тарифам», почему зазорно противодействовать такому хантигу? Петю все устраивало, пока ему не предложили +25% к зарплате. Отпустим и схантим Васю за +50%?
Скажите, пожалуйста, а в курсе есть какая-то специфика именно для команд разработки?
Или это просто универсальный курс «Руководитель», который позиционируется для определенной аудитории?
Спасибо!
А почему вообще было принято решение организовать одну распределенную команду, а не 2 несвязанные?
Кто (или что) мешает разделить зоны ответственности и отпустить каждую из команд в автономное плавание? Если нет потребности во взаимодействии, то и регулярные коммуникации перестают быть необходимыми.
Я наблюдал скрам-команды, которые были не только кросс-функциональными, но и кросс-региональными. И мне они не показались особо эффективными, в первую очередь, по причине отсутствия командного духа и взаимопомощи. Я бы предпочел «распилить» команды по локациям.
Продаж чего и в каком сегменте?
Если холодные звонки так важны, почему их часто отдают на аутсорсинг или вообще используют ботов?
Массовые продажи не только в ларьках, но и в интернете вполне себе обходятся без холодных звонков — слишком дорогой инструмент для розницы со сделками на небольшие суммы.
Во в целом, это офф-топик к вопросу KPI, не говоря уж про саму статью.
Вот так сразу целое направление Digital, когда человек исключается как промежуточное звено в продаже товаров или услуг, стало неактуальным?
Скажем, для подсчета NPS (Net Promoter Score) можно вполне себе обойтись без людей — именно по этой причине опрос встраивают в сам интерфейс.
Не так давно гремели «диванные войны» вокруг Кинопоиска, когда пользователям не понравились изменения. Оштрафовать всех разработчиков, приложивших руку?
Роли, артефакты, правила и события Скрама не подлежат
изменению. При внедрении отдельных элементов данного фреймворка, полученный
результат не может называться Скрамом.
Авторы же не запрещают частичную имплементацию, им просто не нравится, когда ее называют скрамом.
Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
В моем случае это было порядка 10 лет назад.
Причем, для некоторых проблем я не вижу решения даже сейчас.
Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
Не имею отношения к MS, но в масштабных (200+ человеко-лет) проектах с моим участием примерно так и было.
Амбициозные планы, от которых отваливаются громадные куски на 2-м или 3-м году…
Промежуточные релизы текущих версий, на которые оттягивается половина команды…
Интеграция, требующая в 3-е больше ресурсов, чем разработка…
Процедура апдейта и миграции данных пишется в последний момент…
Впихивание мега-фич ближе к концу (все равно уж опаздываем)…
Ностальгия :-)
Как раз фейлы таких мега-проектов и способствовали развитию Agile — они объективно перестали срастаться.
А разработчикам посоветовал бы идти в первую. Т.к. по моим внутренним убеждениям, при прочих равных она выиграет в долгосрочной перспективе. Технический долг сказывается на дистанции, я бы предположил, что во второй команде он выше.
На всякий случай, я не отношусь к консультантам, но понимаю, как они позволяют экономить время и деньги, избегая «детских» ошибок и разочарования (конечно, речь идет о достойных).
Если Ваша компания готова спонсировать эксперименты по внедрению Скрама своими силами (или любые другие) — отлично!
Много знаете спортсменов-профессионалов, которые обходятся без тренера? А любители вполне себе могут.
P.S.
Видео и в самом деле интересное, спасибо за ссылку.
Отлично, если Вы ее достигли (с точки зрения читателей).
Я просто обозначил свой интерес и обратил внимание на пару моментов:
1. Ваша интерпретация Скрама отличается от канонической версии (которая изложена в Скрам Гайде). Это включает понимание ролей и взаимодействия между ними в Скрам-команде.
2. Большое внимание уделено тому, как «продать» Скрам менеджменту, но очень мало внимание уделяется команде (только про преодоление сопротивления). Если проблемы, обозначенные в начале, были решены, команда должна быть счастлива. Разве нет?
Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать. С моей точки зрения, было бы гораздо интереснее и полезнее.
Можно ссылочку на такого рода исследования?
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.
У меня нет оснований сомневаться, что Вы успешно внедрили скрам в своей компании.
Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики. Вероятно, у них тоже не зашел vanilla-scrum… Но наверняка есть все ритуалы, чтобы считать скрам внедренным.
Это какой-то тиражируемый опыт внедрения Скрама в разных компаниях? И каждый раз мы приходим как технарь? При наличии компетенций, знаний и практического опыта внедрения скрама?
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
Скрам-мастер — это лидер, а не менеджер. И рычагами влияния он должен пользоваться как лидер.
Да ладно? Вот так прямо скрам-мастер начал распределять задачи в команде?
Да, и если уж вы решили внедрять скрам самостоятельно, в дополнение к чтению книг и просмотру курсов:
Поэтому сужу только по картинкам.
Да, согласен, что вопрос был не о бюджете проекта, а ФОТ на разработку.
Мое мнение, что выделенный прожект менеджер на команду такого размера — избыточен.
Я бы сказал, что максимум он должен быть утилизирован на четверть (если у него ставка на уровне ведущего разработчика).
Если предполагать, что во время «простоев» люди заняты на других проектах, то возникают «паразитные зависимости» между проектами и переключения контекста.
По сути, нарушается ограничение Work in progress для команды.
Там погрешность в 10% уже становится существенной (скажем, +10% на фазу разработки в одном проекте, -10% во втором, и фазы тестирования в них наложились; или на оборот — фазы разбежались и тестировщики простаивают).
Синхронизовать несколько параллельных проектов, особенно если у каждого из них свой менеджер, гораздо более творческая задача, чем оптимизировать загрузку на одном так, чтобы сократить общее время проекта и снизить накладные расходы.
Я не спорю, возможно кому-то этот темплейт проектного плана и принесет пользу (благо в самом начале четко описан контекст). Просто обращаю внимание на то, что я пытался бы оптимизировать.
При том, что риски проекта 10% — т.е. он достаточно линейный и корректирующих действий особо не требуется?
Фазы проектов не пересекаются (скажем, составление и ревью тест-планов/ПМИ может идти параллельно с разработкой при наличии спецификаций).
Т.е. план не оптимален с точки зрения загрузки ресурсов и сроков поставки, а значит и бюджета проекта.
При работающих механизмах оценки и пересмотра компенсаций, зарплаты команд находятся в равновесном состоянии — т.е. соответствуют «пользе», которую приносят сотрудники.
Оффер на большую з.п. — это может быть не рынок, а аномалия (ну вот не получит Ася такое предложение от любых других компаний, только здесь и сейчас).
Повышая Асе зарплату, мы выводим систему из равновесия — несправедливость по отношению к команде.
Был у меня такой случай.
Собеседовали кандидата, сделали оффер, но он остался на старом месте — зарплату повысили заметно. А через 3 месяца платить перестали — у компании деньги кончились. Это рынок или демпинг?
— зарплаты всех сотрудников пересматриваются минимум раз в год (не всем повышают, но обсуждают со всеми);
— кроме зарплаты компании есть что предложить сотруднику (бренд, стабильность, не декларативная, а реальная возможность обучения, развития и карьерного роста и т.п.).
Т.ч. думаю, что с учетом всех факторов Яндекс платит справедливые (т.е. рыночные, а не максимальные) зарплаты сотрудникам. И даже если кого-то берут по «двойному тарифу» то через пару лет оно приходит в равновесие с остальными сотрудниками.
Да, в компаниях со зрелыми процессами оценки персонала может быть даже двойной контроль:
Конечно, речь о рынке труда с высокой конкуретностью и достаточно крупных компаниях (скажем, IT компания в Москве с достаточным ФОТ от 100 человек). Иногда предлагают сток-опции вместо зарплаты (но это, опять же, компенсационный пакет).
В противном случае так и бывает — повышение зарплаты через контр-офферы («чел получал 600, написал заяву, ему предложили 800»).
Есть ровно один вопрос — если вы готовы хантить по «двойным тарифам», почему зазорно противодействовать такому хантигу? Петю все устраивало, пока ему не предложили +25% к зарплате. Отпустим и схантим Васю за +50%?
Или это просто универсальный курс «Руководитель», который позиционируется для определенной аудитории?
Спасибо!
А почему вообще было принято решение организовать одну распределенную команду, а не 2 несвязанные?
Кто (или что) мешает разделить зоны ответственности и отпустить каждую из команд в автономное плавание? Если нет потребности во взаимодействии, то и регулярные коммуникации перестают быть необходимыми.
Я наблюдал скрам-команды, которые были не только кросс-функциональными, но и кросс-региональными. И мне они не показались особо эффективными, в первую очередь, по причине отсутствия командного духа и взаимопомощи. Я бы предпочел «распилить» команды по локациям.
Продаж чего и в каком сегменте?
Если холодные звонки так важны, почему их часто отдают на аутсорсинг или вообще используют ботов?
Массовые продажи не только в ларьках, но и в интернете вполне себе обходятся без холодных звонков — слишком дорогой инструмент для розницы со сделками на небольшие суммы.
Во в целом, это офф-топик к вопросу KPI, не говоря уж про саму статью.
Скажем, для подсчета NPS (Net Promoter Score) можно вполне себе обойтись без людей — именно по этой причине опрос встраивают в сам интерфейс.
Не так давно гремели «диванные войны» вокруг Кинопоиска, когда пользователям не понравились изменения. Оштрафовать всех разработчиков, приложивших руку?
Авторы же не запрещают частичную имплементацию, им просто не нравится, когда ее называют скрамом.