Комментарии 25
Спасибо за материал. Отдельная благодарность за картинки — они очень наглядны. Надеюсь, вам удастся триумфально завершить процесс ( в частности, разобраться с реп-линками).
Спасибо! Там помимо реп-линков есть ещё более запутанный механизм кросс-линкинга, когда есть внутренняя и внешняя связь между кругами, находящимися на одной ступени холархии, но в разных суперкругах. Тоже очень интересная тема, взрывающая мозг. Если всё сложится, обязательно напишем. Если нет — ещё более обязательно.
А где на схеме реп-линк круга «сервис»?
В распределенных автономных корпорациях всё это работает автомагически!
Сколько у вас сотрудников?
На каком числе пришло понимание, что «всё стало плохо»?
Используете ли какие-то метрики, чтобы понимать, стало лучше или нет? Если да, то какие?
Плюс если не трудно — три главные проблемы, которые удалось решить, три, которые не удалось, и три, которые появились.
На каком числе пришло понимание, что «всё стало плохо»?
Используете ли какие-то метрики, чтобы понимать, стало лучше или нет? Если да, то какие?
Плюс если не трудно — три главные проблемы, которые удалось решить, три, которые не удалось, и три, которые появились.
Сейчас 78 сотрудников. У нас не было понимания, что «всё плохо», было понимание, что можно лучше и что пора подумать о будущем.
Пока холакратия работает на уровне сервиса, мы используем метрики сервиса: количество клиентов на обслуживании, количество отключений, NPS. Но вряд ли холакратия на них как-то заметно повлияет — это же внутренний инструмент, который нужен для того, чтобы не потерять коммуникации и лучше выявлять проблемы в растущем бизнесе.
А про проблемы мы в предпоследнем разделе публикации написали. Или вы про другие? Приведите пример.
Пока холакратия работает на уровне сервиса, мы используем метрики сервиса: количество клиентов на обслуживании, количество отключений, NPS. Но вряд ли холакратия на них как-то заметно повлияет — это же внутренний инструмент, который нужен для того, чтобы не потерять коммуникации и лучше выявлять проблемы в растущем бизнесе.
А про проблемы мы в предпоследнем разделе публикации написали. Или вы про другие? Приведите пример.
Похожие идеи описаны в книге «Management 3.0», Jurgen Appelo. Там автор тоже утверждает, что жесткие иерархии в мире IT не работают и будущее — за самоорганизующимися командами. Я пробую внедрять подобные вещи у себя на работе и уже имеется положительный эффект.
Василий, спасибо Вам и всей Кнопочной команде за эту прекрасную статью. Очень вдохновляет!
Единственный вопрос: почему в холархии полного внедрения круг «Разработка» включает подкруги по специализациям, а не по командам, как в «Сервисе»? Ведь, если вы работаете по Скраму, то дизайнеры, разработчики и тестировщики неизбежно объединяются в кроссфункциональные команды. И получается такая же ошибка, как и в первом варианте сервисной холархии.
Я всё-таки надеюсь, что это полное внедрение рано или поздно произойдёт, и у нас появится возможность прочесть об этом такой же замечательный материал. Успехов! +)
Единственный вопрос: почему в холархии полного внедрения круг «Разработка» включает подкруги по специализациям, а не по командам, как в «Сервисе»? Ведь, если вы работаете по Скраму, то дизайнеры, разработчики и тестировщики неизбежно объединяются в кроссфункциональные команды. И получается такая же ошибка, как и в первом варианте сервисной холархии.
Я всё-таки надеюсь, что это полное внедрение рано или поздно произойдёт, и у нас появится возможность прочесть об этом такой же замечательный материал. Успехов! +)
Поблагодарю за Василия, раз уж написал за него статью, отвечу тоже за него :)
По поводу кругообразования: основной посыл заключается в том, что круги следует организовывать из уже сложившихся команд. Разные сервисные команды работают с разными клиентами, пул клиентов можно представить как своеобразный проект. То есть в сервисе разные круги работают над разными проектами и объединены по этому принципу. В разработке такого разделения нет — все работают над одним проектом, но на разных этапах. UX-ребята делают прототипы и дизайн, бекенд-разработчики делают кишки, фронтенд — морду, тестировщики контролируют качество. Практически любая фича проходит через этот процесс последовательно от старта разработки до релиза. То есть все ребята сейчас работают в командах не по-принципу «одни пилят одну фичу, другие — вторую», а по принципу «одни пилят фичу на одном этапе, другие подхватывают на следующем». Поэтому, такое разделение кажется более логичным, но, опять же, мы можем ошибаться. Как только попробуем — обязательно расскажем!
Ещё раз спасибо, мы старались всё подробно описать. По-моему, получилось даже слишком подробно: )
По поводу кругообразования: основной посыл заключается в том, что круги следует организовывать из уже сложившихся команд. Разные сервисные команды работают с разными клиентами, пул клиентов можно представить как своеобразный проект. То есть в сервисе разные круги работают над разными проектами и объединены по этому принципу. В разработке такого разделения нет — все работают над одним проектом, но на разных этапах. UX-ребята делают прототипы и дизайн, бекенд-разработчики делают кишки, фронтенд — морду, тестировщики контролируют качество. Практически любая фича проходит через этот процесс последовательно от старта разработки до релиза. То есть все ребята сейчас работают в командах не по-принципу «одни пилят одну фичу, другие — вторую», а по принципу «одни пилят фичу на одном этапе, другие подхватывают на следующем». Поэтому, такое разделение кажется более логичным, но, опять же, мы можем ошибаться. Как только попробуем — обязательно расскажем!
Ещё раз спасибо, мы старались всё подробно описать. По-моему, получилось даже слишком подробно: )
Поблагодарю Вас, Дмитрий, за благодарность за Василия, за статью и за ответ +)
Если честно, мне сложно представить итеративную разработку, строящуюся по такому принципу. Получается, внимание участников команд в единый момент времени распределено на разных фичах, иначе, завершив свой этап, они бы простаивали. Это чревато тем, что за короткую итерацию конкретная фича не успеет достигнуть всех критериев готовности и итерация будет провалена, поскольку управляющий продуктом не сможет заняться полноценной проверкой тех предположений, которую в эту фичу были заложены. Именно поэтому в Скраме команда разработки рассматривается как единое целое, и каждый её участник задействован в реализации фичи на протяжении всего спринта, а не на каком-то конкретном этапе.
Не могли бы вы так же подробно, как и обо всём остальном, рассказать о процессах в Разработке: как проходят планирования, ежедневные встречи, обзоры и ретроспективы у обозначенных команд? Есть ли там всё-таки Скрам или его нет, потому что не нужен?
В разработке такого разделения нет — все работают над одним проектом, но на разных этапах. UX-ребята делают прототипы и дизайн, бекенд-разработчики делают кишки, фронтенд — морду, тестировщики контролируют качество. Практически любая фича проходит через этот процесс последовательно от старта разработки до релиза. То есть все ребята сейчас работают в командах не по-принципу «одни пилят одну фичу, другие — вторую», а по принципу «одни пилят фичу на одном этапе, другие подхватывают на следующем».
Если честно, мне сложно представить итеративную разработку, строящуюся по такому принципу. Получается, внимание участников команд в единый момент времени распределено на разных фичах, иначе, завершив свой этап, они бы простаивали. Это чревато тем, что за короткую итерацию конкретная фича не успеет достигнуть всех критериев готовности и итерация будет провалена, поскольку управляющий продуктом не сможет заняться полноценной проверкой тех предположений, которую в эту фичу были заложены. Именно поэтому в Скраме команда разработки рассматривается как единое целое, и каждый её участник задействован в реализации фичи на протяжении всего спринта, а не на каком-то конкретном этапе.
Не могли бы вы так же подробно, как и обо всём остальном, рассказать о процессах в Разработке: как проходят планирования, ежедневные встречи, обзоры и ретроспективы у обозначенных команд? Есть ли там всё-таки Скрам или его нет, потому что не нужен?
Да, внимание разных условных подкругов круга «Разработка» в один момент времени сконцентрировано на разных фичах. В итерацию мы, как правило, редко берём задачу «Довести с нуля до релиза какую-то фичу». Просто у UX-ребят появляется задача «Сделать прототип фичи Z», бэкенд-разработчики в этот момент реализуют кишки фичи Y, прототип которой был готов на предыдущей итерации, а фронтендеры причёсывают фичу X, которая прошла через предшествующие этапы.
Естественно, бывают случаи, когда прототип фичи после начала разработки требует изменений и попадает обратно в руки интерфейсологов, но это не значит, что разработка сидит без дела и ждёт доработок. Как правило, в любой момент времени есть несколько готовых прототипов или потребность в отладке/багофиксинге. Получается непрерывный последовательный процесс, что-то вроде конвеера даже.
Естественно, бывают случаи, когда прототип фичи после начала разработки требует изменений и попадает обратно в руки интерфейсологов, но это не значит, что разработка сидит без дела и ждёт доработок. Как правило, в любой момент времени есть несколько готовых прототипов или потребность в отладке/багофиксинге. Получается непрерывный последовательный процесс, что-то вроде конвеера даже.
Тогда это Kanban, а не Scrum. Это работает нормально вначале, но разработка — не help-desk, продукт неизбежно усложняется. С ростом продукта появятся блокировки, например, когда фронтэндерам нужно поменять что-то в бэкенде в задаче X, о чем они раньше не подумали, а бэкенд уже плотно занят задачей Y, потому что X был 2 недели назад и вообще у них в планах уже висит задача Z, которая, вроде как, более приоритетна и над которой они уже начали думать.
Эти переключения негативно сказываются на качестве доставляемого кода и на общем уровне стресса в команде.
Если команды смешать — будет труднее вначале, зато можно будет реально закидывать на вход фичу X и получать ее же на выходе. При этом планировать станет легче, т.к. не нужно будет учитывать зависимости.
Эти переключения негативно сказываются на качестве доставляемого кода и на общем уровне стресса в команде.
Если команды смешать — будет труднее вначале, зато можно будет реально закидывать на вход фичу X и получать ее же на выходе. При этом планировать станет легче, т.к. не нужно будет учитывать зависимости.
Тогда это действительно не Скрам, хотя вы явно нигде и не писали, что Разработка работает по нему. Скрам приносит максимум пользы там, где есть высокий уровень неопределённости – большая зависимость от реакции пользователей, жёсткая конкуренция, сложная динамичная предметная область или технологические зависимости. Каждая поставленная фича в этом случае позволяет получать новые важные знания о том, как развивать продукт дальше, в том числе саму эту фичу. Если фича задерживается (а при описанной модели это практически неизбежно), знания приходят позже и продукт, соответственно, развивается хуже.
Не знаю, насколько сильно у вас это выражено, но мне кажется, что вы не до конца используете основное преимущество итеративной разработки. И, возможно, формирование традиционных скрам-команд – одно из важных грядущих кнопочных улучшений +)
Не знаю, насколько сильно у вас это выражено, но мне кажется, что вы не до конца используете основное преимущество итеративной разработки. И, возможно, формирование традиционных скрам-команд – одно из важных грядущих кнопочных улучшений +)
Отвечу Fatnir и VadimMusteata как scrum-мастер Кнопки. Есть выражение, которое мне очень нравится: невозможно делать agile, можно только быть agile. Я понимаю о чем вы говорите, но мы вот так подстраиваем свой процесс, сейчас это кажется разумным. Если смотреть на это академически это не канбан, потому что нет пропускной способности у дизайнеров за которую мы не вылезаем, например.
Тут еще дело в том, что большинство гипотез Кнопки лежит в области обслуживания клиентов живыми людьми, так проверять гипотезы куда быстрее, чем программировать и проектировать за итерацию, например хотим проверить оценят ли клиенты предсказание налогов, берем и делаем это просто на руках. Это вообще lean :)
А в разработке у нас есть небольшой план, по сути бэклог, который служит основой при планировании итерации, но не догмой. Но мы всегда учитываем, если нужно что-то подготовить для разработки к следующей итерации. Кстати, проектировщики часто могут кросс-функционально создавать команду с маркетологами и участвовать в запуске рекламных кампаний, с сервисными командами и помогать им обслуживать клиентов и это дает зачастую гораздо больше для проверки гипотез, чем академический подход к скраму. А уж реальной обратной связи дает намного больше и быстрее. Разработка слишком дорогое и долгое дело, даже в скраме для проверки гипотез, гораздо круче проверять гипотезы вообще без разработки, Эрик Рийс наше все :)
Тут еще дело в том, что большинство гипотез Кнопки лежит в области обслуживания клиентов живыми людьми, так проверять гипотезы куда быстрее, чем программировать и проектировать за итерацию, например хотим проверить оценят ли клиенты предсказание налогов, берем и делаем это просто на руках. Это вообще lean :)
А в разработке у нас есть небольшой план, по сути бэклог, который служит основой при планировании итерации, но не догмой. Но мы всегда учитываем, если нужно что-то подготовить для разработки к следующей итерации. Кстати, проектировщики часто могут кросс-функционально создавать команду с маркетологами и участвовать в запуске рекламных кампаний, с сервисными командами и помогать им обслуживать клиентов и это дает зачастую гораздо больше для проверки гипотез, чем академический подход к скраму. А уж реальной обратной связи дает намного больше и быстрее. Разработка слишком дорогое и долгое дело, даже в скраме для проверки гипотез, гораздо круче проверять гипотезы вообще без разработки, Эрик Рийс наше все :)
По проверке гипотез полностью согласен! А вот, что надо не делать гибко, а быть гибким — не очень понял. Первое всегда ясно: было менее гибко, стало более гибко. А вот второе — у каждого своя оценка: 1 считает — что я гибкий, а другой — что ещё не достаточно. И всегда будет тот, чью планку по гибкости я не выполню…
А как вы решаете проблему личного роста сотрудников и текучки? По-сути, работнику некуда стремиться, т.к. нет иерархии.
Только не говорите, что реп-линки и лид-линки получают больше денег, чем обычные работники, ведь тогда они не отличаются от обычных менеджеров.
Только не говорите, что реп-линки и лид-линки получают больше денег, чем обычные работники, ведь тогда они не отличаются от обычных менеджеров.
Нет, реп-линки и лид-линки получают столько же, сколько получали, не занимая оные роли. Это никак не связано с зарплатой, равно как и личностный и профессиональный рост никак не связан с уровнем иерархии и бюрократии. Если смотреть на это с точки зрения присвоения красивых шильдиков — мы просто не берём людей, для которых это самоцель.
Вся идея холакратии строится на людях, которым не нужны повышения, чтобы куда-то стремиться. Если сотрудник хочет развиваться и расти — для этого есть все условия, в том числе финансовые. В Кнопке любой человек может заниматься работой, которая ему по-душе. Зарплата и прочие финансовые штуки зависят от вклада в компанию. Зарплаты у нас не выше рынка, но текучки при этом нет совсем.
Вся идея холакратии строится на людях, которым не нужны повышения, чтобы куда-то стремиться. Если сотрудник хочет развиваться и расти — для этого есть все условия, в том числе финансовые. В Кнопке любой человек может заниматься работой, которая ему по-душе. Зарплата и прочие финансовые штуки зависят от вклада в компанию. Зарплаты у нас не выше рынка, но текучки при этом нет совсем.
А что такое «вклад в компанию»? Это измеримая вещь?
Вы не сочтите за флуд, я просто сам наблюдал трансформацию большой компании к agile и такие вопросы очень важны. Например, я видел, как решение этих вопросов (как оценивать людей) долго откладывали, ведь они, вроде как, не главное в условиях самоорганизующихся команд.
На самом деле — это не так, рост и вклад должны быть измеримыми и достижимыми с самого начала.
Через people manager'ов или еще как-то.
Иначе они (работники) на каком-то этапе понимают, что им продали ту же конфету, но в другой обертке.
Согласитесь, обсуждать вопрос роста и достижений человека, когда у него на руках другой оффер — это не совсем запланированная вещь.
Проблема тут еще в том, что команды сами часто путаются в метриках и много спорят об этом.
Например, где кончается вклад 1го человека и начинается вклад всей команды?
Одна команда сделала 10 легких тасков, а другая — 3 сложных, непонятно, кто внес больший вклад.
Пишите еще о своем опыте — читать интересно! Удачи.
Вы не сочтите за флуд, я просто сам наблюдал трансформацию большой компании к agile и такие вопросы очень важны. Например, я видел, как решение этих вопросов (как оценивать людей) долго откладывали, ведь они, вроде как, не главное в условиях самоорганизующихся команд.
На самом деле — это не так, рост и вклад должны быть измеримыми и достижимыми с самого начала.
Через people manager'ов или еще как-то.
Иначе они (работники) на каком-то этапе понимают, что им продали ту же конфету, но в другой обертке.
Согласитесь, обсуждать вопрос роста и достижений человека, когда у него на руках другой оффер — это не совсем запланированная вещь.
Проблема тут еще в том, что команды сами часто путаются в метриках и много спорят об этом.
Например, где кончается вклад 1го человека и начинается вклад всей команды?
Одна команда сделала 10 легких тасков, а другая — 3 сложных, непонятно, кто внес больший вклад.
Пишите еще о своем опыте — читать интересно! Удачи.
Вклад в компанию определяется субъективным мнением нескольких людей, тут формулы нет, но почему мнение такое всякий раз объясняется. Например, для бухгалтера важно обслуживать клиентов, помогать другим людям в команде и помогать прокачивать бухгалтера как роль, те у кого все 3 направления растут имеют больший вклад. Если какое-то не растет не страшно. Если все 3 не растут мы расстанемся если ничего не поменяется :)
Могу сказать, что эта проблема называется основной причиной невзлетания холакратии в 80е. Сотрудники корпораций не смогли жить без мечты о карьере. У нас пока не такая большая компания, чтобы адекватно судить есть проблема или нет. Всем новичкам Кнопки на входе сообщается, что тут нет «карьерного роста», но твоя ценность и рост будет замечена и отмечена. Тут нет какого-то сверх формализованного процесса, да я думаю он и не возможен, просто сама система предполагает большую прозрачность, чем в традиционной схеме и удается замечать и отмечать. С каждым сотрудником минимум 2 раза в год беседуют по конкретному вопросу как он вырос, какая новая высота и т.д,
evgeny_kobzev Любопытно было бы узнать, как оно два года спустя.
evgeny_kobzev как у вас дела сейчас, насколько изменилась структура кругов за почти 4 года?
Поддерживаю вопрос в предыдущем комментарии.
Поддерживаю вопрос в предыдущем комментарии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практическая холакратия. Нарезаем круги и готовим роли