Начну с главного: если ваши программисты сами выбирают себе задачу, то у вас большие проблемы.
Мы привыкли смотреть на выбор, как на условный оператор в языке программирования или схеме алгоритма. Ну, помните, такой ромбик рисуется, в нем условие выбора, и две веточки – да и нет. При исполнении алгоритма условие проверяется мгновенно, поэтому его производительность обычно не принимается в расчет.
А что есть выбор, выполняемый человеком? Это не мгновенный алгоритм, а процесс. У этого процесса есть начало, конец (дай-то Бог), и, главное – продолжительность. Сколько, по-вашему, может длиться выбор задачи?
Можно гадать, но лучше измерить. Я наблюдал за этим процессом многократно, и вывод неутешительный: программист может выбирать задачу несколько дней.
Процесс выбора плох тем, что скрыт от нашего взгляда. Если бы человек слонялся по кабинету, метался из стороны в сторону, вскидывал голову в протяжном вое, мы бы поняли, что у него проблема. Но происходит иначе.
Программисты давно придумали такой алгоритм, как разведка боем. Применительно к задачам он означает: не просто почитать условие, а зайти и посмотреть. Глянуть на код, формы, связи, метаданные, примеры воспроизведения и аналитические отчеты.
Посмотреть надо для того, чтобы оценить задачу «как следует», не на глазок. Если поймать программиста за этим занятием, то он скажет: я – профессионал, и не могу браться за задачу, не зная всех тонкостей. Казалось бы, чего же тут такого? Правильно ведь делает человек?
Конечно, правильно. Но только если он, по результатам своих исследований, примет окончательное решение – браться за задачу, или нет. Как вариант – взять задачу с оговорками, вроде необходимости изучения дополнительных механизмов.
Если программист решил задачу взять, и сел делать, то все хорошо. Если же он отказался от задачи, то все плохо. Время, потраченное на исследование, будет потеряно даром.
Тут варианта два. Первый – программист откажется наотрез, и задачу будет смотреть кто-то другой. В принципе, возможен вариант, когда первый программист просто перескажет второму результаты своих исследований, обнаруженные подводные камни и сопутствующие трудности. Но на практике программисты предпочитают независимость друг от друга, в том числе – от мнения коллег. Некоторые даже испытывают определенный азарт, разбираясь в задаче, за которую не взялся коллега.
Второй вариант – программист не отказался, а отложил задачу на потом. Когда наступит это «потом» — не известно, но скорее всего – через достаточно продолжительное время. Что будет во время второй итерации разведки боем? Начнет с того места, где остановился в исследованиях? Разумеется, нет – он пройдет тот же путь, от начала и до конца. И, с высокой вероятностью, застопорится на том же самом месте, что и в первый раз.
И вот что получается. Есть время, которое программисты тратят на решение задач. Нормальное, правильное, полезное время. Как правило, время на решение задачи тратится один раз.
А есть время, которое программисты тратят на многократную разведку. Никакой особой пользы в этом времени нет – ни для программиста, ни для клиента, ни для вашей компании. Время на разведку боем – практически чистая потеря.
Но проблема не только в разведке. Бывает и хуже.
Например, программист понимает все задачи в своем списке, но просто не может выбрать, чем ему заняться. Проблема усугубляется тем, что выбор происходит, как Бог на душу положит – без определенного алгоритма, критериев и приоритетов. И тут уж кто во что горазд.
Один выбирает то, что поинтереснее. Другой выбирает то, что полегче. Третий выбирает задачи по механизмам, которые ему знакомы. Четвертый выбирает задачи своего любимого клиента, потому что результат сдавать проще. Пятый выбирает самую амбициозную задачу, чтобы показать себя.
При этом, что важно, почти каждый из них испытывает серьезные душевные терзания из-за неопределенности критериев. Он примерно понимает, какие задачи хочет решать, но, или осознанно, или неосознанно чувствует, что делает что-то не так. Ему кажется, что надо выбирать совсем другую задачу, исходя из стратегии работы компании, состояния проекта, плана развития собственных компетенций и т.д. Но хочется-то выбрать не то, что надо, а то, что по душе.
Такие душевные терзания еще сильнее усугубляют процесс выбора. Человек погружается в мрачные размышления, взвешивая на весах совести свой выбор. И так могут пройти часы и дни.
С точки зрения менеджера, стоящего в стороне, весь этот процесс напоминает сурка из одного известного фильма, который вылезает из норы и «выбирает погоду на ближайшие шесть недель». Чем он там руководствуется, видит свою тень или нет, и почему вообще это делает сурок? Правда, если менеджер часто смотрит на этот процесс со стороны, то вопрос скорее к нему, чем к программистам.
Так же, в контексте выбора большое значение имеет праздник. Программист – он ведь человек, в первую очередь, а не робот. Чего хочется человеку после выполнения сложной работы? Праздника, конечно!
Выполненную задачу нужно отметить. Сходить покурить, выпить чаю или кофе, поболтать с друзьями, похвастаться решенной задачей, посидеть в социальных сетях, почитать новости – в общем, вариантов множество. К сожалению, этот праздник иногда затягивается.
Особенно плохо, если задача была закончена за час, или даже за два до окончания рабочего дня. Ну кто, в здравом уме, будет выбирать себе новую задачу, если скоро – домой?
Как непросто выходить из состояния праздника, знает каждый россиянин – все мы отдыхаем в новогодние каникулы. В нашем случае – еще сложнее, т.к. программист должен вернуться не к решению задачи, а к выбору следующей. Насколько мучителен выбор, мы уже обсудили.
Если резюмировать потери от выбора, то они есть всегда. Вопрос только в их количестве. Чтобы вы прониклись, назову такую цифру: на выбор задачи уходит до 50 % времени. Только вдумайтесь в эту цифру.
Но, в контексте нашего материала, эта цифра просто прекрасна. Избавившись от потерь из-за выбора, вы можете увеличить эффективность вдвое.
Как же избавиться от выбора? Нет ничего проще. Собственно, вы сами знаете, как это сделать. Я изложу свои предложения, а вы скомпонуете их с собственными методами, и получится приличный рост эффективности.
Первое и главное, с чего следует начать, это контроллинг. Какую бы вы не придумали систему приоритетов и распределения задач, она не будет работать, пока программисты вас «не слушаются».
Контроллинг, в двух словах, это – управление на основе цифр. В данном случае цифрой будет не прибыль или сумма продаж, а порядковый номер задачи в очереди. Нужно управлять выбором задачи на основе этого номера, и быть уверенным, что задачи решаются в заданном порядке.
Контроллинг необходим и в случае, если вы управляете командой, и даже тогда, когда вы управляете собой. С собой ведь договориться проще, чем с начальником? «Да сейчас, в последний раз, а потом уж точно!».
Вообще, про контроллинг мы еще поговорим более обстоятельно, здесь я забежал вперед, но оно того стоит. Если вы придумали правила выбора задачи, но их никто не исполняет, то ничего не получится.
Итак, все, что надо сделать – выстроить задачи в очередь и обеспечить следование этой очереди. В некоторых источниках рекомендуется скрывать очередь от программистов, оставляя в поле зрения лишь две задачи – текущую и следующую. Если показать программисту все задачи сразу, то он, как ни старайся, все равно будет «подглядывать», изучать, что там впереди.
Первый способ – распределение задач начальником, без использования автоматизации. Вы просто говорите, кто что делает и в какой последовательности. Можно составлять несложные планы – например, в виде маленьких бумажек, вроде нарядов на выполнение работ, или заданий на производство. Можно просто диктовать номера задач под запись в блокнот.
Можно сделать доску, по типу скрама, и вешать туда стикеры на день. Методика скрама предполагает вывешивание множества задач, например – на неделю или месяц, но нам это не подходит, потому что снова появляется выбор.
Ручное распределение задач очень просто начать, и так же просто прекратить, потому что быстро надоест. Нужно иметь значительную силу воли, или хорошие навыки регулярного менеджмента, чтобы ежедневно заставлять себя распределять задачи. Если сказанное – про вас, то можете начать уже сегодня.
Для ленивых подойдет автоматизация. В вашей информационной системе, где хранятся задачи, надо заложить механизм их сортировки. Как вам ближе? Сортировать по дате постановки? По сроку исполнения? Годится любой способ. Главное, чтобы он был детерминирован и одинаково понимаем программистами. Лично я рекомендую не ограничиться сортировкой, а хранить номера в очереди в виде отдельного поля. Современные системы слишком удобны для пользователя, и позволяют ему настраивать сортировку самостоятельно. Вот вы решили, что надо задачи выполнять в порядке поступления (FIFO), а программист случайно, или умышленно, поменял сортировку на обратную, и получил LIFO.
Если же номер в очереди сохранен, то сортируй, не сортируй, ошибиться сложно.
Можно не привязываться к сортировке, а ставить номера вручную. Тоже годится, если у вас хватит силы воли расставлять эти номера.
Принцип, думаю, понятен. Любая система составления очереди, понятная программистам, и контроль ее соблюдения. Это будет первый шаг к лишению выбора, отнимающего эффективность.
Второй шаг мы рассмотрим дальше. Он позволит нам извлечь из очередей намного больше пользы – не только упростить выбор, но и сделать его правильным.
Резюме
Мы привыкли смотреть на выбор, как на условный оператор в языке программирования или схеме алгоритма. Ну, помните, такой ромбик рисуется, в нем условие выбора, и две веточки – да и нет. При исполнении алгоритма условие проверяется мгновенно, поэтому его производительность обычно не принимается в расчет.
А что есть выбор, выполняемый человеком? Это не мгновенный алгоритм, а процесс. У этого процесса есть начало, конец (дай-то Бог), и, главное – продолжительность. Сколько, по-вашему, может длиться выбор задачи?
Можно гадать, но лучше измерить. Я наблюдал за этим процессом многократно, и вывод неутешительный: программист может выбирать задачу несколько дней.
Процесс выбора плох тем, что скрыт от нашего взгляда. Если бы человек слонялся по кабинету, метался из стороны в сторону, вскидывал голову в протяжном вое, мы бы поняли, что у него проблема. Но происходит иначе.
Программисты давно придумали такой алгоритм, как разведка боем. Применительно к задачам он означает: не просто почитать условие, а зайти и посмотреть. Глянуть на код, формы, связи, метаданные, примеры воспроизведения и аналитические отчеты.
Посмотреть надо для того, чтобы оценить задачу «как следует», не на глазок. Если поймать программиста за этим занятием, то он скажет: я – профессионал, и не могу браться за задачу, не зная всех тонкостей. Казалось бы, чего же тут такого? Правильно ведь делает человек?
Конечно, правильно. Но только если он, по результатам своих исследований, примет окончательное решение – браться за задачу, или нет. Как вариант – взять задачу с оговорками, вроде необходимости изучения дополнительных механизмов.
Если программист решил задачу взять, и сел делать, то все хорошо. Если же он отказался от задачи, то все плохо. Время, потраченное на исследование, будет потеряно даром.
Тут варианта два. Первый – программист откажется наотрез, и задачу будет смотреть кто-то другой. В принципе, возможен вариант, когда первый программист просто перескажет второму результаты своих исследований, обнаруженные подводные камни и сопутствующие трудности. Но на практике программисты предпочитают независимость друг от друга, в том числе – от мнения коллег. Некоторые даже испытывают определенный азарт, разбираясь в задаче, за которую не взялся коллега.
Второй вариант – программист не отказался, а отложил задачу на потом. Когда наступит это «потом» — не известно, но скорее всего – через достаточно продолжительное время. Что будет во время второй итерации разведки боем? Начнет с того места, где остановился в исследованиях? Разумеется, нет – он пройдет тот же путь, от начала и до конца. И, с высокой вероятностью, застопорится на том же самом месте, что и в первый раз.
И вот что получается. Есть время, которое программисты тратят на решение задач. Нормальное, правильное, полезное время. Как правило, время на решение задачи тратится один раз.
А есть время, которое программисты тратят на многократную разведку. Никакой особой пользы в этом времени нет – ни для программиста, ни для клиента, ни для вашей компании. Время на разведку боем – практически чистая потеря.
Но проблема не только в разведке. Бывает и хуже.
Например, программист понимает все задачи в своем списке, но просто не может выбрать, чем ему заняться. Проблема усугубляется тем, что выбор происходит, как Бог на душу положит – без определенного алгоритма, критериев и приоритетов. И тут уж кто во что горазд.
Один выбирает то, что поинтереснее. Другой выбирает то, что полегче. Третий выбирает задачи по механизмам, которые ему знакомы. Четвертый выбирает задачи своего любимого клиента, потому что результат сдавать проще. Пятый выбирает самую амбициозную задачу, чтобы показать себя.
При этом, что важно, почти каждый из них испытывает серьезные душевные терзания из-за неопределенности критериев. Он примерно понимает, какие задачи хочет решать, но, или осознанно, или неосознанно чувствует, что делает что-то не так. Ему кажется, что надо выбирать совсем другую задачу, исходя из стратегии работы компании, состояния проекта, плана развития собственных компетенций и т.д. Но хочется-то выбрать не то, что надо, а то, что по душе.
Такие душевные терзания еще сильнее усугубляют процесс выбора. Человек погружается в мрачные размышления, взвешивая на весах совести свой выбор. И так могут пройти часы и дни.
С точки зрения менеджера, стоящего в стороне, весь этот процесс напоминает сурка из одного известного фильма, который вылезает из норы и «выбирает погоду на ближайшие шесть недель». Чем он там руководствуется, видит свою тень или нет, и почему вообще это делает сурок? Правда, если менеджер часто смотрит на этот процесс со стороны, то вопрос скорее к нему, чем к программистам.
Так же, в контексте выбора большое значение имеет праздник. Программист – он ведь человек, в первую очередь, а не робот. Чего хочется человеку после выполнения сложной работы? Праздника, конечно!
Выполненную задачу нужно отметить. Сходить покурить, выпить чаю или кофе, поболтать с друзьями, похвастаться решенной задачей, посидеть в социальных сетях, почитать новости – в общем, вариантов множество. К сожалению, этот праздник иногда затягивается.
Особенно плохо, если задача была закончена за час, или даже за два до окончания рабочего дня. Ну кто, в здравом уме, будет выбирать себе новую задачу, если скоро – домой?
Как непросто выходить из состояния праздника, знает каждый россиянин – все мы отдыхаем в новогодние каникулы. В нашем случае – еще сложнее, т.к. программист должен вернуться не к решению задачи, а к выбору следующей. Насколько мучителен выбор, мы уже обсудили.
Если резюмировать потери от выбора, то они есть всегда. Вопрос только в их количестве. Чтобы вы прониклись, назову такую цифру: на выбор задачи уходит до 50 % времени. Только вдумайтесь в эту цифру.
Но, в контексте нашего материала, эта цифра просто прекрасна. Избавившись от потерь из-за выбора, вы можете увеличить эффективность вдвое.
Как же избавиться от выбора? Нет ничего проще. Собственно, вы сами знаете, как это сделать. Я изложу свои предложения, а вы скомпонуете их с собственными методами, и получится приличный рост эффективности.
Первое и главное, с чего следует начать, это контроллинг. Какую бы вы не придумали систему приоритетов и распределения задач, она не будет работать, пока программисты вас «не слушаются».
Контроллинг, в двух словах, это – управление на основе цифр. В данном случае цифрой будет не прибыль или сумма продаж, а порядковый номер задачи в очереди. Нужно управлять выбором задачи на основе этого номера, и быть уверенным, что задачи решаются в заданном порядке.
Контроллинг необходим и в случае, если вы управляете командой, и даже тогда, когда вы управляете собой. С собой ведь договориться проще, чем с начальником? «Да сейчас, в последний раз, а потом уж точно!».
Вообще, про контроллинг мы еще поговорим более обстоятельно, здесь я забежал вперед, но оно того стоит. Если вы придумали правила выбора задачи, но их никто не исполняет, то ничего не получится.
Итак, все, что надо сделать – выстроить задачи в очередь и обеспечить следование этой очереди. В некоторых источниках рекомендуется скрывать очередь от программистов, оставляя в поле зрения лишь две задачи – текущую и следующую. Если показать программисту все задачи сразу, то он, как ни старайся, все равно будет «подглядывать», изучать, что там впереди.
Первый способ – распределение задач начальником, без использования автоматизации. Вы просто говорите, кто что делает и в какой последовательности. Можно составлять несложные планы – например, в виде маленьких бумажек, вроде нарядов на выполнение работ, или заданий на производство. Можно просто диктовать номера задач под запись в блокнот.
Можно сделать доску, по типу скрама, и вешать туда стикеры на день. Методика скрама предполагает вывешивание множества задач, например – на неделю или месяц, но нам это не подходит, потому что снова появляется выбор.
Ручное распределение задач очень просто начать, и так же просто прекратить, потому что быстро надоест. Нужно иметь значительную силу воли, или хорошие навыки регулярного менеджмента, чтобы ежедневно заставлять себя распределять задачи. Если сказанное – про вас, то можете начать уже сегодня.
Для ленивых подойдет автоматизация. В вашей информационной системе, где хранятся задачи, надо заложить механизм их сортировки. Как вам ближе? Сортировать по дате постановки? По сроку исполнения? Годится любой способ. Главное, чтобы он был детерминирован и одинаково понимаем программистами. Лично я рекомендую не ограничиться сортировкой, а хранить номера в очереди в виде отдельного поля. Современные системы слишком удобны для пользователя, и позволяют ему настраивать сортировку самостоятельно. Вот вы решили, что надо задачи выполнять в порядке поступления (FIFO), а программист случайно, или умышленно, поменял сортировку на обратную, и получил LIFO.
Если же номер в очереди сохранен, то сортируй, не сортируй, ошибиться сложно.
Можно не привязываться к сортировке, а ставить номера вручную. Тоже годится, если у вас хватит силы воли расставлять эти номера.
Принцип, думаю, понятен. Любая система составления очереди, понятная программистам, и контроль ее соблюдения. Это будет первый шаг к лишению выбора, отнимающего эффективность.
Второй шаг мы рассмотрим дальше. Он позволит нам извлечь из очередей намного больше пользы – не только упростить выбор, но и сделать его правильным.
Резюме
- Выбор задачи – это не мгновение, а длительный процесс;
- Программист выбирает задачу, исходя из собственных представлений;
- На выбор тратится огромное количество времени;
- Процесс выбора не приносит ни пользы, ни удовольствия;
- Выбора надо лишить;
- Распределять задачи можно вручную, как прораб;
- Автоматизация может помочь в составлении очередей.
