Илон Маск запретил удалённую работу в Twitter и попросил сотрудников приготовиться к «тяжёлым временам» Статьи редакции

Запрет уже вступил в силу.

  • Об этом Маск сообщил в письме, которое получили все сотрудники Twitter.
  • Запрет на удалёнку вступил в силу сразу после получения письма — теперь работники должны будут проводить в офисе не менее 40 часов в неделю.
  • Удалёнку будет разрешать лично Маск и только в конкретных случаях.
  • В своём письме глава Twitter попросил сотрудников приготовиться к «тяжёлым временам», отметив, что на фоне замедления роста экономики США компания столкнётся с некоторыми испытаниями. По его словам, эту новость нельзя как-то приукрасить, поэтому надо принять просто как факт.
  • В июне 2022 года Илон Маск запретил работать на удалёнке сотрудникам Tesla, а работникам Twitter на встрече с ними обещал, что запрещать дистанционную работу не будет. Всего удалённо работает около четверти сотрудников соцсети.
0
363 комментария
Написать комментарий...
Павел Лебедев

Интересно как он объясняет это решение? Тем что он ретроград? Этот человек говорил, что у него «синдром аспергера», а ведет себя как типичный нейротипик

Ответить
Развернуть ветку
Илья Осипов

Тяжелее ничего не делать, а потом на митинге отчитаться, что выполнил 4 сторипоинта (которые заключались в "явиться на планёрку") и нужна ещё неделя чтобы закрыть майлстоун.

В IT есть такая проблема, что когда сотрудник не закрыл дедлайн — очень сложно отделить ситуацию "ничего не делал" от "пытался сделать, но столкнулся с неожиданной проблемой". С прогнозированием сроков там вообще пиздец. Условно на заводе всё понятно, вот 10 рабочих делают одно и то же, в среднем деталь за 10 минут, приводим нового, если у него показатели деталь за час — что-то идёт не так. В IT ты не можешь померить "нормальное время на выполнение задачи", потому что почти каждая задача делается впервые в вашей компании. Нормально обсчитать по времени можно только небольшую часть рутинных задач, которые повторяются из проекта в проект.

Так что никто не сможет отличить ситуацию "сотрудник работал 10 часов, просто мы ошиблись в оценке и задача занимает 20 часов на самом деле" от "сотрудник нихуя не делал и возьмётся за 10-часовую задачу только через неделю, и потратит на неё 10 часов".

В офисе откровенное безделие и работа по 2 часа в день заметнее.

Ответить
Развернуть ветку
Неопознанный Енот
почти каждая задача делается впервые в вашей компании

Ну прямо-таки везде уникальные сложные вызовы стоят перед разрабами, да?
«Нормально обсчитать» можно любые проекты и уж тем более задачи, если вы только не работаете в экстремально продвинутых исследовательских институтах, где каждый день работаете с неизвестным, чтобы его приоткрыть.
99% задач разработчика на любой работе в рф можно достаточно точно оценить и «обсчитать».

Ответить
Развернуть ветку
Илья Осипов

Да, везде уникальные сложные вызовы. Не прям уникальные типа "это делается впервые в истории", но "впервые в нашей компании" — это обычное дело.

Собственно как раз потому, что если какая-то задача сделана один раз в любой продуктовой компании — часто второй раз её делать не надо.

UPD: Если вы работаете PHP-шником на галерах и клепаете однотипные интернет-магазины, то это другой вопрос конечно. Но большинство вроде в продуктовых компаниях/стартапах или кровавом энтерпрайзе работают.

Ответить
Развернуть ветку
Неопознанный Енот

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

Ответить
Развернуть ветку
Илья Осипов

Вы решили переехать с кастомной поисковой системы на ElasticSearch. Сколько на это нужно времени, если вы никогда этого не делали?

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

Продакт решил добавить новый блок в профиле с историей прочитанных книг на сайте — кто это будет прогнозировать, если блока раньше не было, а тут решил появиться?

Можно пытаться прогнозировать условными конструкциями, типа "сколько функций/классов мы пытаемся для этого писать", но либо там будут огромные промахи, либо заложен огромный запас, что само по себе не лучше, чем промахнуться.

Ответить
Развернуть ветку
Неопознанный Енот

Вы решили построить дом (в подмосковье), вы никогда раньше этого не делали - ваши действия?

Вы никогда раньше не ходили (недавно родились, валялись в кроватке), решили пойти - как спрогнозировать сроки?

Вы никогда раньше не учили язык, решили выучить - как начать, какие цели ставить, сколько денег и времени закладывать?

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

Я просто напомню, что люди в космосе работают, конечно же можно сделать что угодно и в сроки уложиться, и в бюджет и в ожидания - в конце концов вы их сами и создаете. Управление проектами выросло из ситуации, когда нужно было делать самолеты очень быстро (война), а на запуск модели уходило 10 лет. В войну новые модели запускали за 2 года, если не ошибаюсь - это прецедент начали разбирать и выяснили, что разработкой можно качественно управлять.
Повторюсь, я даже не считаю, что это проблема разработчиков, скорее проблема менеджеров, которые не умеют с имеющейся командой оценить имеющуюся задачу с известной погрешностью. По моим ощущениям, более 90% задач легко обсчитываются и должны (обязаны) укладываться в ожидания - ожидания команды, ожидания бизнеса, ожидания клиента. Здесь нет магии никакой, все процессы давно типизированы - люди много чего за всю историю делали

Ответить
Развернуть ветку
Илья Осипов

Во всех примерах выше люди регулярно промахиваются в оценках, иногда на год+, иногда на 5 лет+.

Пример с английским, например, очень показателен. Кто-то учит за месяц, кто-то за год, кому-то 10 лет мало.

Если нет под рукой людей, которые делали/наблюдали то же самое сотни раз — вы промахнётесь с оценкой. Либо закладывайте огромную вилку, типа x3 к срокам, что в общем-то не сильно лучше, чем промахнуться.

С тем же английским причём даже есть онбординг, тебя определяют в какую-то когорту людей с похожим скиллом, и всё равно разброс в скорости освоения может быть в 2 раза абсолютно спокойно.

Пример с самолётами тоже не показывает способности к прогнозированию. Делали за 10 лет, стали делать за 2 года, но:
- А было ли известно на старте, что успеем за 2 года, или хотели просто "быстрее чем за 10 лет"? Если не было, то разброс от оценки к реальному сроку — в 5, блять, раз!
- А за 2 года реально __выпускали__ самолёт или через 2 года просто говорили "всё, стоп" и выпускали "что получилось"? Тогда решена ли задача за 2 года на самом деле или мы просто хитро пододвинули критерии выполнения задачи под желаемый срок постфактум?

Ответить
Развернуть ветку
Неопознанный Енот

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

Ответить
Развернуть ветку
Илья Осипов

Поход в магазин — частая операция. похрд до метро — тоже. там куда проще накопить статистику лично по моему кейсу.

Вы передёргиваете, я не утверждаю, что хороших эстимейтов не существует. Я утверждаю, что если что-то делалось 0-2 раза в жизни, то вы можете запросто промахнуться с оценкой.

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

Я не спорю, что сроки можно сокращать. Но из этого не следует, что вы можете качественно предсказывать сроки.

Не спорю также и с тем, что предсказуемость можно увеличивать. Но это работает за счёт повторения задачи из раза в раз и сбора статистики. Из этого не следует, что вы можете строить качественные прогнозы в вакууме, без кучи статистики на той задаче, которую вы собираетесь делать. Если задача делается в 1-3ий раз, то статистике взяться неоткуда.

Ответить
Развернуть ветку
Неопознанный Енот

В общем понятно. Это классика срыва сроков - если вы не можете точно оценить таск (пеовый раз делаете или все что угодно) - у вас «ранний старт задачи», это значит, что вы тупо не знаете, что делать. И если так - вы реально по срокам не способны ничего предсказать. Это нормально, но и не требуется. Декомпозируйте задачу до понятного шага, который вы можете адекватно оценить. И двигайтесь пошагово. Не начинайте делать основную задачу, пока не наберете достаточно, чтобы дать уверенную оценку

Ответить
Развернуть ветку
Илья Осипов

Вы видимо работаете в проджект-менеджмете или чём-то ещё близком к топику и воспринимаете себя достаточно высоким авторитетом, чтобы просто описывать свою точку зрения по этому топику и ожидать, что вам будут кивать в ответ.

Но для меня вы не авторитет, вы "Неопознанный Енот". И если спорите, то нужны аргументы, просто сказать "нет, это работает не так" — недостаточно.

Вы снова подменяете тезис, попутно ещё и придумываете мне всякие характеристики "неумелого" человека. Я знаю что такое сбор требований, рассказывать не надо. Про декомпозицию задач, SMART-цели и всё по списку тоже в курсе. Спор в таком виде мне не интересен.

Вы просто доносите мне то, что читали или слышали от других, видимо считаете, что если у меня вдруг другое мнение — это автоматически признак "необразованного в теме". Но необразованный вы, если не можете __аргументами__ показать свою правоту, а не описывая процессы, о которых вы читали или какие-то справки из истории, которые тезис не подтверждают.

Ответить
Развернуть ветку
Филиппов Максим (БА/СА)

Уточните пожалуйста, что подразумеваете под кровавым? Без сарказма, правда интересно чуть подробнее понять

Ответить
Развернуть ветку
Илья Осипов

"Кровавый энтерпрайз" — это уже давно термин, не я придумал, легко гуглится :D
https://otvet.mail.ru/question/215759645
https://techquisitor.livejournal.com/315100.html

Ответить
Развернуть ветку
fffggg gggfff
уникальные сложные вызовы стоят

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

Ответить
Развернуть ветку
Виктор Ефимов

Ну в нормальных организациях не нужно как-то пытаться контроллировать безделие.

Ответить
Развернуть ветку
Илья Осипов

"Нормальной" организацию как раз делают процессы, которые запрещают безделие, за счёт чего его не надо контролировать.

"Ходить в офис" — в полне может быть частью такого процесса.

Ответить
Развернуть ветку
Виктор Ефимов

В нормальных организациях для борьбы с безделием делают не процессы, которые "запрещают", а мотивацию

Ответить
Развернуть ветку
Илья Осипов

Отлаженная мотивация — тоже один из процессов, нет?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Илья Осипов

"За 5 идеально сжигать burnchart" — давайте уточним о чём речь.

1. Вы пилите задачи срок-в-срок, то есть выделили неделю — реально сделали за неделю в спокойном темпе или там закладываются запасы x2-x3, чтобы никогда не промахиваться?

2. Не возникает ли историй, когда периодически разраб просто "хорошо перформит" и может закрыть спринт за 20 часов вместо 40, например?

Про кранчи понятно спрашивать не буду, если вы хотите "идеально сжигать burnchart", то скорее оценки в бОльшую сторону будут переваливать, чем в меньшую.

Просто я обе такие ситуации тоже называю промахом в прогнозировании сроков.

А про "экспертную оценку" — это если a) есть эксперт, который такое уже видел на других проектах и б) оценка не занимает половины от длительности задачи. Наверняка ещё есть в) и г), но я к тому, что не по каждой задаче и не в каждой компании можно собрать бинго из условий, чтобы инструмент сработал нормально.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Илья Осипов

Так ответ-то я не получил, что имеется ввиду под "попадание в ожидания бизнеса >90% в течение 2-3 месяцев"?

Вы пилите задачи срок-в-срок, то есть выделили неделю — реально сделали за неделю в спокойном темпе или там закладываются запасы x2-x3, чтобы никогда не промахиваться?

Просто кто-то скажет, что выделили на задачу 2 часа, сделал за час — это тоже "идеальное попадание", потому что не зафакапили дедлайн же.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
360 комментариев
Раскрывать всегда