Согласитесь, некорректно рассматривать цельную картину выделяя промахи (ошибка члена команды с half life 2) и игнорируя победы (Steam сделала все та же компания с бирюзовой структурой и теми же членами команд). Какая бы ни было структура не была, ошибки возможны везде. Более того стратегическая ошибка незастрахованного разными мнениями и фасилитацией руководителя часто гораздо более фатальна чем ошибка одного члена команды с общим полем деятельности. Ну а заявлять отсутствие half life 3 следствием бирюзовости весьма спорная гипотеза и не более того.
В целом я предлагаю не путать теплое с мягким: процесс работы есть процесс работы, продуктовая стратегия есть продуктовая стратегия. Нету таких продуктов, которые могут создать только бирюзовые компании, а красные и оранжевые не могут and vice versa. Речь о том, что бирюзовая структура способна создать конкурентно способный продукт и не «продолбать все полимеры» не смотря на отсутствие привычной системы управления оранжевых компаний: эта система просто заменена другими, эквивалентными, но необычно выглядящими элементами
Я прошу обратить ваше внимание на то, что не утверждаю, что бирюзовая структура всему голова. Я лишь говорю, что при верном наборе ценностей и ground rules она работает и работает блестяще. Точно так же, как блестяще работает иерархическая структура в компании с другой моделью ценностей и гениальными руководителями во главе. И почему мы должны считать иерархическую структуру наиболее верной для меня не понятно: это лишь другой взгляд, с другими преимуществами и недостатками
Ну, есть несколько отличных примеров где плоская структура отлично справляется с обеспечением большого дохода для компании. Из IT компаний один из самых ярких примеров Valve. Ну помните наверно, Half-Life, Steam, Portal все прочие дела. Вот у этих вот ребят нету руководителей вообще на уровне всей организации целиком, а по уровню капитализации они весьма многим могут дать фору.
Во время работы это часто вызывает проблемы, потому что методология подразумевает встроенное решение любых проблем и вопросов. Я просто за то, чтобы сразу этого избегать, употребляя верные термины. Это мелочь, но каждое такое объяснение в рабочем процессе потихоньку стачивает мозг :)
Пожалуйста, уберите в статье слово методология отовсюду. Scrum — не методология, это framework. Методологий в Agile-mindset вообще дико мало. RUP, например.
Есть очень большая тема про треугольник project-managmenta, работу с заказчиком, разделение ответственности заказчика и исполнителя и прочая прочая. Эта тема достойна пожалуй вереницы статей, потому что это тема про боль и страдания современного it бизнеса :)
Если из этой большой темы выдернуть маленький кусочек который как то коррелирует с вашим описанием рабочего процесса, то можно сказать следующее. В целом да, в идеале бы так оно и было, но практика и даже теория pm'та говорит о том что невозможно зафиксировать scope работ, бюджет проекта и время выполнения одновременно так, чтобы проект был завершен успешно. Оттуда вытекают платные чейндж реквесты, fail сроков, быстрая трата денег с несделанным продуктом, несоответствие продукта и ожиданиям и так далее.
Scrum не про то, чтобы сделать команде хорошо и всё. Scrum — не фреймворк разработки, это фреймворк создания продуктов. Scrum больше про то, чтобы делать проекты успешными и заказчика довольным жизнью, а также обеспечивать востребованность продуктом. Работа команды и с командой это малая часть.
Очень хорошая статься, как повод углубиться в обсуждения преимуществ и недостатков. Я бы порекомендовал вам взять за шкирку челвека который уже пару лет занимается Scrum и обсудить с ним все аспекты. На втором уровне рассмотрения могут выползти другие недостатки, а текущие изящно решиться.
P.S. Статью можно уверенно назвать вбросом недели, комментарии читать не менее интересно чем саму статью. Вообще спорить тут не о чем: у тебя либо скрам работает либо нет, по разным причинам. Любо стоит исправить ситуацию и построить работу по нормальному либо отказаться от фреймворка. В конце концов есть очень много примеров где scrum не применим или не особо нужен.
Верно, общий. Для этого и существует этот документ: описать детали. Чтобы при произнесении словосочетания «менеджер продуктов» все одинаково понимали о какой именно роли идет речь.
Ну у каждой компании индивидуальный подход к работе и свои роли. Здесь же речь идет о вполне конкретной роли: о менеджере (читай владельце) продукта и роль эта описана очень даже правдоподобно.
Кто ж им запретит то в компьютер вносить. Они не являются гражданами РФ и в целом им без разницы какие у нас законы, таким образом это их дело как и где они будут хранить ифномрацию. А передачу информации в вербальной форме никто не запрещал, вроде как.
Это всего лишь одна из возможностей, я упомянул сразу, что она не имеет особого смысла. Мы это не используем, есть примеры когда это используют. Дело вкуса, метрика достаточно репрезентативна, но много граничных условий. Не всегда есть возможность вводить людей по одному с ожиданием в несколько итераций.
Я обязательно как-нибудь напишу длинную статью на это тему, могу в комментарии описать основные соображения в первом приближении. Не уверен, интересно ли будет это читать в таком сжатом виде.
У нас есть задача: определить KPI, по которым мы сможем измерять продуктивность отдельных разработчиков. Какие есть варианты: количество написанного кода, количество переписанного кода, количество багов, которые непонятно как считать в больших командах, время сколько открыта iDE и прочее. Не надо особо долго думать, чтобы понять, что это не сработает. Не буду расписывать почему, каждый разработчик поймет как можно удовлетворять критериям и при этом не работать вообще. Продолжая рассуждения можно прийти к выводу, что изолированно оценивать KPI разработчика невозможно.
Что важно для компании? Для компании важно заработать денег, чтобы их заработать надо делать полезный продукт (я работаю в продуктовой компании, поэтому аутсурс сейчас рассматривать не буду. Идеи там те же, но в профиль или в 3/4). Полезный продукт будут покупать, а продукт полезен тем value, который он привносит в решении проблем пользователей. И мы отталкиваемся именно от этого. Работа поделена на мелкие итерации, которые несут частицу value, наблюдаемую и измеримую. Объем каждой замеряется в SP (некие попугаи, специфичные для конкретных команд). В долгосрочной перспективе можно достаточно точно оценить изменение продуктивности при присоединении нового человека. Но эта оценка не так важна, нет никакого смысла мерить разработчика отдельно от команды. В конце концов разработчик работает по разному с субьективными для него «мудаками» и «няшками». Есть только возможности мерить его профессионализм с точки зрения кода и архитектуры и это делают на review кода, при необходимости вынося это в KPI человека (количество архитектурно-концептуальных исправлений при ревью, количество косметических исправлений и так далее).
А вот у команд есть вполне конкретные KPI (например, количество заваленных итерации на каждые пять/десять), их понятно как мерить и от них зависят напрямую деньги, которые получит компания. А команда саморегулируемый организм: если команда несет ответственность за результат и стремиться улучшить бизнес-KPI, то она первая начнет кричать о том, что в ее рядах есть человек плюющий в потолок. В конечном итоге наблюдают за этим процессом scrum master'а и их задача повышать и развивать самостоятельность команды и ее продуктивность.
Ну а вообще, коли мы тут говорим о зп изначально, то тут должен быть большой разговор не о KPI, а о том, почему мотивация деньгами не работает)
Наверно и компания моя живет в параллельной вселенной :). Если нет возможности оценивать продуктивности разработчиков (я не спорю, что это сложно, мы это решаем за счет командной кооперации), то компания, я извиняюсь, в жопе. Ну или разработчики в терроре начальников. Или начальники в терроре разработчиков.
Странно такое читать, в бюджетировании и продуктивности разработчиков есть вполне серьезные и конкретные процессы регулирования спорных вопросов.
Как, например, при приеме на работу продуктивность и знания разработчика оценивается уполномоченными специалистами компании, после чего существует испытательный срок для валидации KPI работника. В соответствии с этой оценкой сотруднику предлагается заработная плата, отражающая его продуктивность. И если от сотрудника требуют больше чем его оцененная заранее продуктивность, то это вина не сотрудника. Если же можно визуализировать процесс снижения продуктивности, то встает вопрос о компетентности сотрудника и изменении его компенсации. Здесь все честно и нету никакого шантажа или чего-то другого: просто прозрачный процесс регулирования бюджетов.
И напоследок, давайте будем честными: невозможно работать не отрываясь 8 часов в день. Никому, таких людей просто не существует. Будет и вконтактик и разговоры и чай/кофе. Не имеет смысла контролировать сотрудников на тему того что «а открыта ли у вас IDE в данный момент». Потому что все это выльется в то, что IDE будет открыта, но толку от этого не будет. И правда, пора на эту тему уже статьи писать.
Я думаю многочисленные конструкторы упомянули, не буду заострять внимание на них. Мне в детстве запомнились развивающие игры, например квадратные листки однотонные разрезанные на небольшое количество симметричных и асиметричных частей (их надо было собрать обратно). Отец, показывающий физические игровые эксперименты. Микроскоп. Набор химика с настоящими неопасными реактивами. Ну и, конечно, приставки.
В целом я предлагаю не путать теплое с мягким: процесс работы есть процесс работы, продуктовая стратегия есть продуктовая стратегия. Нету таких продуктов, которые могут создать только бирюзовые компании, а красные и оранжевые не могут and vice versa. Речь о том, что бирюзовая структура способна создать конкурентно способный продукт и не «продолбать все полимеры» не смотря на отсутствие привычной системы управления оранжевых компаний: эта система просто заменена другими, эквивалентными, но необычно выглядящими элементами
Я прошу обратить ваше внимание на то, что не утверждаю, что бирюзовая структура всему голова. Я лишь говорю, что при верном наборе ценностей и ground rules она работает и работает блестяще. Точно так же, как блестяще работает иерархическая структура в компании с другой моделью ценностей и гениальными руководителями во главе. И почему мы должны считать иерархическую структуру наиболее верной для меня не понятно: это лишь другой взгляд, с другими преимуществами и недостатками
Если из этой большой темы выдернуть маленький кусочек который как то коррелирует с вашим описанием рабочего процесса, то можно сказать следующее. В целом да, в идеале бы так оно и было, но практика и даже теория pm'та говорит о том что невозможно зафиксировать scope работ, бюджет проекта и время выполнения одновременно так, чтобы проект был завершен успешно. Оттуда вытекают платные чейндж реквесты, fail сроков, быстрая трата денег с несделанным продуктом, несоответствие продукта и ожиданиям и так далее.
Scrum не про то, чтобы сделать команде хорошо и всё. Scrum — не фреймворк разработки, это фреймворк создания продуктов. Scrum больше про то, чтобы делать проекты успешными и заказчика довольным жизнью, а также обеспечивать востребованность продуктом. Работа команды и с командой это малая часть.
P.S. Статью можно уверенно назвать вбросом недели, комментарии читать не менее интересно чем саму статью. Вообще спорить тут не о чем: у тебя либо скрам работает либо нет, по разным причинам. Любо стоит исправить ситуацию и построить работу по нормальному либо отказаться от фреймворка. В конце концов есть очень много примеров где scrum не применим или не особо нужен.
У нас есть задача: определить KPI, по которым мы сможем измерять продуктивность отдельных разработчиков. Какие есть варианты: количество написанного кода, количество переписанного кода, количество багов, которые непонятно как считать в больших командах, время сколько открыта iDE и прочее. Не надо особо долго думать, чтобы понять, что это не сработает. Не буду расписывать почему, каждый разработчик поймет как можно удовлетворять критериям и при этом не работать вообще. Продолжая рассуждения можно прийти к выводу, что изолированно оценивать KPI разработчика невозможно.
Что важно для компании? Для компании важно заработать денег, чтобы их заработать надо делать полезный продукт (я работаю в продуктовой компании, поэтому аутсурс сейчас рассматривать не буду. Идеи там те же, но в профиль или в 3/4). Полезный продукт будут покупать, а продукт полезен тем value, который он привносит в решении проблем пользователей. И мы отталкиваемся именно от этого. Работа поделена на мелкие итерации, которые несут частицу value, наблюдаемую и измеримую. Объем каждой замеряется в SP (некие попугаи, специфичные для конкретных команд). В долгосрочной перспективе можно достаточно точно оценить изменение продуктивности при присоединении нового человека. Но эта оценка не так важна, нет никакого смысла мерить разработчика отдельно от команды. В конце концов разработчик работает по разному с субьективными для него «мудаками» и «няшками». Есть только возможности мерить его профессионализм с точки зрения кода и архитектуры и это делают на review кода, при необходимости вынося это в KPI человека (количество архитектурно-концептуальных исправлений при ревью, количество косметических исправлений и так далее).
А вот у команд есть вполне конкретные KPI (например, количество заваленных итерации на каждые пять/десять), их понятно как мерить и от них зависят напрямую деньги, которые получит компания. А команда саморегулируемый организм: если команда несет ответственность за результат и стремиться улучшить бизнес-KPI, то она первая начнет кричать о том, что в ее рядах есть человек плюющий в потолок. В конечном итоге наблюдают за этим процессом scrum master'а и их задача повышать и развивать самостоятельность команды и ее продуктивность.
Ну а вообще, коли мы тут говорим о зп изначально, то тут должен быть большой разговор не о KPI, а о том, почему мотивация деньгами не работает)
Как, например, при приеме на работу продуктивность и знания разработчика оценивается уполномоченными специалистами компании, после чего существует испытательный срок для валидации KPI работника. В соответствии с этой оценкой сотруднику предлагается заработная плата, отражающая его продуктивность. И если от сотрудника требуют больше чем его оцененная заранее продуктивность, то это вина не сотрудника. Если же можно визуализировать процесс снижения продуктивности, то встает вопрос о компетентности сотрудника и изменении его компенсации. Здесь все честно и нету никакого шантажа или чего-то другого: просто прозрачный процесс регулирования бюджетов.
И напоследок, давайте будем честными: невозможно работать не отрываясь 8 часов в день. Никому, таких людей просто не существует. Будет и вконтактик и разговоры и чай/кофе. Не имеет смысла контролировать сотрудников на тему того что «а открыта ли у вас IDE в данный момент». Потому что все это выльется в то, что IDE будет открыта, но толку от этого не будет. И правда, пора на эту тему уже статьи писать.