Comments 85
Это сработало бы для сферического разработчика в вакууме. Но на практике, работа разработчика имеет задержки. То ждёшь что-то от админов, то тестировщик возвращает тикет, то вопросы к бизнесу появляются. В итоге из 8 часов и без всяких совещаний разработчик в лучшем случае сосредоточенно работает всего часа 2.
Отвлекать программистов от работы — гораздо страшнее, чем кажется на первый взгляд
Отвлекать человека работой — гораздо страшнее, чем кажется на первый взгляд
Интересно, а почему опять речь о "богом избранных" программистах? Отвлекать врачей от работы не страшно? Может водителей? Может дворников на худой конец можно безболезненно отвлекать от работы?
Мне кажется тут смешиваются несколько понятий. Необходимость отвлекать программиста от работы - это всегда показатель отвратительной работы вышестоящего руководства (менеджмента). И ничего больше. Если процессы в организации построены так, что программист вместо написания кода решает какие-то "вопросы" - то туда ли он устроился? Ну или хотя бы на ту ли должность?
Интересно, а почему опять речь о "богом избранных" программистах?
Потому что мы на Хабре, полагаю.
Биологи, схемотехники, конструктора, веб-мастера, менеджеры всех мастей... Даже на Хабре не только программисты. Правда да - тут все же перевод, потому вопрос не к переводчику, а скорее к автору... Но актуальности он все равно не теряет.
А сколько статей ты написал про схемотехников или биологов?
И почему кто то должен делать то что ты даже не начинал?
Это классный вопрос! Особенно если учесть, что его задает человек не опубликовавший ни одной статьи ни по одной теме. Отвечаю.
То, что ты не считаешь других за людей - это твоя персональная проблема. Да, я для схемотехников не пишу и даже не возьмусь - давно не в теме и могу выдать разве что начпоп "для самых маленьких". Да, даже это оказывается до сих пор востребованным вчерашними выпускниками, но... Что до программирования, то тут другая причина - очень узкую статью на интересную мне тему про мой embedded бессмысленно - не так много здесь тех, кто сможет понять, еще меньше тех кто сможет грамотно подискутировать. За то вот таких как ты - которые разведут в комментах очередной виток священной войны на тему "Б говно, все модные давно используют А" - это запросто. А широкую статью в стиле научпоп... С этим прекрасно справляются люди с лучшими писательскими талантами. Все же писательство, как и умение преподавать - это абсолютно отдельный навык. И да, я им в совершенстве точно не владею. По крайней мере в том объеме, чтоб писать. Моя единственная статья тому наглядное подтверждение. И тебе настоятельно рекомендую попробюовать прежде чем такую чушь писать.
@steanlab, @elena_pastukhova, @VAE, @Maximov_psy и можно продолжать дальше - ибо это те, кто совсем не программисты, но кого я тут ЧИТАЮ с огромным удовольствием. И кому при случае задам вопрос по теме в комментариях. Они совсем не программисты, но как хорошая специя оттеняют содержимое. И, уверяю тебя - они тоже читают. И совершенно точно тоже часть того Хабра, который торт.
В этом и одна из проблем текущей реальности: все считают ИТ-шниками только программистов. Прежде чем любой из них самый простенький коммит сделает, стока народу из той-же ИТ сферы потрудятся, что не сосчитать.
А сколько созвонов в день у врачей или водителей? У них точно есть с этим проблема?
Периодически наблюдаю как водителей во время работы отвлекают созвонами, а порой они еще и сами звонят)
У врачей не созвоны, у врачей бумага. Очень много бумаги, сотни километров бумаги в месяц. Когда смотрю, сколько они всего записывают - понимаю, что лечить им, в общем-то, некогда.
Когда смотрю, сколько они всего записывают - понимаю, что лечить им, в общем-то, некогда.
А что вы подразумеваете под "лечить"?
Основная работа типового врача - поставить диагноз (записать на бумаге), выбрать план лечения (записать на бумаге), скорректировать план лечения (на бумаге), выписать пациента (выдать эпикриз на бумаге).
В бытовом понимании лечение организма происходит за счет собственного иммунитета, врач только помогает.
А как можно поставить диагноз, если на прием выделено 15 минут, и из них 12 врач пишет? Как он должен провести осмотр, выслушать жалобы, ознакомится с картой и анализами? Ну и очень далеко не все болезни можно вылечить своим иммунитетом.
Если на прием (особенно, первичный) врачу выделяют 15 минут, пациенту лучше поискать другое место. Да и нормальному врачу тоже.
Если врач не запишет результат осмотра, диагноз, план обследования, план лечения, рекомендации, это будет примерно то же самое, как если программист сочинит в голове кусок кода, расскажет его кому-то вслух, но не станет записывать. Времяпровождение очень занимательное, но с практической точки зрения бесполезное. Немногие пациенты способны со слуха запомнить все формулировки, рекомендации и назначения. И внутренние коммуникации - с точки зрения безопасности пациента, медикаментозное назначение врач должен передавать среднему медперсоналу письменно/в электронном виде. Устно можно только продублировать.
И да, врача тоже не надо отвлекать, пока он работает с пациентом.
Разберем этот миф по порядку.
на прием выделено 15 минут
Это среднее нормативное время приема для терапевта (раз) в поликлинике (два) по ОМС (три). Если упростить понимание, задача такого специалиста сводится к принятию решения из 2 опций: порекомендовать попить витаминки или выписать направление к профильному врачу. Всё. Обычно на это хватает 5 минут. На "интересные" случаи берутся по 5-10 оставшихся минут от типового приема, суммируются и используются по назначению. Или тратятся на внеочередное чаепитие.
из них 12 врач пишет
Мы сейчас в XXI веке. Врач уже давно ничего не пишет в привычном понимании. Он заполняет чекбоксы и пустые поля в типовом шаблоне на компьютере или на заранее распечатанном шаблоне. На это уходит 2-3 минуты.
Возможно вам попался тот самый тип врачей, которые принципиально не пользуются компьютером, шаблонами и всё заполняют от руки. По аналогии с программистами, это как каждый раз начинать писать код с нуля, не пользуясь фреймворками, библиотеками и копипастом. Зачем такие нужны оставим за скобками обсуждений. Или тип врачей, которые по минуте ищут нужную клавишу на клавиатуре. Смотришь и думаешь: светила нашей нации, знают латынь практически как родной язык, но не способны запомнить расположение 40 кнопок. Достали бы своё гусиное перо с чернильницей - быстрее дело пойдёт, но нет. А главное, они не хотят уходить на пенсию и уступать места молодым врачам. Вросли корнями в систему.
Благо, у IT-шников сейчас повально есть ДМС, они с таким не сталкиваются. Остальным можно только порекомендовать потихоньку уходить от бесплатной медицины. Всё-равно "на круг" она обходится дороже из-за перерасхода на покупки ненужных лекарств и места постоянного отдыха..
Потому что со стороны всем кажется, что если программист просто сидит и смотрит в монитор/окно/потолок, то он не работает, поэтому отвлечь его ничего не стоит.
Hidden text
Автор оригинального текста говорит о своей рабочей среде работы, поэтому и неудивительно, что о программистах. Но затронутая тема актуальна практических для многих сфер деятельности.
Необходимость отвлекать программиста от работы - это всегда показатель отвратительной работы вышестоящего руководства (менеджмента).
Нет. Лучше отвлекать программиста от непосредственной работы, корректируя направление этой самой работы, чем дать ему сосредоточиться и сотворить никому не нужную хрень. И заодно корректируя работу множества связанных с программистом людей, включая других программистов, чтобы сделанное было кому использовать.
Собственно, все технологии разработки, без которых уже лет двадцать работать просто нельзя, посвящены именно этому.
Нет
Видимо вам так же не везло с исполнителями, как мне с руководителями.
"Без внятного ТЗ - результат ХЗ". "Как ТЗкнется, так и ТУкнется". "Расскажи что нужно - остальное я сделаю сам". "Не говори мне как делать и я не скажу куда тебе идти". Если менеджерская неспособность выдать грамотное ТЗ маскируется постоянной возней по его корректировке. Если прием прием работы становится фарсом, вместо процедуры. Если реализацией работы занят персонал, чьей квалификации явно недостаточно и ему нужны уточнения в ТЗ. Если ТЗ написано формально ("хочу чтоб было хорошо") - ну тогда да. Лучше отвлекать, и уточнять, и контролировать.
И да - именно создание сложных систем с помощью неквалифицированной рабочей силы - это именно то, о чем так или иначе все эти технологии разработки. При чем "неквалифицированной" в явном виде относится и к менеджерам, и к программистам. Но это не единственный путь, потому категоричное "нет" и не менее категоричное "без которых уже лет двадцать работать просто нельзя" точно не вполне соответствуют действительности. Хотя, безусловно, вынужденно применяются в большинстве задач в реальном мире.
Да, есть очень большая проблема. Ни один программист не признает себя неквалифицированным, которому нужна палка в виде той самой "технологии разработки". А менеджер еще и развернет все - я крут, потому что у меня есть эта самая палка (по сути признав, что без палки он никто и ни на что не способен). И, безусловно, подогнать всех под планку минимальных требований проще. А вот индивидуальный подход давно не в чести. Правильно ли это - я оставлю этот вопрос бизнесу. Впрочем, ответ на него сегодня достаточно очевиден. Регламентированные способы "есть слона по частям" сильно больше нужны именно менеджерам. Для программистов это основной рабочий навык.
Извините, но, наверно, нужно сказать о себе, чтобы было понятно, что я не абстрагирую, а излагаю по опыту:
Я в профессии уже сорок лет, и насмотрелся и на руководителей и на исполнителей. И сам побывал и исполнителем и руководителем. И имел как провальные проекты, так и успешные во вполне международном масштабе. Работал один, в локальных группах, фрилансил пару лет. Последние лет пятнадцать моя группа - люди из четырёх разных городов, на четырёх часовых поясах.
Итак:
Вы пишете с очень и очень устаревшей ремесленной позиции. Вот только, сколь ни уникальны горшки от ремесленника - фабричная продукция куда больше годится для использования.
Брать разработчика с такой позицией в проект - сущее наказание. Ну, разве что он гений (бывает, встречал - но увы, это редкость большая). Для нормальной работы, когда нужно выдать что-то годное, чем не стыдно гордиться - нужны именно технологии разработки и промышленный подход.
Да, планирование разработки идёт из расчёта 4 рабочих дня в неделю. Плюс две недели в конце каждого квартала тоже не идут в зачёт времени на разработку. Именно это позволяет работать синхронно и надёжно - и не дёргать никого неожиданно (по крайней мере - минимизировать это). Именно регулярные совещания помогают избежать проблемы сбитой концентрации. Но ни в коем случае не "работай, дорогой, а мы на кухне посидим, чтобы не отвлекать".
Вы пишете с очень и очень устаревшей ремесленной позиции. ... Брать разработчика с такой позицией в проект - сущее наказание.
Хорошо то, что здесь мы полностью солидарны. А готов применить ровно те же слова по отношению к вам.
Вы можете производить массовую продукцию конкурируя со множеством аналогичных производителей - на здоровье. Это будет давать оборот, и даже даст прибыль. Если вы сделаете свою работу, и "рыба покрупнее" не сожрет. Бизнес хочет прибыль - понятно. На ваш путь - это путь GM, Ford'а или Toyota. Работа с оборота. Воевать на этом поле этом поле с гигантами, используя их же методы, но не обладая такими объемами - это практически гарантированный путь к провалу. Единственный способ выжить и получать прибыль - это путь Ferrari, Pogani, Maserati и делать ту самую продукцию, которую называют "искусством", и на фоне которой все остальное становится "ремесленничеством". Создавая рынок, к которому потом будт тянуться те, кто может позволить себе работу с оборота.
Да, есть некоторые, как бы это сказать, национальные особенности. Те самые, благодаря которым зарплата как в Азии, дороги как в Африке, цены как в Америке. И каждый мнит себя как минимум Bently, в своей области, при этом продолжая производить сомнительную по качеству ремесленную продукцию за цену того самого Bently. Ни я, ни вы с этим ровно ничего не сделаете. Это, видимо, поколенческое и должно пройти само собой. Все, что нас отличает - это направление работы. Вы пытаетесь из любого бизнеса сделать GM, я пытаюсь Koenigsegg. Бизнес больше стремится к моим целям, но лучше получаются ваши.
И да, нет у меня 40 лет опыта. Всего лишь 30. Сопляк, без успешных в международном масштабе проектов (да, черт возьми - только локальные).
Вы можете производить массовую продукцию конкурируя со множеством аналогичных производителей
Нет, не массовую (хотя был такой период, но очень уж давно). От зачатков нейросетей (когда и названия такого у них не было) до современной динамической модели энергетической сети, которая используется во всей РФ и южной части США.
Но понимаю, спорить с крайне устаревшим, но всё ещё очень популярным мнением о том, что такое программист - бесполезно. Жизнь всё расставляет по своим местам, раньше у нас было много конкурентов, сейчас - увы, нет. Хотя мы даже пытались помочь им выжить. Но... как-то не едут кенигсеги. Очень, кстати, хороший пример: полистав автожурналы за хотя бы один навскидку выбранный год, можно увидеть десятки громких заявлений о гиперкарах. Но реально только два есть таких производителя, именно гиперкаров. И то один уже слился с компанией покрупнее. Так что заявление "я строю кенигсег" для меня звучит совсем не громко.
В статье же сказано - лучше использовать асинхронные методы коммуникации. Слак, почту, и т.п. Это дает массу преимуществ. Можно отложить пока ты занят, есть время обдумать вопрос, что то уточнить, и т.п. На митингах решения в основном принимаются на тему "цвета сарая для велосипедов на атомной станции", а любой сложный ответ требует подготовки.
Когда 10 раз в минуту выскакивают уведомления «@vova ответил в чате #newfeature», они тоже отвлекают не хуже совещания. Чтобы быть в «потоке», про который пишет автор, нужно отключить всё и проверять почту/мессенджеры только в заранее выделенное для этого время. Но если я буду так делать, то ещё 10 человек, которые ждут от меня ответа, не смогут работать.
В идеале, наверное, нужно во время дейли нарезать всем работы на день и больше не встречаться, не переписываться до завтрашнего дейли. Автор утверждает, что так повышается продуктивность. Но я что-то сомневаюсь, у нас половина процессов встанет. Или это надо всё менять вообще.
Либо можно договориться с коллегами, что по неотложным вопросам пишем всё в специальный(-е) чат(-ы), преимущественно 1 сообщением, чтобы не спамить уведомлениями. Все остальные чаты можно поставить на mute на несколько часов. Вариант неидеальный, но уже что-то.
1) Таких «специальных» чатов у меня около 20-ти. И в каждый кто-то обязательно пишет 2 раза в день. Разумеется, по «неотложным» вопросам. Это не считая 2-3 человек в личку.
2) Ставить на mute, а потом снимать обратно? А потом объяснять, почему пропустил важное сообщение?
Мессенджеры, как и почта, это сильные отвлекающие факторы, не хуже офлайн сотрудника, которому вдруг захотелось мне что-то срочное сообщить.
Фактически, я большую часть рабочего дня текстю, в свободное от этого время работаю. Поскольку «рабочее окно» может вот-вот захлопнуться, работать стараюсь максимально быстро, иногда «срезая углы» разными костылями, в том числе, и в ущерб качеству, лишь бы не сорвать дедлайн.
Как с этим быть, пока не могу придумать. Вариант нанять ассистента не предлагать.
все просто - приступаешь к задаче - все замьютил и работаешь. Поработал минут 40 ну или сколько надо - открыл чат и почитал все что там наприсылали. В 90% случаях ничего особо важного, требующего решения в сию минуту не бывает, как минимум у программиста. Заодно народ привыкает, что никто им в течении 5 сек отвечать не будет и не планируют свои активности исходя из таких предпосылок.
Возможно, это вариант. За 40 минуту меня набежит 50-60 сообщений, то есть, 10 минут чтобы всё прочитать и ещё 10 чтобы ответить тем, кому надо ответить.
Но надо подумать, как быть с теми, кто ждёт моего апрува. Думаю, им надо просто раздавать по несколько задач, чтобы они, пока ждут меня, делали следующую задачу. Здесь есть минус: появляется мультитаск-эффект, когда много задач требует большего количества переключений. Недавно тут писали, что это страшное зло
1) Такое количество неотложных чатов говорит о проблеме в управлении и эту проблему надо решать, либо таких чатов должно быть меньше либо не во всех из них вы обязаны быть.
2) В мессенджерах есть опция mute с заданным сроком, по прошествии которого mute снимается автоматически.
А потом объяснять, почему пропустил важное сообщение?
Этого не нужно объяснять, нужно поднять вопрос, один раз обсудить, принять регламент работы и работать по нему.
В моём понимании, должно быть не более 2-3 экстренных чатов, которые нельзя мьютить и сообщения туда должны быть строго регламентированы. Все остальные чаты можно мьютить, но не на весь день, а периодически всё же заглядывать (по частоте можно договориться).
К примеру, поработал часик, поставил условно логическую точку, проверил чаты, если ничего нового, продолжил.
Ровно к такой экономии приводит то, что я пишу: запланированные ежедневные встречи плюс планирование и завершение спринта. Потому планируется на разработку 4 дня в неделю и только пять из шести недель спринта.
Но.
Важно понимать, что цель - наличие у заказчика работающего продукта. А не идеальная комфортная работа для исполнителя. Потому, если от заказчика прилетело что-то срочное (и это срочное прошло через фильтр специальных людей, которые хорошо погружены в тему и чья работа - отсеивать дурацкие хотелки) никуда не денешься, приходится и дёргать. Однако как раз за годы перехода на разработки по технологии дёрганий стало в десятки раз меньше.
Спасибо за статью.
Из личного.
Кстати - один очень полезный плюс удаленной работы - невозможность кого либо подойти и стоять у стола.
Когда мне нужно сосредоточенно поработать, я ставлю в Skype статус "Не беспокоить" или "Занят".
Пользуйтесь преимуществами асинхронной коммуникации. Большую часть совещаний можно заменить перепиской в Slack или по электронной почте.
В точку ! Чем меньше онлайн-общения - тем лучше , для технического специалиста. В мессейнджерах ничего не обсуждаю . Только перепиской и только на групповой ящик подразделения.
Кстати - один очень полезный плюс удаленной работы - невозможность кого либо подойти и стоять у стола.
Вы, я так понимаю, не женаты?
Женат. 4 детей .
Тогда поделитесь опытом: как научить жену и детей не подходить и не стоять у стола? Рассказы про состояние потока не помогают. Волшебные трындюли не предлагать.
Ответ на этот вопрос и к теме поста и вообще к тематике ресурса Хабр отношения не имеет и является оффтопиком.
На удаленке с марта 2020 года. В офис - не хочу. Хорошо, что компания тоже понимает выгоду удаленной работы и обладает необходимыми ресурсами для обеспечения. Помнится по началу в 21-м и особенно в 22-м году были некие намеки на возврат в офис. Но здравый смысл преобладал. В офисе сейчас работают только те кто действительно нужен в офисе. Технические специалисты - все на удаленке.
Так вопрос-то не праздный. Компания выгоду понимает, а вот домашние — не понимают, что если я в кабинете работаю, то отвлекать меня нельзя.
Особенно жена, которой постоянно чудится, что у неё что-то смертельное — то тромб оторвался, то мозговой аневризм, то ещё чего. К сожалению, в эпоху "трёх в лодке" (помните, от аритмии до ящура) такая проблема ещё худо-бедно решалась отбором у пациента медицинской энциклопедии — а теперь этот финт не прокатит: есть же интернет!
Уделяйте время жене, явный признак поиска внимания - найти у себя болячку и это обсуждать
Игры настольные с детьми+жена, что ли
от абсцесса
Вы не с того конца подходите к проблеме.
Поговорите с женой, почему она приходит к вам в ваше рабочее время, что ей от вас нужно и чего ей не хватает в ваше нерабочее время.
Сходите вместе к семейному психологу, разберитесь в проблеме.
Самый простой вариант вам уже описал Bessome, но это только одна из возможных причин.
Поговорите с женой, почему она приходит к вам в ваше рабочее время, что ей от вас нужно и чего ей не хватает в ваше нерабочее время.
Я же написал: ей кажется, что у неё какая-то смертельная болячка и она сейчас копыта откинет, если срочно что-то не сделать. Конечно, проверка показывает, что ничего такого и не откинет. Это у неё в любое время бывает, не только в рабочее. Ну нет в ней русского пофигизма!
Пусть жена тоже работает удаленно. Лучше, когда тоже разработчик. У нас так - отличное взаимопонимание. В рабочее время встречаемся, в основном, на кухне у чайника с холодильником. Почитай, как и в офисе у кофемашинки. :)
Я своим обьявил - когда я в наушниках - меня нет. Ну и потом несколько раз просто не реагировал на попытки обратиться ко мне. Это как то сразу до всех дошло, я даже не ожидал.
Тогда поделитесь опытом: как научить жену и детей не подходить и не стоять у стола?
Замок, можно просто шпингалет изнутри на дверь кабинета.
Кстати - один очень полезный плюс удаленной работы - невозможность кого либо подойти и стоять у стола.
Это стало минусом. Потому что подойти (ножками) по мелкому вопросу многие наверное просто ленились (проще наверное так найти инфу в рабочем конфлюенсе). А брякнуть в чат "ты не помнишь как вот это работает?" - так за всегда пожалуйста.
И статусы в чате не особо помогают. "мне же только спросить".
А брякнуть в чат "ты не помнишь как вот это работает?" - так за всегда пожалуйста.
Я не читаю чаты когда сосредоточенно роботаю.
Не знаю как в других мессенджерах, но в Skype если поставить статус "Не беспокоить" - не получаешь оповещения о новых письмах и с тобой невозможно связаться .
"Пишите письма"-я посмотрю когда будет перерыв.
Это очень хорошо ! Ибо 99.999% сообщений этотпросто шум. А об авариях и проблемах СУБД приходят смс .
Это работает, когда от сотрудника не зависит работа других. А когда 10 человек ждут моего ответа, то они не работают. Что как раз снижают продуктивность команды, а не повышает, как утверждает автор. С другой стороны, у нас всех в этом случае не достигается «состояние потока». Замкнутый круг
если работа 10 человек зависит от скорости вашего ответа - у вас обчень плохо с менеджментом. Видимо вы не даете думать или принимать самостоятельные решения своим сотрудникам
Общение с продакт-оунером на мне, как на лиде. И я вынужден просматривать всё, что идёт на ПО, потому что вопросы потом ко мне. Знаю, чем это плохо — команда расслабляется, перестаёт проверять, надеясь, что я проверю. В итоге, количество ошибок растёт. Я на это реагирую, сохраняя эту систему (как минимум). Замкнутый круг распределённой ответственности. Кроме того, есть джуны, которых менторят, конечно, но которых тоже я проверяю, потому что а) менторят их не всегда на 100%, никто не идеален, б) ПО всё это будет потом адресовать мне.
Ну тут одно из двух. Или вы, как лид, занимаетесь слишком большим количеством технических задач, что вам необходимо время для полного погружения и вхождения в поток, или вы, как разработчик, занимаетесь слишком большим количеством менеджерской работы, которой должен заниматься специально выделенный человек.
Если существуют такие вопросы, которые требуют немедленного ответа и останавливают работу 10 человек сразу - вопрос к организации процесса.
Кто заставляет сразу отвечать?
А какая разница. отвечать сразу или потом. "Бряк" в чате уже отвлек.
А канал один. Нет месседжера "для очень важных вопросов и отдельного для "а просто спросить".
Кто заставляет сразу отвечать?
От меня ждут апрува. Пока я не ответил, человек не может продолжать
Это называется микроменеджмент. Он распространен в коллективах с очень низкими компетенциями. От этого надо уходить.
Насколько я понимаю, суть микроменеджмента в следующем. Есть мелкие задачи и есть крупные. Если менеджер контролирует оба типа, это микроменеджмент. Если мелкие делегирует, а контролирует только крупные — то нормальный менеджмент.
В моей команде я апрувлю только выполненную работу. Как, с помощью чего и пр. её выполнять — каждый решает сам. Идеи и пр. высказываем на дейли, потом все разбежались работать, что делать все знают, техтребования и дедлайны прописаны, я не нависаю, смотрю только финал. Если мне всё ОК, то работа уходит на апрув product owner, если ему всё ОК, то на прод. Это микроменежмент? Я думал, что нет.
Отличный пример — ревью запросов pull
проверка важного запроса pull
Кажется, что переводчик не совсем разбирается в предметной области или это машинный перевод
Нате вам ещё аналогию Не будите программиста!
Уже видел свежие методички от эффективных менеджеров, где заявляется, что состояние потока вредно, неэффективно и вообще вымысел. Типа развивайте многозадачность, много совещаний нужно для тимбилдинга и контроля процесса разработки.
Данная тема гораздо полее полно раскрыта в книге Херманса Фелина "Ум программиста. Как понять и осмыслить любой код", и там даже с претензией на научный подход.
Проверьте себя: долго ли вы можете работать, не заглядывая в телефон и не открывая какой-нибудь сайт?
25 пять минут, вообще без проблем, помидорный таймер
Отличное выступление на эту тему - https://youtu.be/0UmUgaJwEr0. Там ещё аналогия классная с засыпанием приведена.
Компания, где этому вопросу посвятят хоть какой-то минимум времени, в т.ч. и объяснение манагерам, что отвлекать челрвека от работы это зло - я хочу работать в ней
Зачем вообще такие статьи, если у большинства скрам? Автор как будто сдельно-премиально в подвале пишет что-то. Для оценки времени берётся некая эталонная задача, которая писалась в таких же условиях с кучей созвонов. Типа вот этот модуль мы сделали за такое то время, за спринт можем сделать три штуки. Значит в спринте 3 сторипойнта. Всё. О каком потоке вы говорите. Никто в своем уме не скажет, что в состоянии потока 15 модулей за спринт сделает )) Пальцем у виска команда покрутит и посоветуют с аддерала слезть.
Если у меня весь день созвоны, то я затрекаю 8 часов созвонов. Зачем делать код ревью ещё во время созвона?
А знаете, что ещё в скраме делают, когда задачи регулярно не укладываются в сроки вдруг из-за созвонов? Уменьшают capacity спринта или выбирают другую эталонную задачу для оценки))
Мне всегда говорили что сторипойнты это не про время, это сумма количества операций всех людей вовлечённых в процесс. То есть ресерч + кодинг программиста + внедрение внедреницем + написание документации тем кто её пишет
Могу копать, могу не копать, не копать могу лучше чем копать.
Для оценки времени берётся некая эталонная задача,
И за кадром всегда остаётся проблема, что повторяющихся типовых задач обычно не так уж много, а большая часть задач с кучей неопределённости, с интеграциями с новыми сервисами, с попыткой договориться с другими командами и такие, что оценить почти нереально
"Сосредоточенная работа — это состояние, при котором задействована
большая часть умственных способностей и которое обычно приносит
уникальный ценный результат." - Это описана психика человека с аутистическим синдромом, занимающимся интересным ему делом. Аутичные люди способны сосредоточиться на проблеме и решать её, забыв про еду и сон. Внезапно (для не знакомых с ситуацией) среди программистов и сисадминов доля аутичных людей выше, чем в других профессиях.
Какая же хорошая статья. На самом деле применима не только к разрабам но и тестерам, которым надо погружаться в сложные глубокие задачи а их дергают по всяким мелочам. Помогает практика: 2 часа работы - час ответов. И вам пишут меньше потому что вы можете не сразу ответить и это известно, и вы не отвлекаетесь. Отвечаете в свободное от задач время. А то получается - вы весь день всем помогаете а задачи не сделаны.
Отвлекать программистов от работы — гораздо страшнее, чем кажется на первый взгляд