Вот что может делать системный аналитик на джуниорской позиции:
Вносить изменения, не меняющие существенно бизнес-процессы и функциональность систем.
Устранять локальные инциденты, исправление которых не требует существенного изменения функций и логики работы системы.
Консультировать пользователей по работе с функциями системы и заинтересованных лиц по требованиям к этим функциям.
Разрабатывать документацию, описывающую работу функций системы.
Очень и очень спорно, если только вся ваша система не состоит из нескольких функций. Возможно подобный опыт получился на примере одного работодателя.
Джуниор может изучать всю систему и делать отдельные слабосвязанные функции под руководством наставника. И его даже близко нельзя подпускать к консультациям и разработке документации функций, которые он изучил поверхностно или не изучил вовсе.
Вносить изменения в бизнес-процессы должен бизнес аналитик, а не системный. И опять, чтобы изменить бизнес-процесс, нужно понимать требования от Заказчика, архитектуру приложения, связанность между СПО и модулями, которые затронуты этим процессом, структуру сущностей, сообщений, вплоть до "неформальной политики" с Заказчиком, когда что-то делается неоптимально потому, что так нужно Заказчику...
Некоторые из этих моментов джуниору знать не только не обязательно, но и вредно - от джуниора требуется научиться делать постановки, соответствующие требованиям и понятные разработчикам, используя определенные приемы и методики.
Новость несомненно отличная. Даже если нашего там только проценты. Без таких производств свое завести с нуля не получится - слишком много нужна знать и уметь.
Производителю хотелось бы пожелать к нормальному железу адекватных цен и технической поддержке... Успех стоит на 3-х столпах, а не на 1-м...
"Сразу отметаю «интуитивно понятный» – это требование, которое невозможно формализовать." - очень даже можно, особенно если вы делаете UI для нового модуля системы, которая уже имеет N реализованных модулей. Ваш UI должен использовать ранее принятые приемы и решения, шрифты, цвета, подходы к отображению ошибок валидации данных и т.д...
Если же вы делаете с UI нуля, то в понятность входят общепринятые подходы к решению определенных ситуаций, вроде:
при удалении объекта должна отображаться форма подтверждения удаления.
при выполнении запросов должен отображаться индикатор.
поля, не прошедшие валидацию должны иметь индикацию.
поля для выбора даты должны иметь возможность вызвать datepicker.
поля для выбора значения из списка должны предоставлять варианты значения для введенного фрагмента.
если кнопка или поле заблокированы, то при наведении должна отображаться причина блокировки.
и прочая прочая... вплоть до того, в каких ситуациях текст должен выравниваться по левому краю, в каких по ширине и какие шрифты и цветовые пары использовать...
Сюда же входит "отзывчивость" - при нажатии кнопки системы должна реагировать в течении N секунд, иначе пользователю работать некомфортно или он вообще входит в ступор. Вполне измеряемая характеристика...
Прочитав статью так и не понял, как вы все делаете. Для работы вам нужно четко понимать для чего используется эпик, какие типы задач есть, кто какие артефакты заполняет и для кого, чтобы каждый, кто получил задачу мог проследить от куда она взялась и кто является источником информации для ее выполнения.
Хотелось бы увидеть что-то вроде:
Эпик - в эпике описывается бизнес функция для реализации. Часто в качестве описания в эпик погружают копипасту из ТЗ. Ответственный PM.
PM, добавляет в него задачу для BA на разработку постановки.
BA написав постановку добавляет задачу на SА, если он есть.
SA в свою очередь добавляет задачу на лида разработки.
Лид разработки уже делит задачу на отдельные задачи по команде разработки. А когда все задачи закрываются добавляет задачу на тестирование.
Тестировщик добавляет баги, баги закрываются и т.д., пока эпик - т.е. функция, полезная для Заказчика не будет готов и не уедет в релиз.
если у вас есть персональные данные и/или гос. контракт логи закрывают требования к защите информации по 152 ФЗ и становятся событиями безопасности, описывающие доступ субъекта через программные средства к защищаемым объектам доступа , с указанием успешности вызова и прочее...
Если у вас есть процессы или обработка объекта, то логи должны быть коррелированы - в разных событиях лога должен быть атрибут с экземпляром процесса, id входящего сообщения и прочее...
Понравилось! Читал и следил за скролбаром страницы опасаясь, что дни закончатся раньше, чем я увижу сообщение о релизе. Так и получилось - теперь буду ждать продолжения...
На сколько я помню, история с избеганием выравнивания по ширине была актуальна именно для колоночной верстки (как в разбираемом примере), когда есть риск получить большой разрыв в центре колонки.
При ширине текста на 50 и более % от ширины экрана часто (но не всегда) использование выравнивания по обоим краям дает более аккуратный результат.
Данный способ - лишь один из возможных вариантов. Где-то он более успешен, где-то менее.
Что касается вашего примера со слоном - вы не сможете его съесть по кусочку, если кто-то, пользуясь другой стратегией, проглотит этого слона целиком. Да, может и подавиться - а может и резко вырасти и тогда других слонов для вас не останется...
Чтобы найти все цивилизации нужно быть на верху технологического развития, а не внизу, как мы.
Образно говоря мы ищем кого-то, размахивающего руками, в то время как более развитая цивилизация общается по радио, а еще более развитая - с помощью квантовой запутанности или еще чего-нить... Суслики есть, но мы их не видим...
Подобные опусы от ведущих специалистов возможны в соответствии с тремя основными обстоятельствами:
1) Совсем тупой - такое бывает, когда человек долго молчит и кажется умным. Опустим, как он достиг звания ведущий, главное что наконец он решает осветить путь другим и открывает рот...
2) Это выгодно - простой и понятный вариант. Ты говоришь так, получаешь за это...
3) Проводник интересов - человек чует, куда дует ветер и начинает грести в нужном направлении. Чем раньше начал - тем больше награда. Это самый грустный вариант, говорящий о том, что это мнение становится доктриной и идет от самых верхов. В этом случае мы еще не раз увидим и услышим развитие этого "мнения"...
Надеюсь, что все таки это частная оплошность, хотя само ее наличие вызывает кучу вопросов о том, что там такое творится?
Желтоватенький заголовок. Звучит так, что эта вода уничтожается... Лучше бы написали, что "для 10 ответов нужен 1 литр воды для охлаждения ЦОД".
Вносить изменения, не меняющие существенно бизнес-процессы и функциональность систем.
Устранять локальные инциденты, исправление которых не требует существенного изменения функций и логики работы системы.
Консультировать пользователей по работе с функциями системы и заинтересованных лиц по требованиям к этим функциям.
Разрабатывать документацию, описывающую работу функций системы.
Очень и очень спорно, если только вся ваша система не состоит из нескольких функций. Возможно подобный опыт получился на примере одного работодателя.
Джуниор может изучать всю систему и делать отдельные слабосвязанные функции под руководством наставника. И его даже близко нельзя подпускать к консультациям и разработке документации функций, которые он изучил поверхностно или не изучил вовсе.
Вносить изменения в бизнес-процессы должен бизнес аналитик, а не системный. И опять, чтобы изменить бизнес-процесс, нужно понимать требования от Заказчика, архитектуру приложения, связанность между СПО и модулями, которые затронуты этим процессом, структуру сущностей, сообщений, вплоть до "неформальной политики" с Заказчиком, когда что-то делается неоптимально потому, что так нужно Заказчику...
Некоторые из этих моментов джуниору знать не только не обязательно, но и вредно - от джуниора требуется научиться делать постановки, соответствующие требованиям и понятные разработчикам, используя определенные приемы и методики.
Увлеченные люди, это хорошо! Сделать такое вдвоем за 5 месяцев - это просто невероятно...
Попробуйте "Неукротимую планету", "Пасынки вселенной", если все это читали - то менее известные тех же авторов, вроде " Чужак в чужой стране"...
«Проект “Аве Мария”», Энди Вейер - плюсую, отличная книга!
Новость несомненно отличная. Даже если нашего там только проценты. Без таких производств свое завести с нуля не получится - слишком много нужна знать и уметь.
Производителю хотелось бы пожелать к нормальному железу адекватных цен и технической поддержке... Успех стоит на 3-х столпах, а не на 1-м...
История, где тоже рисовали кота "хатуль мадан" https://meladan.livejournal.com/377726.html
А у нас в университете ставки делали на "Кто победит" - ставили всех игроков компьютерами и оставляли на ночь.. А утром уже был победитель...
"Сразу отметаю «интуитивно понятный» – это требование, которое невозможно формализовать." - очень даже можно, особенно если вы делаете UI для нового модуля системы, которая уже имеет N реализованных модулей. Ваш UI должен использовать ранее принятые приемы и решения, шрифты, цвета, подходы к отображению ошибок валидации данных и т.д...
Если же вы делаете с UI нуля, то в понятность входят общепринятые подходы к решению определенных ситуаций, вроде:
при удалении объекта должна отображаться форма подтверждения удаления.
при выполнении запросов должен отображаться индикатор.
поля, не прошедшие валидацию должны иметь индикацию.
поля для выбора даты должны иметь возможность вызвать datepicker.
поля для выбора значения из списка должны предоставлять варианты значения для введенного фрагмента.
если кнопка или поле заблокированы, то при наведении должна отображаться причина блокировки.
и прочая прочая... вплоть до того, в каких ситуациях текст должен выравниваться по левому краю, в каких по ширине и какие шрифты и цветовые пары использовать...
Сюда же входит "отзывчивость" - при нажатии кнопки системы должна реагировать в течении N секунд, иначе пользователю работать некомфортно или он вообще входит в ступор. Вполне измеряемая характеристика...
Прочитав статью так и не понял, как вы все делаете. Для работы вам нужно четко понимать для чего используется эпик, какие типы задач есть, кто какие артефакты заполняет и для кого, чтобы каждый, кто получил задачу мог проследить от куда она взялась и кто является источником информации для ее выполнения.
Хотелось бы увидеть что-то вроде:
Эпик - в эпике описывается бизнес функция для реализации. Часто в качестве описания в эпик погружают копипасту из ТЗ. Ответственный PM.
PM, добавляет в него задачу для BA на разработку постановки.
BA написав постановку добавляет задачу на SА, если он есть.
SA в свою очередь добавляет задачу на лида разработки.
Лид разработки уже делит задачу на отдельные задачи по команде разработки. А когда все задачи закрываются добавляет задачу на тестирование.
Тестировщик добавляет баги, баги закрываются и т.д., пока эпик - т.е. функция, полезная для Заказчика не будет готов и не уедет в релиз.
Еще пара нюансов:
если у вас есть персональные данные и/или гос. контракт логи закрывают требования к защите информации по 152 ФЗ и становятся событиями безопасности, описывающие доступ субъекта через программные средства к защищаемым объектам доступа , с указанием успешности вызова и прочее...
Если у вас есть процессы или обработка объекта, то логи должны быть коррелированы - в разных событиях лога должен быть атрибут с экземпляром процесса, id входящего сообщения и прочее...
Понравилось! Читал и следил за скролбаром страницы опасаясь, что дни закончатся раньше, чем я увижу сообщение о релизе. Так и получилось - теперь буду ждать продолжения...
На сколько я помню, история с избеганием выравнивания по ширине была актуальна именно для колоночной верстки (как в разбираемом примере), когда есть риск получить большой разрыв в центре колонки.
При ширине текста на 50 и более % от ширины экрана часто (но не всегда) использование выравнивания по обоим краям дает более аккуратный результат.
Данный способ - лишь один из возможных вариантов. Где-то он более успешен, где-то менее.
Что касается вашего примера со слоном - вы не сможете его съесть по кусочку, если кто-то, пользуясь другой стратегией, проглотит этого слона целиком. Да, может и подавиться - а может и резко вырасти и тогда других слонов для вас не останется...
Хорошая новость.
И все таки хотелось бы спросить - какой % изделия делаем мы сами и не получится ли так, что потом нам наши партнеры опять руки выкручивать будут?
Чтобы найти все цивилизации нужно быть на верху технологического развития, а не внизу, как мы.
Образно говоря мы ищем кого-то, размахивающего руками, в то время как более развитая цивилизация общается по радио, а еще более развитая - с помощью квантовой запутанности или еще чего-нить... Суслики есть, но мы их не видим...
Подобные опусы от ведущих специалистов возможны в соответствии с тремя основными обстоятельствами:
1) Совсем тупой - такое бывает, когда человек долго молчит и кажется умным. Опустим, как он достиг звания ведущий, главное что наконец он решает осветить путь другим и открывает рот...
2) Это выгодно - простой и понятный вариант. Ты говоришь так, получаешь за это...
3) Проводник интересов - человек чует, куда дует ветер и начинает грести в нужном направлении. Чем раньше начал - тем больше награда. Это самый грустный вариант, говорящий о том, что это мнение становится доктриной и идет от самых верхов. В этом случае мы еще не раз увидим и услышим развитие этого "мнения"...
Надеюсь, что все таки это частная оплошность, хотя само ее наличие вызывает кучу вопросов о том, что там такое творится?
Да, вся суть в последней строке! Повторюсь, про Гуру трейдинга нужно знать следующее: если бы было так, как он обещает, то:
1) Он был бы сказочно богат.
2) Он бы никогда не поделился своим рецептом с другими.
Бастион — сегодня ночью вам *****!
А если серьезно - зачем выкладывать это все? Шпионская работа требует тишины...
Когда-то понравилось видео по этой теме: https://youtu.be/FiO6jkNkrb4