Да, известная проблема. Поэтому лучше оценивать относительный объем (например, в поинтах или идеальных днях), а потом считать сколько сделано работы в неделю или за спринт, чтобы прогнозировать сроки.
У меня сейчас на это уходит ну максимум 5 минут в день. По хорошему ещё меньше.
Это вот прямо настолько нерационально с точки зрения фирмы?
Если умножить 8 человек команды на 5 минут в день, то это выходит больше 3х часов в неделю. Мне, как руководителю, нужно 10 минут, чтобы посмотреть, сколько человек вообще в команде — и это мне даст достаточно информации о принятии решений по проекту. Поэтому не рационально.
С чего вы это решили?
Подсказывает многолетний опыт на позициях от разработчика до директора в разных компаниях и общение с другими директорами и менеджерами.
Котоой тоже кто-то должен заниматься.
Я имею ввиду планы по тому, кто на каком проекте будет работать. Такое в любом случае, конечно, нужно. Особенно, если приходится часто переключаться между проектами.
Просто не рационально тратить время множество работников на треканье времени, поскольку работники трекают часы с точностью до часа или дня.
Руководство, как правило, не интересует масштаб часов и даже десятков часов. Руководство интересует масштаб сотен и, скорее, тысяч часов (нормальная команда 6-8 человек за месяц легко тратит на проект тысячу часов). А на таком масштабе уже можно не менее точно прикинуть в FTE.
Если же разрешить работнику трекать часы с меньшей гранулярностью, чтобы он не тратил на это лишнее время и мораль, то тут встаёт вопрос зачем, если итак можно табели в бухгалтерии посмотреть, у кого когда были отпуск или больничный. Или таблицу распределения по проектам, если нужна разбивка по проектам.
Статистики в числах нет. Есть 17 лет опыта заказной и 3 года продуктовой разработки, и то, что рассказывают коллеги из разных компаний.
А кто-то где-то утверждал что это невозможно? И что жёсткий тайм-трекинг необходим именно для того чтобы успешно делать проекты?
В статьте я пишу про то, что в компаниях, которые начинают с аутсорса, бывает так, что привычка трекать время настолько глубоко укореняется, что руководство слишком многое оценивает через призму потраченных часов, теряя при этом общую картину хода проекта.
Конечно, так происходит не везде и не всегда. Статья писалась для тех, кто чувствует, что с тайм-трекингом что-то не так, но не знает как с этим быть.
Так исторически сложилось, что добавленная работа растет вниз на графике. Раньше там ещё были линии тренда, и тогда они показывали своим пересечением на каком сроке сойдется проект. То есть расстояние между синим и красным графиком показывает сколько на данный момент осталось работы.
Я подумал над этой проблемой. Я хочу оставить её решение за рамками этой статьи.
Начальная задача была сделать из императивного компонента декларативный. И сейчас компонент работает аналогично декларативным нативным компонентам, таким как, например, <input />. У них если не контролировать onChange в родителе, то также value будет присваиваться только при ре-рендеринге родителя.
Это не совсем соответствует идеальной декларативности. Но до идеала, наверное, и не добраться, т.к., например, если пользователь нажал внутри плеера stop, а мы программно заставим его вернуться на то же место и играть дальше, то видео всё равно успеет "дёрнуться". Поэтому, я думаю, здесь уже надо отталкиваться от бизнес-задач и конкретной реализации плеера.
Если я на практике столкнусь с тем, чтобы нужно было в нашей обёртке контролировать бизнес-логику, то, может быть, напишу продолжение.
Работать будет. Но вы правы в том плане, что когда видео доиграет до конца, оно не начнёт проигрываться заново. Для этого более тонкая логика нужна в VideoPlayer.
Спасибо! Дополнил. Хотя, преимущество использовать ref для этого не совсем понятно. Разве что то, что ref-ы документация React считает "окном" в императивную работу с DOM.
А вы читали Глеба Архангельского "тайм-драйв"? У него есть понятие хроносных и кайросных задач. Хроносные привязаны ко времени, их надо размечать в календаре. Кайросные - не надо, потому что замучаешься оценивать их и переносить изо дня в день.
Непонятно, как деструктуризация относится к описываемой проблеме. Без деструктуризации, при передаче props.images ?? [] было бы то же самое. И, наоборот, с деструктуризацией, но если можно передать, например, undefined в качестве images, то проблемы нет.
Когда пользователям даешь новую фичу с богатым функционалом и простором для воображения, всегда есть период, когда фича используется как попало. По-идее, со временем народ вырабатывает какой-то свой подход ее использования.
Но! Есть опасность, что ее начнут использовать совсем уж не по назначению. Как например было с отличным проектом Google Wave — народ стал пользоваться вложенностью и возможностю сворачивания комментариев в Wave и плодить километровые волны. А разработчики все-таки рассчитывали, что волны будут примерно похожи на почтовую переписку. В итоге проект провалился, хотя ему прочили заменить все виды письменного общения (почта, чаты, вики).
Т.о. первый вывод: нужно давать пользователям понять, для каких именно случаев разработчики все-таки ввели эту фичу. Может быть не давать общие названия, типа «подзадача». А конкретные: задачи первого уровня — проекты, второго — системы, третьего — подсистемы и т.д. Например, чтобы эти названия можно было настраивать админу достаточно гибко, но система уже заставляла народ использовать заданную структуру. Кажется такое есть в TrackStudio — они очень гордятся иерархичностью своей системы.
Вторая опасность: если каждый человек/компания выработает свой подход к использованию фичи, то дальнейшие фиче-реквесты по ее доработке будут очень разнообразными — т.к. каждый человек захочет ее «допиливать» в разные стороны — под то, под что он ее пытается приспособить.
Да, известная проблема. Поэтому лучше оценивать относительный объем (например, в поинтах или идеальных днях), а потом считать сколько сделано работы в неделю или за спринт, чтобы прогнозировать сроки.
Если умножить 8 человек команды на 5 минут в день, то это выходит больше 3х часов в неделю. Мне, как руководителю, нужно 10 минут, чтобы посмотреть, сколько человек вообще в команде — и это мне даст достаточно информации о принятии решений по проекту. Поэтому не рационально.
Подсказывает многолетний опыт на позициях от разработчика до директора в разных компаниях и общение с другими директорами и менеджерами.
Я имею ввиду планы по тому, кто на каком проекте будет работать. Такое в любом случае, конечно, нужно. Особенно, если приходится часто переключаться между проектами.
Просто не рационально тратить время множество работников на треканье времени, поскольку работники трекают часы с точностью до часа или дня.
Руководство, как правило, не интересует масштаб часов и даже десятков часов. Руководство интересует масштаб сотен и, скорее, тысяч часов (нормальная команда 6-8 человек за месяц легко тратит на проект тысячу часов). А на таком масштабе уже можно не менее точно прикинуть в FTE.
Если же разрешить работнику трекать часы с меньшей гранулярностью, чтобы он не тратил на это лишнее время и мораль, то тут встаёт вопрос зачем, если итак можно табели в бухгалтерии посмотреть, у кого когда были отпуск или больничный. Или таблицу распределения по проектам, если нужна разбивка по проектам.
Статистики в числах нет. Есть 17 лет опыта заказной и 3 года продуктовой разработки, и то, что рассказывают коллеги из разных компаний.
В статьте я пишу про то, что в компаниях, которые начинают с аутсорса, бывает так, что привычка трекать время настолько глубоко укореняется, что руководство слишком многое оценивает через призму потраченных часов, теряя при этом общую картину хода проекта.
Конечно, так происходит не везде и не всегда. Статья писалась для тех, кто чувствует, что с тайм-трекингом что-то не так, но не знает как с этим быть.
Так исторически сложилось, что добавленная работа растет вниз на графике. Раньше там ещё были линии тренда, и тогда они показывали своим пересечением на каком сроке сойдется проект. То есть расстояние между синим и красным графиком показывает сколько на данный момент осталось работы.
Интересно, они просто переписывают на нативе код ноды. Или алгоритмы тоже оптимизируют.
Я подумал над этой проблемой. Я хочу оставить её решение за рамками этой статьи.
Начальная задача была сделать из императивного компонента декларативный. И сейчас компонент работает аналогично декларативным нативным компонентам, таким как, например, <input />. У них если не контролировать onChange в родителе, то также value будет присваиваться только при ре-рендеринге родителя.
Это не совсем соответствует идеальной декларативности. Но до идеала, наверное, и не добраться, т.к., например, если пользователь нажал внутри плеера stop, а мы программно заставим его вернуться на то же место и играть дальше, то видео всё равно успеет "дёрнуться". Поэтому, я думаю, здесь уже надо отталкиваться от бизнес-задач и конкретной реализации плеера.
Если я на практике столкнусь с тем, чтобы нужно было в нашей обёртке контролировать бизнес-логику, то, может быть, напишу продолжение.
Теперь понятно, какой кейс вы имеете ввиду. Да, в статье не обрабатывается такой случай. Доработаю, спасибо.
Работать будет. Но вы правы в том плане, что когда видео доиграет до конца, оно не начнёт проигрываться заново. Для этого более тонкая логика нужна в VideoPlayer.
Спасибо! Дополнил. Хотя, преимущество использовать ref для этого не совсем понятно. Разве что то, что ref-ы документация React считает "окном" в императивную работу с DOM.
А вы читали Глеба Архангельского "тайм-драйв"? У него есть понятие хроносных и кайросных задач. Хроносные привязаны ко времени, их надо размечать в календаре. Кайросные - не надо, потому что замучаешься оценивать их и переносить изо дня в день.
Непонятно, как деструктуризация относится к описываемой проблеме. Без деструктуризации, при передаче props.images ?? [] было бы то же самое. И, наоборот, с деструктуризацией, но если можно передать, например, undefined в качестве images, то проблемы нет.
Спасибо за примеры. Кажется, CT работает аналогично CET. В CET аналогично, осенью час повторяется, а весной пропадает.
Это тоже отличный комментарий, и кому-то это может пригодится.
Но да, я при написании статьи решил это не указывать, т.к. мы, таким образом, запрещаем опциональные аргументы. Что, может быть, не так уж и критично.
Спасибо за ценное замечание, дополнил статью!
Но! Есть опасность, что ее начнут использовать совсем уж не по назначению. Как например было с отличным проектом Google Wave — народ стал пользоваться вложенностью и возможностю сворачивания комментариев в Wave и плодить километровые волны. А разработчики все-таки рассчитывали, что волны будут примерно похожи на почтовую переписку. В итоге проект провалился, хотя ему прочили заменить все виды письменного общения (почта, чаты, вики).
Т.о. первый вывод: нужно давать пользователям понять, для каких именно случаев разработчики все-таки ввели эту фичу. Может быть не давать общие названия, типа «подзадача». А конкретные: задачи первого уровня — проекты, второго — системы, третьего — подсистемы и т.д. Например, чтобы эти названия можно было настраивать админу достаточно гибко, но система уже заставляла народ использовать заданную структуру. Кажется такое есть в TrackStudio — они очень гордятся иерархичностью своей системы.
Вторая опасность: если каждый человек/компания выработает свой подход к использованию фичи, то дальнейшие фиче-реквесты по ее доработке будут очень разнообразными — т.к. каждый человек захочет ее «допиливать» в разные стороны — под то, под что он ее пытается приспособить.