@AVF_613 частично с Вами согласны по поводу поддержания базы процессов. Это действительно трудоемкий процесс, поэтому не нужно описывать все подряд. Моделирование оправдано там, где есть риски, где нужен анализ, где нужна исполнимость процесса в BPMS, а также для проектирования новых для компании процессов. Для этого обычно в компаниях с культурой процессного управления создаются процессные офисы.
Не можем согласиться с высказыванием, что бизнес не разбирается. Если вы встречались с такой ситуацией, то, возможно, у бизнеса не было необходимости в этом разбираться. Это могло быть связано с тем, что культура процессного управления в компании слабо развита, а она начинается с самой верхушки управления. Если там нет заинтересованности, то и ниже ее не будет.
Так же все же считаем, что Lean и ТОС — не инструменты. Это две методологии, которые включают в себя инструменты улучшения бизнес-процессов. Но чтобы что-то улучшить, нужно сначала найти эти «узкие» места, и в этом хорошим подспорьем является процессный подход (опять же, который не заключается в тотальной регламентации).
Данная статья является первой частью цикла статей. Вторая часть доступна тут. И там как раз про этап поиска путей улучшения. По результатам найденных и оцененных методологических улучшений уже принимается решение бизнесом о запуске различных изменений и проектов, в том числе проектов по автоматизации или замене имеющихся методов автоматизации. И вот уже в рамках этих проектов проводится полное обследование и описание модели данных, статусной модели, оцениваются рыночные предложения, выбирается путь автоматизации и прочее.
Обычное тестирование — это тестирование форм, создание, редактирование документов/отчетов, наполнение регистров и т.д. Интеграционное тестирование — это проверка взаимодействия системы 1С с внешними или внутренними ресурсами/микросервисами, например через API или HTTP запросы. Именно такие примеры описаны в статье. А именно инструменты 1С, с помощью которых происходит это взаимодействие.
Привет! Конфигурация выполняется платформой, пользователь взаимодействует с платформой, которая имеет свою конфигурацию. Конфигурация может изменяться под потребности заказчика.
Спасибо за полезное и очень важное дополнение! Существует четкое разделение ролей, но, к сожалению, не все компании и заказчики о них в курсе. На многих проектах каноническое распределение обязанностей между специалистами сильно изменилось. Мы стараемся, чтобы как можно больше разработчиков и заказчиков были осведомлены о правильном распределении ролей, а не искали универсального специалиста в качестве «волшебной таблетки от всех проблем».
Наряду с использованием широкого спектра современных инструментов ИБ, мы подбираем и специфические релевантные варианты для каждого конкретного случая. В некоторых компаниях все еще работают с ПО, которое написано на более ранних версиях Java. И которые в силу различных обстоятельств не могут перейти на более старшие версии. Для них не менее важно уметь настраивать правила безопасности, учитывая и внутренние регламенты организаций. Мы учитываем все пожелания заказчиков и подбираем решение исходя из ситуации. В этом особенность заказной разработки.
Конечно, использование маинд карты для простой формы ввода может показаться излишним. Автор использовала эту форму в качестве визуального примера, на котором просто объяснить, как такой подход может помочь.
На практике интеллект-карты чаще используются для более сложных проектов, где необходимо глубокое понимание пользовательского опыта. Вот почему это помогает:
лучше понять, как пользователи будут взаимодействовать с продуктом;
выявить скрытые проблемы, которые могут быть не очевидны на первый взгляд;
сделать тестирование более эффективным, сфокусировав его на ключевых моментах пользовательского опыта.
В результате время, потраченное на создание маинд карты, окупается за счет лучшего понимания пользователей и выявления важных проблем на ранней стадии.
Привет, благодарим за обратную связь! Мы ценим комментарии наших читателей и нам важно видеть конструктивную критику.
Ответ автора: не сказал бы, что SDET не нужны там, где используют Low-Code. В процессе создания этой статьи я заметил, что на просторах сети есть интересные вакансии, например, эта: https://builtin.com/job/sdet-appian-experience-remote/2957618 Поэтому было принято решение включить маленький кусочек информации про Low-Code/No-Code платформы. Насчет «воды» могу только указать на тег статьи — это лишь мнение :)
Спасибо за комментарий!:) Постараемся ответить по порядку.
Да, такой вариант рассматривался. Но все же мы решили продолжать разрабатывать и поддерживать проект с использованием KMP, так как мы видим тенденцию развития данной технологии и уверены, что вскоре многие проблемы будут решены. В том числе путем перехода на новый UI Compose Multiplatform. Еще раз подчеркнем, что мы не утверждаем, что KMP — это плохая технология и ее нужно опасаться. Совсем наоборот. Мы говорим о том, к каким неочевидным трудностям управления проектом стоит быть готовым при использовании KMP, а также делаем вывод, что при росте масштаба проекта и сложности бизнес-логики растет и фатальность допущенных ошибок.
и 3. Согласны с вами по поводу современных языков программирования. На счет формирования команды автор полагает, что здесь решает, в том числе, владелец проекта и то финансирование, которое он готов вложить команду разработки. Универсальный разработчик - не редкость, но его экспертность дороже оплачивается. Такие специалисты конечно ценятся на проекте, но иногда нужно больше «неуниверсальных» рук и умов, чтобы уложиться в поставленные сроки)
Да, фиксировать контракты между доменной и нативными частями необходимо в любом случае. Но если приложение полностью нативное, то разработчики часто работают по конкретному флоу, реализуя все механизмы от самых низших слоев к высшим (если мы говорим Clean Architecture) и сам более гибко может менять контракт
Конечно нет, KMP не виновник проблем проекта) Все инструменты хороши, нужно уметь ими правильно пользоваться
Новичкам в разработке мы обычно советуем начать с этих книг, независимо от языка программирования: • «Чистый код» Р.Мартина • «Грокаем алгоритмы» А.Бхаргава — очень помогает с базовыми пониманием, что такое алгоритмы, какие бывают и т.д. • «2022. System Design. Подготовка к сложному интервью» — очень рекомендуем прочитать 1 и 2 главу всем, кто планирует работать с микросервисами и т.д. • «TDD Экстремальное программирование» К.Бека — нужно ознакомиться с водной частью (1 и 2 глава), дальше идет уже сильно специфическая тематика.
Для тех, кто только задумался о том, чтобы освоить Golang, можем порекомендовать «Head First. Изучаем Go» Джея Макгаврен, после которой лучше сразу читать «Go на практике» Мэтта Батчера и Мэтта Фарина.
Все остальные книги и последовательность опциональны от выбора и предпочтений молодого бойца на Go :)
Спасибо, работает! Пока работала над этой задачей, тестировала на собственных ссылках, и всегда открытая фигма как раз иконку не отдает :) У них иконки лежат по другому урлу —static.figma.com. Вашим способом фигмовскую иконку я добыла :) Правда, страшненькая, маленькая, но все-таки! Это хороший повод поискать еще несколько вариантов добычи иконок и написать вторую часть статьи :)
Спасибо за комментарий! Действительно, часто иконку не находим, но для наших нужд этого пока хватает. А вот искать иконку с указанием размеров — это идея! Уже думаю :)
В нашем проекте нет такой функции, чтобы обмениваться личными сообщениями. Если появится такая тема, я обязательно учту этот момент, спасибо за то, что обратили внимание :)
Спасибо, что так погрузились! Про «парсить код страницы» — это возможно после того, как ты этот код получишь, а как его получить? Опять запрос, от них отказались. Насчет кэшировать — пока считается, что пользователи пользуются нашим приложением не для хранения ссылок, так что по идее нагрузки большой не должно быть, если появится необходимость, будем думать. Маленький размер картинки тоже пока устраивает :)
@AVF_613 частично с Вами согласны по поводу поддержания базы процессов. Это действительно трудоемкий процесс, поэтому не нужно описывать все подряд. Моделирование оправдано там, где есть риски, где нужен анализ, где нужна исполнимость процесса в BPMS, а также для проектирования новых для компании процессов. Для этого обычно в компаниях с культурой процессного управления создаются процессные офисы.
Не можем согласиться с высказыванием, что бизнес не разбирается. Если вы встречались с такой ситуацией, то, возможно, у бизнеса не было необходимости в этом разбираться. Это могло быть связано с тем, что культура процессного управления в компании слабо развита, а она начинается с самой верхушки управления. Если там нет заинтересованности, то и ниже ее не будет.
Так же все же считаем, что Lean и ТОС — не инструменты. Это две методологии, которые включают в себя инструменты улучшения бизнес-процессов. Но чтобы что-то улучшить, нужно сначала найти эти «узкие» места, и в этом хорошим подспорьем является процессный подход (опять же, который не заключается в тотальной регламентации).
Данная статья является первой частью цикла статей. Вторая часть доступна тут. И там как раз про этап поиска путей улучшения. По результатам найденных и оцененных методологических улучшений уже принимается решение бизнесом о запуске различных изменений и проектов, в том числе проектов по автоматизации или замене имеющихся методов автоматизации. И вот уже в рамках этих проектов проводится полное обследование и описание модели данных, статусной модели, оцениваются рыночные предложения, выбирается путь автоматизации и прочее.
Опечатка. В статье исправили)
Действительно так, спасибо за уточнение ❤️
Действительно так, не следующие 10 бит, а младшие 10 бит. В статье исправили, спасибо!
Добрый день. Если в группе будет хотя бы 1 свободный слот (не tombstone) и не будет искомого элемента, то поиск прекратиться.
При отсутствии искомого элемента и свободных слотов алгоритм переключится на следующую группу.
Обычное тестирование — это тестирование форм, создание, редактирование документов/отчетов, наполнение регистров и т.д. Интеграционное тестирование — это проверка взаимодействия системы 1С с внешними или внутренними ресурсами/микросервисами, например через API или HTTP запросы. Именно такие примеры описаны в статье. А именно инструменты 1С, с помощью которых происходит это взаимодействие.
Привет! Конфигурация выполняется платформой, пользователь взаимодействует с платформой, которая имеет свою конфигурацию. Конфигурация может изменяться под потребности заказчика.
Спасибо за полезное и очень важное дополнение! Существует четкое разделение ролей, но, к сожалению, не все компании и заказчики о них в курсе. На многих проектах каноническое распределение обязанностей между специалистами сильно изменилось. Мы стараемся, чтобы как можно больше разработчиков и заказчиков были осведомлены о правильном распределении ролей, а не искали универсального специалиста в качестве «волшебной таблетки от всех проблем».
Наряду с использованием широкого спектра современных инструментов ИБ, мы подбираем и специфические релевантные варианты для каждого конкретного случая.
В некоторых компаниях все еще работают с ПО, которое написано на более ранних версиях Java. И которые в силу различных обстоятельств не могут перейти на более старшие версии. Для них не менее важно уметь настраивать правила безопасности, учитывая и внутренние регламенты организаций.
Мы учитываем все пожелания заказчиков и подбираем решение исходя из ситуации. В этом особенность заказной разработки.
Конечно, использование маинд карты для простой формы ввода может показаться излишним. Автор использовала эту форму в качестве визуального примера, на котором просто объяснить, как такой подход может помочь.
На практике интеллект-карты чаще используются для более сложных проектов, где необходимо глубокое понимание пользовательского опыта. Вот почему это помогает:
лучше понять, как пользователи будут взаимодействовать с продуктом;
выявить скрытые проблемы, которые могут быть не очевидны на первый взгляд;
сделать тестирование более эффективным, сфокусировав его на ключевых моментах пользовательского опыта.
В результате время, потраченное на создание маинд карты, окупается за счет лучшего понимания пользователей и выявления важных проблем на ранней стадии.
Есть такой вариант в Jira https://www.atlassian.com/ru/agile/tutorials/burndown-charts
Привет, благодарим за обратную связь! Мы ценим комментарии наших читателей и нам важно видеть конструктивную критику.
Ответ автора: не сказал бы, что SDET не нужны там, где используют Low-Code. В процессе создания этой статьи я заметил, что на просторах сети есть интересные вакансии, например, эта: https://builtin.com/job/sdet-appian-experience-remote/2957618
Поэтому было принято решение включить маленький кусочек информации про Low-Code/No-Code платформы. Насчет «воды» могу только указать на тег статьи — это лишь мнение :)
Спасибо за комментарий!:) Постараемся ответить по порядку.
Да, такой вариант рассматривался. Но все же мы решили продолжать разрабатывать и поддерживать проект с использованием KMP, так как мы видим тенденцию развития данной технологии и уверены, что вскоре многие проблемы будут решены. В том числе путем перехода на новый UI Compose Multiplatform. Еще раз подчеркнем, что мы не утверждаем, что KMP — это плохая технология и ее нужно опасаться. Совсем наоборот. Мы говорим о том, к каким неочевидным трудностям управления проектом стоит быть готовым при использовании KMP, а также делаем вывод, что при росте масштаба проекта и сложности бизнес-логики растет и фатальность допущенных ошибок.
и 3. Согласны с вами по поводу современных языков программирования. На счет формирования команды автор полагает, что здесь решает, в том числе, владелец проекта и то финансирование, которое он готов вложить команду разработки. Универсальный разработчик - не редкость, но его экспертность дороже оплачивается. Такие специалисты конечно ценятся на проекте, но иногда нужно больше «неуниверсальных» рук и умов, чтобы уложиться в поставленные сроки)
Да, фиксировать контракты между доменной и нативными частями необходимо в любом случае. Но если приложение полностью нативное, то разработчики часто работают по конкретному флоу, реализуя все механизмы от самых низших слоев к высшим (если мы говорим Clean Architecture) и сам более гибко может менять контракт
Конечно нет, KMP не виновник проблем проекта) Все инструменты хороши, нужно уметь ими правильно пользоваться
Спасибо за замечание! На самом деле мы изначально хотели тестировать без внешних вызовов. Но вы правы — оба варианта могут быть использованы)
Новичкам в разработке мы обычно советуем начать с этих книг, независимо от языка программирования:
• «Чистый код» Р.Мартина
• «Грокаем алгоритмы» А.Бхаргава — очень помогает с базовыми пониманием, что такое алгоритмы, какие бывают и т.д.
• «2022. System Design. Подготовка к сложному интервью» — очень рекомендуем прочитать 1 и 2 главу всем, кто планирует работать с микросервисами и т.д.
• «TDD Экстремальное программирование» К.Бека — нужно ознакомиться с водной частью (1 и 2 глава), дальше идет уже сильно специфическая тематика.
Для тех, кто только задумался о том, чтобы освоить Golang, можем порекомендовать «Head First. Изучаем Go» Джея Макгаврен, после которой лучше сразу читать «Go на практике» Мэтта Батчера и Мэтта Фарина.
Все остальные книги и последовательность опциональны от выбора и предпочтений молодого бойца на Go :)
Спасибо за то, что переводите и издаете такие полезные книги :)
Спасибо, работает! Пока работала над этой задачей, тестировала на собственных ссылках, и всегда открытая фигма как раз иконку не отдает :) У них иконки лежат по другому урлу —static.figma.com.
Вашим способом фигмовскую иконку я добыла :) Правда, страшненькая, маленькая, но все-таки! Это хороший повод поискать еще несколько вариантов добычи иконок и написать вторую часть статьи :)
Спасибо за комментарий! Действительно, часто иконку не находим, но для наших нужд этого пока хватает. А вот искать иконку с указанием размеров — это идея! Уже думаю :)
В нашем проекте нет такой функции, чтобы обмениваться личными сообщениями. Если появится такая тема, я обязательно учту этот момент, спасибо за то, что обратили внимание :)
Спасибо, что так погрузились! Про «парсить код страницы» — это возможно после того, как ты этот код получишь, а как его получить? Опять запрос, от них отказались. Насчет кэшировать — пока считается, что пользователи пользуются нашим приложением не для хранения ссылок, так что по идее нагрузки большой не должно быть, если появится необходимость, будем думать. Маленький размер картинки тоже пока устраивает :)