20% времени это культура работодателя, позволяющая его сотрудникам тратить 20% своего времени на работу над проектами, которые им кажутся интересными - это может быть изобретение нового приложения или улучшение существующего процесса и т. Д. Некоторые люди могут знать это как скунса работать, однако этот термин может не значить (или что-то совершенно другое) для вас.
Есть много задокументированных случаев, когда отличные продукты рождаются из 20% / скунса, работающего в компании. Это похоже на беспроигрышную ситуацию; компания потенциально может получить отличный новый продукт или приложение, и у разработчика есть возможность развить свои творческие мускулы и внедрять инновации.
Я неоднократно пытался ввести какую-то форму 20% / скунса, работавшую у моего предыдущего работодателя, но безуспешно.
Как я могу лучше объяснить это руководству? Какой «правильный» способ подойти к такому типу организации работы?
источник
Ответы:
Основная причина для 20% времени состоит в том, чтобы сохранить загрузку на уровне 80%, а не на 100%.
Вы можете представить организацию разработки программного обеспечения как систему, которая превращает запросы функций в разработанные функции. Вы можете смоделировать его поведение, используя теорию очередей .
ТЕОРИЯ
Если запросы поступают быстрее, чем система может их обслуживать, они помещаются в очередь. Когда прибытие происходит медленнее, размер очереди уменьшается. Поскольку процессы поступления и обслуживания являются случайными, размер очереди изменяется случайным образом со временем.
Математически склонный может спросить об этой «случайности»: должно быть некоторое распределение вероятностей, так какой будет размер очереди в среднем? Математика (теория массового обслуживания) имеет ответ на это: если и процессы прибытия, и процессы обслуживания являются марковскими, то N = rho ^ 2 / (1-rho).
(Где rho - коэффициент использования, равный отношению скорости обслуживания и прибытия. Если процессы немарковские, математика более сложная, но не меняет выводы.)
Если вы построите эту функцию, вы увидите, что средняя длина очереди остается низкой, а загрузка до 0,8 , затем резко возрастает и уходит в бесконечность. Вы можете понять это интуитивно, подумав о процессоре вашего компьютера: когда его загрузка приближается к 100%, компьютер перестает отвечать на запросы.
ПРАКТИКА
Экономика разработки программного обеспечения такова, что компании-разработчики программного обеспечения несут большие расходы, когда их очереди находятся в состоянии высокой очереди. Это включает упущенные рыночные возможности, устаревшие продукты, запоздалые проекты и потери, вызванные конструктивными особенностями в ожидании спроса.
Таким образом, 20% времени - это научный ответ на проблему оптимизации экономических результатов: избегайте стран с высокой очередью, избегая вызывающих их коэффициентов использования. По сути, это слабость, которая держит систему отзывчивой.
Несколько практических выводов следуют сразу:
ОТВЕТЫ НА ВОПРОСЫ В КОММЕНТАРИИ
Дэн , вы правильно поняли и точно описали ошибку, допущенную многими. Вы не можете выбрать свой процент использования, потому что это выходная переменная. Это соотношение характеристик двух процессов, поэтому оно и есть, потому что процессы такие, какие они есть. Организация имеет влияние на оба процесса; Сопоставление возможностей и спроса является одной из трудных проблем, с которыми сталкивается свод знаний по разработке программного обеспечения. Использование - один из показателей того, насколько хорошо эта проблема решается в организации. Вялость проявляется по мере продвижения вашей бережливой инициативы и удаления отходов из потока создания ценности. Но если вы затрачиваете 20% времени, вы попадаете в ту же ловушку утилизации с меньшей доступной емкостью.
Ким , это все еще частично вещь культуры. Самая близкая культурная ссылка, о которой я могу думать, - это синергетический уровень так называемой модели организационных изменений Маршалла . Он возникает в конце успешных преобразований бережливого производства или присутствует в организациях, построенных бережливо с самого начала. ( Вот ссылка на официальный документ Боба Маршалла (PDF) .)
ССЫЛКИ
Вышеуказанная логика хорошо поддерживается в литературе по разработке программного обеспечения. Мэри и Том Поппендик намекнули на это в своей книге 2006 года «Внедрение бережливого программного обеспечения» . Дональд Рейнертсен в своей книге «Принципы разработки продуктов» (глава 3) 2009 года дает подробное описание этой темы с помощью формул и графиков.
источник
Через четырнадцать месяцев после того, как я написал этот ответ, я придумал гораздо лучший .
Я не работал в месте, где такие работы были официально признаны. Но из моих разговоров и попыток узнать об этой практике я обнаружил это - ну, в основном то, чем не является «время 20%»:
источник
" Skunkworks " - это не то же самое, что 20% времени. Как вы сказали, 20% времени - время, которое разработчик сам выбирает, над чем работать. Skunkworks совершенно другой. Проект Skunkworks - это дорогостоящий, дорогостоящий проект, над которым работает команда (часто это команда отколовшихся гуру), о котором не сообщается высшему руководству, и команда самостоятельно решает, как проект должен развиваться без руководства. , Эти проекты часто мотивируются тактической или деловой необходимостью что-то сделать, но в бюджете нет места для этого. Если что-то должно быть сделано , это будет сделано - бюджеты будут прокляты.
Я руководил командой разработчиков, где реализовал 20% времени. Или все равно пытался. У меня было одобрение моего начальства, так что это не было проблемой. Проблема была в том, что команда была слишком маленькой и слишком специализированной. Всякий раз, когда возникали проблемы, требующие немедленного вмешательства, время в 20% сокращалось. Это случилось очень часто.
Я также обнаружил, что некоторые из моих разработчиков находят, что мое отсутствие направления тревожит. Несмотря на то, что я сказал «работай над всем, что хочешь, если это связано с программированием», им все еще трудно было принять часть «что угодно». Они думали, что некоторые проекты будут лучше, чем другие, поэтому они неизбежно работали над низкоуровневыми запросами на реализацию в основном продукте, и тому подобное. Я хотел, чтобы они развивались и росли, но вместо этого они углубились в свой основной опыт.
Я бы сделал это снова, но я бы категорически запретил работу с основным продуктом, и я мог бы начать с некоторых идей, из которых можно выбрать, чтобы начать.
источник
Я работаю на стартап, который внедрил политику 20%. Это мой первый работодатель, который сделал это, и когда он поднял это на собеседовании, я был очень удивлен, так как большинство других работодателей старались не «тратить» ни одного часа.
Я присоединился к стартапу, когда он был сформирован, и почти год я был единственным разработчиком. Я потратил свои 20% в основном на пару вещей:
Время точно не измерено, оно определенно не 32 + 8 часов, иногда есть срочные действия, когда просто не хватает времени, чтобы сократить эти 20%, в других случаях у меня есть больше свободного времени.
Я работаю удаленно, и мы используем чат Campfire 37signal, чтобы общаться и свободно отслеживать присутствие друг друга, и эти часы отслеживаются как «рабочие» часы, я вошел в чат и доступен для коллег, хотя и делаю Понятно, что я сейчас не работаю над нашим проектом.
источник
Исходя из моего небольшого опыта, многие наши проекты начинались именно так. У нас было свободное время и пропускная способность, чтобы заняться новыми проектами, мы собрались вместе и предложили потенциальные идеи для нашего отдела. В свободное время мы разработали прототип, и после того, как он был довольно отполирован, представлен на верхнем уровне, и обычно они видят пользу.
Мне кажется, что верхний уровень знает, чего они хотят, если они видят это, но не знает, что им нужно / нужно, пока они не увидят это. Прототипирование позволило нам создавать свои собственные проекты, предлагать их, а затем, после утверждения, отводить им больше времени для завершения.
источник