Скоро удобство удаленной работы попадет в список тем, которые лучше не обсуждать с незнакомцами — вместе с политикой и религией. Насчет нее никак не сойдутся во мнениях. Одни менеджеры говорят, что давно пора отменить офисы, и скоро индустрия это сделает. Другие наоборот — индустрия разочаровалась и созывает всех обратно под одну крышу.
В споре есть момент единства: на удаленке нужен особый подход, определенные качества, и справятся с ней не все.
Об этом и не только мы поговорили с компанией Девхаб, которая решает проблемы удаленки поиском баланса между строгими правилами и неформальной обстановкой.
С чего начался Девхаб
В середине нулевых, когда торговля в интернете была еще чем-то экзотическим, Александр Самсонов открыл сайт-зоомагазин. Вместе с другом он занимался им три года, а затем продал, чтобы закончить университет. Поработав руководителем интернет-продаж по найму, он решил открыть свою консалтинговую фирму.
«В нулевые электронная торговля активно развивалась, и я понимал, что в стране не хватает руководителей интернет-магазинов, а компаниям хочется выйти на рынок. Поэтому я занялся консалтингом и начал вести несколько проектов», говорит Александр.
Для нового дела он искал современно мыслящего бухгалтера, который бы понимал в дистанционной торговле. Человек, которого Александр нашел, мыслил еще шире — он сам искал разработчиков для одного сложного проекта. Так у компании, которую позже назвали Девхаб, появился первый заказ.
«Проект назывался „Поток ФМ“. У заказчика в 30 городах России были размещены серверы с многоканальными FM-тюнерами, которые круглосуточно собирали данные по 27 радиостанциям. Нам с их помощью надо было создать систему мониторинга радиоэфира, чтобы рекламодатели, запуская рекламу на несколько регионов, могли следить, где и когда она прозвучала».
Система должна была анализировать данные, сравнивать их с эталоном, искать расхождения в эфире и определять их характер. Команда писала и проектировала интерфейс для клиента, всю серверную часть, которая работала с сырыми данными — но в команде состояли всего четыре человека.
«Это был сложный проект. Он пришел первым, причем совершенно случайно, и мы, конечно, его недооценили. Он занял много времени, и заработали мы меньше, чем хотели, зато многому научились. На этом проекте у нас сформировался подход к технологиям и архитектуре, которому мы следуем все эти годы. Именно тогда я понял, что разработка мне интереснее, чем интернет-коммерция».
Но это был только первый сложный и не оправдывающий всех ожиданий проект. Еще несколько лет компания с трудом выживала на рынке и искала свое место.
«Выживать было сложно, поэтому мы брались за всё подряд. Делали корпоративные сайты, на субподряде работали на рекламные агентства. До 2013 года брали и крупные проекты, и всякую мелочь. Только в четырнадцатом году я почувствовал некий перелом. Возможно, к тому времени мы окончательно поняли, как работать на этом рынке. Тогда же мы научились продавать себя по Time & Materials»
Как команда работает сейчас
Сейчас в Девхабе работают около сорока человек, которые ведут больше десяти проектов. Компания теперь занимается и разработкой, и консалтингом — но не таким, как Александр хотел в самом начале. Они консультируют, как правильно разработать ИТ-продукт.
«Мы часто выступаем технологическим партнером для предпринимателей. Их голова болит о бизнесе и продажах, а технические и продуктовые вопросы они делегируют нам. Можно сказать, мы специализируемся на разработке новых стартапов. Если все идёт хорошо и взлетает, мы поддерживаем продукт, а через год-два помогаем заказчику собрать собственную команду».
Александр описывает работу так: его команда формирует стратегию разработки — начиная с MVP, заканчивая тем, как запустить продукт, правильно потратить деньги, собрать фидбек и пойти дальше. «После того, как мы сформировали бизнес-часть, пишем спецификации, технические задания, начинаем проектирование интерфейса, потом дизайн. Параллельно можем начинать разработку».
Культура ротации
В подходе к проектам царит атмосфера хакатонов — так описывает ее фронтенд-разработчик Игорь Дерябин. «Наши команды собираются как междусобойчики друзей. Атмосфера выходит неформальная и дружеская, несмотря на то, что есть требование делать работу хорошо».
В команду входит аккаунт, который общается с клиентом, собирает требования и обсуждает условия работы. За ним идет менеджер проекта, который распределяет эти требования по разработчикам, руководит планами релизов и выкатыванием проектов. Он фактически технический директор, который отвечает за архитектуру, интеграцию, качество, документацию и в то же время управляет командой.
На каждый проект назначаются два ведущих разработчика — техлида. Один на бэкенд, другой на фронт. Техлиды берут себе по два-три разработчика. «В процессе работы люди могут меняться. Когда процесс стабилизируется, и каркас основных фич готов — ведущий разработчик может перейти к следующему проекту и оставить свое наследие другому».
В такой системе очень строгие требования к коду.
«Когда на проект приходит новый разработчик, первые несколько недель его постоянно ревьювят. Когда он осваивается, делают это реже и реже. С таким подходом пока получается держать кодовую базу в целостности.
Все что можно сделать без рук, мы стараемся автоматизировать. У нас есть шаблоны для быстрого развертывания проекта, есть шаблоны с готовыми структурами, чтобы все проекты были на одной платформе. Стараемся как можно больше унифицировать проекты — всё, что возможно, приводим к общему стандарту».
Какие в Девхабе используют технологии
За девять лет существования компании одни технологии стабильно развивались, другие приходили и уходили. Фронтенд стал в разы сложнее, иногда это приводило к неприятностям.
Фронтенд — React и TypeScript
Один из проектов Девхаб начал делать на первом Angular, когда React был недостаточно известен. Заказчик продукта смотрел на прогресс, показывал потенциальным клиентам, просил что-то поменять, снова показывал — и так несколько лет. За это время первый Angular успел уйти в прошлое. «Нам было очень сложно найти разработчика для поддержки и развития этого решения. С другой стороны, переписывать его получалось еще дороже. Но я не скажу, что это был фейл или просчет — мы стали заложниками технологического витка».
Сейчас команда фронтенда самая большая в Девхабе. Они стараются не упускать тренды, отслеживают перспективы, прислушиваются к индустрии и постоянно экспериментируют. В последние месяцы, например, разработчики присматриваются к Flutter — фреймворку для разработки гибридных мобильных приложений. «Сейчас он может стать серьезным конкурентом React Native, поэтому мы ищем проект, на котором могли бы поэкспериментировать». Похожим образом Девхаб сделал React своим основным инструментом в 2016 году — ввел ради пробы на одном из проектов, потому что библиотека показалась перспективной.
Бэкенд — Django+Asyncio
Бэкенд c первого проекта и до настоящего времени Девхаб пишет на Python с Django. Последние три года команда использует Django только как ORM и систему администрирования. С помощью Asyncio команда делает все бэкенды асинхронными.
Никаких предпосылок уходить с Python они не видят, и даже написали инструмент DVHB Hybrid, чтобы подружить Django и Asyncio.
В Девхаб никогда не смотрели в ни сторону Java, ни Go, ни .NET. Александр выразил интерес к Rust, хотя его пока не пробовали в работе. «Писать можно на чем угодно, хоть на Паскале. Надо использовать стек, которым лучше владеешь, и который популярен у сообщества. Важно, чтобы технология была актуальна ближайшие три-четыре года, чтобы под нее выпускались библиотеки и было комьюнити, которое может помочь, и чтобы было кого нанимать».
Мобильная разработка
Мобильные приложения Девхаб делает на веб-стеке и считает, что в их сфере можно обойтись без нативной разработки. «Непрофессиональным взглядом разницы в конечном продукте не увидеть. Но при этом стоимость и сроки разработки значительно снижаются. Когда приходит банк, которому нужно очень крутое мобильное приложение, безусловно им нужна компания, которая хорошо делает нативную мобильную разработку. С другой стороны, мы знаем, как сделать хороший интерфейс и отдать это кому-то на нативную разработку».
Как контролируют удаленную работу
В 2012 году команда Девхаб отказалась от офисов и с тех пор распределилась по всей России и нескольким странам зарубежья. На вопрос, не труднее ли контролировать такую команду, Александр говорит, что это наоборот легче, чем единый офис.
«Мы считаем, система удаленного контроля гораздо эффективнее. В офис приходишь, видишь, что люди на месте, и думаешь, что все хорошо. Создается иллюзия, будто все под контролем. А когда все удаленно, никаких иллюзий нет. Есть проблемы, которые решаются определенными способами».
А основные проблемы в удаленке известны — контроль за рабочим временем и взаимодействие сотрудников. В Девхабе есть два главных пути решения.
Рабочее время и время доступности — это разные вещи
Люди заранее обговаривают, сколько часов они будут работать на будущей неделе, но когда их отрабатывать — решают исключительно сами. Чтобы никто не зависел от чужого графика, ввели отдельное от рабочих часов время доступности. Например, с десяти до шести по Москве каждый день сотрудник просто держит телефон рядом, и может в случае чего ответить на сообщение в Слаке. Работает же — когда удобно.
Почасовая ставка и логирование времени
В Джире у Девхаба на все есть задачи, в которых запускается таймер, и время фиксируется с точностью до минуты. Примерное время для каждой задачи заранее определяют лиды и менеджеры. Они корректируют оценку в процессе, если обстоятельства меняются. Затем раз в неделю и раз в месяц ребята смотрят, кто сколько отработал, и рассчитывают оплату по часовой ставке. Менеджеры гарантируют, что задач хватит на полную загрузку, но сколько работать, сотрудники заранее решают сами.
Для менеджеров есть специальные задачи, которые открываются на всю неделю — вроде «общего управление на проекте». Как говорит Александр, в первую очередь логирование времени введено из-за формата работы с заказчиком. «Они платят за время, у них есть прозрачные отчеты, доступ везде — в Джиру, в Гитлаб. Все, что залогировал член команды, видит также и заказчик».
«Безусловно, работа с таймером немного специфичная», — говорит Игорь, — «Она требует больше дисциплины. Нужно самому контролировать, сколько времени уже потратил, сколько еще осталось. Но мне кажется, это скорее идет на пользу, чем во вред. У тебя самого есть адекватная оценка своей производительности, плюс все прозрачно для менеджеров и заказчика».
Как строят команду и борются с выгоранием
Но не все проблемы удаленки решаются формальными правилами. Иногда они оказываются более глубокими.
«Некоторые сталкиваются с удаленной работой впервые и вдруг понимают, что не знают, как с ней справиться», говорит Анна Дегтярева, эйчар менеджер Девхаб. Она в числе таких людей, потому что полтора года назад пришла из обычного офиса, не веря, что эйчар может быть удаленным. «Когда ты эйчар в офисе, тебе легче устанавливать контакт с командой. Ты видишь всех каждый день. Когда общаешься лично — быстрее узнаешь человека. Здесь же первое время приходилось заставлять себя не переживать по этому поводу».
Для Александра стало плюсом психологическое образование Анны, хотя, как она говорит, бизнес иногда относится к этому с предубеждением. «На рынке устоялось мнение, что психологи больше любят говорить, чем делать».
Тем не менее, отсутствие общения между сотрудниками — даже обычных разговоров — приводит к большим проблемам, особенно на удаленке. Люди замыкаются, не получают обратную связь, не могут оценить свой вклад, не знают, что делать с проблемами, начинают раздувать эти проблемы у себя в голове, выгорают и окончательно выпадают из работы.
«Удаленной команде труднее чувствовать себя командой. Над этим мы и стараемся работать постоянно», говорит Анна.
Наставничество
Например, сейчас Анна внедряет систему наставничества, чтобы к каждому сотруднику был прикреплен ментор. «Это будет как бы доверенное лицо в рамках компании. Человек, который точно увидит перемены в настроении, всегда будет в курсе твоих дел. И если он нащупает проблему, то сможет сообщить мне или лиду, и мы попытаемся человеку помочь».
Еженедельная рассылка
«Каждую неделю, что бы ни случилось, в четыре утра по Московскому времени всем сотрудникам приходит письмо, где собраны новости Девхаба, истории и рассказы коллег, сводки, статистика, фотографии с котиками и подборки свежих мемов. Туда уходит много ресурсов, но все любят эту рассылку. В ней участвует много людей — наш редактор и все сотрудники, кто хочет что-то написать».
Оценка сотрудников
Другой проект начался по инициативе сотрудников, которым не хватало обратной связи от коллег и менеджеров. «Теперь мы пытаемся внедрить систему оценок для каждого сотрудника — составили опросник и разослали ребятам, которые работали с ним. Те ставят оценки, на некоторые вопросы отвечают развернуто. Когда данные собраны, мы назначаем сотруднику созвон, где разбираем ответы и формируем рекомендации. Через полгода будем проводить еще одну итерацию опроса и смотреть, какие рекомендации сработали, что улучшилось. А если нет — разбираться почему».
Но одни только разговоры и правда не всегда помогают — иногда нужны действия. «На одном общении ничего не сделаешь. Если человек не может больше работать, то сколько бы ты с ним ни общался и не мотивировал — эффект будет краткосрочным. Завтра он проснется, и боли будут те же самые.»
Постоянная смена проектов и ролей
«Мы сотрудников любим, и у нас редко бывают случаи, когда мы решаем расходиться. Мы предпочитаем направлять ребят. Поэтому перемещаем сотрудников с проекта на проект. Это работает лучше»
«С выгоранием у меня есть своя история. Летом прошлого года у нас была напряженная ситуация в плане разработки», — рассказывает Игорь, — «Я тогда отвечал практически за весь фронтенд на проекте. Было тяжело находиться в напряжении весь рабочий день на протяжении нескольких недель.
После этого я переключился на другой проект, и да, это помогло. Смена деятельности — лучший отдых. Смена предметной области, темпа, окружения — все это помогает разгрузить голову.
Но и элементарное общение с коллегами помогает. Я для себя сделал вывод, что мне легче работается, когда у меня с коллегами дружеские отношения. Когда я могу неформально поболтать с менеджером и знаю, что он не выше меня в иерархии, а такой же член команды, как все. В этом плане мне нравится, как у нас все устроено, что никто ни над кем не стоит.
Мы вроде разбиты по командам, но в Слаке все равно все вместе».
Как сотрудники держатся вместе
У Девхаба есть традиция посещать города, где живет хотя бы один их сотрудник. Поскольку команда сильно распределена, встречи проходят по следующему принципу — выбирают город, где живет сотрудник компании, собираются там и проводят несколько будних дней и выходные, чтобы и поработать вместе, и посмотреть город.
«За год мы уже посетили пять городов — Казань, Калининград, Лиссабон, Красноярск и Ростов-на-Дону. Периодически ребята приезжают в Москву. Еще были небольшие рабочие съезды в Париже и Барселоне.
Конечно, ездят не все сорок человек. В среднем собирается десять-пятнадцать, но всегда разные. Потому что все больше людей проявляют инициативу и подключаются к нам».
«Последний митап получился не только нашим. В ростовском коворкинге мы провели митап по удаленной работе вместе с другой компанией», говорит Элина, менеджер по маркетингу Девхаба — «Думаю, мы будем продолжать так же — совмещать командные встречи и митапы с местным комьюнити, чтобы больше общаться и развивать культуру удаленной работы.
Редко бывает, чтобы незнакомые команды собрались вместе и поделились опытом и просто пригласили тех, кто работает вокруг. Я знаю, что такая инициатива есть у Skyeng в Москве. Но в регионах такого мы не встречали. А особенность удаленной работы именно в этом — ты не ограничен рынком одного города. Нам очень интересно общаться с комьюнити в регионах и говорить всем: „смотрите, вы можете жить в своем городе, и при этом не ограничиваться только местными компаниями“».
Комментарии (46)
KristinaMyLife
26.06.2019 18:24+1Спасибо за статью!
В ходе работы удаленной команды из моего опыта много времени тратиться на коммуникаци, это время все равно считается потраченной на задачу? и есть ли какие-то задачи, куда уходит время на работу с почтой, и прочие пожиратели времени?
anndegtyareva
26.06.2019 18:35+1Коммуникация в рамках задачи логируется в задачу. Для отдельных созвонов и совещаний заводятся отдельные задачи, как и на встречи команды и с клиентами
musuk
27.06.2019 16:50А как сделанны нотификации о новых сообщениях в задачи?
Куча Email ов на каждый апдейт задачи?anndegtyareva
27.06.2019 17:28на почту падают уведомления о задачах, где ты стоишь в статусе вотчер или тебя заменшели.
обычно в комментариях фиксируем прогресс по задачам. общение идёт в слаке или на созвоне. PM фиксирует основные выводы.
VolCh
26.06.2019 21:26+2А не пробовали доверять оценку задач тому, кто её делать будет?
smarthomeblog
26.06.2019 22:28+1По логике вещей, оценка задачи должна быть разделена между тем, кто ведет проект, и тем, кто эту задачу делать будет.
rodweb
26.06.2019 23:37Оценка — понятие относительное :) Один разработчик оценит в большую сторону, другой в меньшую. Обычно менеджер с лидом садятся и вместе идут по пулу новых задач, дают объективную оценку на основе предыдущего опыта.
Если доверить оценку неопытному разработчику, велика вероятность, что он, во-первых, сделает чересчур оптимистичную оценку, во-вторых, упустит какие-то моменты в реализации и на выходе получим неоптимальное решение задачи. Поэтому, если есть спорные моменты, лид с разработчиком также пересматривают оценку по необходимости.
Ну и в конце концов стопроцентной гарантии выполнения в срок грамотная оценка не даёт, так что она скорее выступает в качестве ориентира.
183614956
27.06.2019 02:48+2Разработчик, если его попросить, оценит задачу в тот сроки когда он её сможет выполнить. Опытные разработчики, привыкшие к требованию эстимации задач, успешно с этим справляются.
Другой вопрос, что задачу можно точно оценить только тогда, когда на 100% известно, как её решать и уже имеется личный опыт решения таких задач.
Пересмотр времени на решение задачи лидом вещь скорее угнетающая. Это как требование "сверху", что задача должна быть решена в этот срок. По возможности, лучше отдать задачу другому более опытному в этой предметной области или части кода программисту, который сам оценил её в более приемлемые сроки, а новичка готовить на других задачах исходя из его собственных временных оценок на них. При должной мотивации и адекватности сотрудника с его стороны будет понимание того, что нужно стараться и где-то приложить больше сил.
В иных случаях вы просто создаёте иллюзию, что задача будет выполнена в срок лида, но каким образом это будет достигнуто — непонятно.
valis
27.06.2019 12:59Таймеры хорошо подходят для людей, которые занимаются линейной работой. По принципу — есть четкая задача, поставил таймер и делай (в ходе можешь задавать уточняющие вопросы и и обсуждать проблему, но это все равно линейность)
Есть люди, которые работают «на подхвате». Это менеджеры, лиды, архитекторы. У тебя вроде и есть «список добрых дел на сегодня», но в любой момент может всплыть проблема вселенского масштаба и тебе срочно нужно переключится. При этом нужно остановить таймер на текущей задаче, создать новый тикет (т.к часто обращение без тикета) и начать в нем фиксировать время.
Когда таких переключений контекста в день случается много тебе очень сложно переключатся между таймерами и в итоге сотрудник забивает на это и в конце дня выставляет время наугад.saalse
28.06.2019 00:11Да, проблема микрологирования существует. Когда время и внимание, чтобы найти/создать задачу, занимает существенную часть. Прежде всего надо учиться последовательно подходить к задачам, контролировать свой фокус внимания, настроить систему уведомлений. Дальше это культура. Например, обсуждаем новый проект, сделали чат в Слаке, в топике указали ссылку на задачу, куда можно переходить и логировать.
У всех, кто «на подхвате», есть недельные задачи, куда списывается время на микроменеджмент. У меня задача всегда открыта в припиненом табе, куда можно быстро переключиться. Для статистики, в апреле команда сделала ворклоги в 39 коммерческих и внутренних проектах, в среднем РМ залогировал в 11, HR в 13, лид по фронтенду в 10 проектов.
evil_random
27.06.2019 14:33Имхо, самый правильный подход это вообще абстрагироваться от времени и просто давать разработчику на спринт несколько задач, а уж как, когда и за сколько он их будет делать это его проблемы.
Нюанс только в том, что нужно понимать сколько задач данный разработчик способен сделать за спринт.
А то если вводить логирование времени для оплаты почасовки, то даже неосознанно, но врать будут почти все.saalse
28.06.2019 00:27Чтобы понимать сколько задач данный разработчик способен сделать за спринт, подходит система сторипоинтов. Мы присматривались к ней, но на внедрение не решились.
По поводу вранья, может удивительно, но это так не работает. Мы собираем очень много данных о времени, что позволяет выявлять аномалии. Но главное здесь отношения — если ты открыто доверяешь человеку, то ему сложнее переступить черту морали. Скорее у нас возникает иногда проблема, что кто-то может недологировать, например, изучая новую для себя область. Это рабочий процесс и должен логироваться также, как при работе в офисе.
realimba
27.06.2019 15:24Не совсем понятно откуда претензии к таймеру/логгеру при правильном его использовании.
Я занимаюсь только R&D проектами и почти всегда с пол-пинка невозможно запланировать объем работ.
Разве что у вас есть целый research отдел с кучей спецов по всем направлениям.
Сначала выделяется время на исследование и эстимацию, затем принимается решение о дальнейших действиях.
Просто включил таймер и работаешь, достаточно договориться с заказчиком о максимальных сроках любого этапа.
На галерах конечно такой вариант не работает т.к. ПМ всегда хочет знать за сколько часов и минут будет решена задача но не больше 8 чтобы порадовать заказчика на вечернем стендапе :Dsaalse
28.06.2019 00:30Сначала задача на исследование и оценку, иногда несколько. Для новых проектов это идёт за внутренний бюджет, для текущих за счёт клиента. Если мы сами придумали идею, то можем работать над ней за внутренний бюджет, а потом продать клиенту.
nomhoi
27.06.2019 16:43В методичке для Императоров Всея Планеты под названием "Город Солнца" говорится, что программисты пишут код не по принуждению или за чашку риса, а по зову сердца, по велению души, по вдохновению.
saalse
28.06.2019 00:33Вдохновение необходимо. Мы не можем браться за проект, если он будет не интересен команде.
SnowLeopard471
27.06.2019 17:28Работать с таймером — это самоограничение, как мне кажется. Иногда бывает возможность выставить клиенту счет на 5х-10х фактически затраченного времени, и лучше это сделать по fixed price, чем просиживать штаны перед таймером или обосновывать $500 за два часа.
anndegtyareva
27.06.2019 19:29У нас прозрачная схема работы с клиентом. Возможности выставить счёт 5x-10x нет, мы и не стремимся к этому.
ddinochrome
28.06.2019 05:37Забавно, что больше всего обсуждений возникло вокруг таймеров.
Я у себя этот вопрос решаю просто. У каждого сотрудника есть определённый ежемесячный доход, который ему нужен для жизни. Это может быть фиксированная сумма, а может быть что-то плавающее. Но в любом случае оно плавает в определённых пределах. Соответственно, можно получить стоимость каждого часа содержания сотрудника — не важно, работает он, спит или играет в покемонов. Например, при ставке 100 тр/месяц стоимость каждого часа будет 100 000 р /(30 * 24 часа) ? 140 р/час. Таймер для сотрудников включен всегда — и ночью, и на выходных, и на праздниках.
Я могу за любой промежуток времени посмотреть что сотрудник сделал полезного и сколько компания на это потратила денег. Если виден профит для компании, то мне не важно сколько из этих часов было отработано, а сколько было потрачено на сон и покемонов. А если профита не видно, то надо или что-то менять, или прощаться друг с другом.
Непосредственный подсчёт отработанного времени хорош только с точки зрения психологии — по нему легче отчитываться перед заказчиком. Так исторически сложилось, что это — привычная для всех схема. Но насколько она эффективна для PMа в качестве инструмента контроля? Лично мне она только мешает, потому что, как уже многие заметили в других комментариях, трудно замерить какое время было рабочим, а какое — нет. Ещё более трудно понять где границы задачи и сколько времени в итоге займёт её решение. И все эти трудности приходится решать PMу в ущерб реальным полезным для проекта задачам.
s37
А бывали ли случаи, что человек включал рабочий таймер, но работу не делал (нажал работаю, сам ушел чай пить)? И есть ли некий «план выработки» или аналог?
anndegtyareva
Мы не знаем о таких случаях, это на совести. Здесь важно другое — соотношение затраченного времени на полученный результат. Задачи декомпозируются так, что она не может занимать более 8 часов. Если РМ или лид замечают, что времени уходит слишком много, то изучают ситуацию. Разработчику может не подходить задача, может просто тратить на решение много времени или дологировать сверху. Это быстро выявляется и принимаются соответствующие меры
smarthomeblog
Тогда зачем таймер?
rodweb
Не очень понял суть вопроса :) Во-первых, чтобы вести учёт рабочего времени сотрудника и оплачивать его работу, во-вторых, чтобы у клиента была четкая картина по прогрессу на проекте, подтверждённая числами.
smarthomeblog
Можно ведь включить таймер и заниматься своими делами. И не будет четкой картины у клиента :) Тоже самое можно сделать и без таймера — есть время, отведенное на задачу, а разработчик пишет свое потраченное время, но без таймера. Главное, чтобы задача была сделана вовремя.
rodweb
Да, можно включить таймер и заниматься своими делами, но потом фактически затраченное время не совпадет с оценкой и нужно будет выяснять, что случилось :)
В целом такое поведение довольно быстро всплывает, поэтому нет нужды пытаться это как-то контролировать, здесь есть определённая степень доверия.
Таймер автоматизирует подсчёт рабочего времени, а мы любим автоматизировать)) Считать в голове или куда-то записывать, когда ты начал работу, потом всё это высчитывать вместо того чтобы сразу переключиться на срочную задачу… такое, в общем. Человеческий фактор лучше исключать насколько это возможно.
mad_nazgul
Вообще то это «палка о двух концах». Проблема оценки времени и нет точного измерения сколько времени тратиться на задачу.
Тут обычно маятник может начнутся в другую сторону, когда оценки времени ставятся очень оптимистично. А т.к. точного учёта времени нет, то исполнитель, чтобы успеть, работает более 8 часов в день. При этом, судя по моему опыту, один и тот же человек, на аналогичных задачах разброс по времени может быть от 1,5 до 3 раз.
Например, вчера «погулял» сегодня «втыкал» в задачу два часа, хотя она делается за 15 минут. Ну или если решил при простуде не оформлять больничный, а поработать. В общем куча факторов, когда реальная стоимость по времени у разных людей в разных обстоятельствах, может скакать очень сильно на одну задачу. При этом они не будут «филонить» и наоборот будут добросовестно работать.
SergeiBB
Мало кто может работать на удаленке — без присмотра. Со временем все равно начинают филонить. Трекеры времени стоят, скрины делают… Ставят просто эмуляторы мышки, мол изучали код, думали… Со временем все больше начинают наглеть. Некоторые изначально отказываются трекер ставить или потом просят его снять, поставить оклад… Ответственных людей единицы.
183614956
Думаю, что это проблема мотивации. А на трекеры лично я бы не согласился, потому что работу можно и нужно оценивать по результатам.
Уверен, что если бы я какое-то время поработал под трекером, то тоже начал бы "наглеть и филонить". При этом, если бы трекера не было, то "филонить" я бы начал существенно позже, а может и вообще не начал бы.
smarthomeblog
Думаете, что в офисе все пашут не поднимая головы? Помнится один коллега писал личные письма прямо в IDE на случай заглядывания начальником в экран :) Согласен с большинством комментирующих, что главное — правильная мотивация. Если ее нет, но ни трекеры, ни подсчет количества коммитов или закрытых задач, не помогут ни в офисе, ни на удаленке.
mrsantak
anndegtyareva
Представим проблему с производительностью. Первая задача будет исследовать проблему. Это вполне укладывается в 8 часов. На основании её результатов заводятся задачи на конкретные работы.
mrsantak
Так оно работает только в случае простых и явных проблем. В реальности можно просидеть в обнимку с профайлером и хипдампами недельку чтобы понять что вообще происходит. А потом уже все пофиксить за час-два.
ddinochrome
Ситуация вполне реальная, но мне кажется, что в повседневной работе devhub'а она обычно не встречается. Платформа и специфика заказов таковы, что можно получать ощутимые результаты для проекта за считанные часы.
u_story
всегда есть гипотезы, которые можно выделить, декомпозировать и проверять.
сидеть неделю без гипотез нет смысла. если у человека нет идей что делать, возможно это не задача его уровня.
mrsantak
Скажите пожалуйста, где я писал про то, что «у человека нет идей что делать»? Это вы сами уже додумали.
Гипотезы-то сформулировать можно, вот только формировать десяток гипотез, а потом сидеть их проверть глупо. Ибо «выстрелить» может уже первая гипотеза. А еще в ходе выяснении, например, третьей гипотезы вылезет дополнительная информация, которая позволит сформировать одинадцатую гипотезу, которая будет более вероятной чем предыдущие десять. Поэтому рационально решать задачу последовательно. Это не полноценная декомпозиция, в которой вы сначала формирруете список подзадач, а потом их решаете, а именно последовательное решение задачи, когда задачу N имеет смысл формировать только после решения задачи N-1.
Вообще, исследовательские задачи обычно крайне плохо поддаются декомпозиции.
smarthomeblog
Есть продвинутые таймеры, которые делают скриншоты экрана раз в 10 минут. Мое ИМХО. Таймеры не мое. Это точно. Я прекрасно понимаю, что так удобнее для руководства. Может и разработчикам тоже нравится. Мне лично нет. Но это моя проблема :)
rodweb
Лично я не люблю скриншоты, по мне так это уже больше в сторону паранойи) Отслеживание активности по клавиатуре туда же. Разработчик может 20 минут тупить в экран, обдумывая решение задачи, гуглить, а эффективное решение в итоге займет 1 минуту. Что здесь дадут понять скриншоты и процент активности за временной промежуток, я затрудняюсь сказать :)
smarthomeblog
Так вот и я не понимаю :) И полностью согласен насчет обдумывания. Таймеры наверное больше подошли бы кодерам, которые тупо пишут код по выданному подробному ТЗ.
anndegtyareva
да, скриншоты экрана это уже переизбыток контроля и у меня бы возникало ощущение, что на моё личное пространство покушаются
rodweb
С другой стороны, например, на Upwork они оправданы, т.к. платишь за выполнение единичного таска совершенно незнакомому человеку.
183614956
Использую таймер toggl.com в личных целях время от времени. Показывать замеры таймера кому-то, зная что по их результатам меня будут заставлять корректировать поведение, я бы не стал.
Показывал бы только в том случае, когда рабочий проект крайне важен для меня, но в этом случае я и так приложу максимум усилий, чтобы выполнить работу максимально быстро и качественно.
Лично мне кажется, что таймер для самоконтроля — вещь отличная. Если же таймер начинает использоваться для контроля кого-то, то, наверное, предпочтительнее поработать над мотивацией сотрудника или найти более мотивированного под такие задачи.
Думаю, что в контексте компании из статьи таймер вполне подходит. Они работают над чужими проектами и продают часы, что и пытаются оптимизировать.
AndreyMyagkov
У нас каждые 3 минуты скриншот делается) Живем как то же
anndegtyareva
а что потом с этими скриншотами делают? как обрабатывают?
AndreyMyagkov
У нас ничего не делают. А вообще они нужны в случае возникновения спорной ситуации с заказчиком. Если заказчик увидит, что скрин не соответствует рабочему процессу, то это время вычитается из оплаты