Выбор - зло

18.05.19

Сообщество - О жизни

Как, и зачем лишать программиста выбора.

В этой статье нет новых мыслей. Прочитав ее, вы скажете – я и так всё это знаю. Если вы не только знаете, но и делаете, то я искренне за вас рад. Если же не делаете, то откроете для себя много нового, применив предложенные методы. Хотя бы для себя.

 

Начну с главного: если ваши программисты сами выбирают себе задачу, то у вас большие проблемы.

Мы привыкли смотреть на выбор, как на условный оператор в языке программирования или схеме алгоритма. Ну, помните, такой ромбик рисуется, в нем условие выбора, и две веточки – да и нет. При исполнении алгоритма условие проверяется мгновенно, поэтому его производительность обычно не принимается в расчет.

А что есть выбор, выполняемый человеком? Это не мгновенный алгоритм, а процесс. У этого процесса есть начало, конец (дай-то Бог), и, главное – продолжительность. Сколько, по-вашему, может длиться выбор задачи?

Можно гадать, но лучше измерить. Я наблюдал за этим процессом многократно, и вывод неутешительный: программист может выбирать задачу несколько дней.

Процесс выбора плох тем, что скрыт от нашего взгляда. Если бы человек слонялся по кабинету, метался из стороны в сторону, вскидывал голову в протяжном вое, мы бы поняли, что у него проблема. Но происходит иначе.

Программисты давно придумали такой алгоритм, как разведка боем. Применительно к задачам он означает: не просто почитать условие, а зайти и посмотреть. Глянуть на код, формы, связи, метаданные, примеры воспроизведения и аналитические отчеты.

Посмотреть надо для того, чтобы оценить задачу «как следует», не на глазок. Если поймать программиста за этим занятием, то он скажет: я – профессионал, и не могу браться за задачу, не зная всех тонкостей. Казалось бы, чего же тут такого? Правильно ведь делает человек?

Конечно, правильно. Но только если он, по результатам своих исследований, примет окончательное решение – браться за задачу, или нет. Как вариант – взять задачу с оговорками, вроде необходимости изучения дополнительных механизмов.

Если программист решил задачу взять, и сел делать, то все хорошо. Если же он отказался от задачи, то все плохо. Время, потраченное на исследование, будет потеряно даром.

Тут варианта два. Первый – программист откажется наотрез, и задачу будет смотреть кто-то другой. В принципе, возможен вариант, когда первый программист просто перескажет второму результаты своих исследований, обнаруженные подводные камни и сопутствующие трудности. Но на практике программисты предпочитают независимость друг от друга, в том числе – от мнения коллег. Некоторые даже испытывают определенный азарт, разбираясь в задаче, за которую не взялся коллега.

Второй вариант – программист не отказался, а отложил задачу на потом. Когда наступит это «потом» — не известно, но скорее всего – через достаточно продолжительное время. Что будет во время второй итерации разведки боем? Начнет с того места, где остановился в исследованиях? Разумеется, нет – он пройдет тот же путь, от начала и до конца. И, с высокой вероятностью, застопорится на том же самом месте, что и в первый раз.

И вот что получается. Есть время, которое программисты тратят на решение задач. Нормальное, правильное, полезное время. Как правило, время на решение задачи тратится один раз.

А есть время, которое программисты тратят на многократную разведку. Никакой особой пользы в этом времени нет – ни для программиста, ни для клиента, ни для вашей компании. Время на разведку боем – практически чистая потеря.

Но проблема не только в разведке. Бывает и хуже.

Например, программист понимает все задачи в своем списке, но просто не может выбрать, чем ему заняться. Проблема усугубляется тем, что выбор происходит, как Бог на душу положит – без определенного алгоритма, критериев и приоритетов. И тут уж кто во что горазд.

Один выбирает то, что поинтереснее. Другой выбирает то, что полегче. Третий выбирает задачи по механизмам, которые ему знакомы. Четвертый выбирает задачи своего любимого клиента, потому что результат сдавать проще. Пятый выбирает самую амбициозную задачу, чтобы показать себя.

При этом, что важно, почти каждый из них испытывает серьезные душевные терзания из-за неопределенности критериев. Он примерно понимает, какие задачи хочет решать, но, или осознанно, или неосознанно чувствует, что делает что-то не так. Ему кажется, что надо выбирать совсем другую задачу, исходя из стратегии работы компании, состояния проекта, плана развития собственных компетенций и т.д. Но хочется-то выбрать не то, что надо, а то, что по душе.

Такие душевные терзания еще сильнее усугубляют процесс выбора. Человек погружается в мрачные размышления, взвешивая на весах совести свой выбор. И так могут пройти часы и дни.

С точки зрения менеджера, стоящего в стороне, весь этот процесс напоминает сурка из одного известного фильма, который вылезает из норы и «выбирает погоду на ближайшие шесть недель». Чем он там руководствуется, видит свою тень или нет, и почему вообще это делает сурок? Правда, если менеджер часто смотрит на этот процесс со стороны, то вопрос скорее к нему, чем к программистам.

Так же, в контексте выбора большое значение имеет праздник. Программист – он ведь человек, в первую очередь, а не робот. Чего хочется человеку после выполнения сложной работы? Праздника, конечно!

Выполненную задачу нужно отметить. Сходить покурить, выпить чаю или кофе, поболтать с друзьями, похвастаться решенной задачей, посидеть в социальных сетях, почитать новости – в общем, вариантов множество. К сожалению, этот праздник иногда затягивается.

Особенно плохо, если задача была закончена за час, или даже за два до окончания рабочего дня. Ну кто, в здравом уме, будет выбирать себе новую задачу, если скоро – домой?

Как непросто выходить из состояния праздника, знает каждый россиянин – все мы отдыхаем в новогодние каникулы. В нашем случае – еще сложнее, т.к. программист должен вернуться не к решению задачи, а к выбору следующей. Насколько мучителен выбор, мы уже обсудили.

Если резюмировать потери от выбора, то они есть всегда. Вопрос только в их количестве. Чтобы вы прониклись, назову такую цифру: на выбор задачи уходит до 50 % времени. Только вдумайтесь в эту цифру.

Но, в контексте нашего материала, эта цифра просто прекрасна. Избавившись от потерь из-за выбора, вы можете увеличить эффективность вдвое.

Как же избавиться от выбора? Нет ничего проще. Собственно, вы сами знаете, как это сделать. Я изложу свои предложения, а вы скомпонуете их с собственными методами, и получится приличный рост эффективности.

Первое и главное, с чего следует начать, это контроллинг. Какую бы вы не придумали систему приоритетов и распределения задач, она не будет работать, пока программисты вас «не слушаются».

Контроллинг, в двух словах, это – управление на основе цифр. В данном случае цифрой будет не прибыль или сумма продаж, а порядковый номер задачи в очереди. Нужно управлять выбором задачи на основе этого номера, и быть уверенным, что задачи решаются в заданном порядке.

Контроллинг необходим и в случае, если вы управляете командой, и даже тогда, когда вы управляете собой. С собой ведь договориться проще, чем с начальником? «Да сейчас, в последний раз, а потом уж точно!».

Вообще, про контроллинг мы еще поговорим более обстоятельно, здесь я забежал вперед, но оно того стоит. Если вы придумали правила выбора задачи, но их никто не исполняет, то ничего не получится.

Итак, все, что надо сделать – выстроить задачи в очередь и обеспечить следование этой очереди. В некоторых источниках рекомендуется скрывать очередь от программистов, оставляя в поле зрения лишь две задачи – текущую и следующую. Если показать программисту все задачи сразу, то он, как ни старайся, все равно будет «подглядывать», изучать, что там впереди.

Первый способ – распределение задач начальником, без использования автоматизации. Вы просто говорите, кто что делает и в какой последовательности. Можно составлять несложные планы – например, в виде маленьких бумажек, вроде нарядов на выполнение работ, или заданий на производство. Можно просто диктовать номера задач под запись в блокнот.

Можно сделать доску, по типу скрама, и вешать туда стикеры на день. Методика скрама предполагает вывешивание множества задач, например – на неделю или месяц, но нам это не подходит, потому что снова появляется выбор.

Ручное распределение задач очень просто начать, и так же просто прекратить, потому что быстро надоест. Нужно иметь значительную силу воли, или хорошие навыки регулярного менеджмента, чтобы ежедневно заставлять себя распределять задачи. Если сказанное – про вас, то можете начать уже сегодня.

Для ленивых подойдет автоматизация. В вашей информационной системе, где хранятся задачи, надо заложить механизм их сортировки. Как вам ближе? Сортировать по дате постановки? По сроку исполнения? Годится любой способ. Главное, чтобы он был детерминирован и одинаково понимаем программистами. Лично я рекомендую не ограничиться сортировкой, а хранить номера в очереди в виде отдельного поля. Современные системы слишком удобны для пользователя, и позволяют ему настраивать сортировку самостоятельно. Вот вы решили, что надо задачи выполнять в порядке поступления (FIFO), а программист случайно, или умышленно, поменял сортировку на обратную, и получил LIFO.

Если же номер в очереди сохранен, то сортируй, не сортируй, ошибиться сложно.

Можно не привязываться к сортировке, а ставить номера вручную. Тоже годится, если у вас хватит силы воли расставлять эти номера.

Принцип, думаю, понятен. Любая система составления очереди, понятная программистам, и контроль ее соблюдения. Это будет первый шаг к лишению выбора, отнимающего эффективность.

Второй шаг мы рассмотрим дальше. Он позволит нам извлечь из очередей намного больше пользы – не только упростить выбор, но и сделать его правильным.

Резюме


 

  • Выбор задачи – это не мгновение, а длительный процесс;
  • Программист выбирает задачу, исходя из собственных представлений;
  • На выбор тратится огромное количество времени;
  • Процесс выбора не приносит ни пользы, ни удовольствия;
  • Выбора надо лишить;
  • Распределять задачи можно вручную, как прораб;
  • Автоматизация может помочь в составлении очередей.

См. также

О жизни Россия Бесплатно (free)

Подводим итоги работы в 1С за 2023 год. Все о вас: 4 подробных раздела с цифрами, графиками и ужасными цветами диаграмм (должна же где-то быть стабильность).

08.02.2024    24853    Neti    85    

117

Личная эффективность Бесплатно (free)

Нам с детства постоянно твердят, что книга – лучший друг, книга – лучший подарок, книга – вообще лучшая вещь в мире. Да, это действительно так. Книги явно и значительно влияют на нашу работу, карьеру и жизнь. О том, как правильно читать книгу, как книга вообще влияет на человека, и главное: зачем вообще читать эти книги программисту, сисадмину, аналитику, расскажем в статье.

31.01.2024    3456    0    a_a_burlakov    25    

46

О жизни Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного работодателя. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все недостатки работодателей от момента собеседования до момента увольнения. Все этапы, как всегда, подкреплены реальными случаями из моего опыта.

22.01.2024    4565    biimmap    67    

73

О жизни Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного работодателя. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все недостатки работодателей от момента собеседования до момента увольнения. Все этапы, как всегда, подкреплены реальными случаями из моего опыта.

16.01.2024    5982    biimmap    99    

79

О жизни Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

Импортозамещение увеличило потребность в архитекторах, аналитиках, разработчиках 1С, в т.ч. по ЗУП. Все их ищут всеми возможными способами, но не могут найти и не знают, чем же их завлечь к себе!? Давайте разберёмся в этом вопросе!

27.11.2023    4876    biimmap    52    

73

О жизни Сообщество Бесплатно (free)

Прочитав название публикации, мысль возникает о свадьбе... Но речь не об этом!

25.08.2023    2778    biimmap    24    

51

О жизни Россия Бесплатно (free)

«Многие кандидаты хотят от собеседования простую вещь: чтобы оно длилось пять минут и брали сразу на 300 000 в наносекунду», — Эльдар Мингалиев, разрабатывает новые форматы собеседований.

22.08.2023    14674    Neti    161    

108
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Поручик 4683 18.05.19 19:12 Сейчас в теме
Я обычно выбираю то, что поинтереснее, потом по механизмам, которые мне знакомы. Если меня лишить выбора, то я буду скучать. А скучающий программист может сделать всё, что угодно. Уволиться, например.
Недавно директор признался, что деградация, особенно в районах, достигла такого уровня, что найти вменяемого просто айтишника почти невозможно, о программистах даже речи нет.
Поэтому выбора меня не лишают. Сначала интересное, потом знакомое, остальные ждут, когда закончу с первыми.
И именно поэтому в обычном франче мне места нет. Там скучно.
LynxX; andreypahov; 7OH; Aggressorak; EvgenURNN; rpgshnik; rusmil; +7 Ответить
2. 1c-intelligence 12825 18.05.19 19:25 Сейчас в теме
(1) мне кажется, вы как раз и описали ситуацию, в которой лишили себя выбора. Вы сделали выбор заранее, превратив его в стратегию. Когда дело доходит до выбора задачи, выбором вы уже не мучаетесь.
Это очень высокий уровень, поздравляю.
andreypahov; gubanoff; acanta; Поручик; +4 Ответить
3. script 128 19.05.19 01:09 Сейчас в теме
Видимо я прихожу именно к тому же.

До 2012 года большинство моих задач, имели длительность от 1 часа до 4-ех.
Я вообще не парился по поводу графиков, сроков и т.д. потому что знал что в течении 2-3 дней могу закрыть любой объем задач от моих постоянных клиентов. Даже если они все сговорились бы и начали заваливать меня задачами, максимум за неделю я все бы разгреб.

На конец 2018 года, средняя продолжительность каждой задачи имела длительность 10-15 часов. Тут все понятно. Клиенты те же. Все основные хотелки давно сделаны, и начались уже обдуманные задачи по повышению эффективности процессов. Вот здесь я уже почувствовал, что у меня часто начали появляться завалы. Даже простую задачу, которую я раньше решал за пару часов, а сегодня я могу сделать за минуты, но выполняю через несколько дней. У меня появились задачи, которые находятся в очереди недели. Есть пару задач которые ждут два месяца.

Но с начала 2019 года, средняя продолжительность задачи увеличилась до 25 часов. И я понял что попал в какую то ловушку. Я не могу взять даже элементарную задачу и выполнить ее сразу, кроме совсем авральных, и естественно в ущерб качеству других.

И на данный момент, одним из выходов из ситуации будет именно очередь задач, и жесткое их выполнение по очереди.
Нужно заранее продумать порядок, расставить все задачи по порядку, и придерживаться этого порядка. Это нужно не потому что мне просто так хочется, а для того чтобы я реально оценивал свои возможности. Это позволит получить реальный уровень загрузки, следующее свободное окно. Я смогу клиенту сразу сказать, что его следующую задачу я смогу взять через n дней, недель ....

Это будет самый правильный подход, потому что он избавляет от иллюзий. Жизнь устроена так, чтобы там не говорили, что можно обмануть кого угодно и есть реальный шанс, что об этом никто и никогда не узнает, и тебе ничего не будет. Но как только начинаешь обманывать сам себя, жизнь сразу начинает больно бить по голове.

Спасибо автору, Хоть он пишет про то, что муки выбора негативно влияют на продуктивность, и нужно от них избавляться, я в этой статье вижу еще одно подтверждение моих опасений. Видимо, не зря разработчики платформы 1С, в интерфейсах пункты меню сортировки называют - Порядок. Шутка конечно, но кто знает?
KapasMordorov; +1 Ответить
4. acanta 19.05.19 01:30 Сейчас в теме
Для выбора задач я применяю алгоритмы типа раскроя (минимизации отходов), где есть цельный промежуток времени, посвященный 1с как лист раскроя (иногда его называют "от забора и до обеда", иногда От заката и до рассвета", а бывает и 1001 ночь).
Необходимо упорядочить задачи таким образом, чтобы потери времени (когда тупим выбирая задачу, метод решения или изучаем варианты, включая рефакторинг и концептуальные изменения в программе, необъяснимые для клиента) был минимальными.
При работе у клиента и дома или на офисе таких листов раскроя два или три. Я составляю план таким образом, чтобы уходя от клиента не оставлять "открытый модуль" или неработающий участок.
Каждая задача должна быть полностью закончена там, где она была начата и с тем представителем заказчика, который даёт задание. В редких случаях можно выбрать другого сотрудника, и только когда есть уверенность, что представитель заказчика не аннулирует результаты его приемки.
Портной может сшить больше шапок из одной шкуры заказчика, если будет относиться к ней бережно.

Мантра эффективного программиста не самообман, а цель, иногда недостижимая, но верить в нее надо.
KapasMordorov; Serg O.; +2 Ответить
5. Serg O. 270 19.05.19 10:28 Сейчас в теме
Очередь - это хорошо и даже прекрасно... Однако срочных и сверхважных задач тоже никто не отменял... Сбой отправки платёжек (ключ банка не работает - иди разберись это же 1с не работает) и т.п

Получается очередь вне очереди, которую прерывают ежечасно... ежеминутно звонками

В результате... Опытный программист да.. как ктото тут писал... Умножает время на 2 или 3... Чтобы точно уложиться в срок... И эти 2х неизбежны... Уже не в силу выбора следующей задачи... А как запас на обяательный аврал ..

Но если аврала нет... И все сделано за 1 а не 2х времени... Тут каждый по своему... "Отдыхает" что то изучает, рефакторит код...доводя до блеска или пишет на инфостарте :)
KapasMordorov; +1 Ответить
6. acanta 19.05.19 14:16 Сейчас в теме
(5) проблема всех фикси в том, что мелкие задачи появляются и исчезают, но это не спасает от завершения проекта (с которого все начинается).
А когда проект завершен, никакие мелкие задачи ни в каким количестве и никакой важности не могут заполнить пустоту.
И специалист либо деградирует и увольняется либо деградирует и остаётся.
Но деградирует неминуемо.
Либо необходимо внедрять проектную методику. Т.е. накапливать массив нерешённых вопросов из которых большая половина к моменту начала проекта потеряет актуальность, что далеко не всегда плохо.
Проблема проектной методики на предприятии в том, что нет локомотива да и постоянное его наличие в штате позволить себе могут только высокотехнологичные компании.
Автор и предлагает доверить выбор задач такому директору по развитию.
Вы представляете себе к примеру, агрофирму, в котором директор по развитию поручает программисту 1с раскурить например розницу и общепит на аксапте. Как вариант второе высшее, сертификация, курсы-тренинги и .. полное непонимание коллег зачем это тебе?
KapasMordorov; +1 Ответить
7. starik-2005 3060 20.05.19 10:00 Сейчас в теме
Вот как раз покер планирования в скраме дает выбор без выбора))) Ты выбираешь тем, что даешь оценку. И ты, и дедка, и бабка, и прочие кошки-мышки - все дают оценку. И кто дает оценку вне границ, тот объясняется. И он может действительно быть прав. И это помимо того, что не даст задачам быть криво оцененными, еще и заполнит пул спринта. И вот когда спринт начался - выбора уже нет, т.к. все гири распилены шурами. А ты о технологии-религии пишешь. Сходи к коучу - телефон с меня. Он скидочку даст.
16. 1c-intelligence 12825 21.05.19 19:09 Сейчас в теме
(7) а причем тут скрам? И причем тут оценка?
Есть в бэклоге спринта 50 задач. Все оценены, отклонения объяснены и устранены.
Проблема выбора задачи для исполнения решена?
8. EvgenURNN 99 20.05.19 10:52 Сейчас в теме
Программист при должном опыте и понимании потребностей заказчика в состоянии выбрать самостоятельно задачу исходя из ее полезности для заказчика.
Некоторые сложные или интересные задачи лучше не делать, к сожалению и для заказчика и для методистов и для разработчика это порой становится понято лишь после ее реализации. Много раз сталкивался с тем, как месяц (а то и больше) делали что-то интересное сложное и технологичное, согласовывали в том числе на уровне хозяина бизнеса, тестировали, презентовали, обучали, а получался неиспользуемый функционал (идеально отлаженный с сопроводительной документацией и протестированный).
9. starik-2005 3060 20.05.19 11:47 Сейчас в теме
И, кстати, умные ипонцы как-то так сказали: "подумав - делай, делая - не думай". Ну и наше "семь раз отмерь - один отрежь" - тоже куда-то сюда. Вот надумали группой товарищей времена и сроки, а потом уже делай не думая о временах и сроках, ибо за тебя уже все подумали. И демократично, и эффективно, и расслабиться не даст. Будешь юзать спринты без планирования - получишь растянутое до бесконечности время решения задач, да и не совсем ясно, что за задачи и кто их оценил. Будешь только планировать - найдется куча работы помимо распланированного и опять задачи из плана не будут выполнены.

Хочешь получить инсулин? Соблюдай технологию. Хочешь творчески подойти к технологии? - вряд ли на выходе получишь инсулин, ибо умные дяди выработали методику до тебя, и они в совокупности внезапно вряд ли окажутся тупее. Но можно их назвать сектой - и ответственность уже на тебе. Альцшуллер в своей ТРИЗ столько технологических карт нарисовал чуть ли не на каждый чих не просто так. И скрам тоже не просто так методологически собран таким вот образом.
Vladimir Litvinenko; +1 Ответить
10. EvgenURNN 99 20.05.19 11:52 Сейчас в теме
(9) предполагается, что программист сам является умным дядей(тётей) и его работа не тоже самое что работа грузчика, где действительно не надо думать
11. starik-2005 3060 20.05.19 12:00 Сейчас в теме
(10) программист - да, дядя умный. Или даже тетя. Но для того, чтобы заставить человека работать, нужно дать ему четко понять, что от него надо. Да, добавить колонку на форме не требует объяснения того, как это сделать технологически - достаточно методологического слоя о характере данных в колонке, ее положения на форме и, возможно, места хранения в системе для данных ее заполнения. Но если не сказать программисту о том, что ему делать и не решить (и вместе с ним - тоже), сколько это должно занять времени, то есть шанс того, что программист будет долго искать "удобную" для себя задачу и будет делать ее бесконечно долго.
17. 1c-intelligence 12825 21.05.19 19:10 Сейчас в теме
(9) японцы в тему. Только там так: решение должно приниматься за семь вдохов. Еще - если раздумья длятся долго, результат будет плачевным.
Только это не про технологию, а про стратегию. И вовсе не про скрам.
12. gubanoff 63 20.05.19 16:53 Сейчас в теме
(0) не мешало бы еще раскрыть тему приоритетов - как именно посчитать "полезность для бизнеса" каждой задачи. Желательно с примерами работающих коэффициентов, т.к. теорий много. Сортировка по дате весьма печальна.
13. starik-2005 3060 20.05.19 17:42 Сейчас в теме
(12)
как именно посчитать "полезность для бизнеса" каждой задачи
Так есть же формулыдля расчета ROI. Вот оно:
Р = (Доход от В - Размер В) / Размер В * 100%

Когда мы вычитаем из доходов наши инвестиции мы получаем ту цифру, которая и является нашим реальным заработком. Дальше все еще проще – отношение конечной прибыли к сумме инвестиций показывает, во сколько раз первое больше второго. В последнем действии мы умножаем на 100% и, если полученное число меньше 100, то вложения не окупаются.
Также там есть формула от финансистов, которая получает ROI по периоду вложений. Можно применить для затрат на поддержку и развитие продукта.

Но если подобный подход оценки возвращенных инвестиций применять к каждой задаче, то может так оказаться, что стоимость расчета KPI будет выше инвестиционного дохода (или экономии) от решения той или иной задачи. Поэтому большинство интуитивно оценивают потенциал, а не конкретную величину возврата вложений. Для этого можно просто составить "квадрат Малевича" на тему того, что нас ждет без этого, что мы без этого не получим, что получим с этим и от чего с этим будем убережены.
14. gubanoff 63 21.05.19 09:03 Сейчас в теме
(13) Формула хороша, но как ее наложить на список задач, чтобы для каждой посчитать приоритет?
15. starik-2005 3060 21.05.19 09:15 Сейчас в теме
(14)
чтобы для каждой посчитать приоритет
Так написал же, что квадрат нужно нарисовать на тему того, что нам обломится если мы это сделаем, и что мы огреббем, если это не сделать.

Вообще, существуют задачи, которые вроде бы не хрен какие РОИшные, но могут в синергии привести к сокращению пары отделов. Смысл оценивать конкретную задачу в плане РОИ отсутствует - только полные идиоты, на мой скромный взгляд, оцценивают это и тратят на оценку больше ресурсов, чем их выхлоп. Оценивать нужно пул задач в рамках проекта или подсистемы, и уже общая оценка может показать, каков выхлоп. Спрогнозировать его весьма непросто. А вот понять, что при отсутствии того или иного механизма можно огрести то и это - тут ума хватит.
18. 1c-intelligence 12825 21.05.19 19:12 Сейчас в теме
(12) делать такую оценку на уровне задач смысла нет. На уровне проектов, или направлений автоматизации - можно. Лучше - проектов.
Там оценка должна быть в цель проекта заложена. Пару месяцев назад писал где-то статью о том, как организовать целевой проект по увольнению сотрудников с помощью автоматизации. Это один из примеров.
Оставьте свое сообщение