Мы привыкли смотреть на выбор, как на условный оператор в языке программирования или схеме алгоритма. Ну, помните, такой ромбик рисуется, в нем условие выбора, и две веточки – да и нет. При исполнении алгоритма условие проверяется мгновенно, поэтому его производительность обычно не принимается в расчет.
А что есть выбор, выполняемый человеком? Это не мгновенный алгоритм, а процесс. У этого процесса есть начало, конец (дай-то Бог), и, главное – продолжительность. Сколько, по-вашему, может длиться выбор задачи?
Можно гадать, но лучше измерить. Я наблюдал за этим процессом многократно, и вывод неутешительный: программист может выбирать задачу несколько дней.
Процесс выбора плох тем, что скрыт от нашего взгляда. Если бы человек слонялся по кабинету, метался из стороны в сторону, вскидывал голову в протяжном вое, мы бы поняли, что у него проблема. Но происходит иначе.
Программисты давно придумали такой алгоритм, как разведка боем. Применительно к задачам он означает: не просто почитать условие, а зайти и посмотреть. Глянуть на код, формы, связи, метаданные, примеры воспроизведения и аналитические отчеты.
Посмотреть надо для того, чтобы оценить задачу «как следует», не на глазок. Если поймать программиста за этим занятием, то он скажет: я – профессионал, и не могу браться за задачу, не зная всех тонкостей. Казалось бы, чего же тут такого? Правильно ведь делает человек?
Конечно, правильно. Но только если он, по результатам своих исследований, примет окончательное решение – браться за задачу, или нет. Как вариант – взять задачу с оговорками, вроде необходимости изучения дополнительных механизмов.
Если программист решил задачу взять, и сел делать, то все хорошо. Если же он отказался от задачи, то все плохо. Время, потраченное на исследование, будет потеряно даром.
Тут варианта два. Первый – программист откажется наотрез, и задачу будет смотреть кто-то другой. В принципе, возможен вариант, когда первый программист просто перескажет второму результаты своих исследований, обнаруженные подводные камни и сопутствующие трудности. Но на практике программисты предпочитают независимость друг от друга, в том числе – от мнения коллег. Некоторые даже испытывают определенный азарт, разбираясь в задаче, за которую не взялся коллега.
Второй вариант – программист не отказался, а отложил задачу на потом. Когда наступит это «потом» — не известно, но скорее всего – через достаточно продолжительное время. Что будет во время второй итерации разведки боем? Начнет с того места, где остановился в исследованиях? Разумеется, нет – он пройдет тот же путь, от начала и до конца. И, с высокой вероятностью, застопорится на том же самом месте, что и в первый раз.
И вот что получается. Есть время, которое программисты тратят на решение задач. Нормальное, правильное, полезное время. Как правило, время на решение задачи тратится один раз.
А есть время, которое программисты тратят на многократную разведку. Никакой особой пользы в этом времени нет – ни для программиста, ни для клиента, ни для вашей компании. Время на разведку боем – практически чистая потеря.
Но проблема не только в разведке. Бывает и хуже.
Например, программист понимает все задачи в своем списке, но просто не может выбрать, чем ему заняться. Проблема усугубляется тем, что выбор происходит, как Бог на душу положит – без определенного алгоритма, критериев и приоритетов. И тут уж кто во что горазд.
Один выбирает то, что поинтереснее. Другой выбирает то, что полегче. Третий выбирает задачи по механизмам, которые ему знакомы. Четвертый выбирает задачи своего любимого клиента, потому что результат сдавать проще. Пятый выбирает самую амбициозную задачу, чтобы показать себя.
При этом, что важно, почти каждый из них испытывает серьезные душевные терзания из-за неопределенности критериев. Он примерно понимает, какие задачи хочет решать, но, или осознанно, или неосознанно чувствует, что делает что-то не так. Ему кажется, что надо выбирать совсем другую задачу, исходя из стратегии работы компании, состояния проекта, плана развития собственных компетенций и т.д. Но хочется-то выбрать не то, что надо, а то, что по душе.
Такие душевные терзания еще сильнее усугубляют процесс выбора. Человек погружается в мрачные размышления, взвешивая на весах совести свой выбор. И так могут пройти часы и дни.
С точки зрения менеджера, стоящего в стороне, весь этот процесс напоминает сурка из одного известного фильма, который вылезает из норы и «выбирает погоду на ближайшие шесть недель». Чем он там руководствуется, видит свою тень или нет, и почему вообще это делает сурок? Правда, если менеджер часто смотрит на этот процесс со стороны, то вопрос скорее к нему, чем к программистам.
Так же, в контексте выбора большое значение имеет праздник. Программист – он ведь человек, в первую очередь, а не робот. Чего хочется человеку после выполнения сложной работы? Праздника, конечно!
Выполненную задачу нужно отметить. Сходить покурить, выпить чаю или кофе, поболтать с друзьями, похвастаться решенной задачей, посидеть в социальных сетях, почитать новости – в общем, вариантов множество. К сожалению, этот праздник иногда затягивается.
Особенно плохо, если задача была закончена за час, или даже за два до окончания рабочего дня. Ну кто, в здравом уме, будет выбирать себе новую задачу, если скоро – домой?
Как непросто выходить из состояния праздника, знает каждый россиянин – все мы отдыхаем в новогодние каникулы. В нашем случае – еще сложнее, т.к. программист должен вернуться не к решению задачи, а к выбору следующей. Насколько мучителен выбор, мы уже обсудили.
Если резюмировать потери от выбора, то они есть всегда. Вопрос только в их количестве. Чтобы вы прониклись, назову такую цифру: на выбор задачи уходит до 50 % времени. Только вдумайтесь в эту цифру.
Но, в контексте нашего материала, эта цифра просто прекрасна. Избавившись от потерь из-за выбора, вы можете увеличить эффективность вдвое.
Как же избавиться от выбора? Нет ничего проще. Собственно, вы сами знаете, как это сделать. Я изложу свои предложения, а вы скомпонуете их с собственными методами, и получится приличный рост эффективности.
Первое и главное, с чего следует начать, это контроллинг. Какую бы вы не придумали систему приоритетов и распределения задач, она не будет работать, пока программисты вас «не слушаются».
Контроллинг, в двух словах, это – управление на основе цифр. В данном случае цифрой будет не прибыль или сумма продаж, а порядковый номер задачи в очереди. Нужно управлять выбором задачи на основе этого номера, и быть уверенным, что задачи решаются в заданном порядке.
Контроллинг необходим и в случае, если вы управляете командой, и даже тогда, когда вы управляете собой. С собой ведь договориться проще, чем с начальником? «Да сейчас, в последний раз, а потом уж точно!».
Вообще, про контроллинг мы еще поговорим более обстоятельно, здесь я забежал вперед, но оно того стоит. Если вы придумали правила выбора задачи, но их никто не исполняет, то ничего не получится.
Итак, все, что надо сделать – выстроить задачи в очередь и обеспечить следование этой очереди. В некоторых источниках рекомендуется скрывать очередь от программистов, оставляя в поле зрения лишь две задачи – текущую и следующую. Если показать программисту все задачи сразу, то он, как ни старайся, все равно будет «подглядывать», изучать, что там впереди.
Первый способ – распределение задач начальником, без использования автоматизации. Вы просто говорите, кто что делает и в какой последовательности. Можно составлять несложные планы – например, в виде маленьких бумажек, вроде нарядов на выполнение работ, или заданий на производство. Можно просто диктовать номера задач под запись в блокнот.
Можно сделать доску, по типу скрама, и вешать туда стикеры на день. Методика скрама предполагает вывешивание множества задач, например – на неделю или месяц, но нам это не подходит, потому что снова появляется выбор.
Ручное распределение задач очень просто начать, и так же просто прекратить, потому что быстро надоест. Нужно иметь значительную силу воли, или хорошие навыки регулярного менеджмента, чтобы ежедневно заставлять себя распределять задачи. Если сказанное – про вас, то можете начать уже сегодня.
Для ленивых подойдет автоматизация. В вашей информационной системе, где хранятся задачи, надо заложить механизм их сортировки. Как вам ближе? Сортировать по дате постановки? По сроку исполнения? Годится любой способ. Главное, чтобы он был детерминирован и одинаково понимаем программистами. Лично я рекомендую не ограничиться сортировкой, а хранить номера в очереди в виде отдельного поля. Современные системы слишком удобны для пользователя, и позволяют ему настраивать сортировку самостоятельно. Вот вы решили, что надо задачи выполнять в порядке поступления (FIFO), а программист случайно, или умышленно, поменял сортировку на обратную, и получил LIFO.
Если же номер в очереди сохранен, то сортируй, не сортируй, ошибиться сложно.
Можно не привязываться к сортировке, а ставить номера вручную. Тоже годится, если у вас хватит силы воли расставлять эти номера.
Принцип, думаю, понятен. Любая система составления очереди, понятная программистам, и контроль ее соблюдения. Это будет первый шаг к лишению выбора, отнимающего эффективность.
Второй шаг мы рассмотрим дальше. Он позволит нам извлечь из очередей намного больше пользы – не только упростить выбор, но и сделать его правильным.
Резюме
- Выбор задачи – это не мгновение, а длительный процесс;
- Программист выбирает задачу, исходя из собственных представлений;
- На выбор тратится огромное количество времени;
- Процесс выбора не приносит ни пользы, ни удовольствия;
- Выбора надо лишить;
- Распределять задачи можно вручную, как прораб;
- Автоматизация может помочь в составлении очередей.
Комментарии (56)
gennayo
07.05.2019 10:01Ну не знаю, по-моему, большая проблема не длительный выбор задачи, а длительный выбор способа её реализации.
Vezzird
07.05.2019 10:14Тут описана ситуация, когда выбор способа ее реализации идет до выбора задачи, в том числе.
Т.е. висит пул и ты сидишь, думаешь. Хочу ли я это делать и как это буду делать.
Ситуация становится совсем затянутой, зачастую.gennayo
07.05.2019 10:25Да какая-то несколько гипотетическая ситуация, как мне кажется.
Vezzird
07.05.2019 10:42Я бы назвал это не гипотетической, а скорее — несколько гипертрофированной.
Но такое встречается, на самом деле.
JustDont
07.05.2019 12:35Это встречается практически всегда на пуле difficult задач (те, которые «сложные», но не complex, а difficult, т.е. разбиению на более простые части не поддаются). Там без проверки способа решения боем практически никогда не обходится, если только у вас вдруг не нашлось рокстар-программиста, который без всякой проверки заранее знает, как это решить. Но рокстар-программисты — это как правило про алгоритмически сложные вещи, а есть еще вещи разряда «взять пяток сторонних инструментов и увязать их в кучу для решения задачи, потому что теоретически они вроде бы должны увязываться».
nmivan Автор
07.05.2019 10:50Это разные проблемы, но обе имеют место. Иногда смешиваются — когда при выборе задачи человек сразу думает над способом реализации. Не может выбрать способ — снова возвращается к выбору задачи.
Vezzird
07.05.2019 10:13на выбор задачи уходит до 50 % времени
С точки зрения выбора, бывает и другая ситуация.
Был опыт — человек взял себе задачу, потому что она показалась ему интересной. 3 дня вертел, крутил (без разработки, просто определял, как ему решить ее) и вернул на доработку аналитикам, с просьбой уточнить.
Так как эта задача уже горела, ее отдели другому, который выразил готовность закрыть срочное дело. Срок передачи на тестирование — чуть менее трех часов, с учетом времени на определение как сделать.
Поэтому — выбор с одной стороны зло. Но возможность брать более интересные себе в данный период времени задачи — влияет на мотивацию. Поэтому, я бы добавил в резюме — периодический «соцопрос» — что хотели бы получать в приоритете. Это усложняет процесс передачи задач в работу, но позволяет поддерживать настрой команды :)
И иногда умышленно идешь на передачу задачи программисту, который сделает ее дольше в 1,5-2 раза, но знаешь, что это поднимет мотивацию ему — «мне верят, дают развиваться», команде — «о нас заботятся» и просто будет приятно. Конечно, при условии, что это не горит.
Gorthauer87
07.05.2019 11:13+1Я думаю, что иногда можно себе позволить делать гадкие и мерзкие задачи, но если между ними не будет интересных, то человек просто серьезно устанет и в лучшем случае просто уволится.
Vantela
07.05.2019 10:20+1Читаю я вас Иван читаю и… что то не впиливаю никак.
Вы пишете худ. рассказики про то как какой то «программист» выбирал задачу три дня, так и не выбрал и поэтому его надо лишить такой возможности. А так как другой программист тоже может раздолбайничать три дня, а потом сказать, что он «задачу выбирал», то давайте мы всех программистов лишим брать себе задачи по вкусу и знаниям.
Иван, не надо выдавать худ. рассказы и возможно вашу веру в людей за реальную жизнь.
Люди которые ни черта не делают часами, днями, неделями, а особо талантливые месяцами и годами — но всегда вам расскажут о каких то трудностях, муках, сложностях и прочем это не программисты. И не работники. Это просто люди которые получают зарплату и просиживают штаны. И таких очень и очень много. Слушать оправдания таких людей очень глупо и наивно. Сегодня он выбирал задачу, завтра он анализировал задачу, после завтра о столкнулся с непредвиденными сложностями, потом был аврал, потом еще что то. А потом выясниться что за последний месяц сотрудник не сделал ничего. Но таймшиты у него аккуратно заполнены. И там что то даже написано. Не надо лишать выбора адекватных людей из-за соботажников и неумех.
Кто будет три дня выбирать задачу как не тот кто не способен ни одной решить? Выгнать его и пусть выбирает вакансии.
Да, на текущий момент я не программист, но когда то был им и работал.
И для меня возможность самостоятельного ранжирования была задач была важным моментом.
Вчитываешься в повестку дня. Прикидываешь, что где. Начинаешь с простого, или понятного, или с того что точно сделаешь за пару часов. По делаешь то, что делается с лету, в голове крутится, то что с лету не ясно как делать. К тому времени как пару маленьких задачек закрыл уже есть понимание, что делать с большой — может к коллеге за консультацией обратиться, а может и появилось понимание куда копать.
Я даже в школе так же задачи решал. Читаем всю контрольную, потом решаем, что решается параллельно крутя в голове стереометрию. К 4ой четверти времени контрольной эта стереометрия как правило в голове сложится во что то удобоваримое. И ее тоже можно будет решить. А вы по сути предлагаете мне сразу хватать стереометрию, тратить на нее 3/4 времени контрольной и вполне вероятно решить только ее, а остальное просто не успеть.
Простите, накипело.nmivan Автор
07.05.2019 10:40Что накипело-то? Ну не согласны вы со мной в данном вопросе, ну другой у вас опыт, чему тут кипеть-то?
Vantela
07.05.2019 11:23+1Кипит от того, что вы продвигаете ваш «вопрос» в худших традициях худших менагеров.
Расскажу историю с позапрошлой работы.
Там у нас иногда приключались сверхурочные работы на выходных. Оплачивалось по двойному тарифу. Мы спокойно все делали из дома. В один неожиданный день… работать из дома запретили. Просто запретили. То есть езжай в выходной в офис и работай оттуда. Почему? Зачем?
Оказывается, у админа по почтово\телефонным системам были запланированы маштабные работы на инфраструктуре далекого далекого, важного и очень крупного филиала. Работы были жестко привязаны ко времени и времени было не так, чтобы много. Он начал работы — читай все сломал. И… у него дома рубануло интернет. Я так понял даже электричество. Админ резко вскочил в такси и погнал на работу. Там у него открыт удаленный рабочий стол со всеми примочками, там все подготовлено для работ. И? Его не пустили через проходную. Звонки всем начальникам и от самих начальников до любого уровня не помогли. Пропуск на доступ в офис надо оформлять заранее, а в воскресенье по звонку от кого либо это сделать нельзя. Нет, объект вполне коммерческий, никаких военных и гостайн.
Это крах. В 4 утра по МСК филиал… не начал работу. Без почты, связи и черт знает еще какой инфраструктуры работа тысяч людей была парализована почти на весь день. Конечно, адимин сделал всю работу в понедельник как только его впустили в офис. Вот только делал он это когда работа была уже парализована. Миллионные убытки как в заработной плате, так и в пролетах по договорам, доставкам, поставкам, отгрузкам и прочему прочему. Уверен вы понимаете во что выливается внезапный простой такого плана.
И что сделали менагеры? У них, уверен, был опыт. Да, они запретили работать удаленно.
Подозреваю им даже в голову не пришло, что разумней облегчить доступ сотрудников в офис. Или хотя бы обязать получать пропуск на вход в офис в выходные если у вас есть сверхурочные. Кстати, правило — «есть пропуск на выходной, обязан прийти или прогул» — осталось.
Уверен, я тоже не идеален и нередко ошибаюсь. Но «запретить всем» и «убить всех человеков» это не выход.nmivan Автор
07.05.2019 11:29+1Что-то я видимо и правда не так написал, раз вы меня с такими парнями ровняете.
Daddy_Cool
07.05.2019 12:00Н-да. С охраной бывают приколы.
У нас как-то замдиректора приехал на встречу в контору-партнер и… не смог пробиться через охрану.
В плане админа — в Мск есть круглосуточные кафе с интернетом и розетками. Хотя если у него дома стационарный комп, а не ноут — то проблемно.
Я сам как-то выполнял какие-то очень срочные работы — комп был подключен к мощному UPS, электричества не было, а я рядом рушились стены ибо ремонт.Vantela
07.05.2019 14:14Да, задним умом то можно много решений придумать.
Понятно, что если заранее знать, что в офис не пустят, то потратишь имеющееся время с большей пользой.
Но даже с ноутами к примеру не все всегда бывает однозначно. Вот сломался он у вас (кофе пролили), а для доступа к корпоративной сети нужен сертификат. А его нет! Даже если срочно схватить ноут супруги…
У меня, кстати, сейчас именно так устроено: если домашний стационарник и ноут накрываются медным тазом, то никакое кафе мне никак не поможет. Вот совсем.
Gorthauer87
07.05.2019 12:00Блин проще выдать человеку ноут, и оплачивать ему мобильный интернет как резервный канал, а скорее всего у человека и так все это есть, а значит можно просто инструкцию составить на случай факапов и потребовать от удаленщиков наличие резервного канала.
Меня например ни светом ни упавшим интернетом не напугаешь.Vantela
07.05.2019 14:17Не бывает абсолютной защиты. Форс-мажор способен испортить все.
У меня и свет вырубало, и запасную линию интернета приходилось использовать. Но фиаско неотвратимо при любых мерах безопасности.Gorthauer87
07.05.2019 22:08Так вопрос в вероятности, если ее на пару порядков снизить, то может ничего и не случится плохое.
Vantela
08.05.2019 09:13Вы готовы купить 2 дополнительных ноутбука, бензиновый генератор на балкон, подключить двух дополнительных провайдеров и после этого сломать правую руку прямо перед запланированными работами?:) Я бы наверно после такого убил себя фейспалмом левой.
ksbes
07.05.2019 12:21На одной работе после подобных потерь (охранники не пускали электриков — по приказу зама по безопасности) ген. дир. просто через суд "повесил" все потери на нач охраны и этого зама (там лимонов 20 вышло). Они, конечно, уволились, и даже скостили себе через суд же раза в два долг. Но всё равно попали.
С тех пор пускали без проблем — просто прописали процедуру как пропускать в нерабочее время.Vantela
07.05.2019 14:20Вот это хорошая история. Я правда уверен, что охранники все равно ничего не поняли.
С другой стороны для справедливости хочется сказать, что в каком то смысле это их… работа. Ну, не пускать в смысле.
А вот почему эта работа всегда так ужасно организована — у меня нет ответа.
Daddy_Cool
08.05.2019 02:28Интересно что было написано в договоре.
А то ведь… «пропуск должен быть подписан начальником охраны — он будет в понедельник». Охране, ясное дело, проще не пускать никого — идеально — охранять пустые, закрытые комнаты без окон.
kapash
07.05.2019 12:26И что сделали менагеры? У них, уверен, был опыт. Да, они запретили работать удаленно.
Всё правильно сделали, минимализировали риски на будущее, что бы прикрыть свою пятую точку.
Просто слабо проработанное тех.решение и не более. Можно было и мобильную флешку каждому с ноутом купить(как ниже писали) и брать второго админа на подстраховку. И списки круглосуточного доступа на объект составить, распечатать и повесить А4 на охране.
Но, это лирика. А по факту «П-планирование»Vantela
07.05.2019 14:22прикрыть свою пятую точку
Вы очень емко сформулировали пожалуй одну из основных корпоративных проблем.
У меня нет решения, но я совершенно точно расстроен, что люди вместо того чтобы решать на работе рабочие проблемы и задачи занимаются исключительно своей пятой точкой.
tchspprt
07.05.2019 11:03Минусами Вас конечно покрыли от негодования, но Вы отчасти правы.
Правда, наверное, где-то посередине — мне кажется, что тут надо внедрять что-то подобное weighted round-robin — 1. Есть N инженеров и N задач; 2. Даётся M часов, много меньших чем описанные Вами несколько дней на выбор каждым инженером K[N] задач, которые были бы интересны — автоматом отсекаются неинтересные; 3. Все задачи, которые не находятся ни в одном из K[N] для всех N автоматом попадают во все K[N] для всех N; 4. Из K[N] задач для каждого инженера выбирается одна рандомно.
Вас понять можно — Вы печётесь о развитии бизнеса. Но с другой стороны как бизнесу развиваться, если инженер будет делать то, что ему не нравится, а значит будет делать это медленее? Может быть Вы предлагаете увольнять по каждому чиху и искать новых? Эджаил, который мы заслужили.nmivan Автор
07.05.2019 11:06В жизни программистов увольнял, не представлял к увольнению. Я за то, чтобы любую задачу сделать интересной. Это работа тимлидера. И это не сложно.
tchspprt
07.05.2019 11:11-1Мне интересны велосипеды, а моему коллеге интересны мотоциклы. Интересны с детства, годами ими занимаемся. Иногда не спим по трое суток. А Вы насильно делаете так, чтобы мне стали интересны мотоциклы, а моему коллеге велосипеды?
nmivan Автор
07.05.2019 11:15+1Нет, не насильно, и не мотоциклы. Тут ситуация проще — человек ведь сам пришел в эту компанию, эту команду, на этот проект. Значит, дал согласие на решение этих задач.
Как сделать, чтобы задача стала интересной, зависит от человека. Кому-то надо бросить вызов — типа сделай так, чтобы все ахнули. Или так, как никто еще не делал. Или сделай быстрее, чем я. Или, если задача относится к новой для человека компетенции, можно об этом упомянуть — сделаешь, и перейдешь на качественно другую ступень.
Вообще, в книжке дальше где-то будет глава на эту тему.S-e-n
07.05.2019 11:45Сама задача или интересна, или нет. То, что вы предлагаете — чтобы программист, например, надрывался ради дешёвых понтов, а сама задача здесь — как метод достижения этого.
Многим ещё и до звезды эти вторичные выгоды. Сами описывали такого персонажа (админ-Специалист).nmivan Автор
07.05.2019 11:48Не все так однозначно. Одна и та же задача может быть сегодня интересной, а завтра — нет.
S-e-n
07.05.2019 12:04Ну и с выбором так же. Где-то нужен, где-то нет. Вы же в статье призываете вообще выбор убирать, а если программисту не нравится — повлиять другими методами. Я о том, что на всех это не сработает.
Aingis
07.05.2019 12:05Тут ситуация проще — человек ведь сам пришел в эту компанию, эту команду, на этот проект. Значит, дал согласие на решение этих задач.
Не всегда так бывает. Меня вот пару раз переводили в паре компаний. На, прямо скажем, не самые интересные задачи и проекты. В итоге дело заканчивалось увольнением. После этого оказывалось, что на новом месте работы находились задачи поинтереснее и зарплата была заметно больше.
Причём от меня ничего по большому счёту не зависело: или переводись, или увольняйся. «Ок, — я отвечал, — посмотрим,» — но по факту оказалось что лучше увольняться.
Neikist
07.05.2019 12:32Вот есть задачи по интеграции систем, есть по UI, есть по отчетности, есть по организации ввода данных, есть… Да много чего есть. Уверены что всем интересно одновременно все?
человек ведь сам пришел в эту компанию, эту команду, на этот проект
Но это не значит что человек не считает какие то задачи в рамках проекта скучными или наоборот. В мою бытность в 1с мне были интересны задачи по интеграциям (особенно http и веб сервисы) и немного по нестандартным UI. Еще написание общих механизмов которые в библиотеки вынести можно было бы. Все остальное меня демотивировало, особенно СКД, учет и т.п. вещи.
Gorthauer87
07.05.2019 11:05И опять отношение к программисту как к рабочему у станка. Процесс разработки не конвеер, если это конечно не толпа кодеров, которая просто пишет хорошо понятную рутину.
Во первых, серьезно заниматься умственной деятельностью больше 4-5 часов в день долго нереально. То есть если программист реально работал 4 из 8 часов, то это не значит потерю времени в 50 процентов, а значит и время на выбор у него вполне остается.
А во вторых в моменты когда не знаешь за что браться, как раз какая нибудь автоматическая система вполне может помочь. Но не в принудительном порядкеnmivan Автор
07.05.2019 11:09+1я сам программист, если что.
Gorthauer87
07.05.2019 11:31А по существу то есть что ответить? Или хочешь сказать, что выбор отнимает 50 процентов от оставшихся 4 часов?
nmivan Автор
07.05.2019 11:38А что по существу? Вы ведь считаете, что больше 4-5 часов в день нереально заниматься умственной деятельностью. А я месяцами по 10 часов в день могу и люблю.
submagic
07.05.2019 11:49Умственная деятельность бывает разная. Можно, например, числа в уме перемножать: 17 х 31 сколько будет? А 19 х 71 сколько?
Программист может писать код к конкретной поставленной ему задаче. А может сам ставить себе задачу для решения задачи более глобальной, более высокого уровня. Это разные ситуации, что тут непонятного?nmivan Автор
07.05.2019 12:02Дайте сразу развернутую постановку, а то наша беседа станет бесконечной.
Gorthauer87
07.05.2019 11:56Это смотря что под ней понимать. В конце концов мозг ей может даже в фоне заниматься, но именно в состоянии потока мозг быстрее всего устает и хватает его в общем часа на 4. А остальным вне потока потом можно заниматься сколько угодно.
Neikist
07.05.2019 12:38Возможно вы исключение, но я не очень в это верю. Я например после полугода *полноценной* напряженной работы по 8-9 часов в день словил головные боли по несколько раз в неделю и нервный тик. Потом конечно это прошло, но до сих пор голова болит несколько раз в месяц. По опыту многих моих знакомых — такая же история. Не могут люди вне авралов в таком режиме постоянно заниматься решением программерских задач.
Ну если конечно это не задачи которые уже расписаны от и до, но как часто такое бывает?
jahr
07.05.2019 14:31+1Мне кажется, что как раз все Ваши проблемы от того, что Вы принимаете за умственную деятельность то, чем Вы способны заниматься по 10 часов в день месяцами.)
kapash
07.05.2019 12:20И опять отношение к программисту как к рабочему у станка.
Доброе утро, программист давно как таксист или грузчик = обычная профессияGorthauer87
07.05.2019 12:22Ну не совсем обычная, со своей спецификой, как и любая проектная деятельность.
kapash
07.05.2019 12:29У каждой профессии специфика и нагрузки. Я том, что любой работник в любой компании — это ресурс и чем он дешевле и производительней, тем лучше.
ksbes
07.05.2019 12:44Это уже зависит от политэкономического строя и порядков в компании. Какой-нибудь сео или замгендиры явно никем как ресурс не рассматривается. У нас сейчас эта грань ресурс/не ресурс проходит чуть выше джунов. Джуны да — "расходный материал" для нашего руководства, а специалистов всё же берегут. Такая вот "дедовщина".
kapash
07.05.2019 13:22+1Какой-нибудь сео или замгендиры явно никем как ресурс не рассматривается.
Рассматривается собственником\советом директоров. У них просто другие задачи. И нет никакой грани и не было никогда. Есть такое понятие — утилизация ресурсов. Специалисты утилизируются гораздо больше джунов в разы, и своими задачи и чужими. А СЕО утилизируются снятием головной боли (для собственников конечно же). Нанял СЕО и бошка не болит, всегда есть на кого поорать за лагающий вифи на айфончике.
kapash
07.05.2019 12:34+1Выбора надо лишить
Но оставить надежду, что бы страдания были.
А если серьёзно — схема «разделяй и властвуй» или «когда правая рука не знает, что делает левая».
lamerok
07.05.2019 14:21+1Я либо что не понимаю, либо что- не так. Как программист может выбирать задачу 3 дня? На скраме же говорится, что сделал и что будет делать, в том числе, если предыдущая задача сделана, берется новая незаблокированная. Если таких много, то у программиста есть 30 секунд, чтобы выбрать из них на скраме подходящую себе, либо он должен уже был сделать выбор до этого и на скраме просто озвучить. Задача длится 8-16 часов, максимум через 16 часов программист должен её закончить, слить и берется новая… какие три дня, не понимаю???
dss_kalika
Хорошая тема.
Я бы ещё рассмотрел вариант случайного распределения задач с одинаковым приоритетом. Очень удобно, когда необходимо что бы программисты были хоть в какой то мере взаимозаменяемы.
ksbes
Наиболее оптимальный алгоритм выбора в сферично-вакуумных условиях — shortest due date. Т.е. браться надо за то, что должно быть быстрее закончено (при этом просроченные задачи — отбрасываются на переоценку сроков). Это даёт наибольшую скорость работы.
Обычно это выливается во то, что сначала разгребается вся мелочёвка, а потом уже большие "куски" в порядке поступления.
Gorthauer87
К тому же мелочевка больше удовольствия от результатов работы приносит.