Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Нужна справка на каждого ребенка. Да, и согласие на обработку персональных данных. От каждого из родителей. Пусть и анкету каждый заполнит. Статистический отчет о том, сколько мальчиков и девочек. Да, и по возрастам. И по районам прописки. Ну и по школам. Разделите там, пожалуйста, обычные школы, лицеи и гимназии. Нет, педсовет пропускать нельзя. Это всего 4 часа. Раз в неделю. Да, всем педагогам надо прийти. Конечно, вам нужно работать еще и в детских садах. Каждому из вас. Трижды в неделю. И костюмы ваши нам не нравятся, нужно меньше красок – чего как попугаи-то?
Так, а почему новых постановок нет? Где победы на конкурсах? Что значит два месяца бегаете бумажки собираете? Какое еще творчество? И почему у вас на него времени нет? Какого еще секретаря вам нанять? Что значит «я ухожу»? Вы серьёзно думаете, что справитесь без нас? Что ж, удачи.
Примерно так описал один очень хороший руководитель одного очень хорошего танцевального коллектива жизнь «под крылом» государственного учреждения, когда объяснял, почему ушёл «из-под крыла».
Случай запал в душу, т.к. я как раз проводил эксперимент (в очередной раз) по избавлению других творческих людей – программистов – от непрофильной, но «такой важной, нужной и обязательной работы» — успеванию в срок.
Я этот эксперимент проводил неоднократно, в разных компаниях – и на проектах, и на разработке, и на заводских программистах, и на оказании услуг по доработке. Хотите верьте, хотите нет, но результат всегда один и тот же.
Если программисты перестают париться насчет сроков, и просто решают задачи, одну за другой, ни на что не отвлекаясь, то продуктивность возрастает вдвое. Соответственно, если включить режим «успевания в срок» обратно, то коэффициент ровно тот же – вдвое, только на этот раз продуктивность на него делится.
Ну и главное: в срок программист всё равно не попадает, хоть убей. А если попадает, то лишь иногда, случайно. Либо ценой снижения продуктивности.
Тут всё очень просто. Аксиому о том, что программист никогда точно не знает, сколько времени уйдёт на решение задачи, доказывать не буду – на эту тему есть куча статей и книг. Если вы работали программистом, то доказательство и не потребуется. Бывают, конечно, исключения – однотипные, повторяющиеся задачи – но это именно исключения.
В основной массе наша работа содержит столько постоянно меняющихся неизвестных, постоянных флешбеков старых задач, неожиданностей от смежников и обновления зависимостей, ошибок проектирования и т.п.
Как планировать выполнение такой работы? Принципиально подхода четыре – фантазии, резерв, объем и поток.
Фантазии – это применение к работе программистов методов планирования серийного производства. Например, Lean или MRP. Этим подходом пользуются все «классические менеджеры», особенно отдельная их каста – «управленцы». Надо просто выдавить из программиста плановые трудозатраты, игнорируя все его вопли типа «блин, да я даже близко не знаю, с чем там столкнусь», и нарисовать красивую колбаску на диаграмме Ганта. И перерисовывать каждый день.
Резерв – это подходы типа теории ограничений, когда к плановым трудозатратам просто добавляется конская доля, на всякий случай. Получившаяся цифра также рисуется в виде колбаски на диаграмме Ганта. Перерисовывается пореже, но почти всегда.
Объем – это когда планируются не сроки решения задач, а продуктивность. Например, такой подход используется в Scrum – зная примерную скорость работы команды (в story points), можно запланировать объем работы за спринт (в тех же SP). Соответственно, у всех задач спринта один и тот же срок исполнения.
Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой. Сроки не известны, но их можно вычислить – зная скорость и номер задачи в очереди. Главное – не озадачивать вычислением срока самого программиста.
Фантазийный подход даже обсуждать смысла нет – он не работает. Мало того – он еще и создаёт постоянный, дикий стресс и идиотскую работу по перепланированию. Жить можно, если перепланированием занимается не программист, а кто-то другой, но так бывает редко. Обычно программиста просто долбят каждый день вопросами типа «назови мне срок», «когда ты уже доделаешь эту задачу?» или «уже все сроки прошли, ты будешь работать или нет?». Естественным, гармоничным путём программист приходит к резервам времени, даже если ничего не знает ни о каких модных методиках.
Резервы времени спасают от нервотрёпки, но снижают продуктивность, в силу действия закона Паркинсона – работа занимает всё отведённое на неё время. В некоторых условиях такой подход устраивает всех – например, для заводских программистов. Правда, до той поры, пока программист не уволится – тогда, как правило, он понимает, что его скорость работы ниже требований рынка.
Сроки при этом соблюдаются, т.к. резервы времени могут составлять тысячи процентов от реальных трудозатрат. Если бизнес, или процесс построен так, что ключевой показатель – именно попадание в срок, то метод резервирования времени очень даже годится.
Объёмные методы, типа Scrum, повышают продуктивность примерно вдвое, т.к. снижают влияние закона Паркинсона и ориентируются на более или менее реальную продуктивность, а не фантазии и резервы времени. Однако спринт – это всё равно срок, поэтому закон Паркинсона продолжает действовать, как и резервирование времени и попытки манипуляции оценками (story points). Люди есть люди – и программисты, и менеджеры. Программисты хотят быть хорошими сотрудниками. А менеджеры настолько привыкли считать хорошими сотрудниками только тех, кто «успевает в срок», что хоть кол на голове теши. Просто называться всё это будет по-другому – типа «все таски бэклога должны быть выполнены в пределах спринта, и нечего тут фасилитировать». И ещё какой-нибудь KPI под это дело придумают, ибо фантазия небогата.
В потоке этих проблем нет, т.к. отсутствует их причина – планирование работы программиста и попытки, так или иначе, оценить сроки исполнения работ. Поток защищает суть работы программиста – творчество. Хочется, конечно, сказать, что поток – это чистое творчество, но так не бывает. Однако, чистота намного выше. И продуктивность возрастает еще вдвое, по сравнению с Scrum.
Что интересно: защита программиста, или любого исполнителя работы, заложена в любой из перечисленных методик. Но применительно к программистам о защите всегда забывают.
Например, Lean, как ни странно, так же основан на идее потока, т.к. придуман на конвейере. Идея в том, чтобы выстроить работу максимально равномерно и гармонично. Чтобы у каждого исполнителя в цепочке, с одной стороны, всегда было чем заняться, а с другой – чтобы перед ним не было очереди. Только минимально необходимый запас работы. Для программиста это – одна задача. Попробуйте менеджеру, знатоку Lean, подать эту идею – он даже не поймёт, о чём речь, т.к. пропустил раздел о защите исполнителей, когда читал статью в википедии про бережливое производство.
В Теории ограничений, которая про резервы, защита звена-исполнителя – вообще базовый постулат. Там, где сидят программисты, они почти всегда – бутылочное горлышко. Что в ТОС написано про бутылочное горлышко? Правильно – его надо защищать. Убрать всю непрофильную загрузку (включая планирование собственной работы), не допускать простоев, не конопатить мозги дурацкими вопросами и совещаниями. Организовать поток работы той скорости, с которой работает бутылочное горлышко. Ну-ка, менеджеры-знатоки ТОС, признайтесь – давно вы думали о том, как защитить программистов от всякой дури?
Ну а Scrum весь – про поток. Там принцип «не мешай людям работать» возведён в абсолют, и выражен в требовании к максимальной автономности команды во время спринта. После – пожалуйста, приходите, смотрите, что получилось, выбирайте задачи на следующий забег, ковыряйтесь в душе. Во время спринта – даже не дышите рядом. Кто работает по Scrum – чё скажете? Никто вас не трогает во время спринта, ага?
Куда ни плюнь, везде нужен поток. Чтобы программист сел и просто программировал. Не вычислял сроки, не фантазировал о трудозатратах, не переставлял по сто раз приоритеты, не ходил на совещания, не участвовал в идиотских переписках и чатах.
Однако, куда ни плюнь, нигде потока нет. Какой бы подход не использовался, менеджер, или клиент, или какой-нибудь идиот найдёт повод вырвать программиста из гармоничного творческого потока ради какой-нибудь безумно важной ерунды.
В поток всегда можно вернуться. Или вернуть. Нужна, правда, воля – и на возврат, и на поддержание. Зуд постоянного контроля работы программиста ведь не даёт покоя. Особенно тем, кто ничего в работе программиста на понимает.
Так, а почему новых постановок нет? Где победы на конкурсах? Что значит два месяца бегаете бумажки собираете? Какое еще творчество? И почему у вас на него времени нет? Какого еще секретаря вам нанять? Что значит «я ухожу»? Вы серьёзно думаете, что справитесь без нас? Что ж, удачи.
Примерно так описал один очень хороший руководитель одного очень хорошего танцевального коллектива жизнь «под крылом» государственного учреждения, когда объяснял, почему ушёл «из-под крыла».
Случай запал в душу, т.к. я как раз проводил эксперимент (в очередной раз) по избавлению других творческих людей – программистов – от непрофильной, но «такой важной, нужной и обязательной работы» — успеванию в срок.
Что будет если?
Я этот эксперимент проводил неоднократно, в разных компаниях – и на проектах, и на разработке, и на заводских программистах, и на оказании услуг по доработке. Хотите верьте, хотите нет, но результат всегда один и тот же.
Если программисты перестают париться насчет сроков, и просто решают задачи, одну за другой, ни на что не отвлекаясь, то продуктивность возрастает вдвое. Соответственно, если включить режим «успевания в срок» обратно, то коэффициент ровно тот же – вдвое, только на этот раз продуктивность на него делится.
Ну и главное: в срок программист всё равно не попадает, хоть убей. А если попадает, то лишь иногда, случайно. Либо ценой снижения продуктивности.
Тут всё очень просто. Аксиому о том, что программист никогда точно не знает, сколько времени уйдёт на решение задачи, доказывать не буду – на эту тему есть куча статей и книг. Если вы работали программистом, то доказательство и не потребуется. Бывают, конечно, исключения – однотипные, повторяющиеся задачи – но это именно исключения.
В основной массе наша работа содержит столько постоянно меняющихся неизвестных, постоянных флешбеков старых задач, неожиданностей от смежников и обновления зависимостей, ошибок проектирования и т.п.
Как планировать выполнение такой работы? Принципиально подхода четыре – фантазии, резерв, объем и поток.
Методы «планирования»
Фантазии – это применение к работе программистов методов планирования серийного производства. Например, Lean или MRP. Этим подходом пользуются все «классические менеджеры», особенно отдельная их каста – «управленцы». Надо просто выдавить из программиста плановые трудозатраты, игнорируя все его вопли типа «блин, да я даже близко не знаю, с чем там столкнусь», и нарисовать красивую колбаску на диаграмме Ганта. И перерисовывать каждый день.
Резерв – это подходы типа теории ограничений, когда к плановым трудозатратам просто добавляется конская доля, на всякий случай. Получившаяся цифра также рисуется в виде колбаски на диаграмме Ганта. Перерисовывается пореже, но почти всегда.
Объем – это когда планируются не сроки решения задач, а продуктивность. Например, такой подход используется в Scrum – зная примерную скорость работы команды (в story points), можно запланировать объем работы за спринт (в тех же SP). Соответственно, у всех задач спринта один и тот же срок исполнения.
Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой. Сроки не известны, но их можно вычислить – зная скорость и номер задачи в очереди. Главное – не озадачивать вычислением срока самого программиста.
Плюсы и минусы
Фантазийный подход даже обсуждать смысла нет – он не работает. Мало того – он еще и создаёт постоянный, дикий стресс и идиотскую работу по перепланированию. Жить можно, если перепланированием занимается не программист, а кто-то другой, но так бывает редко. Обычно программиста просто долбят каждый день вопросами типа «назови мне срок», «когда ты уже доделаешь эту задачу?» или «уже все сроки прошли, ты будешь работать или нет?». Естественным, гармоничным путём программист приходит к резервам времени, даже если ничего не знает ни о каких модных методиках.
Резервы времени спасают от нервотрёпки, но снижают продуктивность, в силу действия закона Паркинсона – работа занимает всё отведённое на неё время. В некоторых условиях такой подход устраивает всех – например, для заводских программистов. Правда, до той поры, пока программист не уволится – тогда, как правило, он понимает, что его скорость работы ниже требований рынка.
Сроки при этом соблюдаются, т.к. резервы времени могут составлять тысячи процентов от реальных трудозатрат. Если бизнес, или процесс построен так, что ключевой показатель – именно попадание в срок, то метод резервирования времени очень даже годится.
Объёмные методы, типа Scrum, повышают продуктивность примерно вдвое, т.к. снижают влияние закона Паркинсона и ориентируются на более или менее реальную продуктивность, а не фантазии и резервы времени. Однако спринт – это всё равно срок, поэтому закон Паркинсона продолжает действовать, как и резервирование времени и попытки манипуляции оценками (story points). Люди есть люди – и программисты, и менеджеры. Программисты хотят быть хорошими сотрудниками. А менеджеры настолько привыкли считать хорошими сотрудниками только тех, кто «успевает в срок», что хоть кол на голове теши. Просто называться всё это будет по-другому – типа «все таски бэклога должны быть выполнены в пределах спринта, и нечего тут фасилитировать». И ещё какой-нибудь KPI под это дело придумают, ибо фантазия небогата.
В потоке этих проблем нет, т.к. отсутствует их причина – планирование работы программиста и попытки, так или иначе, оценить сроки исполнения работ. Поток защищает суть работы программиста – творчество. Хочется, конечно, сказать, что поток – это чистое творчество, но так не бывает. Однако, чистота намного выше. И продуктивность возрастает еще вдвое, по сравнению с Scrum.
Что интересно: защита программиста, или любого исполнителя работы, заложена в любой из перечисленных методик. Но применительно к программистам о защите всегда забывают.
Что в основе любого метода
Например, Lean, как ни странно, так же основан на идее потока, т.к. придуман на конвейере. Идея в том, чтобы выстроить работу максимально равномерно и гармонично. Чтобы у каждого исполнителя в цепочке, с одной стороны, всегда было чем заняться, а с другой – чтобы перед ним не было очереди. Только минимально необходимый запас работы. Для программиста это – одна задача. Попробуйте менеджеру, знатоку Lean, подать эту идею – он даже не поймёт, о чём речь, т.к. пропустил раздел о защите исполнителей, когда читал статью в википедии про бережливое производство.
В Теории ограничений, которая про резервы, защита звена-исполнителя – вообще базовый постулат. Там, где сидят программисты, они почти всегда – бутылочное горлышко. Что в ТОС написано про бутылочное горлышко? Правильно – его надо защищать. Убрать всю непрофильную загрузку (включая планирование собственной работы), не допускать простоев, не конопатить мозги дурацкими вопросами и совещаниями. Организовать поток работы той скорости, с которой работает бутылочное горлышко. Ну-ка, менеджеры-знатоки ТОС, признайтесь – давно вы думали о том, как защитить программистов от всякой дури?
Ну а Scrum весь – про поток. Там принцип «не мешай людям работать» возведён в абсолют, и выражен в требовании к максимальной автономности команды во время спринта. После – пожалуйста, приходите, смотрите, что получилось, выбирайте задачи на следующий забег, ковыряйтесь в душе. Во время спринта – даже не дышите рядом. Кто работает по Scrum – чё скажете? Никто вас не трогает во время спринта, ага?
Итого
Куда ни плюнь, везде нужен поток. Чтобы программист сел и просто программировал. Не вычислял сроки, не фантазировал о трудозатратах, не переставлял по сто раз приоритеты, не ходил на совещания, не участвовал в идиотских переписках и чатах.
Однако, куда ни плюнь, нигде потока нет. Какой бы подход не использовался, менеджер, или клиент, или какой-нибудь идиот найдёт повод вырвать программиста из гармоничного творческого потока ради какой-нибудь безумно важной ерунды.
В поток всегда можно вернуться. Или вернуть. Нужна, правда, воля – и на возврат, и на поддержание. Зуд постоянного контроля работы программиста ведь не даёт покоя. Особенно тем, кто ничего в работе программиста на понимает.
