Введение «20% времени» на рабочем месте [закрыто]

20% времени это культура работодателя, позволяющая его сотрудникам тратить 20% своего времени на работу над проектами, которые им кажутся интересными - это может быть изобретение нового приложения или улучшение существующего процесса и т. Д. Некоторые люди могут знать это как скунса работать, однако этот термин может не значить (или что-то совершенно другое) для вас.

Есть много задокументированных случаев, когда отличные продукты рождаются из 20% / скунса, работающего в компании. Это похоже на беспроигрышную ситуацию; компания потенциально может получить отличный новый продукт или приложение, и у разработчика есть возможность развить свои творческие мускулы и внедрять инновации.

Я неоднократно пытался ввести какую-то форму 20% / скунса, работавшую у моего предыдущего работодателя, но безуспешно.

Как я могу лучше объяснить это руководству? Какой «правильный» способ подойти к такому типу организации работы?

Основная причина для 20% времени состоит в том, чтобы сохранить загрузку на уровне 80%, а не на 100%.

Вы можете представить организацию разработки программного обеспечения как систему, которая превращает запросы функций в разработанные функции. Вы можете смоделировать его поведение, используя теорию очередей .

ТЕОРИЯ

Если запросы поступают быстрее, чем система может их обслуживать, они помещаются в очередь. Когда прибытие происходит медленнее, размер очереди уменьшается. Поскольку процессы поступления и обслуживания являются случайными, размер очереди изменяется случайным образом со временем.

Математически склонный может спросить об этой «случайности»: должно быть некоторое распределение вероятностей, так какой будет размер очереди в среднем? Математика (теория массового обслуживания) имеет ответ на это: если и процессы прибытия, и процессы обслуживания являются марковскими, то N = rho ^ 2 / (1-rho).

(Где rho - коэффициент использования, равный отношению скорости обслуживания и прибытия. Если процессы немарковские, математика более сложная, но не меняет выводы.)

Если вы построите эту функцию, вы увидите, что средняя длина очереди остается низкой, а загрузка до 0,8 , затем резко возрастает и уходит в бесконечность. Вы можете понять это интуитивно, подумав о процессоре вашего компьютера: когда его загрузка приближается к 100%, компьютер перестает отвечать на запросы.

ПРАКТИКА

Экономика разработки программного обеспечения такова, что компании-разработчики программного обеспечения несут большие расходы, когда их очереди находятся в состоянии высокой очереди. Это включает упущенные рыночные возможности, устаревшие продукты, запоздалые проекты и потери, вызванные конструктивными особенностями в ожидании спроса.

Таким образом, 20% времени - это научный ответ на проблему оптимизации экономических результатов: избегайте стран с высокой очередью, избегая вызывающих их коэффициентов использования. По сути, это слабость, которая держит систему отзывчивой.

Несколько практических выводов следуют сразу:

• если вы рассматриваете 20% времени и ведете учет затрат (время разработчиков стоит X, но / и компания может / не может себе это позволить), вы делаете это неправильно.
• если вы выделяете 20% на пятницу каждую неделю, вы делаете это неправильно
• если вы настраиваете систему подачи / рассмотрения / одобрения проектных предложений на 20% времени, вы делаете это неправильно
• если вы заполняете табели, вы делаете это неправильно
• если вы используете инновации в качестве мотиватора в течение 20% времени, вы делаете это неправильно. В то время как новые продукты появились в 20% проектов, это не главное. Если ваша компания не может внедрять инновации в основное время, это проблема!
• 20% времени это не творчество. Не говорите, что вы раскроете свой творческий потенциал за 20% времени, спросите, почему вы недостаточно креативны уже в свои основные часы.

ОТВЕТЫ НА ВОПРОСЫ В КОММЕНТАРИИ

Дэн , вы правильно поняли и точно описали ошибку, допущенную многими. Вы не можете выбрать свой процент использования, потому что это выходная переменная. Это соотношение характеристик двух процессов, поэтому оно и есть, потому что процессы такие, какие они есть. Организация имеет влияние на оба процесса; Сопоставление возможностей и спроса является одной из трудных проблем, с которыми сталкивается свод знаний по разработке программного обеспечения. Использование - один из показателей того, насколько хорошо эта проблема решается в организации. Вялость проявляется по мере продвижения вашей бережливой инициативы и удаления отходов из потока создания ценности. Но если вы затрачиваете 20% времени, вы попадаете в ту же ловушку утилизации с меньшей доступной емкостью.

Ким , это все еще частично вещь культуры. Самая близкая культурная ссылка, о которой я могу думать, - это синергетический уровень так называемой модели организационных изменений Маршалла . Он возникает в конце успешных преобразований бережливого производства или присутствует в организациях, построенных бережливо с самого начала. ( Вот ссылка на официальный документ Боба Маршалла (PDF) .)

ССЫЛКИ

Вышеуказанная логика хорошо поддерживается в литературе по разработке программного обеспечения. Мэри и Том Поппендик намекнули на это в своей книге 2006 года «Внедрение бережливого программного обеспечения» . Дональд Рейнертсен в своей книге «Принципы разработки продуктов» (глава 3) 2009 года дает подробное описание этой темы с помощью формул и графиков.

Через четырнадцать месяцев после того, как я написал этот ответ, я придумал гораздо лучший .

Я не работал в месте, где такие работы были официально признаны. Но из моих разговоров и попыток узнать об этой практике я обнаружил это - ну, в основном то, чем не является «время 20%»:

• это действительно культура, а не политика
• это не может быть предписано высшим руководством
• он не может быть учрежден комитетом разработчиков
• это не 32 часа на это и 8 часов на это

" Skunkworks " - это не то же самое, что 20% времени. Как вы сказали, 20% времени - время, которое разработчик сам выбирает, над чем работать. Skunkworks совершенно другой. Проект Skunkworks - это дорогостоящий, дорогостоящий проект, над которым работает команда (часто это команда отколовшихся гуру), о котором не сообщается высшему руководству, и команда самостоятельно решает, как проект должен развиваться без руководства. , Эти проекты часто мотивируются тактической или деловой необходимостью что-то сделать, но в бюджете нет места для этого. Если что-то должно быть сделано , это будет сделано - бюджеты будут прокляты.

Я руководил командой разработчиков, где реализовал 20% времени. Или все равно пытался. У меня было одобрение моего начальства, так что это не было проблемой. Проблема была в том, что команда была слишком маленькой и слишком специализированной. Всякий раз, когда возникали проблемы, требующие немедленного вмешательства, время в 20% сокращалось. Это случилось очень часто.

Я также обнаружил, что некоторые из моих разработчиков находят, что мое отсутствие направления тревожит. Несмотря на то, что я сказал «работай над всем, что хочешь, если это связано с программированием», им все еще трудно было принять часть «что угодно». Они думали, что некоторые проекты будут лучше, чем другие, поэтому они неизбежно работали над низкоуровневыми запросами на реализацию в основном продукте, и тому подобное. Я хотел, чтобы они развивались и росли, но вместо этого они углубились в свой основной опыт.

Я бы сделал это снова, но я бы категорически запретил работу с основным продуктом, и я мог бы начать с некоторых идей, из которых можно выбрать, чтобы начать.

Я работаю на стартап, который внедрил политику 20%. Это мой первый работодатель, который сделал это, и когда он поднял это на собеседовании, я был очень удивлен, так как большинство других работодателей старались не «тратить» ни одного часа.

Я присоединился к стартапу, когда он был сформирован, и почти год я был единственным разработчиком. Я потратил свои 20% в основном на пару вещей:

• Сообщение / исправление ошибок в случайных проектах с открытым исходным кодом - это может быть так же мало, как разветвление интересного проекта на Github и исправление нескольких опечаток в документации.
• Написание «материала» с открытым исходным кодом - такие вещи, как задачи программирования, просто для удовольствия.
• Ходить на конференции и спринты - каждые несколько месяцев я бываю на спринте, где я могу работать над проектами (некоторые из которых могут использоваться основным приложением, другие нет) и получить некоторый опыт. Существует несколько библиотек, которые используются нашим приложением и приложениями, разработанными другими компаниями, которые отправляют разработчиков на конференции, поэтому это можно рассматривать как прямую выгоду для нашей компании.
• Изучение новых технологий - это то, как я изучил Go , хотя мы не используем его в компании. Это особенно поощряется моим работодателем. В последнее время я следил за некоторыми бесплатными онлайн-классами в Стэнфорде.

Время точно не измерено, оно определенно не 32 + 8 часов, иногда есть срочные действия, когда просто не хватает времени, чтобы сократить эти 20%, в других случаях у меня есть больше свободного времени.

Я работаю удаленно, и мы используем чат Campfire 37signal, чтобы общаться и свободно отслеживать присутствие друг друга, и эти часы отслеживаются как «рабочие» часы, я вошел в чат и доступен для коллег, хотя и делаю Понятно, что я сейчас не работаю над нашим проектом.

Исходя из моего небольшого опыта, многие наши проекты начинались именно так. У нас было свободное время и пропускная способность, чтобы заняться новыми проектами, мы собрались вместе и предложили потенциальные идеи для нашего отдела. В свободное время мы разработали прототип, и после того, как он был довольно отполирован, представлен на верхнем уровне, и обычно они видят пользу.

Мне кажется, что верхний уровень знает, чего они хотят, если они видят это, но не знает, что им нужно / нужно, пока они не увидят это. Прототипирование позволило нам создавать свои собственные проекты, предлагать их, а затем, после утверждения, отводить им больше времени для завершения.