Это говорит о чем? О том, что умение программировать на java еще не означает умение думать головой и анализировать. Это был фееричный исторический пример crapification, где тысячи "инженеров" обгадились.
А я всегда говорил фанатам микросервисной архитектуры: "Ребята, вы хоть один пример из реального мира (желательно природы) микросервисной архитектуры можете привести? Не можете! Так как эволюцией и временем доказано что микросервисная архитектура не жизнеспособна сама по себе и проигрывает монолитам." Есть примеры в природе взаимодействия монолитов, но микросервисов нет!
Правильно, что главное это люди. В феодальной системе трудовых отношений без людей ничего не получится и даже более того любое самодурство любого менеджера тоже может быть реализовано только людьми, сам по себе менеджер ни на что не способен и никакой прибавочной стоимости не создает.
Танцы с бубном будут всегда если вы начинаете искажать реальность и пытаться заставить систему делать тоже самое. Никто никогда не делает паралельно две задачи. Система должна запрещать одновременно иметь более одной задачи в статусе In progress... Вы серьезно думаете, что систему автоматического учета времени невозможно сделать ? И что рутинное ручное заполнение трекера, таймшита, их синхронизация и т.д. гораздо менее затратно для разработчика. А если еще учесть что при ручном заполнении данные могут умышленно искажаться?
В календаре все совещания отмечены заранее до конца проекта, т.к. они часто повторяются, например дейли митинг, новые вносятся проджект менеджером а не разработчиком, поэтому трекать практически ничего не придется.
В вашем примере все зависит от того момента когда вы запушаете пул-риквест каждой задачи. Если запушаете оба пул риквеста в конце, то каждая задача спишет полтора дня и 1,5 часа. Если хотите чтобы маленькая задача списала мало времени то делайте ее первой и сразу пушайте пул-риквест, тогда она спишет три часа.
Все отмечается в календаре, все совещания, больничные, их продолжительность, вся информация должна браться из календаря (Microsoft Outlook например). ... По поводу нескольких паралельных задач на одного разработчика : все просто, списанное время для каждой паралельной задачи определяется по формуле ( на примере 2х задач):
Ваши оба довода никак не мешают списывать время автоматически в момент апрува пул-риквеста, т.е. назначили на разработчика задачу - таймер начал тикать, заапрувили пул риквест - таймер остановился и время списалось. Это касается всего и багов в том числе. Или тут есть какая-то проблема?
Это какой-то позор, что в IT-сфере, которая занимется автоматизацией, списание времени до сих пор остается не автоматизированным а ручным процессом. Прям как сапожник без сапог! Все трудозатраты стангвятся известны на этапе планирования задач, а списание должно проходить когда пул-риквест заапрувили и запушали в репозиторий и все.
Как так получается, что на проекте есть бизнес-аналитик, но при этом, как вы сказали: "считанные люди знают как всё устроено с точки зрения бизнеса.". Он что, на работу не ходит, или ходит но от него мало пользы, и значит я прав?
Думвю что с увеличением налога на прибыль с 2025 весь этот "налет" ввиде всех этих непонятных должностей, возникший из-за избытка денег, будет постепенно слетать и в компаниях скоро снова будут работать только программисты, как в нулевых
Сколько же паразитов развелось вокруг программистов, а ведь все они не создают добавленную стоимость, т.к. не пишут программный код. Я не против чтобы они были, но их труд не должен стоить дорого, т.к. в нем мало пользы (их функции легко сможет выполнить сам программист)
Отсутствие документации создает доп нагрузку и требования. Дошло до того, что стали требовать софт скилы от технарей!!! Более уродливого сценария сложно было представить!
Если в компанию приходит глухонемой разработчик, умеющий читать и писать, и он способен сразу начать писать код и приносить пользу, то в такой компании с документацией все в порядке. Если нет, то с документацией беда. Мало компаний способны пройти "тест глухонемым разработчиком" и вот почему: Документация обнуляет много крикливых паразитов на проекте, чья значимость сильно раздута. Эти паразиты не могут этого позволить и поэтому всячески препятсвуют созданию качественной документации.
Как раз таки я прекрасно понимаю, что PM не создают никакой дрбавленной стоимости. Должность PM надо переименовать в "Бухгалтер проекта" но никак не менеджера.
Считаем, что PM - это бездельники ничего не делающие, что даже эникейщики могут выполнять их функции и прочие случайные люди, например гуманитарии, не знающие таблицы умножения и никогда не видевшие компьютера. Тим лид должен быть руководителем, а PM должен быть в разряде обслуживающего персонала с зарплатой в разы меньше чем у программистов.
Если человек не пишет код проекта хотя бы пару часов в день, то он не имеет права быть менеджером этого проекта, в противном случае он будет только всех раздражать.
Это говорит о чем? О том, что умение программировать на java еще не означает умение думать головой и анализировать. Это был фееричный исторический пример crapification, где тысячи "инженеров" обгадились.
А я всегда говорил фанатам микросервисной архитектуры: "Ребята, вы хоть один пример из реального мира (желательно природы) микросервисной архитектуры можете привести? Не можете! Так как эволюцией и временем доказано что микросервисная архитектура не жизнеспособна сама по себе и проигрывает монолитам." Есть примеры в природе взаимодействия монолитов, но микросервисов нет!
Существуют.
Правильно, что главное это люди. В феодальной системе трудовых отношений без людей ничего не получится и даже более того любое самодурство любого менеджера тоже может быть реализовано только людьми, сам по себе менеджер ни на что не способен и никакой прибавочной стоимости не создает.
Танцы с бубном будут всегда если вы начинаете искажать реальность и пытаться заставить систему делать тоже самое. Никто никогда не делает паралельно две задачи. Система должна запрещать одновременно иметь более одной задачи в статусе In progress... Вы серьезно думаете, что систему автоматического учета времени невозможно сделать ? И что рутинное ручное заполнение трекера, таймшита, их синхронизация и т.д. гораздо менее затратно для разработчика. А если еще учесть что при ручном заполнении данные могут умышленно искажаться?
В календаре все совещания отмечены заранее до конца проекта, т.к. они часто повторяются, например дейли митинг, новые вносятся проджект менеджером а не разработчиком, поэтому трекать практически ничего не придется.
В вашем примере все зависит от того момента когда вы запушаете пул-риквест каждой задачи. Если запушаете оба пул риквеста в конце, то каждая задача спишет полтора дня и 1,5 часа. Если хотите чтобы маленькая задача списала мало времени то делайте ее первой и сразу пушайте пул-риквест, тогда она спишет три часа.
Все отмечается в календаре, все совещания, больничные, их продолжительность, вся информация должна браться из календаря (Microsoft Outlook например). ... По поводу нескольких паралельных задач на одного разработчика : все просто, списанное время для каждой паралельной задачи определяется по формуле ( на примере 2х задач):
t1 = te1 / (te1 + te2) * tp, где
te - оценочное время задачи при планировании
tp - прошедшее время до пул-риквеста
Спишется так: Неделя минус длительность больничного и всех совещаний. В чем проблема?
Ваши оба довода никак не мешают списывать время автоматически в момент апрува пул-риквеста, т.е. назначили на разработчика задачу - таймер начал тикать, заапрувили пул риквест - таймер остановился и время списалось. Это касается всего и багов в том числе. Или тут есть какая-то проблема?
Это какой-то позор, что в IT-сфере, которая занимется автоматизацией, списание времени до сих пор остается не автоматизированным а ручным процессом. Прям как сапожник без сапог! Все трудозатраты стангвятся известны на этапе планирования задач, а списание должно проходить когда пул-риквест заапрувили и запушали в репозиторий и все.
Как так получается, что на проекте есть бизнес-аналитик, но при этом, как вы сказали: "считанные люди знают как всё устроено с точки зрения бизнеса.". Он что, на работу не ходит, или ходит но от него мало пользы, и значит я прав?
Думвю что с увеличением налога на прибыль с 2025 весь этот "налет" ввиде всех этих непонятных должностей, возникший из-за избытка денег, будет постепенно слетать и в компаниях скоро снова будут работать только программисты, как в нулевых
Сколько же паразитов развелось вокруг программистов, а ведь все они не создают добавленную стоимость, т.к. не пишут программный код. Я не против чтобы они были, но их труд не должен стоить дорого, т.к. в нем мало пользы (их функции легко сможет выполнить сам программист)
Отсутствие документации создает доп нагрузку и требования. Дошло до того, что стали требовать софт скилы от технарей!!! Более уродливого сценария сложно было представить!
Если в компанию приходит глухонемой разработчик, умеющий читать и писать, и он способен сразу начать писать код и приносить пользу, то в такой компании с документацией все в порядке. Если нет, то с документацией беда. Мало компаний способны пройти "тест глухонемым разработчиком" и вот почему: Документация обнуляет много крикливых паразитов на проекте, чья значимость сильно раздута. Эти паразиты не могут этого позволить и поэтому всячески препятсвуют созданию качественной документации.
Это эффект низкой базы, если бы З/П на старте была еще ниже, рост был бы гораздо больше, например в 10-20 раз.
Как раз таки я прекрасно понимаю, что PM не создают никакой дрбавленной стоимости. Должность PM надо переименовать в "Бухгалтер проекта" но никак не менеджера.
Никак
Считаем, что PM - это бездельники ничего не делающие, что даже эникейщики могут выполнять их функции и прочие случайные люди, например гуманитарии, не знающие таблицы умножения и никогда не видевшие компьютера. Тим лид должен быть руководителем, а PM должен быть в разряде обслуживающего персонала с зарплатой в разы меньше чем у программистов.
Если человек не пишет код проекта хотя бы пару часов в день, то он не имеет права быть менеджером этого проекта, в противном случае он будет только всех раздражать.