(на фото — известный стритарт от Banksy, фотограф — Niv Singer)
Как мы держим руку на пульсе, чтобы работа компании была эффективной, и почему это работает – под катом.
Мы доверяем своим сотрудникам. Довольно банальное заявление для рассказа о контроле, но это действительно так. Вместе с тем я согласен с известной пословицей: «Доверяй, но проверяй». И мы доверяем, но контролируем. Однако углубиться в детали этого контроля нельзя без некоторого введения в первоначальные договоренности и задачи, которыми мы занимаемся.
О чем мы договариваемся на старте
При приеме на работу с сотрудником оговариваются все условия – мы придерживаемся политики максимальной прозрачности. Никаких «я подразумевал» – все нужно обсудить.
По каждому из пунктов мы стараемся быть гибкими – учитывать особенности жизни ребят из разных регионов, их личные пожелания. К примеру, у нас есть некий стандартный график – с 8-9 до 17-18 часов по Москве с учетом часового обеда по рабочим дням, в соответствии с производственным календарем РФ. Но иногда у сотрудника есть личные обстоятельства, из-за которых он хочет закрепить за собой, например, двухчасовой обед или перерыв в нестандартное время. Свои особенности могут быть и у проектов, на которых будут работать специалисты (предположим, клиент, с которым надо держать связь, находится в другом часовом поясе). Все это мы обсуждаем на старте.
Подробно обсуждается не только график работы, но и другие аспекты взаимодействия, к примеру обязательства относительно релизов (тот факт, что вся команда должна быть доступна в оговоренное время), возможность командировок один-два раза в год и т.п. По сути, мы договариваемся о рамках, внутри которых будем сотрудничать.
У нас есть условия, которые необходимо соблюдать в случае нарушения этих рамок. Если возникают обстоятельства, из-за которых нужно начать позже, закончить раньше или вообще не выйти в определенный день, все должно происходить открыто: сотрудник должен предупредить свою команду. Теоретически пропущенные часы необходимо отработать, но в корпоративной политике у нас предусмотрен некий временной люфт, за который никто не накажет: двое суток в году каждый сотрудник имеет право потратить на свои дела, не объясняя причин. Если «разрешенные прогулы» закончились, всегда можно взять день от оплачиваемого отпуска или отгул за свой счет, ну или отработать по согласованию с командой. Главное – предупредить. Гибкими условиями мы стараемся свести к минимуму необходимость как-то выкручиваться и нарушать договоренности.
Нет слежке!
Изначально выстраивая процессы удаленной работы, мы не стали тратить усилия на введение практики контролирующих звонков сотрудникам или внедрение инструментов микроменеджмента – средств контроля присутствия онлайн или видеонаблюдения через веб-камеры. С моей точки зрения, для интеллектуального труда они бессмысленны. Сначала требуется вложиться в покупку инструментов, потом тратить время и силы на разбор отчетов. Но ответа на главный вопрос – решил ли сотрудник поставленную задачу – они все равно не дают.
Наша позиция объясняется еще и тем, что сотрудники, у которых с самоорганизацией все в порядке, негативно относятся к подобным инструментам. «Результатники» испытывают дискомфорт, когда за ними пристально наблюдают. Снижается мотивация, а мы не можем этого допустить.
Мы не «процессники»,
мы – «результатники»!
В первый год работы «Максилекта» у нас даже был проект на Upwork, где мы отказали клиенту во включении средств контроля, т.к. считаем, что наши сотрудники не должны работать под счетчиками (на уровне Upwork он требовал скрин экрана нашего сотрудника раз в 10 минут). Несмотря на наш отказ, клиент согласился с нами работать и остался доволен итоговым результатом. Тогда мы сошлись на том, что трудозатраты будем списывать вручную, высылая короткие еженедельные отчеты. Вопросов по ним в итоге не было.
Контролируем результат
До сих пор речь шла только о наших договоренностях с сотрудниками. То, как мы контролируем их соблюдение, зависит от особенностей проекта.
«Максилект» в большей степени ориентирован на выполнение сложных задач под ключ. При такой постановке вопроса мы сами решаем, как прорабатывать проект, и декомпозируем задачи на элементарные составляющие. А дальше идет обычная работа проектного менеджера или тимлида (в некоторых проектах – их совместное участие) в соответствии с agile-методологией. Как и у всех, у нас тоже есть недельные спринты и ежедневные созвоны, позволяющие координировать разработку.
Мы предполагаем, что все заявленное время сотрудник занимается полезной работой. Исходя из этого, распределяются задачи, назначаются видеоконференции и т.п. Ведь рабочий процесс – это не просто получение задач на неделю и их выполнение в гордом одиночестве. Команды постоянно взаимодействуют – при удаленном формате работы это даже важнее, чем в офисе. Незаметно «исчезнуть» из всего этого взаимодействия невозможно.
Поскольку все происходит внутри команды, контроль на удаленке фактически ничем не отличается от контроля в офисах распределенных компаний, когда, например, одна часть команды сидит в регионе, а другая – в столице. Возможные накладки по срокам, отставания отдельных сотрудников и прочие неприятности если и возникают, то становятся заметны примерно в течение недели, что позволяет оперативно реагировать на ситуацию. Иными словами, никаких принципиальных сложностей здесь нет.
На некоторых проектах у нас есть учет рабочего времени для внутренних нужд. Он, естественно, реализован не через автоматическую слежку, а через ручную отчетность («одну задачу делал столько-то часов, другую – столько-то»).
Мы не используем распространенные способы оценки коллектива и его вовлеченности, например метод 360 градусов, поскольку перед нами не стоит задачи измерить работу наших сотрудников по HR-метрикам – они не дают нам необходимой информации. Все проектное общение идет неформально, на человеческом языке. Но чтобы видеть ситуацию более-менее объективно, по каждому сотруднику у нас есть план на ближайшие несколько месяцев, где указываются задачи, которые он должен решить, и личные цели, например изучение новых инструментов, технологий, языков программирования. Этот план формируется сотрудником совместно с его непосредственным руководителем.
Защищаясь от «выгорания» технических специалистов, мы даем возможность сотрудникам перейти в другой проект, если, например, «приелся» стек технологий. Компания изначально заявляет, что это нормальная практика, которая не приводит к экономическим или иным санкциям, поэтому о подобных проблемах сотрудник свободно сообщает на ранней стадии и мы можем провести замены на проекте с минимальными потерями, проговорив все перестановки и предусмотрев время на обучение нового специалиста.
Есть у нас отдельные проекты, где часть команды «Максилект» работает бок о бок со специалистами заказчика. И головной боли с точки зрения контроля они доставляют больше. Разница здесь принципиальная. В первом случае мы имеем обычную внутреннюю команду, а во втором – к части команды у нас просто нет доступа, да и влияние на проект ограничено установленными на старте рамками. В этой ситуации спасают взаимоотношения с заказчиком, выстроенные совместными усилиями.
Наш основной инструмент контроля решения задач – сбор обратной связи от клиентов, на чьих проектах работают сотрудники. Аккаунт-менеджеры общаются с клиентом не реже двух раз в месяц, обсуждая, решает ли каждый отдельный сотрудник в команде и команда в целом поставленную задачу:
- качественно ли выполняется работа,
- вовремя ли она выполняется,
- есть ли недоработки,
- что понравилось или не понравилось в работе за последнее время,
- что нужно улучшить в работе конкретного специалиста.
Те же вопросы (только гораздо чаще) мы задаем команде – это позволяет менеджерам получить понимание того, в каком состоянии находится проект, как если бы это была внутренняя команда.
Выше я упоминал, что в рамках постоянных созвонов мы обсуждаем не только проект, но и личное развитие сотрудника. При работе сотрудника вместе со специалистами заказчика свои «пять копеек» в его личный план развития может внести и клиент, если, по его мнению, сотруднику не хватает некоторых технических компетенций.
В итоге получаем контроль на уровне ключевой метрики – качества (в контексте разработки – code style, сроки и т.п.) – без промежуточных и бесполезных для нас данных, вроде открытых на компьютере сотрудника сайтов или сотен фотографий его рабочего стола. А кроме того, все довольны. Пожелания клиента учитываются, работа идет. Сотрудник имеет определенный уровень вовлеченности в проект (не просто пишет код, а становится частью проектной команды) и получает необходимую ему обратную связь.
Все работает, но есть ограничения
Понятно, что не каждого сотрудника можно встроить в наш рабочий процесс так, чтобы его вклад был оценен участниками. Сотрудники должны быть организованными и обладать рядом софт-скиллов. Встретившись с проблемой, они не могут сидеть и ждать, пока она сама разрешится, а должны попробовать решить ее самостоятельно. Если же без стороннего участия решение невозможно, проблему необходимо озвучить. Это могут не все, поэтому мы учитываем необходимые нам софт-скиллы при найме (об этом мы недавно писали). И это еще один компонент нашей системы контроля: те, кто, по нашему мнению, не впишется в процесс, просто не пройдут собеседования.
Хочу оговориться, что какими бы софт-скиллами ни обладал сотрудник, у всех бывают моменты, когда голова не работает: во время болезни, семейных неурядиц и т.п. Для нас это не повод увольнять. Но мы ожидаем, что сотрудник сам нам сообщит о проблеме, и мы вместе найдем решение (например, предоставим незапланированный отпуск). Даже если явного разговора об этом нет, в ходе личного общения мы все равно видим изменения и пытаемся помочь. Контакт с сотрудниками важен еще и с этой точки зрения.
Бюджеты и сроки
Ошибки случаются у всех. Были промахи и у нашей системы контроля. Но мы строим все процессы так, чтобы цена ошибки была минимальной.
Любую задачу мы декомпозируем на фрагменты длительностью не более 32 часов. С одной стороны, это требует больших трудозатрат на этапе оценки. Учитывая это, мы не участвуем в конкурсах, тендерах и других оценках, где пресейл с малой вероятностью приведет к проекту. Но зато в тех переговорах, где дело дошло до расчета стоимости, стараемся получить на этом этапе максимальную детализацию. Дополнительные 8 часов, потраченные на детали, позволяют сэкономить бюджет проекта и уложиться в первоначально озвученные сроки. Это касается проектов обоих упомянутых типов.
Если по каким-то причинам сотрудник не справляется, мы узнаем об этом не через полгода, а через несколько дней, в самом худшем случае – через пару недель. Может быть, у сотрудника есть объективные проблемы или же он использует не самый оптимальный подход для решения – тогда мы подключимся и поможем.
У нас уже были такие ситуации, когда «съезжали» сроки, – это было видно и по количеству решенных сотрудником условно-одинаковых по трудоемкости задач, и по отзывам клиента (проблемы были как раз на проектах, реализуемых совместно с сотрудниками заказчика). И как раз тогда отработали все механизмы контроля на ранней стадии. Еще до того, как клиент открыто заявил о проблемах, были заметны первые звоночки внутри команды. В одном из кейсов у нас даже оказался небольшой запас времени на то, чтобы дать человеку исправиться. Ну а когда он не воспользовался шансом, мы все равно справились с ситуацией так, что это почти не отразилось на проекте. С сотрудником пришлось расстаться. Хотя, честно скажу, для тех, кто какое-то время проработал в компании и показывал результат ранее, увольнение рассматривается как крайняя мера. До него мы стараемся найти какие-то точки соприкосновения и разрешить ситуацию иным способом.
Вместо итогов хочу отметить, что наша схема вряд ли может быть внедрена в любой компании. Здесь необходимо прорабатывать всю, как это называется, корпоративную культуру, меняя фокус с процессов на результат. «Максилекту» было сравнительно легко, поскольку компания строилась так изначально. Хотя многие вещи пришлось изучать на собственном опыте. И мы продолжаем этот путь, улучшая процессы по мере приобретения нового опыта.
Автор статьи: Сергей Марина
P.S.: Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Комментарии (36)
Anton23
09.10.2018 11:44И чем обусловлена «идеология удаленной работы»? В чем ее преимущества для вас?
Maxilect_pr Автор
09.10.2018 13:40В доступе к лучшим кадрам. В возможности не привязываться к физическому месту работы. Это многие уже считают роскошью 21 века. Мы ценим эту свободу, которая, безусловно, требует повышенной ответственности.
Varim
09.10.2018 12:09восемь часов действительно работает
Это очень общее понятие. Что именно это значит для вас?
Когда работаешь в офисе, то 8 часов — это время нахождения в офисе. Максимум дня два в неделю удается покодить 6 часов в день. В обычный день, в среднем 4 — 5 часов кодишь или разбираешься. Остальное время тратится на не понятно что — на поболтать, чай, кофе, отдохнуть.
И это, по моему мнению, нормально, человек не выдержит длительно более интенсивных нагрузок.
Когда читаешь спеки или доки по библиотекам то 80% времени ты читаешь, а не кодишь.
Как вы проверите на что ушло время?
Или когда общаешься с сотрудниками / заказчиком, то вообще за три дня не пишешь и строчки кода.
У меня на удаленке получается что 7 (без обеда) часов я отрабатываю за 11 часов реального времени (с обедом 1 час). То есть по помодоро 7 часов чистого времени, без учета времени перерывов — а астрономическое 11 часов. Это норм? А как вы учитываете или требуете часы?Neikist
09.10.2018 12:22человек не выдержит длительно более интенсивных нагрузок
На самом деле выдержит, но недолго, я помню первые полгода-год работы своей 8 часов работал (именно код писал, хотя скорее пытался))), плюс после работы часа по 2-3 изучал платформу, плюс на выходных старался хотя бы часов по 5 когда работать когда учиться. В итоге заработал нервный тик и еженедельные головные боли, но освоился со временем. А нервный тик быстро прошел, за несколько месяцев после выхода из такого режима. Спустя пару лет и голова теперь болит гораздо реже, раз-два в месяц.
Сейчас у меня режим такой: 4-5 часов на работе стараюсь именно код писать, ТЗ, ТП и подобное, остальное чай, печеньки, совещания, чтение статей. + в дома час-два на продолжение изучения программирования в день, + опять же дома пол часа-час в день на японский язык. Правда подумываю его или чередовать с английским, либо английский сверху накинуть. А на выходных в основном отдыхаю. Часа 3-4, не больше, на учебу. Немного еще уточню, вообще обычно больше по времени непосредственно на работу уходило, часов по 7, но сейчас чуть расслабиться себе позволил. Еще немного подумав: интересно, а куда относить время когда например в душе над рабочими задачами думаешь или за завтраком?))
Хотя кто то может и дольше в более напряженном графике выдержать, от человека зависит.
JustDont
09.10.2018 13:34На мой опыт больше чем 70% продуктивно использованного рабочего времени — это либо кратковременное состояние, либо утопия. Даже в близких к идеалу случаях (нет препятствий, совещаний, вопросов от коллег, и тэ дэ) — из восьми часов рабочего дня минимум час уходит на информационную логистику — почту прочитать, исходники обновить, и тому подобные мелочи. Второй час и более уходит на перерывы вида «встали и выдохнули», сидеть без движения приёмами свыше 3-4 часов мало кто может.
А уж если случай не идеальный — то будет еще больше вынужденных перерывов в работе, и не все из них попадут на твои собственные перерывы.
Итого да, вы всё правильно написали, из 8 часов покодить 6 — это максимум, и даже он далеко не всегда выходит.
Maxilect_pr Автор
09.10.2018 13:41+1Мы не требуем 8 часов непрерывного кодинга, если вы об этом. Рабочий процесс включает планирование, изучение новых технологий, code review для разработчиков и автоматизаторов тестирования и т.п. Все это закладывается на этапе оценки проекта.
ayevdoshenko
09.10.2018 15:32Тоже посчитал — 3-4 часа в день именно на написание кода. Тому несколько причин:
1. Прежде чем писать — надо понять что именно надо написать. Придумать архитектуру решения, если речь не идет об узкой задаче. На это уходит много времени, в рамках проекта — до 30%.
2. Поняв что надо сделать — надо понять как это сделать. Есть, конечно, наработки, но всегда есть и альтернативы, всегда есть что-то свежее. В итоге, требуется написать прототип решения, иногда — несколько, чтобы оценить что выбрать. Если сроки сильно ограничены — делаю так, как наиболее знакомо, но при этом заказчик получит возможно не лучшее решение. Это еще 30% времени.
3. Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость. Производительность со временем падает, ничего хорошего не получается. Можно работать больше, если не прикладывать усилий для разбирательства в делаемом — то есть шпарить по шаблонам, но это опять же в ущерб возможностям и не всегда вообще это доступно в силу специфики задачи. — Это еще 30%
Еще 10 оставшихся процентов — это развертывания всего на свете, деплои, тесты и прочая.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа — итого шесть, еще около 2-3 часов отвожу на изучение платформ, инструментов, технологий, на эксперименты. Работая больше — ловлю себя на том, что острота мысли падает и в итоге работаешь отнюдь не лучше и продуктивнее, а совсем напротив.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить… Что тут сложного! На всякие раздумья и прочее их жаба смотрит осуждающее и с полным непониманием.lastrix
09.10.2018 22:48Тоже посчитал — 3-4 часа в день именно на написание кода.
Зависит от тренировки. Если начинал с самого детства, то лет за 10 можно и 6-8 часов в день выдерживать. Зависит еще сильно от общего физического состояния.
В 14 лет с трудом выжимал из себя 15-40 минут непрерывной концентрации на коде — поэтому везде ходил с блокнотом и карандашом — писал всякую хрень. К 30 годам 6 часов непрерывной умственной нагрузки — даже усталости нет.
Однако при приближении к 8 часам есть снижение всех когнитивных навыков, т.е. вообще всех, падает реакция, глаза болят и висок ноет (левый). По 7-8 часов в день больше 14 дней подряд не выдерживаю, нужен отдых. Силой никто не гонит, просто "хочется еще".
Если так весь год работать, то нужен отпуск примерно 48 дней.
Субъективно, согласен — но пища для размышлений есть.
Поняв что надо сделать — надо понять как это сделать
Так ведь уже сказали, что декомпозиция осуществлена. Все остальные операции — уже очень легкие и не требуют существенного труда.
Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость.
Описал выше. Тренировка и общая физическая подготовка. Стоит обратить внимание на ваше питание. Почитайте про то, как маленькие улучшения коммулятивно дают прирост в разы.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа
Такой же подход, отвлекаюсь на приготовление обеда и т.д. Отвлечение на другую деятельность лучше всего позволяет мозгу отдохнуть.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить…
"Многие" даже траншеи не копали. На прошлой работе начальник вполне легко мог отвлечь посреди задачи, или вовсе что-то обсуждать.
Это не проблема кодинга, а проблема воспитания людей и коммуникации между ними. Вы же не сможете в деталях объяснить быт и труд шахтера? Каждый человек живет в своем мире, просто у кого-то он размером с горошину — представления о других людях соответственные.ayevdoshenko
10.10.2018 06:32Мои 3-4 часа — это наиболее плодотворные часы, когда создается что-то новое в проекте, естественно, бывает и больше, но в среднем — примерно столько в день. Больше 4 часов такой активной работы по моим наблюдениям — это уже приглаживание кода, пробы, отладка и т.д., но никак не наращивание функционала проекта. Поэтому я свой день и делю на две половины — в первую у меня обычно творческий подъем, я с прошлого вечера наметил и обдумал что и как сделать — а с утра начинаю воплощать. Заряда и придумок хватает как раз где-то на 3-4 часа.
Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.
Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!lastrix
10.10.2018 11:04Вы уже сами описали, что смешали работу нескольких специальностей.
Я же описывал именно "возможность" напрягать мозги в одном направлении в течении долгого времени. По опыту — максимум возможностей — 8 часов, и то после тренировок. И кстати результаты совпадают с общественной практикой, люди вообще больше 8 часов в день не могут продуктивно работать над чем-то в течении всего года. Замечу, речь именно о среднесуточной нагрузке в течении года, а не "две недели 60 часов отработал, а потом неделю отдыхал".
Когда есть возможность смешивать работу — ревью, очистка, отладка и т.д. — это облегчение работы.
аналитика, менеджера, программиста, тестировщика и DevOps.
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Но в целом — да. У нас так хаят "неквалифицированную рабочую силу", что забывают насколько "заказчики" бывают недалеки и неквалифицированны вообще во всех сферах кроме "заплатить меньше, получить больше".ayevdoshenko
10.10.2018 11:23Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.
Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))
Estee
09.10.2018 16:08А зачем у вас такой жесткий график 8/9-17/18 по Москве? Почему гибче не получается?
Maxilect_pr Автор
09.10.2018 16:20Получается. В индивидуальном порядке — в зависимости от деталей каждого проекта.
CheY
09.10.2018 18:28Диссонанс какой-то. Вы оцениваете «результат», но при этом строгий 8-ми часовой рабочий день. А если я результат могу за 5 часов предоставить?
Maxilect_pr Автор
09.10.2018 18:47Если сможете дать необходимый результат за 5 часов, то нас это устроит.
geekmetwice
09.10.2018 19:24+7Мы предполагаем, что все заявленное время сотрудник занимается полезной работой… Команды постоянно взаимодействуют – при удаленном формате работы это даже важнее, чем в офисе. Незаметно «исчезнуть» из всего этого взаимодействия невозможно.
Не будь это ваш реальный бизнес, я бы счёл это очередной утопией хабрашкольника. Потому что сам программирую и вот эти ваши «контроли без контроля» выглядят как-то непонятно.
Для начала, как правильно заметили и другие комментаторы, никто не работает 8 часов. И даже четырёх. Забудьте ваши странные «рабочие часы» — это всё пережитки рабовладельческого строя. Хороший программист «топчет клавиши» 2 часа максимум. Остальное — размышлизмы над кодом, вялое чтение мусора под названием «документация к библиотеке», поиск бедолаг по конкретному затыку и периодические «ответы на важные письма» с каких-нибудь Фишек. И это нормально — это мозг, которым нельзя работать 100% дня.
Далее, само понятие «удалёнки» — для меня это не просто возможность не везти задницу в офис и не стоять в пробках — это ещё и ГИБКИЙ ГРАФИК. Гибкий — не в вашем стиле «предупреди, мы найдём решение», а именно что я решаю, когда мне удобнее работать. Я вообще могу днём поехать в магазин — мне что, опять как ребёнок отпрашиваться у мамки? А не устанете «находить решения»? :)) Собственно, в этом и весь смысл — иметь свободный график и делать работу в максимально производительные для себя часы! Например, у меня это после 13 и вплоть до 24. Ну и нафик вы мне нужны в 9, когда я даже третий сон не досмотрел? :) Есть задача — пишите в таски. Нужно совещание — планируйте за день и мы дружно скайпом соберёмся. Но сообщать о каждом чихе — вообще не упёрлось, тогда уж снимайте офис!
И вот это вот «исчезнуть из взаимодействия» — вы чем вообще занимаетесь — программируете или бесконечно совещаетесь?? Я вообще-то и ударить могу, если меня будут отвлекать каждые полчаса от программирования! Если я В ПОТОКЕ, меня отвлекать нельзя. Точка. Это знает любой мало-мальский менеджер проекта. Поэтому я должен и буду «впадать в нирвану», где я пишу код со скоростью мысли. Довольно странно выглядит ваш процесс, если в нём человека дёргают весь день! Может, вы чего-то недообъяснили?
В налаженном проекте «совещания» и нужны именно, что раз в неделю — остальное время ты решаешь задачу, пишешь, тестируешь — сугубо индивидуальная работа.
Короче, мне кажется, вы только играетесь в «удалёнку», почти ничем особо не отличающуюся от «очной» офисной мутотени — разве что за компом можно сидеть в пижаме. :) А я-то думал светлое будущее программистов ближе.ayevdoshenko
09.10.2018 20:14+2Плюсанул бы, но нет правов: ) Я в последние полтора года работаю на фрилансе. Точнее — на подряде, проектно и со свободным графиком — есть план с дедлайнами по этапам, а внутри этого периода я могу работать где и сколько угодно — моя задача принести в клювике к обозначенному сроку результат.
За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.
И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
kolyan222
10.10.2018 10:21Если я В ПОТОКЕ, меня отвлекать нельзя. Точка.
Именно так. И от формата работы офис/дом это не зависит.
Хоть табличку такую делай и ставь к себе на стол.
CheY
10.10.2018 10:35Я бы, наверное, плюсанул, но всё же позиция немного эгоистична и в рамках проекта может быть вредна. Ситуации, когда возникает какой-то важный вопрос, который требует привлечения внимания разработчика и который гораздо важнее его «потоков», случаются. Факап, упавший сервер, критический баг… вариантов много и наверняка каждый сталкивался. И если в этот момент оказывается, что разработчик отъехал в магазин на пару часов и не известно, когда вернётся, то это плохо. Заводить на этот счёт баг в трекере, назначать совещание на завтра и сидеть на попе смирно — это верх бюрократии и неэффективности.
Нет, часы онлайн-присутствия и доступности должны быть обязательно оговорены. А о всяких «отъездах», «дневных снах», «купаниях в море тая» нужно предупреждать команду. Мир не сошёлся на программистах и в работу вовлечены многие люди. И работать так, чтобы не тормозить работу других — важный скилл.lastrix
10.10.2018 10:57Это решаемо, но в целом — да. Возможность хотя бы экстренно выйти на связь в случае ЧП — очень важна.
Либо же просто не работать в таких областях, где такое может произойти.
lastrix
10.10.2018 11:22Однако в защиту товарища хотелось бы упомянуть, что обычно у нас капиталисты говорят о каких-то рисках и прочее, однако вот оборотной стороной (прибылью) никогда не делятся с работниками.
Не про безответственное отношение сотрудника, а про любителей каждую проблему выдавать за срочную и исключительно по вине сотрудника (неоплачиваемую).
Но опять же, лично мое мнение, что возможность вызвать сотрудника в случае ЧП в любое время — это реально важно. Факторы бывают разные. Невозможно все предусмотреть на всех уровнях.
geekmetwice
10.10.2018 13:54Давайте начнём с того, что к серверам разработчик вообще никакого отношения не имеет. :) Это типично русские программисты — и швец, и жнец, и на серверах игрец (собственно, они потому и падают :))) ).
Есть продукт и период его разработки. Пока продукт не релизнут, его не существует и все проблемы решаются планомерно, вносясь в общий план работ. После релиза — ради бога, объявляется «неделя алерта» и все сидят и ждут грома с неба — я только «за»! Но в целом, «удалённая работа» должна иметь какой-то смысл для программиста! Фирма, не снимающая офис, не покупающая мне рабочее место, ПК, интернет, канцелярию, кулер и т.п. экономит сумашедшие бабки, при этом ни цента с этих бабок я не вижу. Но при этом они хотят, извините, «держать меня за яйца» весь рабочий день. Я вообще-то человек, у меня тоже есть куча проблем и если боссу достаточно развернуться задом и «поехать по делам», мне бы тоже хотелось иметь определённые рамки свобод.
Предупреждать — я могу, не проблема — просто тикнуть в мессенджере «busy». Но отпрашиваться по каждому чиху — точно не буду.
Хоть я и выступаю сейчас на стороне «любителя свобод», но я тоже не глупый — я понимаю, что есть разница между удалёнкой студента и зрелого разраба. Вот последнему я бы дал достаточную степень свобод, потому что «большие профессионалы» — редкость, им нужно создавать максимально удобные условия. А «контроль» таких вещей прост — результат.
И работать так, чтобы не тормозить работу других — важный скилл.
Важный скилл МЕНЕДЖЕРА ПРОЕКТА и «главного программиста». Чем лучше вы разделяете задачи, тем более независимы члены вашей команды.
Всё же программист большую часть времени тратит индивидуально, а совещания, хайпы и алерты — ну 1% времени!
Мир не сошёлся на программистах, но мы всё же «боги ПК» — это мы тратим чудовищные усилия, чтобы всё работало по нажатию одной конпки! Читаем тонны литературы, всякие мастер-классы, уроки, новости. Причём недостаточно прочесть и слыть профи до конца дней — мы каждый год окунаемся в какие-то новые вещи, технологии, подходы и постоянно учимся. А теперь вспомните свои студенческие годы — как, не поплохело? А у нас это «суровая реальность»! Мозг программиста насилуют каждый день :) и даже шахматы не идут ни в какое сравнение с продумыванием архитектуры какой-нть 1С! Собственно, за это мы и любим профессию — постоянный напряг мозга.CheY
10.10.2018 18:24Я прекрасно понимаю роль разработчиков и сложности в их работе, поскольку я поработал и в этой роли, а также в роли менеджера, и в роли где-то между ними. И про поток, и про факапы, и про «вечнозанятых» бездельников, и про кошмарных недоменеджеров, и про планирование я тоже не по наслышке знаю.
Подход «вы же сэкономили на мне денег, но не поделились и продолжаете платить по рынку» не верен. Вам платят за ваши навыки исходя из стоимости, сформированной рынком. Если оплата вашего времени и навыков принимается за справедливую обеими сторонами, то уже никто никому ничего не должен. Всё остальное — плюшки. О каких бабках, которые вы не видели может идти речь? Может ещё все софтверные гиганты должны доплачивать каждому индусу на аутсорсе за то, что они на нём экономят? Тогда где экономия, простите?
Вы этим постом лишь подчёркиваете ту проблему, из-за которой многие компании не хотят работать с удалёнщиками. Даже если компания смогла осознать тот факт, что «8 часов + обед» не имеют никаких реальных оснований в IT, что большинство IT-специалистов способно работать откуда угодно лишь бы был интернет и ПК, что коммуникации возможно наладить на достаточном уровне и без личного присутствия (это пожалуй, второе по сложности), что людям можно доверять и оценивать по результатам (это первое по сложности), то вот проблему контролирования рисков вы
для них не решаете, а лишь ярко подчёркиваете. Они ваши слова увидят в виде «да, я могу пропасть среди дня, потому что я же дома работаю, а не в вашем офисе, значит у меня полная свобода, может я предупрежу, но не факт, тем более что у меня поток, так что могу и не ответить, даже если я тут». Удалённая работа это только работа «где хочу», а не «когда и как хочу».
Что до возвышения работы программиста над остальными в ИТ (и не только в ИТ), то нет, я и тут вас не поддержу. Да, это умственный труд, да, порой весьма напряженный. Но не надо думать, что мир сходится на программистах и они самые недооценённые и непонятые люди в сфере. И хороший менеджер, хороший дизайнер, хороший тестировщик, хороший девопс/админ, хороший аналитик тратят не меньше усилий, и точно так же учатся.ayevdoshenko
11.10.2018 12:44Что-то не понятно — о каком риске речь, и как он успешно контролируется с помощью офиса?
geekmetwice
11.10.2018 16:07Вы узколобо смотрите на слово «деньги» — не про них же речь! Речь про то, что фирма имеет свой (немалый) профит, не снимая офиса и т.п. Я тоже хочу иметь свой профит в том, что могу сам выбирать рабочие часы, инструменты и т.п. Здесь нет никакого перетягивания одеяла, я (как человек) прошу элементарные удобства, которые никак не затрагивают работодателя.
Риски тут практически нулевые, потому что 1) вы перевираете мои слова — я указал, что МОГУ ставить статус отсутствия, вы же это вывернули в полную опциональность и неизвестность 2) Для удалёнщиков тоже есть «тестовый период» — если я вижу, что задача решается в адекватные сроки и человек отлично себя показал за 2 месяца, я со спокойной душой могу давать ему задачу и забывать на неделю 3) Риск есть даже у «планктона», ибо сотрудник просто не приходит на работу и процесс встаёт колом — очевидно, риск не больший, чем у удалёнщика с похмельем. :)
Я не хочу спорить со словами, которые вы сами придумали и сами отважно опровергаете. Я говорю, что программист — высокоинтеллектуальная работа и разумеется, я считаю программиста профессией высокого уровня — как разница между лудильщиком проводов и проектировщиком схем. Разумеется, люди интеллектуального труда ОБЯЗАНЫ обслуживаться по более лояльной категории, иметь какие-то привилегии и т.п. Лощёный менеджер-самоучка, размахивающий руками у доски, может быть заменён десятком других с ещё большей амплитудой рук. Разработчик заменяется как родной орган — только с кровью и мясом. Не будете бережно обходиться с ядром софтостроения, будете бесконечно сидеть в долгах и текучке, выжимая код с вечно недовольных рабов.
Хорошая аналогия — ресторан. Ты можешь сколько угодно раздувать щёки какой ты отличный менеджер, но все вы не стоите ничего, если у вас нет классного ПОВАРА. Так вот, повара — это мы, главные создатели продукта. Без программиста вся софтверная шарашка не стоит бумаги, из которой сделан ваш бэйджик.ayevdoshenko
11.10.2018 16:45Тут даже вопрос не про выставление статуса, а про адекватность и ответственность разработчика. Верно то, что адекватному и ответственному просто не нужен этот контроль от слова совсем — он только мешает, а вот неадекватного и безответственного человека — хоть законтролируйся — все равно в лучшем что-то ну очень посредственное получишь. В итоге вся идея контроля — не от большого ума и высокой компетенции менеджмента компании, сама цель непонятно — что хотят контролировать и чего добиться? Самоудовлетворения своей значимости (ай эм биг босс!) или поддерживать иллюзию контроля? В самом деле, вот просто житейски — какой из этого прок и кому?
И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Maxilect_pr Автор
10.10.2018 19:55Момент про «рабочие часы» прокомментирован выше.
Удаленная, как и очная работа бывает разной. В офисе вам могут предложить свободный график, а могут потребовать быть «от и до». Тут уж каждый сам решает, соглашаться ему на такие условия или нет.
Как и у других компаний на рынке, у нас есть некая отработанная схема, которую мы предлагаем кандидатам на вакансии. С удовольствием сотрудничаем с теми, кого она устраивает. Готовы к компромиссам в разумных пределах.
В статье описана некая общая схема командной работы. И команда здесь — ключевой момент. Членам этой команды для успешного достижения поставленных целей необходимо время от времени взаимодействовать между собой.
Описанная вами схема — с задачами на несколько дней или даже на неделю — у нас тоже может существовать для разработчиков в рамках отдельных проектов (при соблюдении определенных условий), либо для тестировщиков. К примеру, последние могут взять задачи на тестирование на неделю, самостоятельно с ними справиться в любое удобное время, а результаты занести в трекер.
Но мы делаем акцент именно на командной работе, поэтому и пишем о ней.ayevdoshenko
11.10.2018 13:05А на чем эти построения о «командной работе» основаны? Я, например, как человек приземленный, предпочитаю свои соображения соотносить с практикой. И мой опыт говорит, например, о том, что есть очень большие интервалы, когда никакой командной работы — не требуется, и даже сидя в офисе — ты сам в себе, в своей работе. Есть, разумеется, и напротив — интервалы, когда требуется командная работа — это особенно важно на этапе выработки концепции, на этапе тестирования большого блока, на этапе запуска и первых дней жизни проекта — тут разговора нет и никакому вменяемому разработчику не придет в голову уклоняться от этого. Но жесткая структура митапов — ежедневно, например, вне зависимости от контекста — это не более чем синдром контроля головного мозга, а не необходимость в виду реальных предпосылок. Это тот же микроменеджмент, задекорированный под благие намерения.
Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.
А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.Maxilect_pr Автор
11.10.2018 15:45Спасибо за комментарий. Мы по-разному смотрим на вопрос командной работы.
ayevdoshenko
11.10.2018 15:55Очень возможно — я не претендую на исчерпывающую полноту своего личного опыта, однако он имеет место быть, и, насколько мне известно — он у меня не уникален и довольно распространен. Соответственно здесь, в рамках обсуждения ваших методов контроля мы и делимся своими соображениями и опытом, что потенциально могло бы и вам пригодиться, если смотреть на излагаемое как на источник информации, а не попытку подорвать ваш авторитет или чего-то в этом роде.
Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
geekmetwice
11.10.2018 14:05«Командная работа»? Вы что, американский футбольный тренер?? :))) Вы сами прекрасно знаете, что код пишется одним человеком. Им же (как правило) и сопровождается, ибо нет ничего хуже, чем лазить по чужим исподникам. Причём тут «команда»? Или вы под командой подразумеваете «мы наняли пучок студоты за одну зарплату, а ты, главный программист, должен беспрестанно работать для них справочником-учителем-цербером»? Ну, тогда в одном месте я видал такие «команды»!
Кратковременная помощь — это нормально и я это делаю. Опять же, никакой «команды» тут нет. И фиксы чужого кода я тоже не воспринимаю за какую-то «общность». Получается, что всё, что вы скрываете за словом «команда» — это держать удалёнщиков на непрерывном шухере «а вдруг КОМАНДА меня дёрнет по телефону?». Я правильно всё понял? :)Maxilect_pr Автор
11.10.2018 15:44Нет, Вы не правильно поняли. Такой смысл мы не закладывали статью.
Karlson_rwa
09.10.2018 22:5553 местоимения «мы» в тексте.
Вот читаешь, вроде всё хорошо, но ощущение «большого брата» не проходит.
К чему бы это?geekmetwice
10.10.2018 16:50Вот-вот :) «мягко стелят, да жёстко спать!». Ты вроде бы как и свободен, но только на длину цепи между тобой и ПК. :) Рабы выбирают себе цвет оков.
Anton23
Какойу вас стек технологий?
Maxilect_pr Автор
Основной стек, с помощью которого решаем задачи клиентов:
1. Java / Kotlin / Scala.
2. Angular 2 и выше, React.
3. Python.
4. QA Automation (Java и Python).