Весьма символично, что они решили удовлетворить просьбы пользователей по роутеру, которые просили еще с версии 1.5 в версии 5.1 :-) как говорится не прошло и 20 лет.
Я могу вас в репу добавить... Дело в том что мы сейчас очень далеко от joomla. Лично я все больше даже от php и программирования так такового отдаляюсь.
Скорее всего вы просто попадаете под авто-фильтры на hh. Но как человек, которому доводилось разбирать вакансии с hh могу сказать, что большая часть соискателей отчасти сами виноваты:
Ни кто не разбирается чего там недописал соискатель. Если резюме плохо написано (плохо это просто списко фирм где работал), то скорее всего его закроют.
Сильно много текста не по делу могут недочитать.
Не релевантный опыт вакансии, тоже весьма вероятно, что закроют.
Плюс очень многое зависит скажем от языка программирования. Питонистов пачками после курсов (если интересно то на последнюю вакансию питониста было откликов на hh +800 за месяц), там все по косой читают. А скажем go там откликов меньше, читают внимательно.
Для пользователя отличие joomla 4 и joomla 5 минимум... А вот для хостеров и для владельцев сайтов на шаредах это проблема. Так как joomla 5 отказалась от устаревших версий php и mysql. Собственно по этому она и joomla 5, а не joomla 4.5.
На самом деле тут интересный момент. Я вообще слабо представляю, как жить в разработке по, на текущих заказах. Все кто более менее долго работают... они как правило имеют 2-5-10 якорных клиентов, которые обеспечивают 50-70% загрузки. Жить на потоке в этом деле очень сложно, и как раз тогда то и возникают кассовые разрывы, фекапы менеджеров и прочее.
Ооо... вы ещё многого не ощутили :-) как только вы откроете приточно - вытяжную вентиляцию, да ещё и с рекуператором тепла, вы откроете для себя новый уровень автоматизации :-)
Я взял многоквартирник в пример. Потому, что там без проекта полного невозможно построить, что-то причем полного. Вы не сможете без него ничего рассчитать и у вас очень ярко проявится факторы: я думал, я так всегда делал, да вы ничего не понимаете. И вам не поможет, то что у вас мега опытные рабочие и прорабы... :-) так как весь процесс не будет помещаться в одну голову. Ну и собственно на стройке идёт именно итеррационная разработка, по полному проекту. Сами рабочие не знают на кой эта работа нужна и как этот узел который они сейчас заливают отразится на всем здании.
Угу особенно учитывая, то что обычно закрытие задачи зависит минимум от двух людей. От постановщике и исполнителя. То есть если постановщик недоработал, то исполнитель пожертвовал своими выходными :-)
Про команду гениев у меня тоже сложилось мнение. Опять же мы не знаем сколько участников процесса разработки и сколько команд работает. Может быть у нас 3-5 человек и все. И там все это отлично работает, а другой вопрос, как это распространить на скажем 30-50 человек и скорее всего невозможно на 500 человек.
Тут про другое когда цена ошибки высока, допустим как в строительстве ее уже нельзя исправить на последующем этапе. Это области которые касаются аппаратно программных платформ, почти вся промышленная разработка и прочее, где нельзя вернуться на предыдущий этап и подкрутить... Грубо говоря нельзя такие подходы представить в области строительства самолётов :-) точнее они были таковыми, но на начальных этапах, сейчас ждать пока самолёт упадет с пассажирами недопустимо.
Из моего опыта все же работают комбинированные подходы, когда нам ясны процессы, но не проработаны до деталей, они и становятся нашим первоначальным ТЗ. Потом когда мы уже опускаемся на уровень реализации действий, мы уже делаем итерации иногда настолько мелкие, что задача может для разработчика составлять 1-3 дня. Таким образом мы можем прогнозировать, что она завершится в обозримые сроки, он ее поймет и даже если постановщик накосячил цена ощибки будет минимальная. Когда мы нарезаем задачи даже в 5 дней, уже возникают проблемы с прогнозами реализации задачи.
Собственно для этого и нужны аналитики, чтоб собирать пазлы.
Давайте по другому рассмотрим вопрос на примере дома. Можно ли дом построить без проекта? Частный жилой дом, да наверное можно. Многоквартирный - невозможно.
Давайте смотреть на разработку ПО. Можно ли написать по которое реализует бизнес процесс не понимая как он работает? Да можно... но вы будете всегда возвращаться на несколько шагов назад, чтоб что-то подкрутить, что то исправить, что то доработать, так как тут мы несли что в этом справочнике нужны такие данные, тут нам надо получить данные из других систем потому, что мы не знали, что они нужны вообще, мы о такой системе даже не знали. На выходе может получится Франкенштейн. Работать будет, возможно, но не факт, что хорошо. Теперь представим что мы делаем какую нибудь систему которая объединяет много бизнес процессов:-) вот тут мы сталкиваемся с тем, что цели ещё более размыты, а иногда при итерационной разработке даже толком и не известны. И вам надо паралельно разработать 5 таких процессов. Знаете какая боль будет? А ведь там менеджеры проекта могут даже не задать вопрос зачем это мы делаем. Я видел как до 50% конечного продукта после этого выкидывалось, хотя тут надо сказать и видел как продукты разработанные по ТЗ выкидывались. Но тут суть не в этом в результате мы можем получить какую то кашу, которая неизвестно как работает и неизвестно отвечает ли настоящим требованиям заказчика.
Вы гении :-) либо чего то очень сильно не договариваете. Если бы я не участвовал и не был свидетелем нескольких сот проектов я бы может и поверил :-) не бывает такого, чтоб не переделывали...
При таких подходах заказчик ищет правильный путь путем экспериментов, то есть он сам не знает конечный результат. А значит вы приходите на сессию скажем с начальником отдела, он вам говорит одно, потом при проверке выясняется, что нужно было другое, это по ТЗ то регулярно происходит. А в таких процессах разработки просто могут сказать, мы тут подумали и решили, что надо все по другому. Делаем вот так. Я даже могу сказать почему, потому что заказчик не скован конечными требования, и полет фантазии обычно не ограничен, плюс не заставляет его выяснять на первых этапах, как работает тот или иной процесс. Это с одной стороны не плохо, позволяет быстро сделать mvp и проверить гипотезу с другой стороны часто ведёт к растягиванию разработки и ухудшает качество кода.
Хех... а вы пробовали без ТЗ автоматизировать хоть, сколько нибудь сложный бизнес процесс. На самом деле тз нужно заказчику, чтоб понять, что он хочет. На этапе проработки задания, как правило задача аналитика утрясти процесс не только для разработчиков, но и для клиентов. Для примера: Как звучит процесс для руководителя бизнеса. Мы получаем прибыль с продажи. Для отдела логистики. Мы отправляем грузы по складам и заказчикам. Для отдела скажем продаж. Мы выполняем планы по продажам. И так далее в зависимости от того, куда вы придёте у всех будет разное виденье процессов и скорее всего ни один человек в компании не будет знать, как в реальности продается товар. Все видят свою маленькую часть, ньансов смежников могут не знать, а часто они вообще не представляют, что творится у его же сотрудника за соседним столом.
И вот вы такие пришли хорошие и сделали как вам сказал скажем начальник отдела продаж... а потом выяснилось, что интересы других вы не учли вообще... и да вы быстро сделали молодцы :-) но потом 10 раз переделали. Я просто сейчас наблюдаю, как менеджеры бьются за сокращение проработки заданий на разработку, но экономя 10% времени, они часто тратят +100% времени разработчика. За то да шороху наводят знатного... И ещё чем меньше по объему задача, тем она как правило понятнее и прогнозируемая по времени исполнения... но чтоб эту задачу декомпозировать на много мелких... нужно понимание общей задачи. Опять же судя по всему вы решаете достаточно типовые для вас задачи, в таких случаях может быть и прокатывает.
Проблема низко скила даже не в этом. Он часто даже не понимает, что есть хорошо.
Мы всегда просим кандидата и нам иногда присылают такой ужасный код, что дальше говорить бессмысленно. Так как человек даже не понимает, что это стыдно показывать.
Вкусный :-) для роутера... Это как 10ти летний коньяк :-)
Весьма символично, что они решили удовлетворить просьбы пользователей по роутеру, которые просили еще с версии 1.5 в версии 5.1 :-) как говорится не прошло и 20 лет.
Я могу вас в репу добавить... Дело в том что мы сейчас очень далеко от joomla. Лично я все больше даже от php и программирования так такового отдаляюсь.
Всегда радуюсь, когда вижу, что вышел дайдест по Joomla. Сейчас редко Joomla касаюсь, но интересно порой почитать, что происходит в этой сфере.
Скорее всего вы просто попадаете под авто-фильтры на hh.
Но как человек, которому доводилось разбирать вакансии с hh могу сказать, что большая часть соискателей отчасти сами виноваты:
Ни кто не разбирается чего там недописал соискатель. Если резюме плохо написано (плохо это просто списко фирм где работал), то скорее всего его закроют.
Сильно много текста не по делу могут недочитать.
Не релевантный опыт вакансии, тоже весьма вероятно, что закроют.
Плюс очень многое зависит скажем от языка программирования. Питонистов пачками после курсов (если интересно то на последнюю вакансию питониста было откликов на hh +800 за месяц), там все по косой читают. А скажем go там откликов меньше, читают внимательно.
Для пользователя отличие joomla 4 и joomla 5 минимум... А вот для хостеров и для владельцев сайтов на шаредах это проблема. Так как joomla 5 отказалась от устаревших версий php и mysql. Собственно по этому она и joomla 5, а не joomla 4.5.
Честно не смог все прочитать в один присест. Снимаю шляпу за труд.
На самом деле тут интересный момент. Я вообще слабо представляю, как жить в разработке по, на текущих заказах. Все кто более менее долго работают... они как правило имеют 2-5-10 якорных клиентов, которые обеспечивают 50-70% загрузки. Жить на потоке в этом деле очень сложно, и как раз тогда то и возникают кассовые разрывы, фекапы менеджеров и прочее.
Ооо... вы ещё многого не ощутили :-) как только вы откроете приточно - вытяжную вентиляцию, да ещё и с рекуператором тепла, вы откроете для себя новый уровень автоматизации :-)
Я взял многоквартирник в пример. Потому, что там без проекта полного невозможно построить, что-то причем полного. Вы не сможете без него ничего рассчитать и у вас очень ярко проявится факторы: я думал, я так всегда делал, да вы ничего не понимаете. И вам не поможет, то что у вас мега опытные рабочие и прорабы... :-) так как весь процесс не будет помещаться в одну голову. Ну и собственно на стройке идёт именно итеррационная разработка, по полному проекту. Сами рабочие не знают на кой эта работа нужна и как этот узел который они сейчас заливают отразится на всем здании.
Честно мое мнение, что лучше бы новую статью написал :-) и перекрёстным ссылками соединил.
Угу особенно учитывая, то что обычно закрытие задачи зависит минимум от двух людей. От постановщике и исполнителя. То есть если постановщик недоработал, то исполнитель пожертвовал своими выходными :-)
Про команду гениев у меня тоже сложилось мнение. Опять же мы не знаем сколько участников процесса разработки и сколько команд работает. Может быть у нас 3-5 человек и все. И там все это отлично работает, а другой вопрос, как это распространить на скажем 30-50 человек и скорее всего невозможно на 500 человек.
Тут про другое когда цена ошибки высока, допустим как в строительстве ее уже нельзя исправить на последующем этапе. Это области которые касаются аппаратно программных платформ, почти вся промышленная разработка и прочее, где нельзя вернуться на предыдущий этап и подкрутить...
Грубо говоря нельзя такие подходы представить в области строительства самолётов :-) точнее они были таковыми, но на начальных этапах, сейчас ждать пока самолёт упадет с пассажирами недопустимо.
Не хотел бы я у вас работать :-)
Из моего опыта все же работают комбинированные подходы, когда нам ясны процессы, но не проработаны до деталей, они и становятся нашим первоначальным ТЗ. Потом когда мы уже опускаемся на уровень реализации действий, мы уже делаем итерации иногда настолько мелкие, что задача может для разработчика составлять 1-3 дня. Таким образом мы можем прогнозировать, что она завершится в обозримые сроки, он ее поймет и даже если постановщик накосячил цена ощибки будет минимальная. Когда мы нарезаем задачи даже в 5 дней, уже возникают проблемы с прогнозами реализации задачи.
Собственно для этого и нужны аналитики, чтоб собирать пазлы.
Давайте по другому рассмотрим вопрос на примере дома. Можно ли дом построить без проекта? Частный жилой дом, да наверное можно. Многоквартирный - невозможно.
Давайте смотреть на разработку ПО. Можно ли написать по которое реализует бизнес процесс не понимая как он работает? Да можно... но вы будете всегда возвращаться на несколько шагов назад, чтоб что-то подкрутить, что то исправить, что то доработать, так как тут мы несли что в этом справочнике нужны такие данные, тут нам надо получить данные из других систем потому, что мы не знали, что они нужны вообще, мы о такой системе даже не знали. На выходе может получится Франкенштейн. Работать будет, возможно, но не факт, что хорошо.
Теперь представим что мы делаем какую нибудь систему которая объединяет много бизнес процессов:-) вот тут мы сталкиваемся с тем, что цели ещё более размыты, а иногда при итерационной разработке даже толком и не известны. И вам надо паралельно разработать 5 таких процессов. Знаете какая боль будет? А ведь там менеджеры проекта могут даже не задать вопрос зачем это мы делаем. Я видел как до 50% конечного продукта после этого выкидывалось, хотя тут надо сказать и видел как продукты разработанные по ТЗ выкидывались. Но тут суть не в этом в результате мы можем получить какую то кашу, которая неизвестно как работает и неизвестно отвечает ли настоящим требованиям заказчика.
Вы гении :-) либо чего то очень сильно не договариваете. Если бы я не участвовал и не был свидетелем нескольких сот проектов я бы может и поверил :-) не бывает такого, чтоб не переделывали...
При таких подходах заказчик ищет правильный путь путем экспериментов, то есть он сам не знает конечный результат. А значит вы приходите на сессию скажем с начальником отдела, он вам говорит одно, потом при проверке выясняется, что нужно было другое, это по ТЗ то регулярно происходит. А в таких процессах разработки просто могут сказать, мы тут подумали и решили, что надо все по другому. Делаем вот так. Я даже могу сказать почему, потому что заказчик не скован конечными требования, и полет фантазии обычно не ограничен, плюс не заставляет его выяснять на первых этапах, как работает тот или иной процесс. Это с одной стороны не плохо, позволяет быстро сделать mvp и проверить гипотезу с другой стороны часто ведёт к растягиванию разработки и ухудшает качество кода.
Хех... а вы пробовали без ТЗ автоматизировать хоть, сколько нибудь сложный бизнес процесс. На самом деле тз нужно заказчику, чтоб понять, что он хочет. На этапе проработки задания, как правило задача аналитика утрясти процесс не только для разработчиков, но и для клиентов.
Для примера:
Как звучит процесс для руководителя бизнеса. Мы получаем прибыль с продажи.
Для отдела логистики. Мы отправляем грузы по складам и заказчикам.
Для отдела скажем продаж. Мы выполняем планы по продажам.
И так далее в зависимости от того, куда вы придёте у всех будет разное виденье процессов и скорее всего ни один человек в компании не будет знать, как в реальности продается товар. Все видят свою маленькую часть, ньансов смежников могут не знать, а часто они вообще не представляют, что творится у его же сотрудника за соседним столом.
И вот вы такие пришли хорошие и сделали как вам сказал скажем начальник отдела продаж... а потом выяснилось, что интересы других вы не учли вообще... и да вы быстро сделали молодцы :-) но потом 10 раз переделали. Я просто сейчас наблюдаю, как менеджеры бьются за сокращение проработки заданий на разработку, но экономя 10% времени, они часто тратят +100% времени разработчика. За то да шороху наводят знатного...
И ещё чем меньше по объему задача, тем она как правило понятнее и прогнозируемая по времени исполнения... но чтоб эту задачу декомпозировать на много мелких... нужно понимание общей задачи.
Опять же судя по всему вы решаете достаточно типовые для вас задачи, в таких случаях может быть и прокатывает.
Проблема низко скила даже не в этом. Он часто даже не понимает, что есть хорошо.
Мы всегда просим кандидата и нам иногда присылают такой ужасный код, что дальше говорить бессмысленно. Так как человек даже не понимает, что это стыдно показывать.