По поводу рабочего графика программистов.

Один из читателей блога задал вопрос:

Как лучше всего распределять время и рабочий график программиста?

Я это спрашиваю в связи с тем, что в последнее время стал замечать, что совершенно не могу работать в офисе. Меня эта обстановка сковывает и я целый день занимаюсь фигнёй и ковыряюсь в интернете. Но совершенно по-другому обстановка выглядит дома. Тут я могу сосредоточенно думать, могу писать код по 4-5 часов подряд. И всегда, самые интересные мысли приходят когда я занимаюсь совершенно посторонними вещами.

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

Не уверен, но думаю не у одного меня такое ощущение: приходишь на работу работать, потому что это надо не тебе, а директору. Хотя хочется приходить на работу творить и создавать новое, ради удовольствия.

Как я понимаю, под «распределять время/рабочий график» имелось в виду «когда, где и как» работать.

Разобью вопрос на несколько частей.

1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?
2) Какие методы хороши для каких видов работы?
3) Куда послать директора или что нужно фирме?
4) Творить или не творить?

Итак пойдем по пунктам.

1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?

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

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

2) Какие методы хороши для каких видов работы?

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

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

3) Куда послать директора или что нужно фирме?

Если вы работаете в обстановке, которая не подходит для вашего типа деятельности, то это может обозначать несколько вещей
Категория недопонимание:
— вы делаете не тот тип деятельности который от вас на самом деле от вас ожидали (например, вы — team lead и должны со всеми общаться, а вы хотите на неделю запереться дома и активно педалить код)
— просто ваше начальство не осознает, что вы могли бы быть более продуктивным работая по другому.

Тут, все просто. Вы идете и в спокойной обстановке обсуждаете, как сделать так, чтобы и вы и фирма выиграли (вы получили более подходящий метод работы. фирма получила более эффективного программиста).

Категория несоответствие:
— вы осознаете, что от вас хотят (например сосредоточение на коде), но вы хотите совсем другого (team leader’ство с постепенным переходом в менеджеры)
— вашей компании может не быть прямой выгоды от того, что вы работаете эффективно (например для тех компаний которые берут внешние проекты c time&material оплатой, может складываться ситуации, когда выгодно чтобы программист делал как можно дольше (естественно удерживая это ниже уровня, когда заказчик уйдет)

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

Категория конфликт:
— вы и компания хотите чего-то одного (например эффективности), а ваш прямой начальник хочет чего-то совсем другого (минимального напряжения на работе, при игнорировании целей фирмы).

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

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

3 комментария to “По поводу рабочего графика программистов.”

  1. Согласен с тем что имелось ввиду по поводу задач и мест их решения в разное время и место, но категорически не согласен с тем что надо тишком-нишком свалить на другую контору, если менеджер не прав. Да, ошибки менеджеров чаще всего приводят к этому, но посудите сами, вдруг на следуюущей фирме такой же менеджер или проект хуже и надо все по-новой начинать, вот тогда что делать, опять отправлять резюме и так до бесконечности пока не найти идеальное место или как?

    • Victor Ronin:

      Где-то 8-9 лет назад я решил не «тишком-нишком» уходить, а устроить полноформатную войну с менеджером (пошел через его голову к следующей ступеньки (который был владельцем фирмы)).

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

      А теперь внимание вопрос, кому я сделал этим лучше?

      Плюс, по пришествию достаточно долгого времени, когда я уже и сам побыл менеджером, я понял, что где-то на процентов 30% сам был не прав в той ситуации.

  2. Да, конечно, работать по расписанию в офисе не для всех разработчиков удобно и максимально комфортно, но здесь преследуются и цели менеджера/тим-лидера и в общем команды:
    — разработчик в зоне досягаемости в предсказуемое (рабочее) время, менеджер может узнать у него состояние задачи, на которой он усердно работает
    — есть возможность участникам проекта по-быстрому обсудить возникший проблему, вопрос и т.п.
    — у менеджера есть некая уверенность, что разработчик занимается не фигней, а делом. Хотя тут, конечно, больше показуха и самовнушение у менеджера