Проектировать так же. В контексте есть группа кейсов, вокруг классов модели. Эти кейсы сами себя не реализуют. Выделяет контекст, затем снова кейсы и задача сводится к предыдущей.
В новый контекст её добавишь. Огромное лукавство в том, что возникает иллюзия: правильная архитектура защитит от изменений. Но всегда найдётся требование, ломающее архитектуру.
Нет не попробуем. Это неизбежно заведет нас в политическую дискуссию, которые тут запрещены.
Давайте лучше про этику. Про вопросы благодарности, про "не плюй в колодец", про то, как Паша слетал поужинать в Париж. И про то, что при наличии сотен сигналов, предупреждающих людей о, не будем говорить "опасности", о небезоблачности некоторых решений, мыши продолжают грызть кактус. А сигналы эти для самоуспокоения будем называть желтыми.
Если оставить эмоции, надо учесть, что есть еще и факты. И если написанное правда, что мы и пытаемся тут выяснить - это камушек на чашу весов при принятии во многом судьбоносных решений для многих наших коллег.
И раз вы говорите об уважении, то где оно у вас самого? Почему не дать людям оценить факты самостоятельно, а сразу начать затыкать автора и принижать ценность его информации?
Вот пример far manager: >Первоначально Far Manager был доступен в качестве 40-дневной условно-бесплатной программы для всех, за исключением граждан стран бывшего СССР, которые могли использовать его как бесплатную программу только для некоммерческого использования.
И вот, что пишет нам miro: >На прошлой неделе мы сообщили вам, что с введением новых санкций США и ЕС мы не сможем поддерживать работу аккаунтов, зарегистрированных в России и Беларуси после 12 сентября.
Добавлю к этому: "проектировать взаимодействие машина-машина: тут у разработчиков сильно лучше " Тут оба разработчика взаимодействующих машин каждый тянет в свою сторону и получаются часто очень причудливые архитектуры :) А потом нужна связь взаимодействия пяти машин с пользовательским сценарием и у разрабов сразу лапки: "у меня все работает, а пользовательский сценарий - не моя профессия!"
Добрался уточнить: в Москве на системного аналитика учат 20 колледжей. Обычно - это ~4 года, за которые сделать младшего СА из школьника, увлеченного информатикой, вполне можно. https://postupi.info/city/1/coll-prof/2384
Посмотрим. На мой взгляд наоборот, аналитик требований - профессия из заказного режима разработки длинными итерациями. Такой режим сильно вытесняется короткими итерациями при малом документировании, где требования, как документ или артефакт часто вообще не создаются или создаются на коленке.
А вот вопрос: кто напишет 200 тикетов в месяц стоит все острее
Новый профстандарт расширяет профессию. Аналитик требований нужен в заказной разработке и сильно бюрократизированной внутренней. Но есть и продуктовые проекты и ит-сервисы и там нужны аналитики, но не чистые аналитики требований, а проектировщики.
По многим причинам разделять профессии не нужно. Там, где нужен аналитик требований не обойтись без понимания, как работает проектирование. Системы усложняются. Системные требования очень много где включают тонны интеграции и межсервисного взаимодействия. Это подтверждается исследовнием вакансий системных аналитиков.
С другой стороны работа аналитика требований к системе глазами пользователей уходит к бизнес-аналитикам и продактам.
Так что по нашим наблюдениям, рынок, как вы говорите лег на бок.
Профстандарт расширен для учета обоих положений :)
Я не преподавал в ит-колледже. Но думаю, что выпускник колледжа тоже вполне имеет эти навыки на выходе. По крайней мере ит-студент на 2-3м курсе может работать младшим и иметь эти навыки
Не очень понятно, из чего вы исходите в оценке навыков младшего СА.
Профстандарт предполагает, что СА - это ИТ-инженер со специализацией в проектирование и разработку требований. И перед тем, как стать младшим СА надо стать вообще ИТ-инженером.
Теперь по пунктам:
Сбор образцов данных из систем, продуктов и баз данных;
Сбор образцов исходного программного кода аналогичных, заменяемых, развиваемых или интегрируемых систем и продуктов;
Сохранение собранных исходных данных и ведение реестра собранных материалов.
Под контролем старших товарищей - идти, куда послали собирать то, что сказали, класть в реестр, разработанный старшими. Посмотрите комплиментарные функции более высоких грейдов.
Вести деловые переговоры;
Опять же не конфликтные переговоры, а войти, поздороваться, обьяснить, кто ты и чего хочешь, забрать материалы, поблагодарить. Не сморкаться в рукав... Не бином Ньютона.
Пользоваться инструментами для просмотра данных в текстовом и двоичном виде;
Пользоваться инструментами для доступа к данным и извлечения данных из реляционных баз данных;
Читать исходный программный код;
Знать языки манипулирования данными (SQL);
Пользоваться инструментами онлайн-опросов.
Посмотрите ФГОС по информатике - это при нормальном преподавании дети умеют на выходе из школы.
Навыки по изучению задач автоматизации и работы аналогичных и интегрируемых систем (оставлены сложные пункты) - длинный список не привожу
Оформление проектной и эксплуатационной документации (оставлены сложные пункты) - длинный список не привожу
Это делают бакалавры любой ИТ-специальности 2-3го курса в курсовом проекте.
>>>Заключение: впечатление от нового профстандарта СА, что "лохматость повысилась"
Младший СА сегодня - это выпускник любой ИТ-специальности с высшим образованием.
Это становится разочарованием для тех, кто шел в специальность по принципу "я писать умею, пойду в аналитики требования писать" и для "беглых от технологий", кто имеет ИТ-специальность, но всерьез ненавидит технологии и не хочет к ним прикасаться.
Для таких товарищей можно рекомендовать профессию бизнес-аналитика. Правда, для нее есть свой профстандарт :)
Про иерархию жоп правдоподобно. А вот путь к повышению не так очевиден, как написано в статье. Повышают того, кто искусно раскидывает жопы на соседей. Никогда со своего места не отпустят человека, успешно уничтожающие жопы своего масштаба. Человека, успешно уничтожающего жопы масштаба начальника надо держать в черном теле, чтобы он тебя не подсидел и не зазнался - унижать, придираться недодавать ресурсов и замыкать какие-то мелочи на себя или самых жопоруких соседей.
Путь к повышению лежит через смену работы. При этом надо научиться на собеседовании успешно убеждать, что справишься с жопой нанимателя за три копейки (в масштабах жопы), а потом умело спустить жопу подчиненным и найти среди них терпилу, который ее вывезет (можно нанять со стороны). Ну или продержаться годик на методе трех конвертов: по конверту в квартал + отпуск и больничный и снова менять работу. Есть и другие методы :)
Судя по тому, как написано "Каждый кто хочет получить повышение", писал начальник для своих подчиненных :)
Полно таких историй. На моих глазах только что был вариант, когда половину переписанного сайта со всеми огрехами коленом выдавили в продакшен по настоянию собственника. После этого посчитали, сколько осталось работы. Начальника разработки «пристрелили». Ушли в полном составе команда продактов, команда дизайнеров, проектный офис упловинили, отстрелив проджектов, а аналитиков переделали в продакто-проджекто-аналитиков, разработку и тестирование тоже ощипали. Мобильные команды катапультировались чуть раньше. Правда в новый бизнес срулил арт-директор сместе с исполнительным, кажется.
Остальное доделывали маленькими шажками, не стесняясь выкатывать по одной странице в новом дизайне.
Сейчас вижу подобную ситуацию, но там пока еще хлещет кровь и не ясно, просто останется шрам, или бизнес потеряет конечность.
Дело же не только в левой и правой границе. Есть еще точность задания значения и допуск на саму величину, если мы говорим вообще о жизни.
У меня в хлебопечке «вес» — это 3 значения: 0.5, 0.75, 1кг и все.
Про здания и деревья вот пример: в задаче выдачи разрешения от аэропорта на строительство здания/сооружения высота объекта вообще считается в единицах метров, но от уровня моря. Тут может оказаться, что здание — 1050м, дерево на соседнем холме — 1150м.
В итоге понимать, как в физическом мире измеряется величина перед сохранением и как потом она будет использоваться после вывода из системы — критически важно.
У меня в живой практике коллега один раз запилил для паспорта объекта благоустройства возраст дерева в годах без всякого указания года высадки и был доволен.
методы проектирования в ИТ развиваются считанные десятилетия и достаточно тяжелы, но главное — мало изучены массами
опыт применения ИТ эволюционирует слишком быстро во многих областях и мало где можно себе позволить цикл проектирования длиной в год-два — слишком быстро меняются требования это к вашему тезису про сверхприбыль — она спутница высокого риска
отношения стоимости проектирования и реализации для систем среднего размера гораздо меньше, чем в строительстве и машиностроении, что часто позволяет вместо проектирования еще разик переписать систему
благодаря высочайшей повторяемости операций в ИТ-системах кривая наработки на отказ выглядит не так, как в машиностроении. Если система отлажена, она будет работать всегда. Это снижает ценность предварительных «прочностных и усталостных» расчетов.
Бюджеты в ИТ гораздо ниже, чем в машиностроении и строительстве благодаря высочайшей автоматизации самого производства. Де-факто сборку делают машины, человек только готовит конструктивные решения и технологические карты для их работы.
В большинстве случаев и ответственность ИТ-систем тоже ниже, что опять снижает ценность предварительного анализа
Тестирование ИТ-систем в большинстве случаев дешевле на порядки, особенно «разрушающие виды тестирования»
Однако, с ростом опыта применения ИТ, охвата, критичности и размера систем многие из этих факторов уйдут со сцены. Это уже происходит на наших глазах.
Системы баз данных. Полный курс
Гарсиа-Молина Г., Ульман Дж. Д., Уидом Дж.
Первые главы этой книги исчерпывающее объясняют, где взять модель предметной области.
Это знание можно подпереть методологией описания бизнес-процессов и будет полный фарш.
Методология структурного анализа и проектирования SADT. Дэвид А. Марка, Клемент МакГоуэн
Мы все бежим куда-то в ооп сразу, забывая, что база закладывается в структурных подхода. И в практика ооп уже никто ничего не разжевывает.
Но многие мои знакомые коллеги, все это считает старье, не заслуживающим внимания и остаётся без базы.
Проектировать так же. В контексте есть группа кейсов, вокруг классов модели. Эти кейсы сами себя не реализуют. Выделяет контекст, затем снова кейсы и задача сводится к предыдущей.
В новый контекст её добавишь. Огромное лукавство в том, что возникает иллюзия: правильная архитектура защитит от изменений. Но всегда найдётся требование, ломающее архитектуру.
В РФ человек может работать по договору ГПХ. В других странах тоже может быть контрактные сотрудники. Нужно больше деталей.
Пожалуй, даже учебник математики за 3й класс способен раскачать на эмоции :)
А так это журналисты - это их работа, их так учат. Новость же дана в перепечатке.
Автор мог что-то добавить от себя, но не стал, да.
Сам же факт надо проверить. Возможно кто-то тут близок к ситуации.
Хорошо, попробуем.
Нет не попробуем. Это неизбежно заведет нас в политическую дискуссию, которые тут запрещены.
Давайте лучше про этику. Про вопросы благодарности, про "не плюй в колодец", про то, как Паша слетал поужинать в Париж. И про то, что при наличии сотен сигналов, предупреждающих людей о, не будем говорить "опасности", о небезоблачности некоторых решений, мыши продолжают грызть кактус. А сигналы эти для самоуспокоения будем называть желтыми.
Если оставить эмоции, надо учесть, что есть еще и факты. И если написанное правда, что мы и пытаемся тут выяснить - это камушек на чашу весов при принятии во многом судьбоносных решений для многих наших коллег.
И раз вы говорите об уважении, то где оно у вас самого? Почему не дать людям оценить факты самостоятельно, а сразу начать затыкать автора и принижать ценность его информации?
Не знаю, как это объяснить. Вероятно, если надо объяснять, то не надо объяснять.
К тому, что ушло поколение.
Вот пример far manager:
>Первоначально Far Manager был доступен в качестве 40-дневной условно-бесплатной программы для всех, за исключением граждан стран бывшего СССР, которые могли использовать его как бесплатную программу только для некоммерческого использования.
И вот, что пишет нам miro:
>На прошлой неделе мы сообщили вам, что с введением новых санкций США и ЕС мы не сможем поддерживать работу аккаунтов, зарегистрированных в России и Беларуси после 12 сентября.
Добавлю к этому: "проектировать взаимодействие машина-машина: тут у разработчиков сильно лучше "
Тут оба разработчика взаимодействующих машин каждый тянет в свою сторону и получаются часто очень причудливые архитектуры :)
А потом нужна связь взаимодействия пяти машин с пользовательским сценарием и у разрабов сразу лапки: "у меня все работает, а пользовательский сценарий - не моя профессия!"
Добрался уточнить: в Москве на системного аналитика учат 20 колледжей. Обычно - это ~4 года, за которые сделать младшего СА из школьника, увлеченного информатикой, вполне можно. https://postupi.info/city/1/coll-prof/2384
Посмотрим. На мой взгляд наоборот, аналитик требований - профессия из заказного режима разработки длинными итерациями. Такой режим сильно вытесняется короткими итерациями при малом документировании, где требования, как документ или артефакт часто вообще не создаются или создаются на коленке.
А вот вопрос: кто напишет 200 тикетов в месяц стоит все острее
Новый профстандарт расширяет профессию. Аналитик требований нужен в заказной разработке и сильно бюрократизированной внутренней. Но есть и продуктовые проекты и ит-сервисы и там нужны аналитики, но не чистые аналитики требований, а проектировщики.
По многим причинам разделять профессии не нужно. Там, где нужен аналитик требований не обойтись без понимания, как работает проектирование. Системы усложняются. Системные требования очень много где включают тонны интеграции и межсервисного взаимодействия. Это подтверждается исследовнием вакансий системных аналитиков.
С другой стороны работа аналитика требований к системе глазами пользователей уходит к бизнес-аналитикам и продактам.
Так что по нашим наблюдениям, рынок, как вы говорите лег на бок.
Профстандарт расширен для учета обоих положений :)
Я не преподавал в ит-колледже. Но думаю, что выпускник колледжа тоже вполне имеет эти навыки на выходе. По крайней мере ит-студент на 2-3м курсе может работать младшим и иметь эти навыки
Не очень понятно, из чего вы исходите в оценке навыков младшего СА.
Профстандарт предполагает, что СА - это ИТ-инженер со специализацией в проектирование и разработку требований. И перед тем, как стать младшим СА надо стать вообще ИТ-инженером.
Теперь по пунктам:
Сбор образцов данных из систем, продуктов и баз данных;
Сбор образцов исходного программного кода аналогичных, заменяемых, развиваемых или интегрируемых систем и продуктов;
Сохранение собранных исходных данных и ведение реестра собранных материалов.
Под контролем старших товарищей - идти, куда послали собирать то, что сказали, класть в реестр, разработанный старшими. Посмотрите комплиментарные функции более высоких грейдов.
Вести деловые переговоры;
Опять же не конфликтные переговоры, а войти, поздороваться, обьяснить, кто ты и чего хочешь, забрать материалы, поблагодарить. Не сморкаться в рукав... Не бином Ньютона.
Пользоваться инструментами для просмотра данных в текстовом и двоичном виде;
Пользоваться инструментами для доступа к данным и извлечения данных из реляционных баз данных;
Читать исходный программный код;
Знать языки манипулирования данными (SQL);
Пользоваться инструментами онлайн-опросов.
Посмотрите ФГОС по информатике - это при нормальном преподавании дети умеют на выходе из школы.
Навыки по изучению задач автоматизации и работы аналогичных и интегрируемых систем (оставлены сложные пункты) - длинный список не привожу
Оформление проектной и эксплуатационной документации (оставлены сложные пункты) - длинный список не привожу
Это делают бакалавры любой ИТ-специальности 2-3го курса в курсовом проекте.
>>>Заключение: впечатление от нового профстандарта СА, что "лохматость повысилась"
Младший СА сегодня - это выпускник любой ИТ-специальности с высшим образованием.
Это становится разочарованием для тех, кто шел в специальность по принципу "я писать умею, пойду в аналитики требования писать" и для "беглых от технологий", кто имеет ИТ-специальность, но всерьез ненавидит технологии и не хочет к ним прикасаться.
Для таких товарищей можно рекомендовать профессию бизнес-аналитика. Правда, для нее есть свой профстандарт :)
Это анекдот про три гвоздя :) Три конверта - это вали на меня, вали на обстоятельства, готовь три конверта :)
https://zen.yandex.ru/media/id/602a72555e0abe56107efee3/anekdot-pro-tri-konverta-603f82edafc00e4c65e54349
Про иерархию жоп правдоподобно. А вот путь к повышению не так очевиден, как написано в статье. Повышают того, кто искусно раскидывает жопы на соседей. Никогда со своего места не отпустят человека, успешно уничтожающие жопы своего масштаба. Человека, успешно уничтожающего жопы масштаба начальника надо держать в черном теле, чтобы он тебя не подсидел и не зазнался - унижать, придираться недодавать ресурсов и замыкать какие-то мелочи на себя или самых жопоруких соседей.
Путь к повышению лежит через смену работы. При этом надо научиться на собеседовании успешно убеждать, что справишься с жопой нанимателя за три копейки (в масштабах жопы), а потом умело спустить жопу подчиненным и найти среди них терпилу, который ее вывезет (можно нанять со стороны). Ну или продержаться годик на методе трех конвертов: по конверту в квартал + отпуск и больничный и снова менять работу. Есть и другие методы :)
Судя по тому, как написано "Каждый кто хочет получить повышение", писал начальник для своих подчиненных :)
Остальное доделывали маленькими шажками, не стесняясь выкатывать по одной странице в новом дизайне.
Сейчас вижу подобную ситуацию, но там пока еще хлещет кровь и не ясно, просто останется шрам, или бизнес потеряет конечность.
У меня в хлебопечке «вес» — это 3 значения: 0.5, 0.75, 1кг и все.
Про здания и деревья вот пример: в задаче выдачи разрешения от аэропорта на строительство здания/сооружения высота объекта вообще считается в единицах метров, но от уровня моря. Тут может оказаться, что здание — 1050м, дерево на соседнем холме — 1150м.
В итоге понимать, как в физическом мире измеряется величина перед сохранением и как потом она будет использоваться после вывода из системы — критически важно.
У меня в живой практике коллега один раз запилил для паспорта объекта благоустройства возраст дерева в годах без всякого указания года высадки и был доволен.
По вопросу: в ИТ все сразу пошло не так:
Однако, с ростом опыта применения ИТ, охвата, критичности и размера систем многие из этих факторов уйдут со сцены. Это уже происходит на наших глазах.