Я обычно выбираю то, что поинтереснее, потом по механизмам, которые мне знакомы. Если меня лишить выбора, то я буду скучать. А скучающий программист может сделать всё, что угодно. Уволиться, например.
Недавно директор признался, что деградация, особенно в районах, достигла такого уровня, что найти вменяемого просто айтишника почти невозможно, о программистах даже речи нет.
Поэтому выбора меня не лишают. Сначала интересное, потом знакомое, остальные ждут, когда закончу с первыми.
И именно поэтому в обычном франче мне места нет. Там скучно.
(1) мне кажется, вы как раз и описали ситуацию, в которой лишили себя выбора. Вы сделали выбор заранее, превратив его в стратегию. Когда дело доходит до выбора задачи, выбором вы уже не мучаетесь.
До 2012 года большинство моих задач, имели длительность от 1 часа до 4-ех.
Я вообще не парился по поводу графиков, сроков и т.д. потому что знал что в течении 2-3 дней могу закрыть любой объем задач от моих постоянных клиентов. Даже если они все сговорились бы и начали заваливать меня задачами, максимум за неделю я все бы разгреб.
На конец 2018 года, средняя продолжительность каждой задачи имела длительность 10-15 часов. Тут все понятно. Клиенты те же. Все основные хотелки давно сделаны, и начались уже обдуманные задачи по повышению эффективности процессов. Вот здесь я уже почувствовал, что у меня часто начали появляться завалы. Даже простую задачу, которую я раньше решал за пару часов, а сегодня я могу сделать за минуты, но выполняю через несколько дней. У меня появились задачи, которые находятся в очереди недели. Есть пару задач которые ждут два месяца.
Но с начала 2019 года, средняя продолжительность задачи увеличилась до 25 часов. И я понял что попал в какую то ловушку. Я не могу взять даже элементарную задачу и выполнить ее сразу, кроме совсем авральных, и естественно в ущерб качеству других.
И на данный момент, одним из выходов из ситуации будет именно очередь задач, и жесткое их выполнение по очереди.
Нужно заранее продумать порядок, расставить все задачи по порядку, и придерживаться этого порядка. Это нужно не потому что мне просто так хочется, а для того чтобы я реально оценивал свои возможности. Это позволит получить реальный уровень загрузки, следующее свободное окно. Я смогу клиенту сразу сказать, что его следующую задачу я смогу взять через n дней, недель ….
Это будет самый правильный подход, потому что он избавляет от иллюзий. Жизнь устроена так, чтобы там не говорили, что можно обмануть кого угодно и есть реальный шанс, что об этом никто и никогда не узнает, и тебе ничего не будет. Но как только начинаешь обманывать сам себя, жизнь сразу начинает больно бить по голове.
Спасибо автору, Хоть он пишет про то, что муки выбора негативно влияют на продуктивность, и нужно от них избавляться, я в этой статье вижу еще одно подтверждение моих опасений. Видимо, не зря разработчики платформы 1С, в интерфейсах пункты меню сортировки называют — Порядок. Шутка конечно, но кто знает?
Для выбора задач я применяю алгоритмы типа раскроя (минимизации отходов), где есть цельный промежуток времени, посвященный 1с как лист раскроя (иногда его называют «от забора и до обеда», иногда От заката и до рассвета», а бывает и 1001 ночь).
Необходимо упорядочить задачи таким образом, чтобы потери времени (когда тупим выбирая задачу, метод решения или изучаем варианты, включая рефакторинг и концептуальные изменения в программе, необъяснимые для клиента) был минимальными.
При работе у клиента и дома или на офисе таких листов раскроя два или три. Я составляю план таким образом, чтобы уходя от клиента не оставлять «открытый модуль» или неработающий участок.
Каждая задача должна быть полностью закончена там, где она была начата и с тем представителем заказчика, который даёт задание. В редких случаях можно выбрать другого сотрудника, и только когда есть уверенность, что представитель заказчика не аннулирует результаты его приемки.
Портной может сшить больше шапок из одной шкуры заказчика, если будет относиться к ней бережно.
Мантра эффективного программиста не самообман, а цель, иногда недостижимая, но верить в нее надо.
Очередь — это хорошо и даже прекрасно… Однако срочных и сверхважных задач тоже никто не отменял… Сбой отправки платёжек (ключ банка не работает — иди разберись это же 1с не работает) и т.п
Получается очередь вне очереди, которую прерывают ежечасно… ежеминутно звонками
В результате… Опытный программист да.. как ктото тут писал… Умножает время на 2 или 3… Чтобы точно уложиться в срок… И эти 2х неизбежны… Уже не в силу выбора следующей задачи… А как запас на обяательный аврал ..
Но если аврала нет… И все сделано за 1 а не 2х времени… Тут каждый по своему… «Отдыхает» что то изучает, рефакторит код…доводя до блеска или пишет на инфостарте 🙂
(5) проблема всех фикси в том, что мелкие задачи появляются и исчезают, но это не спасает от завершения проекта (с которого все начинается).
А когда проект завершен, никакие мелкие задачи ни в каким количестве и никакой важности не могут заполнить пустоту.
И специалист либо деградирует и увольняется либо деградирует и остаётся.
Но деградирует неминуемо.
Либо необходимо внедрять проектную методику. Т.е. накапливать массив нерешённых вопросов из которых большая половина к моменту начала проекта потеряет актуальность, что далеко не всегда плохо.
Проблема проектной методики на предприятии в том, что нет локомотива да и постоянное его наличие в штате позволить себе могут только высокотехнологичные компании.
Автор и предлагает доверить выбор задач такому директору по развитию.
Вы представляете себе к примеру, агрофирму, в котором директор по развитию поручает программисту 1с раскурить например розницу и общепит на аксапте. Как вариант второе высшее, сертификация, курсы-тренинги и .. полное непонимание коллег зачем это тебе?
Вот как раз покер планирования в скраме дает выбор без выбора))) Ты выбираешь тем, что даешь оценку. И ты, и дедка, и бабка, и прочие кошки-мышки — все дают оценку. И кто дает оценку вне границ, тот объясняется. И он может действительно быть прав. И это помимо того, что не даст задачам быть криво оцененными, еще и заполнит пул спринта. И вот когда спринт начался — выбора уже нет, т.к. все гири распилены шурами. А ты о технологии-религии пишешь. Сходи к коучу — телефон с меня. Он скидочку даст.
Программист при должном опыте и понимании потребностей заказчика в состоянии выбрать самостоятельно задачу исходя из ее полезности для заказчика.
Некоторые сложные или интересные задачи лучше не делать, к сожалению и для заказчика и для методистов и для разработчика это порой становится понято лишь после ее реализации. Много раз сталкивался с тем, как месяц (а то и больше) делали что-то интересное сложное и технологичное, согласовывали в том числе на уровне хозяина бизнеса, тестировали, презентовали, обучали, а получался неиспользуемый функционал (идеально отлаженный с сопроводительной документацией и протестированный).
И, кстати, умные ипонцы как-то так сказали: «подумав — делай, делая — не думай». Ну и наше «семь раз отмерь — один отрежь» — тоже куда-то сюда. Вот надумали группой товарищей времена и сроки, а потом уже делай не думая о временах и сроках, ибо за тебя уже все подумали. И демократично, и эффективно, и расслабиться не даст. Будешь юзать спринты без планирования — получишь растянутое до бесконечности время решения задач, да и не совсем ясно, что за задачи и кто их оценил. Будешь только планировать — найдется куча работы помимо распланированного и опять задачи из плана не будут выполнены.
Хочешь получить инсулин? Соблюдай технологию. Хочешь творчески подойти к технологии? — вряд ли на выходе получишь инсулин, ибо умные дяди выработали методику до тебя, и они в совокупности внезапно вряд ли окажутся тупее. Но можно их назвать сектой — и ответственность уже на тебе. Альцшуллер в своей ТРИЗ столько технологических карт нарисовал чуть ли не на каждый чих не просто так. И скрам тоже не просто так методологически собран таким вот образом.
(10) программист — да, дядя умный. Или даже тетя. Но для того, чтобы заставить человека работать, нужно дать ему четко понять, что от него надо. Да, добавить колонку на форме не требует объяснения того, как это сделать технологически — достаточно методологического слоя о характере данных в колонке, ее положения на форме и, возможно, места хранения в системе для данных ее заполнения. Но если не сказать программисту о том, что ему делать и не решить (и вместе с ним — тоже), сколько это должно занять времени, то есть шанс того, что программист будет долго искать «удобную» для себя задачу и будет делать ее бесконечно долго.
(0) не мешало бы еще раскрыть тему приоритетов — как именно посчитать «полезность для бизнеса» каждой задачи. Желательно с примерами работающих коэффициентов, т.к. теорий много. Сортировка по дате весьма печальна.
как именно посчитать «полезность для бизнеса» каждой задачи
Так есть же для расчета ROI. Вот оно:
Р = (Доход от В — Размер В) / Размер В * 100%
Когда мы вычитаем из доходов наши инвестиции мы получаем ту цифру, которая и является нашим реальным заработком. Дальше все еще проще – отношение конечной прибыли к сумме инвестиций показывает, во сколько раз первое больше второго. В последнем действии мы умножаем на 100% и, если полученное число меньше 100, то вложения не окупаются.
Также там есть формула от финансистов, которая получает ROI по периоду вложений. Можно применить для затрат на поддержку и развитие продукта.
Но если подобный подход оценки возвращенных инвестиций применять к каждой задаче, то может так оказаться, что стоимость расчета KPI будет выше инвестиционного дохода (или экономии) от решения той или иной задачи. Поэтому большинство интуитивно оценивают потенциал, а не конкретную величину возврата вложений. Для этого можно просто составить «квадрат Малевича» на тему того, что нас ждет без этого, что мы без этого не получим, что получим с этим и от чего с этим будем убережены.
Так написал же, что квадрат нужно нарисовать на тему того, что нам обломится если мы это сделаем, и что мы огреббем, если это не сделать.
Вообще, существуют задачи, которые вроде бы не хрен какие РОИшные, но могут в синергии привести к сокращению пары отделов. Смысл оценивать конкретную задачу в плане РОИ отсутствует — только полные идиоты, на мой скромный взгляд, оцценивают это и тратят на оценку больше ресурсов, чем их выхлоп. Оценивать нужно пул задач в рамках проекта или подсистемы, и уже общая оценка может показать, каков выхлоп. Спрогнозировать его весьма непросто. А вот понять, что при отсутствии того или иного механизма можно огрести то и это — тут ума хватит.
(12) делать такую оценку на уровне задач смысла нет. На уровне проектов, или направлений автоматизации — можно. Лучше — проектов.
Там оценка должна быть в цель проекта заложена. Пару месяцев назад писал где-то статью о том, как организовать целевой проект по увольнению сотрудников с помощью автоматизации. Это один из примеров.
Я обычно выбираю то, что поинтереснее, потом по механизмам, которые мне знакомы. Если меня лишить выбора, то я буду скучать. А скучающий программист может сделать всё, что угодно. Уволиться, например.
Недавно директор признался, что деградация, особенно в районах, достигла такого уровня, что найти вменяемого просто айтишника почти невозможно, о программистах даже речи нет.
Поэтому выбора меня не лишают. Сначала интересное, потом знакомое, остальные ждут, когда закончу с первыми.
И именно поэтому в обычном франче мне места нет. Там скучно.
(1) мне кажется, вы как раз и описали ситуацию, в которой лишили себя выбора. Вы сделали выбор заранее, превратив его в стратегию. Когда дело доходит до выбора задачи, выбором вы уже не мучаетесь.
Это очень высокий уровень, поздравляю.
Видимо я прихожу именно к тому же.
До 2012 года большинство моих задач, имели длительность от 1 часа до 4-ех.
Я вообще не парился по поводу графиков, сроков и т.д. потому что знал что в течении 2-3 дней могу закрыть любой объем задач от моих постоянных клиентов. Даже если они все сговорились бы и начали заваливать меня задачами, максимум за неделю я все бы разгреб.
На конец 2018 года, средняя продолжительность каждой задачи имела длительность 10-15 часов. Тут все понятно. Клиенты те же. Все основные хотелки давно сделаны, и начались уже обдуманные задачи по повышению эффективности процессов. Вот здесь я уже почувствовал, что у меня часто начали появляться завалы. Даже простую задачу, которую я раньше решал за пару часов, а сегодня я могу сделать за минуты, но выполняю через несколько дней. У меня появились задачи, которые находятся в очереди недели. Есть пару задач которые ждут два месяца.
Но с начала 2019 года, средняя продолжительность задачи увеличилась до 25 часов. И я понял что попал в какую то ловушку. Я не могу взять даже элементарную задачу и выполнить ее сразу, кроме совсем авральных, и естественно в ущерб качеству других.
И на данный момент, одним из выходов из ситуации будет именно очередь задач, и жесткое их выполнение по очереди.
Нужно заранее продумать порядок, расставить все задачи по порядку, и придерживаться этого порядка. Это нужно не потому что мне просто так хочется, а для того чтобы я реально оценивал свои возможности. Это позволит получить реальный уровень загрузки, следующее свободное окно. Я смогу клиенту сразу сказать, что его следующую задачу я смогу взять через n дней, недель ….
Это будет самый правильный подход, потому что он избавляет от иллюзий. Жизнь устроена так, чтобы там не говорили, что можно обмануть кого угодно и есть реальный шанс, что об этом никто и никогда не узнает, и тебе ничего не будет. Но как только начинаешь обманывать сам себя, жизнь сразу начинает больно бить по голове.
Спасибо автору, Хоть он пишет про то, что муки выбора негативно влияют на продуктивность, и нужно от них избавляться, я в этой статье вижу еще одно подтверждение моих опасений. Видимо, не зря разработчики платформы 1С, в интерфейсах пункты меню сортировки называют — Порядок. Шутка конечно, но кто знает?
Для выбора задач я применяю алгоритмы типа раскроя (минимизации отходов), где есть цельный промежуток времени, посвященный 1с как лист раскроя (иногда его называют «от забора и до обеда», иногда От заката и до рассвета», а бывает и 1001 ночь).
Необходимо упорядочить задачи таким образом, чтобы потери времени (когда тупим выбирая задачу, метод решения или изучаем варианты, включая рефакторинг и концептуальные изменения в программе, необъяснимые для клиента) был минимальными.
При работе у клиента и дома или на офисе таких листов раскроя два или три. Я составляю план таким образом, чтобы уходя от клиента не оставлять «открытый модуль» или неработающий участок.
Каждая задача должна быть полностью закончена там, где она была начата и с тем представителем заказчика, который даёт задание. В редких случаях можно выбрать другого сотрудника, и только когда есть уверенность, что представитель заказчика не аннулирует результаты его приемки.
Портной может сшить больше шапок из одной шкуры заказчика, если будет относиться к ней бережно.
Мантра эффективного программиста не самообман, а цель, иногда недостижимая, но верить в нее надо.
Очередь — это хорошо и даже прекрасно… Однако срочных и сверхважных задач тоже никто не отменял… Сбой отправки платёжек (ключ банка не работает — иди разберись это же 1с не работает) и т.п
Получается очередь вне очереди, которую прерывают ежечасно… ежеминутно звонками
В результате… Опытный программист да.. как ктото тут писал… Умножает время на 2 или 3… Чтобы точно уложиться в срок… И эти 2х неизбежны… Уже не в силу выбора следующей задачи… А как запас на обяательный аврал ..
Но если аврала нет… И все сделано за 1 а не 2х времени… Тут каждый по своему… «Отдыхает» что то изучает, рефакторит код…доводя до блеска или пишет на инфостарте 🙂
(5) проблема всех фикси в том, что мелкие задачи появляются и исчезают, но это не спасает от завершения проекта (с которого все начинается).
А когда проект завершен, никакие мелкие задачи ни в каким количестве и никакой важности не могут заполнить пустоту.
И специалист либо деградирует и увольняется либо деградирует и остаётся.
Но деградирует неминуемо.
Либо необходимо внедрять проектную методику. Т.е. накапливать массив нерешённых вопросов из которых большая половина к моменту начала проекта потеряет актуальность, что далеко не всегда плохо.
Проблема проектной методики на предприятии в том, что нет локомотива да и постоянное его наличие в штате позволить себе могут только высокотехнологичные компании.
Автор и предлагает доверить выбор задач такому директору по развитию.
Вы представляете себе к примеру, агрофирму, в котором директор по развитию поручает программисту 1с раскурить например розницу и общепит на аксапте. Как вариант второе высшее, сертификация, курсы-тренинги и .. полное непонимание коллег зачем это тебе?
Вот как раз покер планирования в скраме дает выбор без выбора))) Ты выбираешь тем, что даешь оценку. И ты, и дедка, и бабка, и прочие кошки-мышки — все дают оценку. И кто дает оценку вне границ, тот объясняется. И он может действительно быть прав. И это помимо того, что не даст задачам быть криво оцененными, еще и заполнит пул спринта. И вот когда спринт начался — выбора уже нет, т.к. все гири распилены шурами. А ты о технологии-религии пишешь. Сходи к коучу — телефон с меня. Он скидочку даст.
Программист при должном опыте и понимании потребностей заказчика в состоянии выбрать самостоятельно задачу исходя из ее полезности для заказчика.
Некоторые сложные или интересные задачи лучше не делать, к сожалению и для заказчика и для методистов и для разработчика это порой становится понято лишь после ее реализации. Много раз сталкивался с тем, как месяц (а то и больше) делали что-то интересное сложное и технологичное, согласовывали в том числе на уровне хозяина бизнеса, тестировали, презентовали, обучали, а получался неиспользуемый функционал (идеально отлаженный с сопроводительной документацией и протестированный).
И, кстати, умные ипонцы как-то так сказали: «подумав — делай, делая — не думай». Ну и наше «семь раз отмерь — один отрежь» — тоже куда-то сюда. Вот надумали группой товарищей времена и сроки, а потом уже делай не думая о временах и сроках, ибо за тебя уже все подумали. И демократично, и эффективно, и расслабиться не даст. Будешь юзать спринты без планирования — получишь растянутое до бесконечности время решения задач, да и не совсем ясно, что за задачи и кто их оценил. Будешь только планировать — найдется куча работы помимо распланированного и опять задачи из плана не будут выполнены.
Хочешь получить инсулин? Соблюдай технологию. Хочешь творчески подойти к технологии? — вряд ли на выходе получишь инсулин, ибо умные дяди выработали методику до тебя, и они в совокупности внезапно вряд ли окажутся тупее. Но можно их назвать сектой — и ответственность уже на тебе. Альцшуллер в своей ТРИЗ столько технологических карт нарисовал чуть ли не на каждый чих не просто так. И скрам тоже не просто так методологически собран таким вот образом.
(9) предполагается, что программист сам является умным дядей(тётей) и его работа не тоже самое что работа грузчика, где действительно не надо думать
(10) программист — да, дядя умный. Или даже тетя. Но для того, чтобы заставить человека работать, нужно дать ему четко понять, что от него надо. Да, добавить колонку на форме не требует объяснения того, как это сделать технологически — достаточно методологического слоя о характере данных в колонке, ее положения на форме и, возможно, места хранения в системе для данных ее заполнения. Но если не сказать программисту о том, что ему делать и не решить (и вместе с ним — тоже), сколько это должно занять времени, то есть шанс того, что программист будет долго искать «удобную» для себя задачу и будет делать ее бесконечно долго.
(0) не мешало бы еще раскрыть тему приоритетов — как именно посчитать «полезность для бизнеса» каждой задачи. Желательно с примерами работающих коэффициентов, т.к. теорий много. Сортировка по дате весьма печальна.
(12)
Так есть же для расчета ROI. Вот оно:
Когда мы вычитаем из доходов наши инвестиции мы получаем ту цифру, которая и является нашим реальным заработком. Дальше все еще проще – отношение конечной прибыли к сумме инвестиций показывает, во сколько раз первое больше второго. В последнем действии мы умножаем на 100% и, если полученное число меньше 100, то вложения не окупаются.
Также там есть формула от финансистов, которая получает ROI по периоду вложений. Можно применить для затрат на поддержку и развитие продукта.
Но если подобный подход оценки возвращенных инвестиций применять к каждой задаче, то может так оказаться, что стоимость расчета KPI будет выше инвестиционного дохода (или экономии) от решения той или иной задачи. Поэтому большинство интуитивно оценивают потенциал, а не конкретную величину возврата вложений. Для этого можно просто составить «квадрат Малевича» на тему того, что нас ждет без этого, что мы без этого не получим, что получим с этим и от чего с этим будем убережены.
(13) Формула хороша, но как ее наложить на список задач, чтобы для каждой посчитать приоритет?
(14)
Так написал же, что квадрат нужно нарисовать на тему того, что нам обломится если мы это сделаем, и что мы огреббем, если это не сделать.
Вообще, существуют задачи, которые вроде бы не хрен какие РОИшные, но могут в синергии привести к сокращению пары отделов. Смысл оценивать конкретную задачу в плане РОИ отсутствует — только полные идиоты, на мой скромный взгляд, оцценивают это и тратят на оценку больше ресурсов, чем их выхлоп. Оценивать нужно пул задач в рамках проекта или подсистемы, и уже общая оценка может показать, каков выхлоп. Спрогнозировать его весьма непросто. А вот понять, что при отсутствии того или иного механизма можно огрести то и это — тут ума хватит.
(7) а причем тут скрам? И причем тут оценка?
Есть в бэклоге спринта 50 задач. Все оценены, отклонения объяснены и устранены.
Проблема выбора задачи для исполнения решена?
(9) японцы в тему. Только там так: решение должно приниматься за семь вдохов. Еще — если раздумья длятся долго, результат будет плачевным.
Только это не про технологию, а про стратегию. И вовсе не про скрам.
(12) делать такую оценку на уровне задач смысла нет. На уровне проектов, или направлений автоматизации — можно. Лучше — проектов.
Там оценка должна быть в цель проекта заложена. Пару месяцев назад писал где-то статью о том, как организовать целевой проект по увольнению сотрудников с помощью автоматизации. Это один из примеров.