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