Тут про другое когда цена ошибки высока, допустим как в строительстве ее уже нельзя исправить на последующем этапе. Это области которые касаются аппаратно программных платформ, почти вся промышленная разработка и прочее, где нельзя вернуться на предыдущий этап и подкрутить... Грубо говоря нельзя такие подходы представить в области строительства самолётов :-) точнее они были таковыми, но на начальных этапах, сейчас ждать пока самолёт упадет с пассажирами недопустимо.
Из моего опыта все же работают комбинированные подходы, когда нам ясны процессы, но не проработаны до деталей, они и становятся нашим первоначальным ТЗ. Потом когда мы уже опускаемся на уровень реализации действий, мы уже делаем итерации иногда настолько мелкие, что задача может для разработчика составлять 1-3 дня. Таким образом мы можем прогнозировать, что она завершится в обозримые сроки, он ее поймет и даже если постановщик накосячил цена ощибки будет минимальная. Когда мы нарезаем задачи даже в 5 дней, уже возникают проблемы с прогнозами реализации задачи.
Собственно для этого и нужны аналитики, чтоб собирать пазлы.
Давайте по другому рассмотрим вопрос на примере дома. Можно ли дом построить без проекта? Частный жилой дом, да наверное можно. Многоквартирный - невозможно.
Давайте смотреть на разработку ПО. Можно ли написать по которое реализует бизнес процесс не понимая как он работает? Да можно... но вы будете всегда возвращаться на несколько шагов назад, чтоб что-то подкрутить, что то исправить, что то доработать, так как тут мы несли что в этом справочнике нужны такие данные, тут нам надо получить данные из других систем потому, что мы не знали, что они нужны вообще, мы о такой системе даже не знали. На выходе может получится Франкенштейн. Работать будет, возможно, но не факт, что хорошо. Теперь представим что мы делаем какую нибудь систему которая объединяет много бизнес процессов:-) вот тут мы сталкиваемся с тем, что цели ещё более размыты, а иногда при итерационной разработке даже толком и не известны. И вам надо паралельно разработать 5 таких процессов. Знаете какая боль будет? А ведь там менеджеры проекта могут даже не задать вопрос зачем это мы делаем. Я видел как до 50% конечного продукта после этого выкидывалось, хотя тут надо сказать и видел как продукты разработанные по ТЗ выкидывались. Но тут суть не в этом в результате мы можем получить какую то кашу, которая неизвестно как работает и неизвестно отвечает ли настоящим требованиям заказчика.
Вы гении :-) либо чего то очень сильно не договариваете. Если бы я не участвовал и не был свидетелем нескольких сот проектов я бы может и поверил :-) не бывает такого, чтоб не переделывали...
При таких подходах заказчик ищет правильный путь путем экспериментов, то есть он сам не знает конечный результат. А значит вы приходите на сессию скажем с начальником отдела, он вам говорит одно, потом при проверке выясняется, что нужно было другое, это по ТЗ то регулярно происходит. А в таких процессах разработки просто могут сказать, мы тут подумали и решили, что надо все по другому. Делаем вот так. Я даже могу сказать почему, потому что заказчик не скован конечными требования, и полет фантазии обычно не ограничен, плюс не заставляет его выяснять на первых этапах, как работает тот или иной процесс. Это с одной стороны не плохо, позволяет быстро сделать mvp и проверить гипотезу с другой стороны часто ведёт к растягиванию разработки и ухудшает качество кода.
Хех... а вы пробовали без ТЗ автоматизировать хоть, сколько нибудь сложный бизнес процесс. На самом деле тз нужно заказчику, чтоб понять, что он хочет. На этапе проработки задания, как правило задача аналитика утрясти процесс не только для разработчиков, но и для клиентов. Для примера: Как звучит процесс для руководителя бизнеса. Мы получаем прибыль с продажи. Для отдела логистики. Мы отправляем грузы по складам и заказчикам. Для отдела скажем продаж. Мы выполняем планы по продажам. И так далее в зависимости от того, куда вы придёте у всех будет разное виденье процессов и скорее всего ни один человек в компании не будет знать, как в реальности продается товар. Все видят свою маленькую часть, ньансов смежников могут не знать, а часто они вообще не представляют, что творится у его же сотрудника за соседним столом.
И вот вы такие пришли хорошие и сделали как вам сказал скажем начальник отдела продаж... а потом выяснилось, что интересы других вы не учли вообще... и да вы быстро сделали молодцы :-) но потом 10 раз переделали. Я просто сейчас наблюдаю, как менеджеры бьются за сокращение проработки заданий на разработку, но экономя 10% времени, они часто тратят +100% времени разработчика. За то да шороху наводят знатного... И ещё чем меньше по объему задача, тем она как правило понятнее и прогнозируемая по времени исполнения... но чтоб эту задачу декомпозировать на много мелких... нужно понимание общей задачи. Опять же судя по всему вы решаете достаточно типовые для вас задачи, в таких случаях может быть и прокатывает.
Проблема низко скила даже не в этом. Он часто даже не понимает, что есть хорошо.
Мы всегда просим кандидата и нам иногда присылают такой ужасный код, что дальше говорить бессмысленно. Так как человек даже не понимает, что это стыдно показывать.
Пытались. И ничего хорошего это не приносит. Вопросы же такие, на которые с лёгкостью ответит любой член текущей команды. Вот вы думаете на собесах чсв у людей. А я вам приведу пример. Вот допустим возьмём человека, у которого завтра операция, и он узнает, что человек который ему делать ее не хирург вообще ни разу. Он тут по чату gpt и видосик посмотрел и хорошо сделает. Одна проблема скальпеля не держал и вообще слабо представляет, как там все внутри устроено, а так он уверенно говорит, что он хирург, особенно если пару раз попрактикуется. Как вы думаете, если бы вы были на месте этого пациента. Вы бы согласились на операцию?
Ответьте себе на этот вопрос.
А теперь поймите другое: Часто люди при оценке своих навыков и способностей опираются на свой опыт. Тут парадокс в том, что обычно вы в ловушке этого опыта. Большая часть ищет людей под конкретные задачи. И переучивать ни кого не хотят, большая часть хочет, чтоб их пришли и научили. То есть мне если нужен ветеринар, я не хочу нанимать даже прекрасного агронома. И сколько я не присутствовал на интервью, завалить человека ни когда не было целью, проверить потолок знаний в какой то узкой теме, есть, цели показать, что кото умнее кого-то нет. Остальное восприятие.
Так как провожу много собеседований могу сказать, что на рынке много людей, но реально хороших очень мало.
Большая часть просто не квалифицированы. Нет иногда знаний элементарных вещей. Это как если механик на сто с 10ти летним стажем не знает зачем нужен маслянный фильтр или чем отличается то или иное масло. Да работать конечно можно, но можно ли этого товарища назвать специалистом? Ну и меня всегда пугают люди, которые работают с какой то вещью годами и не узнали почему же оно так.
Обман. Я понимаю, что люди которые закончили курсы вчера думают, что можно получать зп +200к сразу. Но реально рассказы про проекты которые не делали. Перечисление технологии с которыми не работали и так далее. Самое эпичное последний собес, когда человек даже не мог прочитать код.
Что хочу сказать на канансию питониста с опытом бывает по 1000 откликов. Не важно какие параметры. Причем поговорить из этих 1000 можно с 20ю.... И нормальных может вообще не оказаться среди них.
Я конечно не хочу обижать тайгу... Но она рядом с Яндекс трекер не стояла, а уж тем более с жирой. Судя по скринам у вас очень скромные требования к ведению задач, но тем не менее, мы когда в прошлом году еютайгу разворачивали для тестирования, там сразу надо было пилить. Авторы весьма специфично рассматривают закрытие задач, диаграмма сгорания кривая, и если у вас хоть сколько то сложный ворклоу у задачи она не подходит. Но есть конечно возможность допила.
Надо кстати сказать что мы смотрели больше 10ка решений и на тот момент, ни одно решение не подходило для полноценного ведения задач, либо это решения типа трелло. Либо требует пиления и допила для нормальной работы с гитлабом ну или другим любым репозиториев кода. В результате сидим на Яндекс трекер, тоже куча кривизны и ещё и со следующего года в 2 раза дороже будет... Но хоть как то реализуется воркфлоу для относительно простых процессов.
Вы удвитесь но допусти введение статуса тестирования в других трекерах задач становится для них непосильной ношей. Нормальной интеграции с гитом нет ни у кого. Под нормальной я говорю про ажур девопс.
Это утопия. Как бы такая ОС конечнно существовать может, но она по факту ни кому не нужна. Сервисы гугла или хуевей или ещё кого-то это то из за чего собственно и покупают всё это добро. Элементарная функция пушей. Казалось бы чего тут такого? А это ведь централизованный сервис доставки сообщения от бекенда разработчика к приложению на вашем телефоне. Он приносит информацию, будет приложение и.т.п. да можно запишись свои сервисы пушей... Но во первых это будет фигня полная во вторых представьте как будет тормозить и жрать батарейку ваш телефон если у вас будет 20-30 процессов таких фоновых крутится. Я даже оставлю вопрос того, что возможность внедрения любым приложением таких функций в основном не безопасно. И пуши это самый элементарный сервис. А таких сервисов которые вы юзаете на телефоне 10ки. Разобрались с тем, что они нужны. Но почему лицензирование? И почему платно? А вы теперь представьте, что вам нужно обеспечивать инфраструктуру под это всё дело. И второе вам надо чтоб производитель придерживался минимальных стандартов качества. В конце концов не устраивал доса на вашу инфраструктуру. Вот и возникает система лицензирования. То есть это в целом благо для потребителей.
Там на самом деле много проблем... Нет CI, нет нормального управления проектами и нормальных интеграций со стороними системамр управления проектов. К слову сказать в gitlab с управлением проектом тоже всё плохо.
Режимы начали выделать, когда в этом оказался смысл... Если у вас модель условно прогнозирует 5%, то создание еще одной модели под какой то специфический момент вам не поможет, мы на ранних этапах мы просто отбрасывали данные.
То что вы описываете, я так понимаю вы хотите узнать наработку на отказ, это можно сделать проще, такие эксперименты мы делали. Но она все рано будет плюс минус километр, дело в том, что вы не может сказать в оптимальном ли режиме работает оборудование в данной конкретной точке установки и данный момент времени (это весьма динамичная характеристика). Если эти данные есть, то можно достаточно точно наработку на отказ прогнозировать при условии, что у вас есть достаточно данных на это оборудование. Но опять же, я хочу заметить, отказ в нашем случае - это не наработка на отказ. Причин отказов гораздо больше.
Я так понимаю что через год поменялась гравитация, и жидкость нужно было притягивать искусственно.
На самом деле все очень печально с этой точки зрения, мы когда начали более глубоко по годам раскладывать данные выяснилось, что кое где напряжения вообще указаны как 220в, а этого впринципе не может быть.
Такое ощущение что вы взялись за ту сферу, в которой ранее никто из вас не работал вообще.
Вы удивитесь, но часто лучше спросить или ознакомится с опытом других людей, прежде чем делать, что-то свое.
Тут про другое когда цена ошибки высока, допустим как в строительстве ее уже нельзя исправить на последующем этапе. Это области которые касаются аппаратно программных платформ, почти вся промышленная разработка и прочее, где нельзя вернуться на предыдущий этап и подкрутить...
Грубо говоря нельзя такие подходы представить в области строительства самолётов :-) точнее они были таковыми, но на начальных этапах, сейчас ждать пока самолёт упадет с пассажирами недопустимо.
Не хотел бы я у вас работать :-)
Из моего опыта все же работают комбинированные подходы, когда нам ясны процессы, но не проработаны до деталей, они и становятся нашим первоначальным ТЗ. Потом когда мы уже опускаемся на уровень реализации действий, мы уже делаем итерации иногда настолько мелкие, что задача может для разработчика составлять 1-3 дня. Таким образом мы можем прогнозировать, что она завершится в обозримые сроки, он ее поймет и даже если постановщик накосячил цена ощибки будет минимальная. Когда мы нарезаем задачи даже в 5 дней, уже возникают проблемы с прогнозами реализации задачи.
Собственно для этого и нужны аналитики, чтоб собирать пазлы.
Давайте по другому рассмотрим вопрос на примере дома. Можно ли дом построить без проекта? Частный жилой дом, да наверное можно. Многоквартирный - невозможно.
Давайте смотреть на разработку ПО. Можно ли написать по которое реализует бизнес процесс не понимая как он работает? Да можно... но вы будете всегда возвращаться на несколько шагов назад, чтоб что-то подкрутить, что то исправить, что то доработать, так как тут мы несли что в этом справочнике нужны такие данные, тут нам надо получить данные из других систем потому, что мы не знали, что они нужны вообще, мы о такой системе даже не знали. На выходе может получится Франкенштейн. Работать будет, возможно, но не факт, что хорошо.
Теперь представим что мы делаем какую нибудь систему которая объединяет много бизнес процессов:-) вот тут мы сталкиваемся с тем, что цели ещё более размыты, а иногда при итерационной разработке даже толком и не известны. И вам надо паралельно разработать 5 таких процессов. Знаете какая боль будет? А ведь там менеджеры проекта могут даже не задать вопрос зачем это мы делаем. Я видел как до 50% конечного продукта после этого выкидывалось, хотя тут надо сказать и видел как продукты разработанные по ТЗ выкидывались. Но тут суть не в этом в результате мы можем получить какую то кашу, которая неизвестно как работает и неизвестно отвечает ли настоящим требованиям заказчика.
Вы гении :-) либо чего то очень сильно не договариваете. Если бы я не участвовал и не был свидетелем нескольких сот проектов я бы может и поверил :-) не бывает такого, чтоб не переделывали...
При таких подходах заказчик ищет правильный путь путем экспериментов, то есть он сам не знает конечный результат. А значит вы приходите на сессию скажем с начальником отдела, он вам говорит одно, потом при проверке выясняется, что нужно было другое, это по ТЗ то регулярно происходит. А в таких процессах разработки просто могут сказать, мы тут подумали и решили, что надо все по другому. Делаем вот так. Я даже могу сказать почему, потому что заказчик не скован конечными требования, и полет фантазии обычно не ограничен, плюс не заставляет его выяснять на первых этапах, как работает тот или иной процесс. Это с одной стороны не плохо, позволяет быстро сделать mvp и проверить гипотезу с другой стороны часто ведёт к растягиванию разработки и ухудшает качество кода.
Хех... а вы пробовали без ТЗ автоматизировать хоть, сколько нибудь сложный бизнес процесс. На самом деле тз нужно заказчику, чтоб понять, что он хочет. На этапе проработки задания, как правило задача аналитика утрясти процесс не только для разработчиков, но и для клиентов.
Для примера:
Как звучит процесс для руководителя бизнеса. Мы получаем прибыль с продажи.
Для отдела логистики. Мы отправляем грузы по складам и заказчикам.
Для отдела скажем продаж. Мы выполняем планы по продажам.
И так далее в зависимости от того, куда вы придёте у всех будет разное виденье процессов и скорее всего ни один человек в компании не будет знать, как в реальности продается товар. Все видят свою маленькую часть, ньансов смежников могут не знать, а часто они вообще не представляют, что творится у его же сотрудника за соседним столом.
И вот вы такие пришли хорошие и сделали как вам сказал скажем начальник отдела продаж... а потом выяснилось, что интересы других вы не учли вообще... и да вы быстро сделали молодцы :-) но потом 10 раз переделали. Я просто сейчас наблюдаю, как менеджеры бьются за сокращение проработки заданий на разработку, но экономя 10% времени, они часто тратят +100% времени разработчика. За то да шороху наводят знатного...
И ещё чем меньше по объему задача, тем она как правило понятнее и прогнозируемая по времени исполнения... но чтоб эту задачу декомпозировать на много мелких... нужно понимание общей задачи.
Опять же судя по всему вы решаете достаточно типовые для вас задачи, в таких случаях может быть и прокатывает.
Проблема низко скила даже не в этом. Он часто даже не понимает, что есть хорошо.
Мы всегда просим кандидата и нам иногда присылают такой ужасный код, что дальше говорить бессмысленно. Так как человек даже не понимает, что это стыдно показывать.
Пытались. И ничего хорошего это не приносит. Вопросы же такие, на которые с лёгкостью ответит любой член текущей команды.
Вот вы думаете на собесах чсв у людей. А я вам приведу пример. Вот допустим возьмём человека, у которого завтра операция, и он узнает, что человек который ему делать ее не хирург вообще ни разу. Он тут по чату gpt и видосик посмотрел и хорошо сделает. Одна проблема скальпеля не держал и вообще слабо представляет, как там все внутри устроено, а так он уверенно говорит, что он хирург, особенно если пару раз попрактикуется. Как вы думаете, если бы вы были на месте этого пациента. Вы бы согласились на операцию?
Ответьте себе на этот вопрос.
А теперь поймите другое:
Часто люди при оценке своих навыков и способностей опираются на свой опыт. Тут парадокс в том, что обычно вы в ловушке этого опыта.
Большая часть ищет людей под конкретные задачи. И переучивать ни кого не хотят, большая часть хочет, чтоб их пришли и научили. То есть мне если нужен ветеринар, я не хочу нанимать даже прекрасного агронома.
И сколько я не присутствовал на интервью, завалить человека ни когда не было целью, проверить потолок знаний в какой то узкой теме, есть, цели показать, что кото умнее кого-то нет. Остальное восприятие.
Так как провожу много собеседований могу сказать, что на рынке много людей, но реально хороших очень мало.
Большая часть просто не квалифицированы. Нет иногда знаний элементарных вещей. Это как если механик на сто с 10ти летним стажем не знает зачем нужен маслянный фильтр или чем отличается то или иное масло. Да работать конечно можно, но можно ли этого товарища назвать специалистом? Ну и меня всегда пугают люди, которые работают с какой то вещью годами и не узнали почему же оно так.
Обман. Я понимаю, что люди которые закончили курсы вчера думают, что можно получать зп +200к сразу. Но реально рассказы про проекты которые не делали. Перечисление технологии с которыми не работали и так далее. Самое эпичное последний собес, когда человек даже не мог прочитать код.
Что хочу сказать на канансию питониста с опытом бывает по 1000 откликов. Не важно какие параметры. Причем поговорить из этих 1000 можно с 20ю.... И нормальных может вообще не оказаться среди них.
все может :-)
Я конечно не хочу обижать тайгу... Но она рядом с Яндекс трекер не стояла, а уж тем более с жирой. Судя по скринам у вас очень скромные требования к ведению задач, но тем не менее, мы когда в прошлом году еютайгу разворачивали для тестирования, там сразу надо было пилить. Авторы весьма специфично рассматривают закрытие задач, диаграмма сгорания кривая, и если у вас хоть сколько то сложный ворклоу у задачи она не подходит. Но есть конечно возможность допила.
Надо кстати сказать что мы смотрели больше 10ка решений и на тот момент, ни одно решение не подходило для полноценного ведения задач, либо это решения типа трелло. Либо требует пиления и допила для нормальной работы с гитлабом ну или другим любым репозиториев кода. В результате сидим на Яндекс трекер, тоже куча кривизны и ещё и со следующего года в 2 раза дороже будет... Но хоть как то реализуется воркфлоу для относительно простых процессов.
Вы удвитесь но допусти введение статуса тестирования в других трекерах задач становится для них непосильной ношей. Нормальной интеграции с гитом нет ни у кого. Под нормальной я говорю про ажур девопс.
Имхо... В будущее заглянуть не получилось :-) во вчера возможно. Как бы перспективы php, как бекенда, туманны.
Да и тренды в разработке очень поменялись. Боюсь что через 5-10 лет вы даже WP можете в широких массах не увидеть.
Очень крутой дайджест с удовольствием прочитал.
Рад, что статьи по Joomla появляются, и самое главное качество статей растет.
Читал статью в три подхода... сразу не осилил. Очень большой дайджест в этот раз. Подсмотрел даже одно интересное расширение.
С интересом прочитал и даже пару интересных вещей увидел. Спасибо.
Ну я бы сказал что вебкроны, тоже не плохое нововведение.
Это утопия. Как бы такая ОС конечнно существовать может, но она по факту ни кому не нужна. Сервисы гугла или хуевей или ещё кого-то это то из за чего собственно и покупают всё это добро. Элементарная функция пушей. Казалось бы чего тут такого? А это ведь централизованный сервис доставки сообщения от бекенда разработчика к приложению на вашем телефоне. Он приносит информацию, будет приложение и.т.п. да можно запишись свои сервисы пушей... Но во первых это будет фигня полная во вторых представьте как будет тормозить и жрать батарейку ваш телефон если у вас будет 20-30 процессов таких фоновых крутится. Я даже оставлю вопрос того, что возможность внедрения любым приложением таких функций в основном не безопасно. И пуши это самый элементарный сервис. А таких сервисов которые вы юзаете на телефоне 10ки. Разобрались с тем, что они нужны. Но почему лицензирование? И почему платно? А вы теперь представьте, что вам нужно обеспечивать инфраструктуру под это всё дело. И второе вам надо чтоб производитель придерживался минимальных стандартов качества. В конце концов не устраивал доса на вашу инфраструктуру. Вот и возникает система лицензирования. То есть это в целом благо для потребителей.
Там на самом деле много проблем... Нет CI, нет нормального управления проектами и нормальных интеграций со стороними системамр управления проектов. К слову сказать в gitlab с управлением проектом тоже всё плохо.
Режимы начали выделать, когда в этом оказался смысл... Если у вас модель условно прогнозирует 5%, то создание еще одной модели под какой то специфический момент вам не поможет, мы на ранних этапах мы просто отбрасывали данные.
То что вы описываете, я так понимаю вы хотите узнать наработку на отказ, это можно сделать проще, такие эксперименты мы делали. Но она все рано будет плюс минус километр, дело в том, что вы не может сказать в оптимальном ли режиме работает оборудование в данной конкретной точке установки и данный момент времени (это весьма динамичная характеристика). Если эти данные есть, то можно достаточно точно наработку на отказ прогнозировать при условии, что у вас есть достаточно данных на это оборудование. Но опять же, я хочу заметить, отказ в нашем случае - это не наработка на отказ. Причин отказов гораздо больше.
На самом деле все очень печально с этой точки зрения, мы когда начали более глубоко по годам раскладывать данные выяснилось, что кое где напряжения вообще указаны как 220в, а этого впринципе не может быть.
Вы удивитесь, но часто лучше спросить или ознакомится с опытом других людей, прежде чем делать, что-то свое.