Редактор Хабрахабра
2,0
рейтинг
17 сентября 2014 в 20:40

Управление → Почему у нас нет боссов и офиса, и почему мы работаем 4 дня в неделю перевод



В 2008 мы с партнёром закончили обучение по специальности «компьютерная инженерия» в университете в Аргентине.

На старших курсах мы проходили стажировку в таких компаниях, как HP, IBM, Intel. Именно тогда мы заметили недостаток в их работе. Мы не могли понять, почему люди без технических знаний говорят программистам, что им делать, и кроме того, проверяют, как именно они это делают.

Поэтому, когда мы делали Project eMT, сравнительный поисковик для Латинской Америки, мы решили работать по-другому: без менеджеров проектов. Через шесть лет у нас в команде было 34 инженера из Чили, Бразилии, Мексики и Колумбии, и мы всё ещё работаем без использования традиционных структур и рабочего графика, а наш ежегодный рост составляет 204%.

Без начальства


В больших технологических компаниях мы часто наблюдали, как программисты делали что-то быстро и плохо и получали поощрение от руководства. Со временем это приводит к стандарту: «сделай пусть и плохо, зато быстро».

Ларри Пейдж говорил: «Над инженерами не должны стоять менеджеры проектов с ограниченными техническими познаниями»

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

Разработчику необходимо в среднем четыре часа непрерывной работы для продуктивной деятельности. Поэтому в идеале программисту надо работать с 9 до 13, и потом с 14 до 18, для достижения максимальной эффективности.

Если, к примеру, начальник назначает встречу на 11 утра – утро потеряно, потому что мне надо подготовиться к нему, присутствовать там, со всеми поздороваться, обсудить проблемы, вернуться назад к рабочему месту и продолжить оттуда, где я закончил. Со всей этой шебутнёй утро теряется.

Пол Грэхам – предприниматель, программист и основатель YCombinator говорил: «для программиста стоимость встречи всегда выше».

Без офиса


По правде говоря, в начале офис был нам недоступен. У нас просто не было средств на первых этапах для снятия офиса.

Так продолжалось до второго года, когда мы смогли въехать в офис со всякими плюшками, о которых давно мечтали (столы для пинг-понга, видеоигры, повара в кафе, гимнастический зал и здоровые телевизоры). Этот этап продолжался всего восемь месяцев, а потом мы решили вернуться к удалённой работе, по нескольким причинам.

Для начала, дорога – неважно, общественным траспортом, или на своём авто,- занимала в среднем час туда и час обратно. То есть, при 9-часовом рабочем дне мы тратили 22% времени на перемещения. Стоимость дороги и аренды офиса добавлялась к расходам.

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

Теперь у нас работают люди из пяти стран, и мы верим, что привычка удалённо работать позволит нам расти и дальше.

Четырёхдневная рабочая неделя.


Уменьшение количества дней в рабочей неделе – это наше недавнее нововведение. Мы работаем так последние два года и это оказалось отличным решением.

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

Нам нужны инженеры, удовлетворённые работой и мотивированные на качественное исполнение. Нам не интересно количество, нам важно качество.

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

По нашему опыту, прекрасный программист решает задачу в два раза быстрее среднего, причём с лучшим качеством.

Кроме того, мы устали слышать про балансирование между работой и семейным временем. Для нас, это был отличный ответ извечной проблеме – теперь вы можете проводить с семьей на 50% больше времени.

Шаг за шагом


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

Это может показаться неудобным, но мы так работаем уже три года и это для нас абсолютно нормально. Мы прочли про то, как производственное предприятие сэкономило эквивалент примерно 200 зарплат, просто уменьшив время встреч до 30 минут, и максимальное количество человек на встречах до 7 – и поняли, что мы на правильном пути.

2. Никакой повестки дня. Никто не включает встречи в наше рабочее время и не меняет наш график. Работа организуется каждым из нас, на основании знаний и расписаний.

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

3. Ещё один важный момент состоит в том, что мы полностью отказались от e-mail. Мы устали использовать почту как список дел. Она не была предназначена для этого, и тем более не была эффективно заточена под это.

Мы перешли от исторической методологии пинков (push) к механизму запросов (pull). То есть, никто не может отправить мне емейл с требованием что-то сделать. Я выбираю свои дела сам для себя.

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

Таким образом, мы все видим списки задач, прогресс, и можем создавать и участвовать в задачах, чтобы доводить их до конца.

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

Быть требовательным


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

Неактивные инженеры наносят вред нашей рабочей культуре. Высокопроизводительный инженер хочет работать с тем, кто ещё больше (и лучше) работает. Мы ошибались, нанимая программистов, у которых не было таких качеств. Но через несколько дней, максимум – недель, мы обнаруживали это. Я советую не тянуть с разрывом рабочих отношений, которые не складываются – это лучше для обоих сторон. Если программистам нужен надзиратель, они найдут себе место в другой компании, с менеджерами.

Советую начинать с подобных привычек сразу – это будет гораздо легче, чем менять их потом.
Перевод: Cristian Rennella
Вячеслав Голованов @SLY_G
карма
262,2
рейтинг 2,0
Редактор Хабрахабра
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (58)

  • +21
    Цитата Ларри доставила, она звучит красиво. Но на деле, даже в гугле менеджеры проектов очень часто не технические специалисты или с ограниченными техническими познаниями. Зато они знают слова скрам, дедлайн, естимейт, умеют рисовать красивые таблички в спредшитах, писать много писем и проводить 10 митингов каждый день. Так же они любят звать на митинги инженеров, которых митинг вообще не касается и на каждом планинге задавать одни и те же вопросы по проекту, который они менелджат, но не знают и не могут понять как он работает.
    • 0
      Видимо, вторая часть цитаты: «но куда же мы без менеджеров».
    • +9
      Я читал на хабре про гугл, не помню к о чем речь шла, но суть такова: Ларри Пейдж говорил, что поначалу они хотели обойтись без менеджеров, но очень скоро пришло понимание, что разработчики тратят много времени «не туда», ибо сваливается множество организационных вопросов и прочего.
      Я считаю, что наша главная особенность – качество нанимаемых нами инженеров. Главное их свойство в способности быть проактивным. Люди, работающие с нами, сами себе предприниматели – им не нужен человек, который постоянно проверяет, работают ли они.

      Ну если команда небольшая и у вас вот только такие проактивные люди, которые заинтересованы в росте Вашей компании, то поначалу такое и прокатит. Думаю это пройдет, если ваше дело перенесет бурный рост и разработчиков уже будет не хватать, и придется нанимать других разработчиков.
  • –5
    Какой бред. Действовать по принципу «так не получилось, значит наоборот — получится» означает лишь то, что вы вначале не подумали, а сразу стали делать. И уж тем более не надо советовать людям делать так же. В итоге пришли-то к таким баянным результатам, которые описывал каждый второй владелец бизнеса в IT.
  • 0
    Как-то слишком утопично. Явно не для наших компаний и не для наших заказчиков. Может быть в небольших стартапах и будет работать, когда сам себе придумываешь работу, понимаешь, что от тебя зависит все, когда действительно ты — часть бизнеса.
    • 0
      Вообще-то ты — всегда часть бизнеса. Даже если пол моешь в офисе трансконтинентальной корпорации. Разумеется, глупо предполагать, что в этой стране так может стать в одночасье. Однако люди новой формации, скажем, молодые ай-ти специалисты, которые только выходят на рынок, вполне себе могут начать жить именно так.
  • 0
    А что за приложение класса SAAS использует команда автора?
    • +3
      >нашей внутренней разработкой, которую мы зовём iAutonomous

      Я так понимаю, она и есть
  • +12
    А какими продуктами и успехами известны герои статьи?
    • +4
      В статье и гугле все есть

      >Поэтому, когда мы делали Project eMT, сравнительный поисковик для Латинской Америки, мы решили работать по-другому: без менеджеров проектов. Через шесть лет у нас в команде было 34 инженера из Чили, Бразилии, Мексики и Колумбии, и мы всё ещё работаем без использования традиционных структур и рабочего графика, а наш ежегодный рост составляет 204%.

      Беглое гугление дает, что это крупнейший подобный сервис в Латинской америке, кол-во пользователей около 21 млн.
  • +9
    4 рабочих дня в неделю это хорошая идея кстати. Надо всерьез об этом подумать.
    • +2
      Дополнительные 28 дней отпуска к основным 28 выгоднее для компании, да и для работника наверняка тоже. Лично я уже на второй день выходных начинаю маяться дурью, а вот от отпуска бы не отказался.
      • +4
        А можно сделать выходным среду. Тогда 2 дня работаешь, 1 день отдыхаешь, 2 — работаешь, 2 — отдыхаешь.
        • 0
          Отличное получится решение со средой из старого анегдота :)

          Руководитель собрал коллектив в понедельник на летучку.
          «Ну что, сегодня понедельник, надо отдохнуть от выходных, а во вторник надо уже втягиваться в работу. В среду придется поработать, а в четверг надо готовиться к выходным, ну а в пятницу короткий день. Вопросы есть?»
          «Есть, а когда эта фигня со средой закончится?»
    • –1
      Давно надо об этом подумать. Вообще при царе барщина была три дня.
      • +5
        3 дня крестьянин работал, чтобы было что кушать барину, а в оставшиеся 4 дня крестьянин работал на своем участке, чтобы было что кушать ему и его семье
        • 0
          Об этом и толкую.
    • +1
      Мне больше импонирует идея короткого рабочего дня. 6 часов вполне достаточно.
      • 0
        В том или ином смысле, подобная идея выражается в таком принципе, что работа должна быть организована таким образом, чтобы программист мог 20% рабочего времени посвятить самому себе.
  • +9
    А мне понравилась такая система. Если я правильно понял, у них есть что-то вроде баг-треккера, куда каждый ставит задачи типа «Надо сделать такую-то менюшку», или «Надо реализовать либу для такой-то задачи», или «Отваливается то-то и то-то при попытке сделать это». А потом кто-нибудь из разрабов САМ берет себе задачу на основании своих навыков и желаний, и работает над ней. Мне кажется, это восхитительно. Получается, что если у кого-то есть опыт и желание заниматься GUI, он занимается им, у кого-то графикой — занимается графикой, у кого чем-то низкоуровневым — занимается этим. По-моему, именно это и даёт такой прирост производительности.
    • 0
      Agile же!
      • +2
        Agile, но за вычетом обязательного личного общения. То есть, они не отвлекаются в процессе работы, не созывают митингов.
    • +1
      Не все задачи, особенно после выката проекта в продакшн, будут находить своих героев)
      • +1
        Если команда хоть немного настроена на результат, то даже не самые интересные задачи будут кем-то решены. Но это только моё мнение.
        • +6
          Обязательно. Когда-нибудь, когда закончатся интересные задачи на созидание, а не на фикс плавающего бага.
          Все-таки распределение тасков по принципу «взял, что понравилось», на мой взгляд, не совсем жизнеспособно. Скорее всего что-то автор недоговаривает.
          • +2
            Автор, скорее всего, недоговаривает то что такая методика ориентирована на относительно узкий класс задач и наверняка не подойдет для разработки сложных бизнес-приложений со множеством ролей, процессов, интерфейсов, интеграций, отчетов и т.п.
            Для поисковика не знаю — может и подойдет.
          • 0
            Исправление плавающего бага (гейзенбага) это тоже созидание. Ведь никто из пользователей просто не увидит новую функциональность если проект работает нестабильно. Да и как показывает практика гейзенбаги не возникают на ровном месте, а возникают лишь в местах либо недоделок (не до конца решённых задач), а таких, по идее, при указанной схеме работы не должно быть. Либо возникают из-за не очень хорошей архитектуры, когда наращивание функциональности не обходится без костылей, но при указанной схеме проще и полезнее на перспективу допилить архитектуру, нежели по-быстрому выкатить новую функциональность.
          • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Все таки понимание целей проекта ортогонально скиллам менеджера (технические/не технические).
      Вопрос в выдержке, силе воли, желанию в конце концов вывести проект в продакшн. Точно так же и обычные менеджеры могу запороть проект.
    • +4
      Но… но я же существую! :cry:

      Много лет работал удаленно и, как потом оказалось, куда более продуктивно чем в офисе.
      В офисе много отвлекалок. Постоянные бла-бла, приколы и т.п. Это хоть и неплохо, но порой слишком сильно убивает производительность. По сути из 5 рабочих дней почти день уходит на бла-бла. + 2 часа на дорогу в день тоже не мотивируют. Но хотябы жопу от стула отдираю =)
      Удаленно работал в команде программистов, где был ПМ. Он, кроме программирования занимался общением с заказчиками и выставлением/назначением задач. Часто единственный от него вопрос был «есть вопросы по задаче?». Дальше никто никого без необходимости не трогает до конца дня. Контроль был вида: успел за отведенное время — молодец, лови еще задачу, а если не успел — объясни в кратце что случилось и сколько еще нужно времени. Претензий ни разу небыло если завалил сроки, а объяснения скорее помогали понять где мы не досчитали сложность задачи. Оценку времени проводили всей толпой 1 раз за спринт (1-2 недели) и чаще всего времени было с небольшим запасом. Это работало очень эффективно. Но нас было 6 человек всего. Не думаю что такой вариант прокатит если в комадне более 10 человек.
  • +1
    Я так и не понял, как они ведут задачи? Кто план то рисует что делать, а если нужно взаимодействие между N-инженерами, которые типа сами знаю, что им делать… что угодно, но не твою задачу? Короче самый главную проблему, где как раз и нужен начальник/координатор, обошли стороной.
  • +8
    Автор просто троллит менеджеров и продукт owner'ов
    Типа, он не понимает зачем они нужны.
    Во-первых, они поисковик пилят. У поисковика специфический набор требований.
    Там продукт owner особо и не нужен.
    Ашманов в курсе ;0)
    А роль менеджера снижена набором программистов-предпринимателей (я так понимаю они в доле). Т.е. там управление не надо менеджеру делегировать.
    Хе-хе, если бы каждая контора где я работал брала меня в долю…
    • +4
      Хе-хе, если бы каждая контора где я работал брала меня в долю…

      Однажды я предложил руководству компании принять некий регламент, согласно которому человек, придумавший приносящую прибыль услугу, получал бы процент с прибыли от нее. Руководство покивало головой, но так ничего и не сделало.
      Еще один мой коллега прямо заявил, что он знает способ усовершенствовать нашу систему, который бы принес миллионы рублей прибыли. Но он готов им поделиться только за процент. Ему отказали.
      Вообщем, наши компании не хотят делиться с программистами. Мы всего лишь наемные работники.
      • +1
        Возможно, руководство и так знает, что нужно сделать.
        Знать что сделать и сделать — это не одно и то же.
  • 0
    «и кроме того, проверяют, как именно они это делают»

    Не хочу пользоваться программами/системами/машинами, которые неизвестно как сделаны и которые никто не проверял.
    • –1
      То есть, вы хотите пользоваться программами/системами/машинами, код и использованные технологии которых проверены каким-то менеджером, а не программистом (знающим человеком)?
  • +10
    Проблема здесь в стереотипе, что менеджер — это начальник. Даже цитата Ларри Пейджа здесь подтверждает: многие разработчики просто не могут понять, что в правильной системе управления менеджер может делать много полезной организационной работы и освободить их мозги для интересного и продуктивного программирования, при этом не имея никакого права ничего указывать.
    В любом современном agile, да и в больших методологиях (не только методологиях разработки ПО — вообще в подходах к управлению), единственный настоящий стереотипный начальник — это клиент.
    • 0
      в правильной системе управления менеджер может делать много полезной организационной работы и освободить их мозги для интересного и продуктивного программирования

      Точно. Об этом ещё неплохо написано в Peopleware.
  • +3
    Эх, была бы в конце статьи еще и кнопка как на хедхантере «Хочу здесь работать!».
    • 0
      Вакансии на их сайте находятся без труда:
      qz.com/about/hiring
  • 0
    Хочу у вас работать!
  • +1
    В принципе позиция этих ребят понятна — они собирают лучших людей, проактивных, самомотивирующихся, любящих и хотящих работать, даюти этим людям хорошие условия, минимум ограничений и контроля и получают отличный результат. Это прекрасно и радует что у них получилось.

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

    Хорошо иметь трёх офигительных программистов. Но когда их нет — приходится за те же деньги брать 10 таких себе программистов, менеджера, тим-лида и тестировщика. И это реально работает!
    • 0
      Это реально работает пока задача — автоматизировать бизнес-процессы
      или сайты клепать для цветочных ларьков.

      Наберите хоть 100 000 быдлокодеров с обвязкой из тимлидов
      и тестировщиков — они вам движок гугла не родят,
      так же, как 100 макак не напишут Войну и Мир,
      хоть целый год будут барабанить по печатным машинкам.

      Для определенного уровня задач подходят только суперзвезды.
      • +1
        Вы же сами себе и отвечаете. Для определённого уровня задач суперзвёзды не годятся — они воротят нос и говорят, что не нанимались делать грязную работу.
        Если уж мы говорим об отрасли вообще, то да, кому-то надо делать и сайты для цветочных ларьков, пока цветочным ларькам нужны сайты и они готовы платить за них свою тысячу долларов.
      • +1
        Это спорное утверждение. Звезда нужна для открытия. Леонардо Да Винчи придумал вертолёт, но есть ли гении уровня Леонардо на современных авиазаводах? И нужны ли они там?

        Придумать движок гугла — это изобретение, тут нужна светлая голова. А накодить софта для работы тысяч серверов по всему миру, с разными обвязками и условиями — это уже не изобраетение, это рутинная работа. И она вполне по силе тысяче посредственностей под управлением.

        Сравнение с макаками некорректно. Ребята из статьи собирают людей лучших во всём. Я говорю что можно брать людей с недостатками, например ленивых, или необязательных, или глупых и вместе при правильном построении команды они будут заменять одного уберменша. За счёт компенсации недостатков друг друга, организации, контроля. И это необходимо делать, потому что работы в мире много, а идеальных людей на всю её не хватает.
        • +2
          > А накодить софта для работы тысяч серверов по всему миру, с разными обвязками и условиями — это уже не изобраетение, это рутинная работа. И она вполне по силе тысяче посредственностей под управлением.

          Это вы немного поторопились. Там столько заморочек, что без, как минимум, грамотного архитектора и нескольких хороших разработчиков ничего не сделать.
          Придумать гениальную идею и реализовать её «в железе» — задачи хоть и разные, но требующие хороших спецов в любом случае.
  • +1
    А по какому принципу у вас начисляется зарплата?
    • 0
      Ну хоть статья и называется «почему у нас», но это перевод. Ссылка на оригинал идёт с имени автора оригинала «Cristian Rennella». Не совсем очевидно, но уж такой интерфейс на хабре.
      Вот по ссылке их сайт есть, qz.com, там можно найти всю информацию и спросить.
    • 0
      Видимо сами себе назначают =)
  • 0
    Как именно там программисты всё-таки общаются? Через iAutonomous? Я надеюсь, там есть функция «просто сказать тому-то то-то»?
    • 0
      Я полагаю, там просто есть комментарии к задачам.
  • +1
    Интересно кто увольнял неправильных программистов или кто решал что нужно нанять новых.
    • 0
      Действительно, этот момент за кадром. Я так понимаю, что этот автор статьи как раз один из основателей бизнеса, и он по совместительству HR.
      • 0
        … и по совместительству босс…
  • 0
    С задачами понятно. А как решаются более глобальные задачи, например, как они обсуждают/утверждают архитектуру фронтенда или бакенда не важно?
  • 0
    Очень круто! Немного завидую…
    Удачи:-)
  • 0
    Я считаю, что наша главная особенность – качество нанимаемых нами инженеров.


    Так с менеджерами то же самое.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.