Пустой офис, суббота и продуктивность

Вчера, в субботу, отработав полноценный рабочий день в пустом офисе, в очередной раз убедился, насколько важен фактор тишины и спокойствия в работе программиста. За одну только субботу сделал большую сложную задачу, которую обдумывал уже пару недель. Сделал быстро и качественно - заработало сразу после первой компиляции.
Это уже не первый раз, когда в субботу код пишется быстро и практически сам. Почему?


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


Да, в эпоху Agile и гибких технологий не принято говорить о том, что ты планируешь пару недель, прежде чем написать код. Все пишут сразу. Максимум - набросав небольшой план на доске и обсудив его в команде. Но эффективно ли это? Не хочу разбивать чьих-то иллюзий, но мой ответ - нет, не эффективно.
Мой личный подход немного отличается от этого.
Я всегда стараюсь иметь некоторый пул задач, хотя бы штук 5-10. Это задачи, которые я собираюсь реализовать, но еще не знаю как. Имея такой пул, я могу думать над задачами и заниматься их планированием неделями. Это происходит автоматически прямо в голове. Если ты имеешь задачу и думаешь над ней, то в конце концов решение придет. При этом ты не занимаешься именно “планированием” - ты не отвлекаешься от других дел, пишешь код и т.д., а мозг сам придумывает решение задач из пула.
В итоге через пару недель такого обдумывания у меня есть готовое решение задачи. Всё, что требуется - это просто сесть и закодировать. Часто последняя фаза настолько проста, что даже скучно :)
При этом самое замечательное - никто никогда не заметит этой фазы планирования, т.к. она скрыта. У меня всегда есть пул задач, поэтому всегда в этом пуле есть задачи, для которых я уже нашел решение - их я и реализую постоянно. А пока я делаю их, мозг находит решение остальных задач. В итоге для других всё выглядит так, будто на обдумывание время не уходит совсем! Это эффективно и незаметно для окружающих.


Я использую такой метод долгого предварительного планирования уже несколько лет и он мне нравится. Советую и вам его попробовать, если еще не.



Понравилась статья? Подпишись на RSS!

Похожие записи:
Потоки и память
Знай свою память
Книги + программисты = деньги
Не будите спящего программиста
2 признака кода с душком: убей его и лови всё молча

35 комментариев к Пустой офис, суббота и продуктивность

  • SWW

    Я согласен в тобой насчет того, что работать в тишине - это обалденно. Как было подмечено на предыдущем месте работы Open Space - это ужасно для программиста, отдельные комнаты на команду однозначно решают. Работать в выходные тоже довольно приятно, если задача уже есть или нужен быстрый research, в тишине и без отвлекающих моментов это можно сделать довольно быстро.

    А вот насчет пула задач и того как ты их решаешь я не согласен. Это хаос, так нельзя :) План, подготовленный заранее после обсуждения с командой очень сильно помогает. Распыляться на несколько задач неэффективно как показывает практика, лучше иметь 2 задачи, но не 5 - точно. Почему две? Потому что есть фактор “задолбало писать это гамно” и в этот момент можно перейти к другой задаче, отвлечься, а потом вернуться к первой.

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

      Так я же не против обсуждений и планов. Обычно в голове созревает первичное решение, которое уже с кем-то можно обсудить, если есть сомнения. Либо же сразу сделать :)
      Если вообще ничего не понятно, то обсуждение в команде - это отличный начальный толчок. Иногда даже решение сразу находится. Если же нет - начинаешь думать.

      • G300

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

        А ассоциация с телепередачей “100 к 1″
        - за 15 сек вы должны ответить на 5 вопросов тра-та-та-та………
        поехали. 1 вопрос……тра-та-та….2 вопрос….
        - Извините время вышло….
        -А теперь давайте посмотрим что вы наотвечали…. и герои программы вместе с ведущим ухахатываются над ответами.

        Думаю многим приходится волей - неволей работать в похожем режиме.

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

        Другое дело если обдумывать ответы на вопросы…. но то передача, на этом и построено развлечение, у кого лучше отработают мозговые реакции , ассоциативное мышление….

        А вот на счет пула задач, тут спорный момент, кажется вычисленно определенное число задач оптимальное для эффективного выполнения, превышать которое не рекомендуется, но тут думаю все зависит от конкретного человека, мне кажется для меня, 3 задачи одновременно(последовательно) обдумывать, это потолок, дальше только головная боль и перегрузка нервной системы….

        • Идея не в том, чтобы постоянно думать про эти 10 задач. Это просто пул. Ты про них знаешь и даже не думаешь - решение рождается само. Идея как раз в обратном - не думать о них, а делать что-то другое. И только изредка возникают мысли или новые идеи - тогда вспоминаешь про задачу из пула, а решение уже готово :)
          Если конкретно думать и размышлять, то даже 3 задачи - много.

          • G300

            Согласен, только у наз разные специфики работы видимо =)
            Как только появляется задача, так сразу есть человек, который тебе компосирует мозг - ” а когда будет готово..?”,” а вы про меня не забыли …?” , “а к такому-то числу успеете ?…”

    • Тут идея не в том, что у тебя открыто 5 редакторов и ты одновременно как многозадачная ОС пишешь туда код и все готово. Идея в том, чтобы знать задачи наперед и пытаться решить их оффлайн (в автобусе, в туалете, за едой и т.д). Как показывает опыт, это достаточно эффективно, но порой смахивает на одержимость - мозг постоянно работает и ищет решения (для этого он собственно и нужен). Бывало и так, что сидишь с семьей гдето и вдруг - “дай бумажку! у меня тут идеи!…”
      Я же предпочитаю писать одну задачу за единицу времени, но если решение было продумано заранее, то это проще и быстрее обычно.

    • SS

      Все правильно! Сначала план на этап рассписаный по задачам и разработчикам, потом выполнение. Исключение если есть в команде аналитик, тогда разработчики работают аналитик ставит задачи и оптимально распаралеривает их, но схема по сути та же.
      //Распыляться на несколько задач неэффективно
      Так никто и не заставляет заниматся всем сразу :)
      А иногда переключение необходимо, скажем выполнение твоей маленькой задачки тормозит других разработчиков так не ужели не правильно спланировать что бы все могли работать паралельно и если где то план нарушился можно было поднять приоритет задачи и переключить тебя на эту задачу что остальные были при деле?

  • Andreo

    По поводу пула задач. Абсолютно согласен. Тоже использую такой подход. Сначала рождается идея и я пока не готов ее реализовать, не знаю как лучше сделать те или иные детали, таких идей несколько, даже 5. Идет время и я собираю информацию, параллельно делая то, что уже для меня очевидно. Когда я понимаю, что готов приступить к выполнению - делаю.

  • Интересно, но я использую именно такой подход и прелесть его в том, что решения как бы появляются сами собой, перед сном подумал немного или во время еды и т.д., а когда подходит время кодировать, набросок уже в голове есть и работа идет как по маслу. У меня редко когда пул превышает 5-6 задач, но обдумывать скажем архитектуру таким методом достаточно эффективно (между делом рисуя схемы на бумаге). На практике это выглядит еще впечатляюще (особенно для менеджеров), когда подходит время делать задачу, а ты, только закончив предыдущий таск, предлагаешь уже почти полное решение нового. По опыту, думаю что многозадачность характеризует программиста профессионала.
    ИМХО, метод работает, только если ты сам и есть держатель задачи, а если работает команда, то это даже опасно и явного проектирования не избежать.

    • >> ИМХО, метод работает, только если ты сам и есть держатель задачи, а если работает команда, то это даже опасно и явного проектирования
      >> не избежать.

      При работе в команде тоже есть куча задач, которые запланированы, но еще не продуманы, не обсуждены. И очень хорошо иметь почти готовое решение прямо перед обсуждением :) Так что пул задач и тут помогает.
      Но всё зависит от ответственности - если ты рядовой и не хочешь брать ответственность и решать сам, то будешь ждать общего обсуждения и там уже думать. Но по мне так лучше самому заранее подумать.
      Даже если кто-то предложит лучшее решение - невелика беда, результат не пострадает.

  • какой ужас.. чем то напомнило Бредбери с его Фаренгейт 451 только в отношении программеров
    “Гай сидел тихо и тупо набирал что то на клавиатуре, стараясь не показать черезчур подозрительным коллегам, что он обдумывает задачу, так как в эпоху тотального Agile это было чревато свиданию с железным псом”

    • Ага, типа того :)
      На самом деле скрам настолько гибок, что можно запланировать специальный таск - планирование и планировать.
      То есть, всё не так плохо. Просто я не люблю планировать 1 задачу в 1 единицу времени.

  • Если работать без пула (например Agile), то придется много переделывать, ибо работа предполагает схожие задачи и соответственно общие механизмы…

    • В Agile нет пула? Это не совсем так.
      Если команда видит пул одинаковых задач, то она может их взять и сделать себе пул. Даже если не всё за 1 спринт будет сделано - это не проблема, можно растянуть надольше, пока продукт не ломается от разбиения.

      • Пулы немного разные, будет поспешно сделана работа, от которой впоследствии избавятся. Этого можно было бы избежать, если бы пул держался больше времени и тем самым было время для обдумывания.

  • mich

    Это реальная фотография оффиса F-SECURE?

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

    • Я бы не стал так просто называть всех, кто использует Agile “неспособными”. Иначе так можно далеко зайти и решить, что в Microsoft, IBM, Google - везде одни неспособные, раз Agile.

      • Исследовательские лаборатории обычно работают в своём режиме. В производстве. Ну да, можно много говорить о М$ и IBM. C Гуглом внутри тоже не всё чисто.

        Потом, не надо путать рекламные слоганы с религиозным верованием.

  • ваш офис на фотке?
    мониторы образца прошлого века…

    у меня рабочий настрой слабо связан с внешними факторами, мне кажется он полностью зависит от “внутренних” процессов.

  • В итоге может оказаться, что “после пары недель обдумывания” и субботнего программирования ваше решение (тут есть варианты):
    - То, что нужно. Ура!
    - Не совсем то, что нужно :(
    - Совсем не то, что нужно. :((

    Часто нужно очень быстро выкатить какую-либо “альфа”-версию и получить быстрый фидбек, а потом ее можно усовершенствовать. За те две недели, которые тратятся на обдумывание можно рассмотреть до трех таких альфа, понять, какая из них достойна развития и развивать уже ее. Продакт менеджемнту же хочется побыстрее все пощупать в живую а не на словах. А так получится, что даже обсуждая все и со всеми две эти недели и выкатив потом нечто, окажется, что это не совсем, то, что вы обсуждали, или Вас не так поняли, или одни и те же термины понимаются по-разному Вами и коллегами - и что? еще две недели?? Не айс.
    Другое дело, если Вы сами себе и заказчик и пользователь и разработчик - это да, можно и по три недели мусолить мысль, но, обычно эти продукты и не нужны никому больше.
    Я считаю, самое важное, чтобы фидбек был настолько быстрым насколько возможно.

    • Безусловно, если тебе дают новую задачу и надо ее прототип сделать через 3 дня - мой метод не подойдет. Но за такие задачи вообще надо посылать менеджеров. Любую задачу надо обдумывать и не должно быть таких мгновенно возникших сложных задач. Если она простая и думать не надо - тогда пожалуйста.
      Но если это креатив, но должно быть готово через 3 дня - пусть идут лесом.

    • SS

      Ой не надо, ой бросьте :)
      Проекты разные бывают! :) Вот например какие проеты бывают, “… быстро модифицируем старый проект и выпускаем новую версию чтобы можно было по тестить посмотреть, покрутить… Ребята не раслабляемся дорога каждая минута!!! Релиз через два года!!!” :)

  • Ninibel

    В принципе описанные условия работы желательны для любого интеллектуала. Помните в старых романах - “папин кабинет”. Папа работает дома, его нельзя беспокоить. Присутственные места для чиновников выглядели иначе: большая комната, ряды столов, много людей. В ХХ веке интеллектуалов тоже заставили сидеть на “стадионах”, в лучшем случае с перегородками (часто низенькими и иногда прозрачными). Результат: не просто низкая эффективность работы, а вообще нулевая. Я вчера собирался отредактировать 10 страниц текста, требующего внимания на каждом знаке. В результате ничего не сделал, взял его домой на выходные, т.к. не уверен в том, что получится без ошибок. Стресс, злость, ненависть к окружающим. А все потому что комната - проходной двор, каждые 10 минут “здрассте”, “досвиданья”, телефон 1, телефон 2, телефон 3, ответы на вопросы и т.п. В таких условиях эффективно не будешь даже коробки клеить.

  • Недавно с интересом отметил, что за 2 часа работы дома перед сном успеваю сделать больше, чем за 8-часовой день в офисе. Хотя, это и не удивительно – на работе через каждые 20-30 минут приходится переключаться на другие задачи. Поэтому на домашние спокойные два часа оставляю проектирование (оно требует максимального сосредоточения), а на рабочие часы – кодинг. Проектировать на работе практически невозможно.
    О важности проектировании полностью поддерживаю. Перед тем, как сесть за кодирование, поэтапно формализую задачу до состояния, когда кодинг становится почти тривиальным. Нахожу это очень эффективным.
    Насчёт пяти задач в пуле. Готов поверить в эффективность, хотя у самого подход получается слегка иной. 1-2 задачи для текущей проработки и масса задач, над которыми не работаю (и пока не собираюсь), но они мне интересны. Так вот, время от времени неожиданно всплывают фрагменты решений по этим фоновым задачам. Эти фрагменты я тут же записываю в файлы с названием задачи. В итоге, в каждом таком файле скапливаются разносторонние соображения по конкретной задаче. Когда впоследствии данная задача становится активной, у меня уже есть масса соображений, которые трудно вызвать насильно, по заказу.
    Но вместо того, чтобы просто прочитать эти соображения и взяться за задачу, я поступаю хитрее. ;) Сначала пытаюсь проработать задачу, как бы, с нуля.

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

      Ага, в этом вся суть.
      Вчера прочитал у кого-то в жж отзыв, что то, что я написал похоже на Latency и Throughput в процессорах. Не такая уж и большая у нас пропускная способность для решения задач, но мы можем увеличивать Latency и тем самым решать много больше задач в единицу времени :)

    • У меня аналогичная ситуация - быстрее всех работаем вечерами.

  • Bishop, Мне это напомнило старинную статейку.
    Сейчас вот нагуглил ее: - Еще раз о настоящих программистах.

    Все уже сказано до нас. :) Почти 20 лет назад.

    “Работа хакера напоминает работу столяра, забивающего гвоздь одним ударом молотка. Хакер некоторое время ходит вокруг машины (радиус хождения может составлять до нескольких тысяч километров), затем садится за клавиатуру и делает за один вечер то, на что было выделено 15 дней. Не надо думать, что четырнадцать дней, которые хакер потратил на хождение вокруг машины пропали даром: все это время хакер подсознательно обдумывал поставленную задачу. Другое дело, была ли необходимость в этих раздумьях.”

    • Ага, типа того. Только я эти 14 дней не просто хожу, а делаю те таски, которые обдумывал в предыдущие 14 дней :) Так что, за 20 лет хакеры стали опытнее :)

  • Спасибо. Попробую тоже что-то на подобие пула задач сделать. И тишина действительно решает)

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>