Комментарии 41
Вот я всегда не понимал, какой больной придумал "опенспейс". Как посмотрю на некоторые офисы, где сидят разрабы рядами как на галерах, и чето там проектируют, так сразу задаюсь вопросом, как вообще можно в таких условиях что то делать.
И зачем людей тащат в эти офисы... Мне кажется что организованная удаленка (с тайм трекерами и прочим "онлайном") намного эффективней в итоге будет, чем офисы. Ну при условии, конечно, что у сотрудника не детский сад дома.
Вот насчёт тайм-трекеров - тема очень холиварная. Метрики конечно же считать нужно. Но считать это разумно, а не по "количеству кликов в минуту" (наслышан о таких). И если удалёнщик выполняет все нужные работы с нужным качеством, и за ним не нужно "заносить хвосты" - зачем ему тайм-трекер ? Чтобы недопустить превышения количества походов на кухню за кофе ? Чтобы регламентировать перерыв на "работу с гантелями" или "взять ноут и выехать поработать несколько часов в парке"? Так такие перерывы только прибавят производительности! Техника "помодоро" рулит. И интервалы у каждого свои.
Вообще я за мягкий гибрид. Что б чувствовалась вовлечённость в процесс каждого. Что б "лицо на том конце дейлика" было конкретным человеком. И в то же время чтобы можно было на месяц-другой свалить на удаленку в другую страну. //геополитические "особенности" тут не обсуждаем.
Time tracker - это инструмент для time material для аутсорсеров / аутстафферов в первую очередь. Делать ли из него инструмент контроля - это уже вторичный вопрос.
Давайте я отвечу, как сторонник учета времени.
Я, как менеджер, даю срок Заказчику внутреннему и внешнему. По этому сроку мне приходят деньги или мой VP и я получаем премию или нет.
Срок выше я даю на основании оценки исполнителя. С рисками, траливали и все все, но - на основании оценки разработчика. Он слово дает.
И если разработчик не держит слово, слово не держу я. Я лишаюсь премии, мой шеф ее лишается, а в худшем случае (у меня они были), компания не получает деньги на зп сотрудникам (в том числе ошибившемуся разработчику).
То есть все строится на договоренностях. И если проектная система - это мои договоренности с заказчиками, то трекер - это моя система договоренностей с исполнителями. Он нужен для фиксации договоренностей и отслеживания их исполнения.
Доброго дня.
Вас не затруднит дать несколько комментариев про оценку времени исполнителем.
1. В год, например, вы запрашиваете оценку по условно 1000 задачам. Сколько из них реально попадают в первичную оценку?
2. Если по вашему опыту оценка некорректная, то тогда что? Договариваетесь с исполнителем снизить его оценку?
3. Почему вы сами не ставите время выполнения задачи?
Спасибо.
около 90%. Оценка варьируется от умения человека попадать в свои оценки, но в среднем за последние 5 лет так (мы внимательно считали). Любопытно, что есть люди, которые учатся попадать, а есть хронические оптимисты. 5 лет чувак работает а все равно всегда х2 к его оценкам приходится добавлять чисто статистически. Но там психологическое желание быть лучше, чем он есть, по моему мнению.
спрашиваю, почему она такая, прошу объяснить, так как не понимаю ее. Иногда снижаем, если оба согласны. Иногда я понимаю что не понимал и оставляю как есть или докидываю (заодно понимаю риски и что говорить заказчику)
потому же, почему я не берусь выполнять сроки, данные не мной: это не моя оценка и не мое слово. Я привык отвечать за свои слова, но за слова других отвечать - тема мутная.
А как вы поступаете с задачами, где реалистичную оценку дать затруднительно из-за характера самой задачи? (требуется RnD и т.п.)?
даем на то, что ясно. Если ничего не ясно - даем несколько дней, чтобы наметить план. Результат - сделать хоть ченить, затем обсудить, куда дальше.
Важно чтобы этот RnD шел контролируемо, а не в стиле "РП поставил задачу на исследование, сам забыл, а разраб ковырялся 2 месяца и выжрал бюджет". Ясно что это не проблема разраба, он молодец вообще то.
Но менеджеру башку оторвать за такое планирование :)
К вопросу 3 ещё такое уточнение для обмена опытом.
Допустим, пришёл заказ на сайт. У вас есть дизайнер, который красиво нарисует, и разработчик, который подготовит страницы и опубликует их.
Также допустим, ваша команда уже делала подобные заказы и вы предполагаете, что через 3 недели покажете сайт заказчику и подпишите акт выполненных работ.
В этом случае вы будете ждать оценки времени от дизайнера и разработчика?
И не получится ли так, что пока вы будете ждать эти оценки, заказ уйдёт другой команде?
Если от вас как от руководителя не ждут таких оценок, то тоже ок, просто другой опыт по работе со временем.
(Вместо сайта, дизайнера и разработчика можно подставить другую область и исполнителей)
дааа, люблю такую историю.
Когда я был неопытный, я всегда шел спрашивать лида/архитектора или кого то, кто готов взять ответственность. Для джунов и миддлов, я считаю, это норм.
Для синьора нормально уметь прикинуть оценку самому (плюс-минус), так, чтобы потом разработка в эти деньги уложилась и еще осталось маржи. А если не рассчитал, он должен уметь обосновать заказчику увеличение. Я как то писал в статье про "допущения и ограничения" - вот тут оно очень помогает.
Если про меня - я уже лет 5 сам даю оценки, которые или не отличаются от оценок разработчиков или выше их только потому что я еще считаю риски, аанлитику, тестирование, запасы и тп. И в оценки попадаю. Но тут просто опыт и насмотренность. И да, там не про сайты, там про проекты больше 100 млн)
О, узнаю себя! Это я такой хронический оптимист был. Пока работал программистом, всегда давал оценки, в которые чтобы вписаться, нужно было порваться на британский флаг. Зачем? - Не знаю, автоматически
Сейчас подвожу итоги года в своей команде, из 700+ задач процентов 40 были выполнены быстрее первоначальной оценки, процентов 30 в оценке, 30 медленнее оценки
Гугл придумал посадить кучу разработчиков в как можно более тесные офисные помещения, чтобы происходило "творчество", об этом много где написано, в частности у Шмидта в "How Google Works". Возможно это и правда необходимо, если процесс находится в бесконечном R&D на пике научной мысли, но вот оттуда все начали эти практики применять, особо не анализируя необходимость.
Что хорошо для Гугля, то вредит промышленной разработке, где вместо НИОКРа надо просто прикрутить личный кабинет к биллингу и чтобы баланс отображался (например)))
и поскорее)) тут не творчество нужно, ясно дело...
Опенспейс располагает к брейнстормингу любой, даже — на первый взгляд — простейшей проблемы. Огромное количество задач из бэклога, кажущихся тривиальными, оказывается на поверку перегружены подводными камнями, которые быстрее придут в три головы, чем в одну.
А потом надо будет прикрутить еще один биллинг, потому что у клиента второй счет на BVI, и личный кабинет поломается, а чтобы починить — надо будет переписывать с нуля.
С контролем времени всё просто: если он есть, контора идет нахер.
А с ругой стороны тратить на брейнсторминг больше часа в день = сжигать ресурсы на ППР встречи.
А с другой стороны, в офисе галдеж, вышли покурить и то-се. Я и сам гораздо лучше пишу доки, к примеру, дома. В офисе лучше коммуникация - это факт. И своим опытом необходимо и достаточной коммуникации я поделился.
А про контроль времени я вас не понял :) чего это контора сразу идет нахер, зачем? )
О, в этом плане интересен ваш опыт как в раз в НИОКР проектах.
У меня сложилось плотное впечатление что приличная часть процессов и особенно эстимейты — артефакт наличия человека с шапкой «проджект». И в НИОКР они, ммм, не окупаются. Мы в итоге живем в формате когда вместо «назвал срок и по-пацански уложился» просто «по-пацански где надо сделал хорошо и остальное побыстрее»
У этого есть свои трейдоффы и интересно, как оно работало у вас где есть вера в ТЗ и процессы.
Трейдоффы например
Тут Лид / продакт должны очень понятно сказать, где вероятно поменяется и сделать надо дешево, а гле фундамент для следующих 30 фич.
Вместо ТЗ — контекст + доспоросить если нужно, что не всем IC удобно / нравится
я не знаю, что такое тредофф, никогда не пользовался термином. Если поясните попроще - отвечу )
НИОКРы тоже разные бывают, есть чистые научные исследования - никогда не работал, но если было бы надо - просто планировал работу и примерные цели в формате "было бы неплохо" и тестировании гипотез, пока бабло есть
НИОКР как создание нового продукта - ну тут все +- структурировано: MVP, backlog с приоритизацией и гипотезы.
ТАк что если есть четкая постановка и вопрос - говорите, иначе слишком общий разговор получится
про опенспейсы писал ещё Демарко, сильно задолго до Гугла. Но я заметил серьёзное отличие от западных опенспейсов и наших. Там обычно кубиклы с небольшим персональным пространством, а у нас локоть к локтю :(
Непонятно желание бизнеса засадить в офис тех сотрудников, чья команда распределена по всей стране: один сотрудник - в одном филиале, второй - в другом. И так вся команда. Да, все сидят в офисе. Но по факту они как на удаленке, так как общаются-то они все так же в чатах и по видео. Живого общения, за которые многие ратуют, нет.
Обобщение неверно в силу категоричности. Естественно, для интеллектуальной работы, требующей длительной концентрации, обязаловку "с 9 до 18" вообще уже странно обсуждать. Наилучший результат достигается при организации наилучших условий, для которых удаленка имеет существенные ограничения. Если вы не можете создать условия для разработки в офисе лучше, чем дома, то мои соболезнования вам и вашим заказчикам.
спорно также в силу категоричности. Давайте начнем сутра, когда сотрудник просыпается в своей ипотечной квартире где то в Саларьево, Кудрово (или подставить любой новый район города-миллионника РФ) и едет минимум час на работу (вечером обратно). вместо того чтобы поспать/позавтракать и даже погулять.
Это не заменить модным офисом никак вообще и это одна из самых важных причин.
Вторая - бедность :) вы говорите про соболезнования тем, кто не может обеспечить идеальные условия, но таких - 95% рынка, не поверите. Я работал в очень многих компаниях, в модных тоже. Набирают удаленщиков, потому что они дешевле. Даже сейчас сотрудник из Мск будет подороже, чем из условного Томска. Ну и как вы Томича привезете в Мск?
А вот если вы про то, что написанное мной не должно отменять наличия классного офиса, в который при желании можно приехать - вот тут согласен. Потому что далеко не все вообще любят работать из дома (к примеру, я сам).
А списание времени, это как ? Это отличается от тайм трекера ?
Для меня звучит как , отработал часы, нажал кнопку или что то подобное
Списание времени - это когда вместо тайм трекера ты сам в конце рабочего дня/рабочей недели/etc. расписываешь как такую-то задачу делал X часов, а другую Y. И в итоге надо набрать пресловутые 40 часов в неделю.
ну или не надо, кстати. зависит от того, как это использовать.
А если не надо, то зачем тогда вообще это нужно?
чтобы я, как менеджер, понимал, когда разработка закончится и мог планы планировать.
А еще следил за прогрессом выполнения по декомпозированным задачам.
А товарищ разработчик старался уложиться в данные им сроки.
И да, я в курсе про "раз вы будете просить оценивать, мы будем давать завышенные оценки" и знаю, что на это отвечать :)
Мудрый подход без перекоса в ту или иную сторону, приятно почитать. По поводу присутствия в офисе добавлю, что если разрабатываемый продукт вполне себе физический (в моём случае машинка), то даже тестеру нужно иногда подъезжать в офис, чтобы посмотреть на прототипы. Но это наверно вот как раз ближе к аналитике, о чём и говорится, что аналитик должен бывать в офисе немного чаще.
А можете раскрыть концепцию "списания времени" для разработчиков, я такое впервые слышу, любопытно. Или может слышала, но под другим названием.
Как это в первый раз? Этому холивару уже 20 лет. Называется "разработчик это творец или исполнитель"? ))
Это просто план/факт по каждой задаче. Исполнитель дает оценку, обычно в трекере, затем в трекере же списывается. В итоге получаем статистику, насколько исполнитель попадает в свои же оценки. По сути, это ровно тоже самое, что требуется от самого РП, только спроецированное на исполнителей.
Ну это типа стори-пойнты или футболки/майки? Такое видела, но не видела, чтобы собирали статистику по попаданию и списывали как-то это время. К тому же иногда задачу может оценивать и вся команда, и тимлид - в общем, не только разработчик сам для себя.
Спасибо, буду знать теперь)
В Jira есть учёт времени по любой задаче, просто ставишь сколько времени ушло
ой, ну вы что :)
это классика списания которая была задолго до того как придумали этот покер с оценками. Как ниже написали, два параметра: time estimated; time spent - все тупо :)
Как верно замечено, копий на эту тему сломано уже много, и до истины не добраться - везде есть свои нюансы и обстоятельства. Для меня краеугольными камнями являются условия работы и самодисциплина. Почему-то по-умолчанию считается что разработчики живут одни, вокруг не крутятся дети-жена-тёща, и в квартире есть хоть немного оборудованный рабочий уголок, а не табуретка в ванной с ноутом на коленях. Уж чего я не насмотрелся на ВКС в ковид, даже у людей на вполне серьёзных должностях - кроме оборудованного рабочего места, не говоря уж про отдельный кабинет. Также считается что разработчики нацелены на максимальную производительность и не подвержены соблазнам "холодильника или ютюба", не говоря уж про желание брать халтурку на стороне. И понятие "рабочая атмосфера" придумана не просто так, "эффект толпы" работает - когда вокруг люди заняты делом, меньше соблазнов отвлечься на нерабочие моменты, и задать короткий вопрос на рабочем месте или по дороге в столовую, который ты не будешь задавать в мессенджере - экономит часы рабочего времени.
Разработчики не шахтёры, где можно выработку считать в кубометрах - любые метрики адаптируются под методики их измерения. Причём ползучим образом - невозможно заметить, что то что в офисе делалось за полгода на удалёнке делается за 6.5 месяцев. А потом за семь. А через 5 лет за год. И каждый раз будут убедительные объяснения про усложнение ПО и новые фреймворки, когда руководитель будет искренне удивляться почему раньше трава была зеленее а проекты делались быстрее и качественнее.
а вот тут спорить будем :) Я ж говорю, я с удаленщиками работаю давно и долго. Я готов сказать, что при должном контроле оценок (которые есессно все иногда завышают) и контроле списаний (когда можно иногда попросить рассказать что реально было сделано), производительность на удаленке не отличается. Более того, есть граждане, которые бакланить будут что дома, что на работе.
Для меня вот эта история про "я позову человека в офис, потому что он дома сосредоточится не может" - какая то безответственная. Мне пофигу откуда ты работаешь, но у меня есть задача, ты дал оценку, мы согласовали и ты должен попасть в срок. Та самая пацанская договоренность. Если ты не пацан - я поставлю над тобой пацана - лида. Чтобы пинал отвечал за тебя и учил. А если пацан, то я тебя и контролировать не буду - зачем?
У меня последние 5 лет была очень хорошая скорость time to market. Наверное быстрее, чем за весь прошлый опыт (оценочно, по жопомеру). И в офисе не было ни одного программиста. Вообще. Ну или приезжали просто потусить и пива попить. Но у нас реально были классные процессы, за исполнением которых следили.
Присоединюсь тут. Последние 2,5 года работаю в одном полустартапе, вся команда разработки удалённая. И MVP запустили в рекордно короткие сроки, и потом много фич поставили. Вопрос постановки процессов, контроля, а также отбора сотрудников: безответственных балбесов, которым постоянно нужен надсмотрщик, просто не берём на работу. Лентяев выгоняем, были и такие случаи
поддержу. эффективность от людей и процессов, а не от места.
прячется сотрудник от детей/кошки дома или от любителей перекуров и потрындеть о вчерашней пьенке - нет разницы ;)
Разница лишь в том, кто обеспечивает рабочую атмосферу.
Да, у меня опыт работы с удалёнщиками небольшой и достаточно печальный, особенно если квалификация средненькая. Поэтому и интересуюсь, сравниваю ощущения. Оценка принимается, в неё попадают - отлично, но откуда уверенность что при офисной работе она не будет меньше? И что условный джун не набирается опыта в коллективе быстрее, нежели сидя дома? По мне это баланс между возможностью сосредоточится, когда не отвлекают от работы все кто не попадя, и высокими издержками на коммуникацию (надо подробнее всё расписывать, и простые вопросы отнимают больше времени, и часто не задаются).
Мне кажется что сильно зависит от конкретной задачи и коллектива, при хороших процессах и квалифицированных сотрудниках вполне работает, а в "усреднённых условиях" не очень.
Но, наверное, это не формат обсуждения в комментариях :)
прочитал.
Откуда уверенность: да чисто мои ощущения. Никаких расчетов у меня нет.
Есть, конечно, базовые правила работы с удаленкой:
контроль показателей разработки, никаких задач без трекера, процесс разработки/тестирования и прочее
джунов надо набирать только под толковых и проактивных лидов, которые сами будут джунов пинать и контролировать.
костяк точно должен быть сильный (впрочем как и в офлайн компании).
ну и наверное надо почаще общаться с лидами и сотрудниками и не лениться делать голосовые или даже видео встречи. Чтобы никто не чувствовал себя брошенным
Удаленка, гибрид или офис, или как пасти котов в 2025 году?