Comments 26
Delivery lead? Ведущий курьер что ли?
Будьте активны, а не реактивны.
В первую очередь я делаю свою важную работу, а уже потом отвечаю на сообщения и письма.
Ну, не всегда так можно. Только с одноранговыми. За что я и не люблю менеджмент.
Во всем согласен с автором, только встречи не отклоняю. Поэтому на собственно работу остаётся часов 10 в неделю
Если контора готова платить зарплату за присутствие на совещаниях, это и вправду выглядит странно. Но похоже - это "новая реальность".
Да, в новой реальности организация платит за выполнение обязанностей, а совещания - побочный эффект что ли. Когда календарь разрастается, и совещаний становится так много, что они занимают всё рабочее время, организации в целом безразлично. Это становится личной проблемой человека, который начинает перерабатывать, выгорать, болеть, а организация платит как раньше
Аналогично и в разработке. На прошлом месте работы понял, что совершенно не нужно перенапрягаться, чтобы работать столь же эффективно, как и остальные (и даже лучше). Реальное время работы составляло порядка 4-5 часов максимум и, когда вынужден был уволиться из-за переезда, сказали, что работал при этом очень быстро и хорошо (за пару месяцев до этого команду сократили вдвое, т.к. основной цикл разработки стартапа завершился). Уроки танцев сразу после работы просто заставляли меня заканчивать вовремя, не задерживаясь на работе более, чем на 10 минут. И оказалось, что никому и не нужно, чтобы я задерживался.
Будучи джуном, я привык, что надо стараться сделать за день максимально много - и это хорошо, даже правильно, пока ты новичок и надо нарабатывать опыт. Будучи мидлом, всё продолжилось в том же духе - хотелось как можно поскорее вырасти. А уже в качестве сеньора не сразу удалось притормозить и понять, что качество работы оценивается не количеством написанных строк и, если можно сделать задачу, даже не открывая код, то так и надо делать. Так появились задачи, которые мне банально не хотелось выполнять после прочтения описания, т.к. чувствовался от них какой-то душок. Во всех таких случаях она на следующий день отменялась. Но для этого нужна насмотренность и хорошее понимание проекта.
В целом, продолжаю в том же духе. При этом задачи заканчиваются быстрее, чем время, на них отведённое.
Появились дейлики, где сидит команда 20 человек, где каждый ждёт своей очереди, чтобы рассказать о своих вчерашних задачах
Сто раз уже всем объясняли что на daily scrum надо рассказывать что мешает решить сегодня сегодняшние задачи. И как это побороть. А не вот это все. Но нет.
Так устроен скрам by design. Методология для тех, кому ничего более сложное и продвинутое не осилить. Поэтому в скраме всегда есть и всегда будет "эксцесс исполнителя". Просто потому, что исполнители уровнем выше базового - не будут использовать скрам.
Это, конечно, легкий троллинг с моей стороны. Не воспринимайте всерьез :)
А где пункт 8?
В целом, все по теме сказано десятилетия тому назад. Брукс, ДеМарко и Листер, вот это вот все. Но каждое поколение вынуждено заново открывать для себя базовые вещи.
Автор молодец, что сам дошел до правильной практики. Печально, что пришлось учиться на собственных ошибках, а не на чужом опыте. Но что уж тут поделать.
Я заканчиваю рабочий день вовремя
Я отклоняю встречи
Я включаю режим "в самолёте"
Я не работаю в обед
Я отказываюсь от многозадачности
Я говорю "нет"
и потом тебя увольняют за низкую продуктивность ;) потому что из 10и человек 7 скажет что ты не пингуешься, что с тобой трудно найти время на решение повисшей задачи и ты постоянно блочишь других.
Некоторые риски есть, но они преувеличены. У любого начальника выбор невелик.
Или чувак, который "плохо пингуется", но при этом способен решать задачи.
Или новичок, который первый полгода будет только других "пинговать", чтобы хоть в чем-то разобраться. А когда разберется, не факт что не свалит.
Если сосредоточенность сотрудника на своих задачах является проблемой для конторы, может не стоит в такой конторе работать?
не знаю, решайте сами, но чем выше у вас грейд, тем больше вопросов к вам со стороны разных людей и как правило вопросы блочат работу этих людей. Автор же не пытается решить несуществующую задачу, просто он нашел такое специфическое. Нужно быть очень серьезным человеком в компании чтобы футболить людей, а в непосредственной рабочей команде все равно такого не поймут кем бы вы не были и коллеги вас "оценят" по заслугам на перформанс ревью. а все остальное это воображаемый идеальный мир
чем выше у вас грейд, тем больше вопросов к вам со стороны разных людей
да
и как правило вопросы блочат работу этих людей
у меня с ростом грейда больше вопросов стало только от паникующих продаванов, пытающихся влиять на приоритеты моей команды своими дурацкими звонками. Естественно, ни чьей работы это не блокирует.
Нужно быть очень серьезным человеком в компании чтобы футболить людей
всех подряд — да. Но всех подряд футболить и не надо. Начать надо со всяких бессмысленных болтунов и паникёров, за которых никто не вступится. Дальше можно расширять практику. Поставить Окна Овертона на пользу обществу, так сказать
непосредственной рабочей команде все равно такого не поймут
Ну опять же, на вкус и цвет все фломастеры разные, но я лично никогда не видел (и даже не слышал про) команду разработчиков, где болтовню по телефону предпочитают текстовым сообщениям. Так что ваша ситуация мне видится крайне гипотетической. Но если в некоей команде принята такая практика, а некоему разработчику она не подходит, то надо или менять практику или менять команду или менять себя. Это верно и для любой другой практики, кстати.
Спасибо за статью, чувствуется что пропустили через себя. Добавьте пожалуйста 8й пункт, так как сейчас его нет
Про пункт 9 оставлю статью по теме как говорить нет: https://habr.com/ru/articles/837070/
владельцу продукта вообще ничего не интересно, он думает о развитии и продвижении. Каждый высказывается по 2–3 минуты, а остальные 37–38 минут сидит фоном.
Вот не найду в каком видео высказывался Gabe Newell, но мысль была такова: в отличии от других компаний, где информация распространяется по принципу push (т.е. сотрудники пишут отчеты регулярные, потом заведующий их может читает или нет -- нужны они или нет), у них в Valve Software информация запрашивается в режиме pull: надо что-то знать -- спросил. Таким образом информация собирается только тогда, когда кому-то надо, а что никому не интересно, того и нет (: И отдельным пунктом проговаривалась открытость в этом плане, т.е. (со слов) рамок в плане доступа (почти?) никаких не было.
Из этого также вытекает практическое отсутствие болтовни бесформенных совещаний.
9 причин работать медленнее, чтобы успевать больше