Комментарии 98
Палка о двух концах.
Перегиб в затворничество приводит к тому, что итог кодирования никому не нужен.
Хорошо, если у тебя большая полностью детерминированная задача, тут можно на недели уходить в себя, вот только таких задач все меньше.
Доработки все элементарнее и все ближе к заказчику, и все больше вопросов не как закодить, а что закодить, прояснения логических тупиков и прочих нестыковок.
Непрерывная работа по 4 часа в 21-м веке называется затворничеством? Тогда что в 21-м веке называется прояснением логических тупиков и прочих нестыковок? Это по несколько митингов каждый день, когда только из разосланных резюме с трудом вспомнишь о чем была речь? А самым сведущим на проекте НЕОЖИДАННО оказывается программист, который сидит на удаленке.
Ещё один важный момент опущен, на мой взгляд… Современная тенденция такова, что двигаться по карьерной лестнице проще тем, кто больше говорит о своем результате труда, чем те у кого результат труда качественней.
Другими словами не достаточно уйти «в ракушку» и делать качественно свою работу. Нужно уметь её ещё и презентовать и иметь хорошие социальные навыки.
Другими словами не достаточно уйти «в ракушку» и делать качественно свою работу. Нужно уметь её ещё и презентовать и иметь хорошие социальные навыки.
Одни решают проблемы и делают дело, а другие презентуют эти решения и делают карьеру. О том и речь, что два разных мира.
Не два разных мира. Никто не запрещает тем кто делает дело презентовать свои решения. Даже самый затворнический гений сможет выделить на это хотя бы один час в неделю.
Тем более что да, в современном мире хорошая презентация собственной работы – половина успеха, с точки зрения карьеры, и в этом есть доля смысла.
Другое дело что нужно гнать прочь эфективных менеджеров которые после обеда решили с вами еще раз обсудить как идут дела.
Тем более что да, в современном мире хорошая презентация собственной работы – половина успеха, с точки зрения карьеры, и в этом есть доля смысла.
Другое дело что нужно гнать прочь эфективных менеджеров которые после обеда решили с вами еще раз обсудить как идут дела.
Два, два. Есть поле действия «презентаторов», а есть поле «работников». Первые занимаются только своим делом и больше ничем, а вторым — придётся делать два дела.
Но да, никто не запрещает, да.
Никто не запрещает рядовому гражданину прокачать юриспруденцию и одолеть штатных юристов крупной корпорации в суде.
Никто не запрещает бухгалтеру тёте Клаве прокачать шахматы и обыграть Каспарова.
Никто не запрещает нелюдимому, но сильному технарю дополнительно к основной специализации прокачать ещё и словоблудство и одолеть того, кто словоблудство прокачивает всю жизнь и сделал это своей единственной профессией.
Никто не запрещает, да.
Но да, никто не запрещает, да.
Никто не запрещает рядовому гражданину прокачать юриспруденцию и одолеть штатных юристов крупной корпорации в суде.
Никто не запрещает бухгалтеру тёте Клаве прокачать шахматы и обыграть Каспарова.
Никто не запрещает нелюдимому, но сильному технарю дополнительно к основной специализации прокачать ещё и словоблудство и одолеть того, кто словоблудство прокачивает всю жизнь и сделал это своей единственной профессией.
Никто не запрещает, да.
Не два дела делать, а нести ответственность за сделанное другими дело и вести свое аппаратное, менеджерское. И чем выше должность тем дело абстрактнее и туманнее, только вот статистика не подтверждает, что эффективность компании на столько же зависит от CEO, на сколько больше он получает. В этом ряду, самый полезный навык — печатание денег. Правда, уборщице не разрешат.
Не нужно обладать уровнем Стива Джобса, чтобы быть в состоянии рассказать о своей работе.
Если только вы не тянете в одиночку целый проект, умение доносить другим свои мысли — это такой же важный навык для разработчика, как умение печатать или знание английского.
Если только вы не тянете в одиночку целый проект, умение доносить другим свои мысли — это такой же важный навык для разработчика, как умение печатать или знание английского.Только вчера смотрел серию из IT Crowd, как умеющая доносить свои мысли менеджер доносила их таким же менеджерам, рассказывая об интернете. Который в ее понятии выглядел как коробочка с лампочкой. Может все-таки уметь тянуть проект важнее, а не такой же важный для разработчика, как общение менеджерами? Он же разработчик.
Не нужно обладать уровнем Стива Джобса, чтобы быть в состоянии рассказать о своей работе.
Билл Гейтс пытался рассказать о своей работе по созданию планшета…
Цены сравните. За 2000 долларов таблет никому не нужен был. А в три раза дешевле — разошёлся.
Телефоны от Microsoft тоже никому не нужны кстати.
Вот телефоны от Майкрософт я бы попросил не трогать!
По удобству использования это были лучшие устроства из тех, что я использовал. После них от Андроида и «однокнопочных» айфонов грустно и тоскливо.
По удобству использования это были лучшие устроства из тех, что я использовал. После них от Андроида и «однокнопочных» айфонов грустно и тоскливо.
1. Это совершенно разные продукты, даже по стоимости. У майкрософта более профессиональное решение (по сути ноутбук без клавиатуры), у Эппла более казуальное (платформа изначально созданная под тач интерфейс и задачи связанные с потреблением, а не созданием контента).
2. В 2002 году ни массовый пользователь, ни интернет не были готовы к таким устройствам. Какая средняя скорость интернета была тогда? У многих ли был дома Wi-Fi? Да даже GPRS то не везде был.
Уверен, что планшетные компьютеры выпускались и до 2002 года, но были ещё менее популярными чем даже MS Tablet PC по тем же причинам: дороговизна и сложность для массового потребителя.
2. В 2002 году ни массовый пользователь, ни интернет не были готовы к таким устройствам. Какая средняя скорость интернета была тогда? У многих ли был дома Wi-Fi? Да даже GPRS то не везде был.
Уверен, что планшетные компьютеры выпускались и до 2002 года, но были ещё менее популярными чем даже MS Tablet PC по тем же причинам: дороговизна и сложность для массового потребителя.
Только делать что-то полезное и презентовать свой результат обычно проще, чем делать бучу на ровном месте и присваивать чужие заслуги. А еще безопаснее, и карма не страдает.
С такой кармой и такой смешной комментарий.
Всем начальникам собраться завтра в 11:00 я буду до 12:00 рассказывать о своих успехах, чтобы вы доложили топам, и мне повысили оклад.
Всем начальникам собраться завтра в 11:00 я буду до 12:00 рассказывать о своих успехах, чтобы вы доложили топам, и мне повысили оклад.
Вам смешно, а почему собственно нет?
Только приглашать нужно не на рассказ о ваших личных успехах, а на апдейт по важному для компании направлению, которым, так сложилось, занимаетесь именно вы.
У начальников кучу своей головной боли и им нет дела до ваших программистских заморочек. И если не объяснять им на регулярной основе почему ваша работа важна для компании, никто за вас этого делать не будет. И да, на фоне других языкатых коллег (особенно не разработчиков) вы вскоре начнёте выглядеть как-то блекло.
Тянете на себе всю команду коллег недоумков? Расскажите об этом начальнику, но не жалуйтесь, а предложите план по повышению квалификации ваших коллег — он оценит.
А если сидеть и только «делать работу», есть риск в какой-то момент оказаться уволенным за недостаточную продуктивность в лучших традициях историй «о том парне который сидел в углу, который ушёл и все процессы развалились».
Только приглашать нужно не на рассказ о ваших личных успехах, а на апдейт по важному для компании направлению, которым, так сложилось, занимаетесь именно вы.
У начальников кучу своей головной боли и им нет дела до ваших программистских заморочек. И если не объяснять им на регулярной основе почему ваша работа важна для компании, никто за вас этого делать не будет. И да, на фоне других языкатых коллег (особенно не разработчиков) вы вскоре начнёте выглядеть как-то блекло.
Тянете на себе всю команду коллег недоумков? Расскажите об этом начальнику, но не жалуйтесь, а предложите план по повышению квалификации ваших коллег — он оценит.
А если сидеть и только «делать работу», есть риск в какой-то момент оказаться уволенным за недостаточную продуктивность в лучших традициях историй «о том парне который сидел в углу, который ушёл и все процессы развалились».
Есть такое довольно распространенное мнение, что нафиг такие конторы, где увольняют "за недостаточную продуктивность" людей делающих работу, а болтателей языком поощряют.
Вы не разбираетесь ни в психологии, ни в работе с персоналом, и поэтому даже не поняли смысл статьи. Это не удивительно в наше время «эффективных менеджеров», которые не обязаны пройти все ступени карьерной лестницы от станка. Зато вот токарь, по их мнению, обязан подобно им вертеться вокруг начальства, чтобы позаботиться о своей карьере.
Вот отличный комментарий ))
Я совершенно согласен с тем, что, возможно, им нет дела (это зависит от того чем вообще контора занята, если это управление водопроводом, скажем, то да), и тогда посвящать их в наши заморочки незачем. А если контора такая, что не надо разрабатывать, а надо общаться, может надо поискать другую, а эти пусть общаются.
У начальников кучу своей головной боли и им нет дела до ваших программистских заморочек.
Я совершенно согласен с тем, что, возможно, им нет дела (это зависит от того чем вообще контора занята, если это управление водопроводом, скажем, то да), и тогда посвящать их в наши заморочки незачем. А если контора такая, что не надо разрабатывать, а надо общаться, может надо поискать другую, а эти пусть общаются.
Есть шикарное совещание про семь перпендикулярных красных линий, наверное уже ставшее баяном. www.youtube.com/watch?v=UoKlKx-3FcA
И да, на фоне других языкатых коллег (особенно не разработчиков) вы вскоре начнёте выглядеть как-то блекло.
Полностью с вами согласен. Случай из жизни.
Пол года назад, увольняется начальник ИТ.
На его место устраивается мой коллега («языкастый коллега»), который в этой конторе давно.
После чего выясняется, что разница в ЗП всего лишь 10%.
Благодаря его социальным навыкам, он раскачивал себе ЗП и будучи не начальником ИТ, хорошо получал.
Теперь он тянет отдел ИТ по ЗП и результаты есть.
Ну это психология "вот я умру, вы все будете плакать-плакать, а я буду сидеть на небесах на вас смотреть и смеяться".
У начальников кучу своей головной боли и им нет дела до ваших программистских заморочек.
Я правильно понимаю, что слово "начальник" вы никак не связываете с тем, что надо начальствовать?
Рулить программистами, да будет вам известно, это единственное, что от него и требуется. Это заложено в самом его названии. А ему нет дела до того, как работают эти "биологические механизмы"? А как же он собрался тогда этим управлять?
Ещё один важный момент опущен, на мой взгляд… Современная тенденция такова, что двигаться по карьерной лестнице проще тем, кто больше говорит о своем результате труда, чем те у кого результат труда качественней.Это достаточно просто объясняется: качество результата в разработке измерить крайне сложно и не всегда вообще возможно. Поэтому нужно либо держать специального человека на каждые N разработчиков, который будет заниматься только тем, что будет оценивать их работу (мораль разработчиков и этого человека в такой ситуации представьте сами), либо полагаться на объяснение собственно самих разработчиков. А оценивать необходимо — нельзя же просто повышать всех одинаково. У менеджера просто выхода нет кроме как полагаться на красноречие разработчика. А он — тоже человек, а значит пристрастен по умолчанию.
В общем это не просто современная тенденция, это единственно возможный вариант.
Вообще-то есть peer review, когда коллеги оценивают друг друга.
Вклад всегда понятен тем, кто работает в одном репозитории.
Вклад всегда понятен тем, кто работает в одном репозитории.
Окей, если я переписал какую-нибудь функцию так, чтобы она работала в 10 раз быстрее, а мой коллега за это время сверстал макет, то кого как оценить?
Оценивать по полезности для общего дела.
Если функция/лендинг это все, что сделали коллеги за квартал, то это должны быть очень полезные лендинг/функция.
Если функция/лендинг это все, что сделали коллеги за квартал, то это должны быть очень полезные лендинг/функция.
Что значит «полезность для общего дела»? Для команды? Для бизнеса? как это измерить?
Положим, у меня есть гипотеза, что внятная в моём представлении архитектура приложения позволит в будущем разрабатывать приложение быстрее, и зарабатывать больше денег. Но у меня нет цифр, потому, что нужно сначала попробовать и потом понять. Как директору оценить это? По комментариям других разработчиков? Как быть уверенным в том, что они не продвигают что-то нужное для себя, а не для продукта или бизнеса?
Положим, у меня есть гипотеза, что внятная в моём представлении архитектура приложения позволит в будущем разрабатывать приложение быстрее, и зарабатывать больше денег. Но у меня нет цифр, потому, что нужно сначала попробовать и потом понять. Как директору оценить это? По комментариям других разработчиков? Как быть уверенным в том, что они не продвигают что-то нужное для себя, а не для продукта или бизнеса?
Есть рынки, где требовать повышение не очень принято. И тогда весь разговор переходит уже в другую плоскость, нематериальных привилегий, которые решать всё-равно будет начальник и не факт, что в зависимости от красноречия и умения презентовать свою работу.
Поэтому нужно либо держать специального человека на каждые N разработчиков, который будет заниматься только тем, что будет оценивать их работу (мораль разработчиков и этого человека в такой ситуации представьте сами)И должность этого «специального человека» называется руководитель. Оценивать работу своих прямых подчиненных и принимать на основе этого решения о премировании/депремировании — это одна из его основных обязанностей. А если руководитель на это не способен, то он профнепригоден.
Жаль только, что на практике в большинстве случаев начальники ничерта не понимают в том, что делают их подчинённые :(
Жаль только, что на практике в большинстве случаев начальники ничерта не понимают в том, что делают их подчинённые :(Что в свою очередь говорит о квалификации руководителя начальника. Есть гипотеза, что цепочка руководителей склонна к накапливанию ошибок. Поэтому и есть стимул делать её максимально короткой.
Полностью согласен!
Исторический опыт показывает, что один компетентный вождь вполне может руководить общиной в 100-200 человек. Так что можно предположить, что хороший руководитель с коллективом в 100 человек вполне справится.
Один хороший руководитель более высокого уровня справится со 100 руководителей уровнем ниже. Итого даже для большинства огромных корпораций хватило бы всего трёх уровней иерархии (главный руководитель — местные руководители — исполнители), где исполнителю, в случае проблем, нужно переступить всего через одну ступень чтобы добраться до самого главного.
Увы, в реальности есть «небольшие» проблемы с реализацией такой схемы… Начиная с того, что в общинах из общего числа выделялся лидер, а тут лидер назначается сверху. Соответственно в общине лидером просто не мог быть тот, кто не пользуется авторитетом, некомпетентен и т.д. Община либо заменит его другим, либо быстро распадётся/вымрет. А вот в корпорации руководитель запросто может быть презираем всеми, некомпетентен и т.д.
Исторический опыт показывает, что один компетентный вождь вполне может руководить общиной в 100-200 человек. Так что можно предположить, что хороший руководитель с коллективом в 100 человек вполне справится.
Один хороший руководитель более высокого уровня справится со 100 руководителей уровнем ниже. Итого даже для большинства огромных корпораций хватило бы всего трёх уровней иерархии (главный руководитель — местные руководители — исполнители), где исполнителю, в случае проблем, нужно переступить всего через одну ступень чтобы добраться до самого главного.
Увы, в реальности есть «небольшие» проблемы с реализацией такой схемы… Начиная с того, что в общинах из общего числа выделялся лидер, а тут лидер назначается сверху. Соответственно в общине лидером просто не мог быть тот, кто не пользуется авторитетом, некомпетентен и т.д. Община либо заменит его другим, либо быстро распадётся/вымрет. А вот в корпорации руководитель запросто может быть презираем всеми, некомпетентен и т.д.
Очень, важная тема. Сегодня к примеру, день летит «коту под хвост» просто потому, что назначены два митинга один в 11-00, второй на 15-00 при этом обед с 12-30 до 13-30. Полный финиш, не могу целый день взяться за конвейер виджетов, так как мое присутствие обязательно. Вроде как должен знать какую реализацию GraphQL, будут использовать на беке, притом что я фронтенд. Блин ну напишите мне просто, что вы выбрали, а я своей работой займусь. Вместо кода пишу комменты на хабре
Ага, и всё, муза улетела. Еще сюда добавить сочетание разработки с сопровождением этого же или прошлых проектов, и муза не вернется. Останется писать коменты на хабре и читать статьи про прокрастинацию.
П.С. Я в свое время вместо себя посылал на совещания вновь принятого разработчика, он сообщал мне решения, а через полгода стал начальником отдела. А то что я в одиночку сделал проект на моей карьере никак не отразилось.
П.С. Я в свое время вместо себя посылал на совещания вновь принятого разработчика, он сообщал мне решения, а через полгода стал начальником отдела. А то что я в одиночку сделал проект на моей карьере никак не отразилось.
Вот об этом и был мой комментарий выше… Но каждый выбирает то, что ему больше по душе в том числе и методы продвижения по карьерной лестнице.
Была история, как главный ит-безопасник сортировал новичков. Давал задание получить права администратора на ПК без его санкции. Получивших права через ит-скилы ставил инженерами, а тех, кто социальной инженерией через сервис деск — начальниками.
П.С. В моем случае на совещаниях обсуждали, что нарисовать и отправить наверх, чтобы отчитаться о выполнении и получить следующую часть бюджета. У проекта был прототип, поэтому вопросов «что делать» у меня не было. А вопросы «как делать», приходилось решать в одиночку.
При этом у них еще была смешная оценка сроков. И сроки получились совершенно не реальные. Поэтому я не только совещания прогуливал, я и на работу приходил рано утром и/или после обеда. Чтобы поработать в тишине. Всё по книге «Путь камикадзе» Эдварда Йордона, которую тогда же прочитал.
Мой проект все же удалось завершить, хотя и с увеличением срока в Пи раз. Но только потому, что я сконцентрировался и не терял фокус. Карьеры же по любому не было бы, т.к. там на программистов денег жалко, их мало, и расти некуда. А сделать программиста начальником нельзя, работать некому будет.
П.С. В моем случае на совещаниях обсуждали, что нарисовать и отправить наверх, чтобы отчитаться о выполнении и получить следующую часть бюджета. У проекта был прототип, поэтому вопросов «что делать» у меня не было. А вопросы «как делать», приходилось решать в одиночку.
При этом у них еще была смешная оценка сроков. И сроки получились совершенно не реальные. Поэтому я не только совещания прогуливал, я и на работу приходил рано утром и/или после обеда. Чтобы поработать в тишине. Всё по книге «Путь камикадзе» Эдварда Йордона, которую тогда же прочитал.
Мой проект все же удалось завершить, хотя и с увеличением срока в Пи раз. Но только потому, что я сконцентрировался и не терял фокус. Карьеры же по любому не было бы, т.к. там на программистов денег жалко, их мало, и расти некуда. А сделать программиста начальником нельзя, работать некому будет.
В приглашалках всегда есть кнопки decline/maybe.
Винить среду просто, нажать на decline сложно (OMG так же не принято).
Винить среду просто, нажать на decline сложно (OMG так же не принято).
А до 11-00, начиная с 9-00 из-за гибкого графика в офисе все 100 человек опенспейса здороваются с интервалом в минуту… и почему то обязательно через рукопожатие. И не всегда это рукопожатие, к сожалению, чистое и свежее.
Вот это, вообще, никогда не понимал.
Ну в чём смысл со всей комнатой здороваться за руку? Зашел, сказал "доброе утро", кто захотел — ответил, кто в наушниках — проигнорировал, кто пил кофе — аналогично.
А тут получается, что целый день потом кто-то тебя ещё с утра не видел и лезет руку пожать.
Я тут не отвечу, не люблю всю эту антисанитарию, и ни с кем первым за руку не здороваюсь.
Своим невежливым примером поборол эту дурацкую традицию в отдельно взятой команде :) В смысле все по-прежнему ручкались, а я стал просто говорить «привет» и «пока» всем сразу, направлясь прямо к своему столу/выходу. Я думаю, многие давно так хотели, но не хотели быть самым невежливым
Здороваюсь за руку только с нашей командой, менеджерами и админами, иначе слишком много людей и запарно.
Человек 10 выходит, вполне приемлемо, кмк.
А уходя, вы с коллегами тоже всех за руку дёргаете?) Для меня рукопожатие было всегда синонимом «поздороваться», поэтому до сих пор не понимаю к чему это рукопожатие при прощании. Вроде здоровались же сегодня...)
В точку!!! е я один такой… Был у меня период когда я любил приходить пораньше. И потом каждые 3-5 минут все заходили здороваться. Одел уши, спрятался за 3 мониторами, не помогало, требушат пока не получат желаемое.
Вместо этого общение может происходить в более спокойном асинхронном режиме в виде вдумчивых, письменных дискуссий, а не драматичных собраний или хаотичного обмена репликами по одной строке в чате.
Как-то я не видел чтоб это работало. Если есть четкая задача, которую плюс-минус понятно как делать, то написать ТЗ и попросить всех посмотреть ещё как-то сработает (хотя скорее всего читать не будут), но если задача вообще не ясна, то без личного мозгового штурма у меня не получается. Может есть какие-то джедайские техники?
Менеджеры преимущественно экстраверты, которые думают «через произношение». А исполнители преимущественно интроверты, они думают внутри.
www.youtube.com/watch?v=efQL3uylh7M&t=37
www.youtube.com/watch?v=efQL3uylh7M&t=37
Исполнители, если поймут, что им не хватает письменного общения, сами соберутся и устроят штурм.
Может я пессимист, но скорее всего исполнители решат, что "тут и так все ясно" и каждый сделает по своему.
Это твой коммент левацкое говно. Только у вас в Совке стадам идеи приписывали, чтобы задавить ярких личностей. А в развитых странах идеи и прибыли приходят и оседают индивидуально.
Чтобы брейншторм был эффективным с проблемой нужно «переспать».
Т.е. в начале нужно погрузиться в проблему, обдумать самостоятельно, а потом уже с группой товарищей пробовать варианты «на зуб».
Т.е. в начале нужно погрузиться в проблему, обдумать самостоятельно, а потом уже с группой товарищей пробовать варианты «на зуб».
Вот как раз в офисе и сидишь полдня «скролишь фейсбук» (ну или вот я сейчас Хабр скролю, что не принципиально отличается), т.к. всё равно работать в такой обстановке толком не можешь.
Работаю разработчиком в САПР — мой менеджер пошёл ещё дальше: новая фича отдаётся пользователям, которые мне потом задачи в Asana накидывают (типа баги и т.п.). Т.е. тестирование боем. Причём для проверки этих фидбеков нужно тратить уйму времени, так как пишу под Revit (он долго запускается и долго открывает проекты). На разработку тратится очень мало времени. А мой менеджер считает, что все норм...
Как будто мои мысли изложили, но одну причину не описали, это огромное кол-во задач на разных проектах, и менеджер каждого проекта будет звонить, наваливать новую задачу и спрашивать у тебя «когда?».
Автору — «Золотые слова, Юрий Венедиктович!!!»(с)
На одной из моих работ (на производстве ) был у нас программист по системам реал-тайм, так он днем обычно работал в наушниках ( глушилки, не аудио).
Потом договорился с директором и стал ходить периодически «в ночное», на 12 часов, с 8 вечера до 8 утра (вместе с «вахтой», до работы добраться можно было только на служебном шатле или такси)
Ночная смена, с его слов,
с 20 до 20-30 перекус, чай-кофе
до 4-5 часов утра работа
с 4-5 до 7 поспать
За одну «ночевку» выполнялись задачи для которых требовалась неделя «в день».
На одной из моих работ (на производстве ) был у нас программист по системам реал-тайм, так он днем обычно работал в наушниках ( глушилки, не аудио).
Потом договорился с директором и стал ходить периодически «в ночное», на 12 часов, с 8 вечера до 8 утра (вместе с «вахтой», до работы добраться можно было только на служебном шатле или такси)
Ночная смена, с его слов,
с 20 до 20-30 перекус, чай-кофе
до 4-5 часов утра работа
с 4-5 до 7 поспать
За одну «ночевку» выполнялись задачи для которых требовалась неделя «в день».
Из личного опыта могу сказать, что чрезмерно любящий общение заказчик, который в середине рабочего дня просит объяснить «на пальцах» зачем нужны ВСЕ классы в проекте и что их методы делают, конечно же, очень способствует повышению производительности труда.
А «любимые» всеми опенспейсы бесят до невозможности — представьте себе, что вы пытаетесь решить сложную проблему, когда в метре от вас ваш коллега сербает чай, одновременно чавкая вафлей.
А «любимые» всеми опенспейсы бесят до невозможности — представьте себе, что вы пытаетесь решить сложную проблему, когда в метре от вас ваш коллега сербает чай, одновременно чавкая вафлей.
Спасибо за статью!
О таких деталях не задумывался, но когда прочитал, понял как много времени я терял из-за большого потока звонков, сообщений, и большого кол-ва одновременных задач.
1-2 месяца как перевелся в другое подразделение, и теперь по настоящему могу оценить и сравнить свою производительность между двумя вариантами (вариант с большим кол-вом прерываний/отвлечений и вариант полного спокойствия/сосредоточения).
О таких деталях не задумывался, но когда прочитал, понял как много времени я терял из-за большого потока звонков, сообщений, и большого кол-ва одновременных задач.
1-2 месяца как перевелся в другое подразделение, и теперь по настоящему могу оценить и сравнить свою производительность между двумя вариантами (вариант с большим кол-вом прерываний/отвлечений и вариант полного спокойствия/сосредоточения).
Спасибо за статью!
Конечно нет черного и белого. Готов согласиться с общей идеей и особенно с тем что частые прерывания делают неэффективным выполнение большой неделимой задачи
Что хотелось бы добавить из личного опыта
1. по любой теме, всегда до встречи стараюсь отправить материалы и вопросы по почте. люди в удобное для них время обдумают тему, ответят на вопросы и сама встреча пройдет в разы эффективнее если вообще понадобится
2. менеджерам тоже иногда надо весь день выделить на одну большую задачу. и всё остальное просто отправляется «на завтра»
3. очень редко вопрос, который пришел в голову сейчас, требует ответа прямо сейчас. людям свойственно преувеличить важность проблем о которых они узнали только что. и что плохо — они таким образом могут преуменьшить значение проблем давно висящих и еще нерешенных…
к чему это я, к тому что 72% прерываний происходят не из-за того что нужно что-то решить, а из-за того что кому-то показалось что это нужно решить прямо сейчас
В общем, думаю что дело не в менеджерах и созидателях, а в подходе к управлению.
Все упирается в то, какая цель у менеджера. В его руках и возможность выбирать даты и время для встреч и также разбиение больших задач на мелкие (если нужно чтобы созидатель спокойно взял и выполнил задачу целиком, без отвлечения на митинги — просто задача небольшая и умещается в «перерыв» между встречами)
Конечно нет черного и белого. Готов согласиться с общей идеей и особенно с тем что частые прерывания делают неэффективным выполнение большой неделимой задачи
Что хотелось бы добавить из личного опыта
1. по любой теме, всегда до встречи стараюсь отправить материалы и вопросы по почте. люди в удобное для них время обдумают тему, ответят на вопросы и сама встреча пройдет в разы эффективнее если вообще понадобится
2. менеджерам тоже иногда надо весь день выделить на одну большую задачу. и всё остальное просто отправляется «на завтра»
3. очень редко вопрос, который пришел в голову сейчас, требует ответа прямо сейчас. людям свойственно преувеличить важность проблем о которых они узнали только что. и что плохо — они таким образом могут преуменьшить значение проблем давно висящих и еще нерешенных…
к чему это я, к тому что 72% прерываний происходят не из-за того что нужно что-то решить, а из-за того что кому-то показалось что это нужно решить прямо сейчас
В общем, думаю что дело не в менеджерах и созидателях, а в подходе к управлению.
Все упирается в то, какая цель у менеджера. В его руках и возможность выбирать даты и время для встреч и также разбиение больших задач на мелкие (если нужно чтобы созидатель спокойно взял и выполнил задачу целиком, без отвлечения на митинги — просто задача небольшая и умещается в «перерыв» между встречами)
Не отрываясь. Я сомневаюсь что у вас хватит attention span высидеть столько.
Здесь жалуются те, у кого attention span'а хватает на четыре часа и больше, но каждые два часа им его насильно прерывают очередным митапом.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения.
При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Ссылка на статью
При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Ссылка на статью
Идея хорошая, но не в этом смысл. Одно из правил Scrum — самоорганизация команды и отвечают за результат все, а не каждый персонально. Если люди не способны самоорганизоваться, то нужен team leader, который будет отвечать за все, распределять работу и требовать результаты от подчиненных. Scrum это будет или уже нет, я не знаю, вопрос к теоретикам Scrum.
ваша эффективность в коммуникациях, как одном из ключевых навыках менеджера, налицо.
Знакомый коач это диван что ли?
attention span у взрослых в среднем 10-20 минут
Речь в статье несколько о другом. Разумеется, эти каждые 10-20 минут будет просто встать/пойти поссать/пойти налить кофе/пойти достать на разморозку/пойти перекусить/etc. С работы над основной задачей, которая будет длиться суммарно часы, это не будет сбивать, в отличие от совещаний.
Я на себе наблюдал, наибольшая эффективность у меня была, и по 6 часов, и больше, когда я не в офисе сидел, а дома безработным, работая над опенсорс-проектом. Очень контрастная разница с офисом, где нередки дни "нет, сегодня уже ничего полезного сделать не выйдет".
почему люди не любят скрам
Потому что из техники, годной для выруливания из авральных ситуаций, пытаются сделать типа-нормальную повседневность. На Хабре зимой 2018/19 была отличная большая статья с разбором проблем, поищите.
коач [...] лентяии
О, надсмотрщик с шарлатанством детектед. Предъявите-ка собственные достижения в производительной работе, а мы оценим их количество и качество, наряду с полезностью сообществу. Нет, менеджерство и коучинги всякие не считаются, только настоящая работа.
Это как бы аннулирует весь поинт этой статьи про часы сфокусированной работы
C чего бы это вдруг? Встал я пойти поссать или просто побродить по комнате рядом с компом, голова над задачей думать не перестает.
А ну то есть если дедлайн не подпирает, то можно расслабиться и работать как работается. Ясно понятно.
Лол, примитивный уровень понимания держиморды, не видящий вариантов кроме двух. Окей, спущусь на него и поиронизирую — да, лучше именно так, чем сделать вовремя, да говно.
Странно почему только менеджеры и создатели, а не притянули еще сюда сов и жаворонков, экстравертов и интравертов, холериков и флегматиков, горящих и уже перегоревших и т.п.
Просто все люди разные и любят разные условия труда, это нужно учитывать для получения максимальных результатов от сотрудников за ту же зарплату. Если менеджеров результаты интересуют, а не одна движуха.
Просто все люди разные и любят разные условия труда, это нужно учитывать для получения максимальных результатов от сотрудников за ту же зарплату. Если менеджеров результаты интересуют, а не одна движуха.
Всё правильно. У нас в лаборатории когда надо писать отчеты, или статьи, или что-то считать народ часто сидит дома и э… мэйкерит. А придешь на работу — шеф захочет какую-нибудь фигню или решит пообщаться на мотивационные темы, кто-то зайдет поздороваться, кто-то зайдет попросить что-то, придет аспирант, придет студент… и такая дребедень целый день. И да — часто замечал — муза прилетает ночью.
Спорить ни о чем можно долго и нудно. Если результаты работы измеримы, то нужно всего лишь протестировать вариант А и вариант Б, и сделать соответствующие выводы. Если результаты работы НЕ измеримы, то любой и каждый будет стараться вешать лапшу на уши в свою пользу.
прочитал адресатов письма как mark, kill me
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Если вы что-то создаёте, избегайте расписания менеджера