Comments 24
Примерно такой же подход мы применяли в работе на одного американского заказчика. К моменту когда задача в Jira доходила до программиста уже были подготовлены все требования, условие приёмки и иногда даже интеграционные тесты. Задачи на программистов раскидывал менеджер. Те должны были при поступлении задачи в течении 10 минут оценить трудоёмкость в часах. После того как все задачи в рамках релиза были распределены специальный скрипт сообщал стоимость релиза в часах менеджеру, а тот отдавал сведения заказчику, который принимал решение пилить релиз или нет, зная его стоимость.
Так как продукты были однотипными мы создали шаблоны тикетов в Jira в виде дерева. Корень - непосредственно релиз, потом идут тикеты на деплой, ниже - QA и разработка. Был даже специальный плагин который рисовал дерево релиза в виде графа, раскрашивая тикеты разными цветами в зависимости от проделанной работы, чтобы менеджер мог сразу оценить где затык.
У менеджера была специальная консоль (самописная на QT) где он мог поднимать приоритет задачи или переназначать её на другого сотрудника. У каждого сотрудника было приложение в трее которое показывало именно ту задачу над которой нужно работать в данный момент. К примеру, сломал программист ногу - менеджер тут же переназначал его задачи на других и информировал заказчика о смене даты выхода релиза с учётом уменьшения ресурсов.
Было очень круто и технологично.
Так и представляю взял задачу на 6-8 часов, начал разбиратся, погружатся, и через 3 часа уведомление в трее, бросай эту задачу и хватайся за другую... Выглядит очень технологично))
Тут бы подошло выражение "Коней на переправе не меняют". И логичным было бы менять следующую задачу, а не текущую.
А бывают ещё безумные менеджеры которые могут менять задачи каждый час создавая видимость своей работы.
В общем, этот кейс подходит явно не всем и только при жестких ограничениях.
Ну если менеджер назначил вам одну задачу, а потом резко поменял на другую и это снизило вашу продуктивность, это проблема менеджера. Это же он решает что важнее сейчас для продукта. Да?
Некоторые решения руководителей выглядят не совсем логично и технологично.
Как в известном анекдоте про ватерполистов. Тренер игроку кричат снова и снова: "Отдай мяч Васе! Отдай мяч Васе!!!" В конце концов радостный игрок удивляется, что его ругают: "Но я же гол забил!" В ответ ему: - "Ты гол забил, а Вася утонул..."
Так и представляю взял задачу на 6-8 часов, начал разбиратся, погружатся, и через 3 часа уведомление в трее, бросай эту задачу и хватайся за другую...
Именно так. Заказчику понадобилось демо на выставку через неделю и он сказал - бросайте всё пилите демо. Его право и его деньги.
Наш продукт кстати продавался в Walmartе и прочих супермаркетах. Бесплатная телефония по всему США, только абонентская плата 25 баксов в год.
Потом правда заказчик продал бизнес и нас всех уволили, но это уже другая история.
Было бы очень интересно посмотреть на эту консоль. Утомившись от поиска подходящих плагинов, я тоже реализовал самописный дашборд с помощью которого разруливаются приоритеты и сроки на наших проектах. О нем я планирую рассказать в следующей статье.
planfix? @aimfirst
время - деньги
не считаем время - не считаем деньги
"Когда создавали программное обеспечение для лунной программы NASA, программисты видимо умели правильно работать. "
всё очень просто - они рассчитывали орбиты, моменты инерции и дельта в. Поскольку менеджеры ничего в этом не понимают, они не вмешивались.
Когда программируют опердени, менеджеры заказчика и подрядчика принимают живейшее участие в процессе разработки, и всё идет по ... худшему сценарию.
Правила нашей удаленки подразумевают, что с 9.00 до 18.00 сотрудники должны быть готовы:
Какая жесть. Даже во времена офисной работы не было такого "окна". Обычно выбиралось что-то вроде "12-16" обязательные часы присутствия. Кто-то любит приходить рано, а кто-то поспать или сходить в бассейн, пока людей мало.
И да - недостаточно 30 минут чтобы "сходить в магазин". Максимум - забежать в ларек (или что-то типа пятерочки, если есть рядом), схватить что-то резко понадобившееся.
При учете времени неизбежно станет вопрос - а соответствует ли результат работы отмеченному времени? Как вы его будете решать? Если вы умеете оценить результат работы и сказать соответствует затраченному времени или нет - то зачем отмечать время, ведь вы из результата сможете все понять. Если не умеете - тогда тем более зачем отмечать время, все-равно не сможете сказать много это или мало.
Основная проблема отмечания времени - это выводит из потока. Я работаю пока работается и боюсь выйти из этого состояния потока. Бывает что пока не отрублюсь. Именно в такие моменты успеваю сделать очень много. Устроит ли вас, если я будут прилежно отмечать время, но результат работы будет в 2-3 раза медленнее?
Таймтрекинг необходим для понимания руководителем проекта каким ресурсом времени он располагает. При таймтрекинге он оценивает этот ресурс глазами исполнителя. При этом в моменте оценка соответствия результатов работы затраченному времени неважна. Важно сколько времени нужно именно этому исполнителю для завершения задачи. При нехватке ресурса надо предпринимать управленческие телодвижения. Оценка соответствия результатов работы затраченному становится видна, если рассматривать эти результаты за достаточно продолжительный период. О своих способах оценки результатов отдельного сотрудника надеюсь рассказать в одной из последующих статей.
Вывод из потока - согласен на все 100%. Для снижения фактора выбивания из потока при учете трудозатрат взамен типовой формы регистрации JIRA придуман другой способ о котором я планирую рассказать прамо в следующей статье.
Однако в статье нигде не написано, что при регистрации времени я настаиваю на отчетности каждый час. Я стараюсь вмешиваться в процесс работы своих коллег только если есть такая необходимость. Мне достаточно чтобы эти сведения оказались в JIRA до очередного ежедневного совещания. Полагаю, что настоящего джедая не выбьет из потока необходимость оценки потраченного времени один раз в сутки.
Таких эффективных менеджеров: *** да в музей . Сотрудник должен работать головой, а не 12 часов. Все эти попытки надзирать , никогда хорошим не кончились
Вечная дискуссия о "палке о двух концах"...
Я участвовал на проектах без какого-либо управления от менеджеров, в команде с первоклассными разработчиками. По итогу, в системе было сделано просто дофига классных фич, разработчики гордились своем творением. К сожалению, из-за неконтролируемой работы вне скоупа заказа, маржинальность проекта стремилось к нулю, пока проект не перерос в разряд "репутационно-инвестиционных." Это был не первый такой "успешный" проект и по итогу отдел пришлось расформировать как убыточный.
Были и другие проекты, где, казалось, число менеджеров-контролёров было буквально сопоставимо с числом разработчиков. За год из команды в 15 человек - 10 разрабов ушло и столько же было нанято на их место. Люди выгорали и впадали в экзистенциальный кризис. Но заказчик был счастлив, и при сдачи проекта, все получили свои премии. Но почему то у разработчиков осталось горькое послевкусие...
О чем это может говорить ? Успешный проект - это не то же самое, что успешный продукт.
Можно понять и менеджера и разработчика.
Менеджер хочет наивысшую возможную маржинальность проекта - бабло, выражаясь проще. Это его работа.
Разработчик хочет интересных, развивающих задач. Разве можно его за это судить ?
Но если разработчик начинает чувствовать зудение в пятой точке от того, что его слишком контролируют, стоит задаться вопросом - "а откуда у работодателя денюшка на мою зарплату ?". У большинства зуд сразу приутихнет. Остальные скажут "Да этот менеджер самодур, дует тут щеки на проекте для важности!" ОК. "Даже если вас съели существует два выхода"(с). 1.Пишем письмо руководителю\внутренней службе HR с таким содержанием: "считаю действия данного сотрудника контрпродуктивными для проектной деятельности, вот столько косяков за этим менеджером было мною подмечено и вот последствия." Далее описываете свои предложения по улучшению рабочего процесса. Поверьте - если у вас будет достаточно аргументов - как минимум к этому управленцу будут очень неудобные вопросы от начальства. На моем опыте, так удалось освободить отдел от одного руководителя с крайне истеричным методом управления.
2. Никто вас слушать не хочет. Либо вам впадлу продвигать свои идеи. Тогда просто ищите себе новое место работы.Так я тоже делал, оставляя теперь уже бывших коллег жить счастливо в их болоте.
Смешно и грустно читать такие статьи. "Все не так однозначно, у всех сторон есть свои аргументы" — нет, аргументов нет. Надзирательство с палкой мало того что неэффективно, так ещё и отпугивает нормальных сотрудников. Я лучше на зарплату в 2 раза меньше пойду, но с творческой свободой, чем в цирк с трекингом. Но вот интересно, обычно галеры с трекингом платят ещё и меньше чем нормальные фирмы. Вроде парадокс, но при этом наблюдаемый и подтвержденными многоими факт.
Что до неправильных программистов современности и правильных из наса — давайте сравним временные и финансовые бюджеты программы апполон и продукта который нам интересен и все внезапно встанет на свои места.
Смешно и грустно видеть, как читатели в комментариях приводят «цитаты» которых нет в тексте статьи, а потом начинают их критиковать. В статье нет ни слова о палке. В статье нет ни одного слова об ограничении творческой свободы. В статье нет призывов использовать этот подход везде и всюду. Совсем наоборот.
Никто не спорит, что скрипки Страдивари гораздо лучше, чем фабричное изделие. Никто не спорит, что Страдивари за свои скрипки получал денег гораздо больше, чем мастер на фабрике струнных музыкальных инструментов. Не вижу парадокса. Только вот статья не об искусстве изготовления скрипок.
Это статья о некоторых гранях ремесла управления производством скрипок. В условиях той команды, которая есть здесь и сейчас. В условиях фиксированного бюджета. В условиях не вами согласованных сроков. Эта статья о поиске путей, как в этих имеющихся условиях своевременно достигать целей проекта наименее болезненными способами. И о том, как на нашей фабрике научиться делать продукты, если и не Страдивари, но хотя бы на уровне Crafter или Yamaha...
И кстати, финансирование программных проектов, которые сравниваются в статье, на мой взгляд, было соизмеримо. Деньги конечно важны. С этим никто и не спорил. Однако, насколько они важны? Я раньше думал, что если российский футбол финансировать на мировом уровне, все внезапно встанет на свои места. Ну стали игроков финансировать на мировом уровне... И что изменилось?
Я сейчас активно работаю с ребятами из галер. Кстати сказать, работают все хорошо.
Так вот. Трекаем фиктивную задачу, чтобы вот такие начальнички себе заносили. А в реале - работают, как нормальные люди, над задачей, а не над будильником. Эффективно, с самоотдачей
Заунывно это всё. Сочувствую людям работающим в такой среде - с таким отношением и эффективным проектным менеджментом.
С чем-то соглашусь, с чем-то нет, но юмор с отсылками на разные источники в статье мне очень зашёл
Следующим этапом будет озарение, что люди в процессе - со всеми своими особенностями - это не аномалия, а часть процесса, которую следует учитывать в первую очередь. А их время - это уже производная : )
Рабочее время: кошелек или жизнь?