Нет, по моей аналогии - инженер это человек, который может не знать тонкостей обработки деталей, работы станка, режимов резания и т.д., но владеет более общей картиной по изделию, может пояснить за допуски, шероховатости и материалы, как СА например понимает почему именно такие атрибуты, почему именно такие кейсы описаны и нужны именно определенные проверки на фронте/бэке. Разработчик, как и фрезеровщик, может не знать/не понимать каких то тонкостей по, например, эксплуатации изделии (зачем такие допуски, зачем такие шероховатости, почему именно такой материал и тд), в то же время инженер может не знать, какие именно режимы резания у нержавейки и углеродистой стали. Ему, инженеру, в целом достаточно знать, что они разные.
Могут ли разработчики читать документацию к апи? Могут, конечно же. Только чтение документации без наложения на это дело требований - бесполезно. СА как раз тот человек, который читает документацию и доводит до менеджмента/заказчика невозможность и/или сложность реализаций каких то функций из-за каких-то ограничений. Может ли разработчик прочитать доки к апи и потом написать на понятном менеджеру языке, почему это нельзя/долго реализовывать? Могут, но не все. И займет это времени скорее всего дольше, чем у СА + вместо написания кода, разработчик будет заниматься согласованием функций, сроков их и т.д.
Макеты, кстати, сюда же. СА - это первичный фильтр между заказчиком и разрабами и как правило именно он первично говорит "Так не будет работать". Или вообще СА, что чаще, рисует первичные технические макеты с учетом бд/требований. Тоже отдать разработчику?:) Конечно, при разработке тоже может выясниться, что какой то момент упустили, но одно дело - пара полей на фронте, а другое - макет в целом.
Вопрос не в том, что БА/СА лучше чем разработчик или разработчик лучше чем БА/СА - это все люди, у которых своя зона ответственности и разные требования к выполняем ими функциям.
Довольно поверхностное суждение=) Аналитик и разработчик ~ как инженер и токарь/фрезеровщик. Может ли производство работать без инженеров? Выпуская примитивные изделия - может, а если что то сложнее болта с гайкой (хоть и там есть куча нюансов) очень вряд ли. БА при проектировании системы собирает требования, отсеивает откровенный бред и тд, а затем оформляет их в виде схем разного рода нотаций. Далее, как правило именно БА с помощью СА пишет всякие доки для закрытия проекта - чтз, пз, пми и т.д. Это отдельные компетенции - написать доки так, чтобы всем было хорошо: одновременно не подставить команду излишне подробным чтз и при этом угодить заказчику=) У БА на первом месте софт скилы и личные навыки, а не хард - хард скилов от БА действительно не сильно много требуют.
Про СА это вообще отдельный разговор - это именно тот, кто проектирует по сути какой то функционал - перекладывает бизнес требования на "язык" пермишенов, бд и математики. На этапе проектирования это СА вместе с архитектором проектируют модель данных. Если нужно взаимодействие между системами - это опять же, описывает СА. Именно он читает документацию, вычленяет от туда нужное, общается со второй командой для уточнения неясных моментов, недокументированных особенностей и тд. И в результате его работы и получается "краткое" изложение требований на язык разработчиков - постановка. На этапе разработки именно СА описывает поведение системы при взаимодействии пользователя с ней: какие проверки и ошибки должны отображаться, какими пермишенами закрыто, какой сценарий основной, а какой нет. Опять же, это именно он ведет все эти документы-постановки - когда понадобится произвести какую то доработку к системе, вместо выдергивания разработчика можно посмотреть в постановку и понять логику работу какой либо функции. Да, она скорее всего на 100% не будет соответствовать тому, что реализовано, но как правило на 90-95% соответствует - этого достаточно, чтобы разобраться и вспомнить как функционирует та или иная часть системы. Тестирование - опять же, это тестировщики месте с СА пишут тест-кейсы и тестировщик пойдет именно к СА спрашивать, что ожидается от того или иного взаимодействия (или в идеале - почитает постановку)=)
Я видел команды (и работал с ними), которые работают без аналитиков - с ними крайней тяжело взаимодействовать, потому что разработчики часто забывают сообщать о каких либо изменениях, крайне неохотно общаются в принципе и скажем так, не очень умеют общаться и излагать мысли - хоть ртом, хоть текстом. Также разработчики чаще всего не умеют собирать требования и видеть несостыковки на этапе сбора требований - это довольно сильно усложняет разработку. Когда в команде есть нормальные аналитики, разработка ведется заметно легче, быстрее и комфортнее для всех участников=)
БА в идеале должен быть чуток СА, чтобы не бегать уточнять каждое требование к разрабу/са. И документы (чтз, пз, пми и тд) сами себя не напишут - для этого тоже нужны компетенции.
Вы бы сначала условия отказов выяснили:) На зп 200-250к спокойно находят работу, примерно выше 250к уже да, проблема.
Можно подумать, что в других сферах такого отношения к выпускникам нет. Такое отношение было всегда и есть 3 варианта: 1) зацепиться по какой нить программе от крупных компаний во время учебы 2) набираться опыта в шарашкиных конторах 3) устраиваться через знакомых в около нормальное место. Устроиться самому в норм место вчерашнему выпускнику без опыта почти нереально - так во всех сферах.
Так все зависит от степени тяжести - если действительно серьезная патология с челюстями, то ходи не ходи по спецам, а без операции прикус не исправить. Насколько я понял, то если нет ассиметрии сильной и дистальный/мезиальный прикус небольшой, то можно и без операции - с помощью наклона зубов и не совсем идеального смыкания компенсировать это дело.
А вот если дистальный/мезиальный прикусы глубокие, сильная ассиметрия, то ортодонтия тут не поможет - можно только хуже сделать.
Судить нужна/не нужна операция без КТ и диагноза невозможно (разве что в совсем тяжелых случаях, когда проблемы очень заметны невооруженным глазом)
P.s. Сам постепенно готовлюсь к дистрактору, брекетам и двухчелюстной остеотомии - ассиметрия челюстей около 6 мм, не считая всего остального.
Нет, по моей аналогии - инженер это человек, который может не знать тонкостей обработки деталей, работы станка, режимов резания и т.д., но владеет более общей картиной по изделию, может пояснить за допуски, шероховатости и материалы, как СА например понимает почему именно такие атрибуты, почему именно такие кейсы описаны и нужны именно определенные проверки на фронте/бэке. Разработчик, как и фрезеровщик, может не знать/не понимать каких то тонкостей по, например, эксплуатации изделии (зачем такие допуски, зачем такие шероховатости, почему именно такой материал и тд), в то же время инженер может не знать, какие именно режимы резания у нержавейки и углеродистой стали. Ему, инженеру, в целом достаточно знать, что они разные.
Могут ли разработчики читать документацию к апи? Могут, конечно же. Только чтение документации без наложения на это дело требований - бесполезно. СА как раз тот человек, который читает документацию и доводит до менеджмента/заказчика невозможность и/или сложность реализаций каких то функций из-за каких-то ограничений. Может ли разработчик прочитать доки к апи и потом написать на понятном менеджеру языке, почему это нельзя/долго реализовывать? Могут, но не все. И займет это времени скорее всего дольше, чем у СА + вместо написания кода, разработчик будет заниматься согласованием функций, сроков их и т.д.
Макеты, кстати, сюда же. СА - это первичный фильтр между заказчиком и разрабами и как правило именно он первично говорит "Так не будет работать". Или вообще СА, что чаще, рисует первичные технические макеты с учетом бд/требований. Тоже отдать разработчику?:) Конечно, при разработке тоже может выясниться, что какой то момент упустили, но одно дело - пара полей на фронте, а другое - макет в целом.
Вопрос не в том, что БА/СА лучше чем разработчик или разработчик лучше чем БА/СА - это все люди, у которых своя зона ответственности и разные требования к выполняем ими функциям.
Довольно поверхностное суждение=) Аналитик и разработчик ~ как инженер и токарь/фрезеровщик. Может ли производство работать без инженеров? Выпуская примитивные изделия - может, а если что то сложнее болта с гайкой (хоть и там есть куча нюансов) очень вряд ли. БА при проектировании системы собирает требования, отсеивает откровенный бред и тд, а затем оформляет их в виде схем разного рода нотаций. Далее, как правило именно БА с помощью СА пишет всякие доки для закрытия проекта - чтз, пз, пми и т.д. Это отдельные компетенции - написать доки так, чтобы всем было хорошо: одновременно не подставить команду излишне подробным чтз и при этом угодить заказчику=) У БА на первом месте софт скилы и личные навыки, а не хард - хард скилов от БА действительно не сильно много требуют.
Про СА это вообще отдельный разговор - это именно тот, кто проектирует по сути какой то функционал - перекладывает бизнес требования на "язык" пермишенов, бд и математики. На этапе проектирования это СА вместе с архитектором проектируют модель данных. Если нужно взаимодействие между системами - это опять же, описывает СА. Именно он читает документацию, вычленяет от туда нужное, общается со второй командой для уточнения неясных моментов, недокументированных особенностей и тд. И в результате его работы и получается "краткое" изложение требований на язык разработчиков - постановка. На этапе разработки именно СА описывает поведение системы при взаимодействии пользователя с ней: какие проверки и ошибки должны отображаться, какими пермишенами закрыто, какой сценарий основной, а какой нет. Опять же, это именно он ведет все эти документы-постановки - когда понадобится произвести какую то доработку к системе, вместо выдергивания разработчика можно посмотреть в постановку и понять логику работу какой либо функции. Да, она скорее всего на 100% не будет соответствовать тому, что реализовано, но как правило на 90-95% соответствует - этого достаточно, чтобы разобраться и вспомнить как функционирует та или иная часть системы. Тестирование - опять же, это тестировщики месте с СА пишут тест-кейсы и тестировщик пойдет именно к СА спрашивать, что ожидается от того или иного взаимодействия (или в идеале - почитает постановку)=)
Я видел команды (и работал с ними), которые работают без аналитиков - с ними крайней тяжело взаимодействовать, потому что разработчики часто забывают сообщать о каких либо изменениях, крайне неохотно общаются в принципе и скажем так, не очень умеют общаться и излагать мысли - хоть ртом, хоть текстом. Также разработчики чаще всего не умеют собирать требования и видеть несостыковки на этапе сбора требований - это довольно сильно усложняет разработку. Когда в команде есть нормальные аналитики, разработка ведется заметно легче, быстрее и комфортнее для всех участников=)
БА в идеале должен быть чуток СА, чтобы не бегать уточнять каждое требование к разрабу/са. И документы (чтз, пз, пми и тд) сами себя не напишут - для этого тоже нужны компетенции.
Вы бы сначала условия отказов выяснили:) На зп 200-250к спокойно находят работу, примерно выше 250к уже да, проблема.
Можно подумать, что в других сферах такого отношения к выпускникам нет. Такое отношение было всегда и есть 3 варианта: 1) зацепиться по какой нить программе от крупных компаний во время учебы 2) набираться опыта в шарашкиных конторах 3) устраиваться через знакомых в около нормальное место. Устроиться самому в норм место вчерашнему выпускнику без опыта почти нереально - так во всех сферах.
Так все зависит от степени тяжести - если действительно серьезная патология с челюстями, то ходи не ходи по спецам, а без операции прикус не исправить. Насколько я понял, то если нет ассиметрии сильной и дистальный/мезиальный прикус небольшой, то можно и без операции - с помощью наклона зубов и не совсем идеального смыкания компенсировать это дело.
А вот если дистальный/мезиальный прикусы глубокие, сильная ассиметрия, то ортодонтия тут не поможет - можно только хуже сделать.
Судить нужна/не нужна операция без КТ и диагноза невозможно (разве что в совсем тяжелых случаях, когда проблемы очень заметны невооруженным глазом)
P.s. Сам постепенно готовлюсь к дистрактору, брекетам и двухчелюстной остеотомии - ассиметрия челюстей около 6 мм, не считая всего остального.