что, остановим часы на конвеере тайоты с ее бережливым производством?)
и только разрабы делают научный труд и все как один могут за денюжки ПМа оценить задачи пальцем в потолок. так и оценивайте, а то как виноват в сроках и увольняют, так ПМа. разрабы в этот момент как у Чуковского "под мосток и молчок")))
зависит от грунта, моего состояния, какая лопата, есть ли кирка, надо заложить риски что прихватит спину или еще чего.
это срок от 30 мин до 2 дней
и если всего этого не учел разраб при оценке эпика(фичи) мы с большой долей вероятности понятия не имеем, когда ее запилим. зато ЗП 10 числа все захотят в полном обьеме, не обращая сделана фича в срок или нет. а если контора делала фиче под кредит СЕО то продолжения тупо не будет
есть только занесенные часы? нет, с ними потом НИЧЕГО не сделать! епт ну читаем текст то.
если есть первоначальная оценка фичи в часах и потом фактически потраченные часы, да, можно посмотреть и если факт в 3 раза больше плана, есть смысл больше не связывать свои фичи с таким разрабом, пусть он с кем то другим интерполирует, если не может понять примитивов.
вы не поймете ответа, потому что в вашей картине мира есть только занесенные часы... и все))
ну почитайте ответы выше то.
часы дают профит если есть не только они, но и связи с целями, которые имеют оценку хоть в каких то числах. часы должны с чем то сравниваться на старте, на ходу и по завершению.
ну классика - метод освоенного обьема. любой проект FP так работает. пообещали эпик сделать через полгода ценой 2 человек? ну вот вам и часы бюджета этого эпика, трекинг будет позволять видеть сколько часов вы уже сьели из своего обещания (тупо в jira забираете оценки часов задач в эпике из самого эпика) - действует очень отрезвляюще))
но пока в голове "писать код - это искусство" то этого не понять(( ЗП то капает и откуда взять бабло это задача СЕО, пусть он и отдувается.
просто надо дальше развивать кругозор, и подумать "а зачем трекают?"
а затем чтобы знать сколько будут затраты, чтобы сравнить их с прибылью и решить а надо оно или не надо (выбрать правильное надо из нескольких вариантов)
только много ли вы видели задач в jira, где по саязям можно дойти до цели, посмотреть профит компании (и себя - премии например)?
и опана, оценку ты уже делаешь совсем с другим подходом;)
ну и классика таких статей - если эстимейтим задачи, то обязательно до минут и еще отчет каждый день в ворде. ну примите правило что минимальная оценка 1д, неужто так трудно в конце дня в задачу кликнуть за 30 сек часы.
что делает разработка описали, что делает поддержка описали, что должны делать SRE... упс, это "следующая ступень") а, ну сразу понятно стало)) ступень в овраг? ;)
просто это не РП, как говорил мой аналитик, они просто не в профессии. кто в РП идут? те кому не хватило ума быть разрабом, кого не взяли даже в тестировщики, изредка аналитики. но все это не менеджеры же.
я же сказал, РП поймет за 1-2 проекта, а остальные просто не менеджеры и никакие статьи им не помогут.
аналитик реально плохо составил тз, оба разраба вместо того чтобы остановится когда непонятно в каком формате передавать нафигачили код как вздумалось и решили это все ... введением коммуникации)))
боюсь у вас все трое оказались джунами и ваше "решение" прокачает остальных джунов до такого же уровня;)
ну да, и в первой цепочке забыли про существование тестирования требований.
работа токаря - точить, сборщика - собирать.
и чего к ним нормы по времени предьявляют)
что, остановим часы на конвеере тайоты с ее бережливым производством?)
и только разрабы делают научный труд и все как один могут за денюжки ПМа оценить задачи пальцем в потолок. так и оценивайте, а то как виноват в сроках и увольняют, так ПМа. разрабы в этот момент как у Чуковского "под мосток и молчок")))
я был по обе стороны барикад
а что, хочется быть безответственным исследователем в коммерческой конторе?
и часы защита от таких нахлебников, но я понимаю что им от этого больно)) все таки их денюжек чужих на халяву лишают))
ну да, управление требованиям никто не отменял.
правда те кто ноют про часы, требования обычно на входе хотят, еще и зафиксированные))
такие двойные стандарты
вопрос ни разу не прост
зависит от грунта, моего состояния, какая лопата, есть ли кирка, надо заложить риски что прихватит спину или еще чего.
это срок от 30 мин до 2 дней
и если всего этого не учел разраб при оценке эпика(фичи) мы с большой долей вероятности понятия не имеем, когда ее запилим. зато ЗП 10 числа все захотят в полном обьеме, не обращая сделана фича в срок или нет. а если контора делала фиче под кредит СЕО то продолжения тупо не будет
это примитивно автоматизируется в жире на основе статусов. но там есть риск, что не получится ровно 40 часов в неделю.
ну опять 25.
есть только занесенные часы? нет, с ними потом НИЧЕГО не сделать! епт ну читаем текст то.
если есть первоначальная оценка фичи в часах и потом фактически потраченные часы, да, можно посмотреть и если факт в 3 раза больше плана, есть смысл больше не связывать свои фичи с таким разрабом, пусть он с кем то другим интерполирует, если не может понять примитивов.
вы не поймете ответа, потому что в вашей картине мира есть только занесенные часы... и все))
ну почитайте ответы выше то.
часы дают профит если есть не только они, но и связи с целями, которые имеют оценку хоть в каких то числах. часы должны с чем то сравниваться на старте, на ходу и по завершению.
ну классика - метод освоенного обьема. любой проект FP так работает. пообещали эпик сделать через полгода ценой 2 человек? ну вот вам и часы бюджета этого эпика, трекинг будет позволять видеть сколько часов вы уже сьели из своего обещания (тупо в jira забираете оценки часов задач в эпике из самого эпика) - действует очень отрезвляюще))
но пока в голове "писать код - это искусство" то этого не понять(( ЗП то капает и откуда взять бабло это задача СЕО, пусть он и отдувается.
так менеджеры были выше такого качества, что толку от часов не могли показать. но причем тут вывод - вносить часы это плохо?
люди делают управление наполовину, ясен пень оно не работает, но вывод что первая половина от этого плохая - оно не от большого ума ))
просто надо дальше развивать кругозор, и подумать "а зачем трекают?"
а затем чтобы знать сколько будут затраты, чтобы сравнить их с прибылью и решить а надо оно или не надо (выбрать правильное надо из нескольких вариантов)
только много ли вы видели задач в jira, где по саязям можно дойти до цели, посмотреть профит компании (и себя - премии например)?
и опана, оценку ты уже делаешь совсем с другим подходом;)
ну и классика таких статей - если эстимейтим задачи, то обязательно до минут и еще отчет каждый день в ворде. ну примите правило что минимальная оценка 1д, неужто так трудно в конце дня в задачу кликнуть за 30 сек часы.
что делает разработка описали, что делает поддержка описали, что должны делать SRE... упс, это "следующая ступень") а, ну сразу понятно стало)) ступень в овраг? ;)
а еще они про манипуляцию не скажут))
просто это не РП, как говорил мой аналитик, они просто не в профессии. кто в РП идут? те кому не хватило ума быть разрабом, кого не взяли даже в тестировщики, изредка аналитики. но все это не менеджеры же.
я же сказал, РП поймет за 1-2 проекта, а остальные просто не менеджеры и никакие статьи им не помогут.
хорошо раскрыто, но ведь это понимаешь после пары проектов (то есть через 1-2 года) РПшства.
а если не понял, то там же грусть печалька и строго по треугольнику и пмбок тебе путь.
все всегда опускают кому нужен потом этот "опыт", который так лихо получается в аутсорсе?
правильно, в продуктовой команде))
потому что никто не хочет вечно менять проекты/команды и получать этот "опыт"
аутсорс это только минус, но хорош как точка входа, поэтому обе стороны понимают рассклады и одни довольны контролируемой текучкой, а вторые "опытом"
ищу статью про инжиниринг менеджера, думаю - о, годный вариант!
а внизу вижу свое упоминание. оказывается есть люди, которые нормально критику воспринимают)
я правильно понял суть, что весь код в мире пишут джуны?)
о, а у вас интересный профиль)
мало интереса к статье, чтобы тратить время и рисовать)
страница конфа -> скрипт -> компонент жира.
все, это вся диаграмма)
ну анкета и анкета, эти вопросы задаст любой кто понимает разработку ПО.
а если не понимает, то даже если и задаст, то не поймет смысла и что делать с ответами.
в чем смысл то писать а без б?)
аналитик реально плохо составил тз, оба разраба вместо того чтобы остановится когда непонятно в каком формате передавать нафигачили код как вздумалось и решили это все ... введением коммуникации)))
боюсь у вас все трое оказались джунами и ваше "решение" прокачает остальных джунов до такого же уровня;)
ну да, и в первой цепочке забыли про существование тестирования требований.