Правильно ли я понимаю, что в таком случае разработчик просто пишет код и ничего более? Получается ему не требуется погружаться в контекст, а нужно просто реализовать написанное в документации?
Я считаю, что системный аналитик не должен проектировать реализацию, потому что его сила не в этом.
Возьмем гипотетическую задачу. Мы хотим автоматически оплачивать налоги по вкладам конце года. И в этой задаче есть большая аналитическая часть: надо понять как считать налоги, куда отправлять, какие коды и поля надо заполнять чтобы налоговая приняла такой платеж.
В вашей ситуации, аналитик должен потратить львиную долю времени на проектирование базы, эндпоинтов и контрактов и, если я правильно понял, еще потратить время на все то, что я описал выше. И это еще должно как то повысить TTM, но абсолютно непонятно как это должно быть сделано.
В моем же случае, аналитик занимается той частью, которую разработчик физически выполнить не может. Ну не может он ходить и собирать информацию о том, какие там поля в формуляре надо заполнять. Но разработчик может почти бесплатно спроектировать БД и API, ведь ему это ничего не стоит. Он все равно будет это делать.
Тогда разработчик это просто перекладыватель фантазий аналитика в код? Не проще ли написать транслятор с аналитического в какой-нибудь верхнеуровневый язык, кроме того этих языков у аналитиков весьма много. Заодно можете соотнести с профстандартом который непонятно как вообще был приплетен к разговору.
Нет такой кореляции. Проектирование эндпоинтов дело 2х минут, если это все равно будет отображаться в условном swagger - тащить дубликат в confluence не имеет смысла.
Я не понимаю, вы про бизнес аналитика или про системного? Очень странно что в кросс-функциональных бизнес командах контекст есть только у одного лица. В гибких методологиях весь упор ставиться что бизнес-ценность доносится командой, а не конкретной ролью.
olap не выгружается в рамках бизнес-процесса, это единожды стандартизированный процесс, кроме того это не мешает отразить такое в требованиях. Мы, все же работаем с OLTP данными, не надо смешивать их в одном контексте. Разработчик может в базе распологать данные так, как его душе требуется и зачастую это связанно с особенностями хранения + реализации.
Моя точка зрения в том, что аналитик - переходное звено в PO или SA. Ни тот, ни другой не заправляет реализацией. Ценность разработчика не в знании очередного фреймворка, а в том, что на своей стороне он корректно реализует бизнес-требования и они будут отвечать требованиям надежность, масштабированию и сопровождению. Если для поддержания масштабирования нам надо складывать данные иначе, чем нафантазировал аналитик - так тому и быть.
Не должен системный аналитик проектировать ни бд, ни эндпоинты. Если в вашей компании это называется анализом - грош цена такому анализу.
Смысл системного анализа корректно составить функциональные требования и выяснить узкие места. Например необходимые интеграции, правила обработки данных. Разработчики уж как-нибудь сами разберутся как им гонять данные и куда их складывать.
Фактически в российском ИТ эта должность повсеместно не нужна. Нет в банках в рядовых командах таких процессов что требуют глубокого анализа. Зачастую это просто должность, которая плодит тонны документации устаревающей быстрее чем она пишется и при этом не помогает пониманию работы системы.
2-3 спринта делается одна и та же задача «до идеала» или документация пишется долго и слишком детально
Это исправляется не документированием всего до уровня атомов, а требованием аналитика собирать функциональные требования к функции и контроль чтобы задачи без этого вообще в работу не брались ни в каком виде.
Если валятся сроки реализации, как правило, в этом виновата не разработка и не мифические сжатые сроки. На моей практике оказывалось что бизнес вообще не знает что он хочет, а расхлябанность процессов порождает требования вида «хочу чтобы пользователь мог получить %киллерфича_нейм%». Короче говоря, бизнес понятия не имеет что он хочет, а аналитик не знает или не может вытащить эти данные из него.
Тимлидство в большинстве российских компаниях это особый вид мазохизма когда ты и разраб и аналитик, и между делом за продукт должен болеть между делом в 10 раз подбивая статусы в сливке, ведь менеджмент не может в тикет-систему.
Я вижу что все большее число компаний вместо построения и улучшения процессов уповают на распределенные роли, коллективную ответственность и бесконечные коммуникации в чатах/созвонах без фиксации чего либо в понятных артефактах.
Все это и приводит к тому что у нас все вроде бы что-то делают, но по людям это размазано настолько сильно, что собрать в систему это будет практически невозможно.
Это все конечно хорошо, но до тех пор пока бизнес не захочет "натянуть сову на глобус". С ужасом вспонимаю ситуации когда нужно было поменять что-либо в середине data transform, очень напоминало word когда изменение границы таблицы ломало весь документ.
Было бы классно почитать какие реальные профиты дает Pega для бизнеса как в денежном (полагаю ФОТ сильно режется из-за понижения требуемой квалификации), так и в скорости выкатки фич в условиях кровавого энтерпрайза. И о необходимости сертификации PEGA
Agile выглядит красиво лишь в постах и мечтах. На практике же гибкие методологии вносят неопределенность. Банально все начинается с архитектуры, сегодня бизнесу нужно сделать быстро. Мы закладываем систему с учетом того чтобы сделать быстро (за делать долго бизнес не хочет платить), затем, оказывается, бизнесу все-таки надо сложно. А платить временем снова никто не хочет мотивируя тем что "ну вы же сделали уже этот кусок, переиспользуйте его".
Я понимаю, проблема описываемая мной это сферическая проблема в вакууме и решается она хорошим архитектором, но именно эта проблема показывает что без тз получается хз. И что мы даже при гибких методологиях должны закладывать избыточность системы какой бы простой она не была.
Даже в статье приводится пример:
Это еще не окончательный каталог, но посмотрите и скажите, что тут нужно, что – нет, какие кнопки куда переместить и вообще, как сделать продукт более удобным для вас?
И этот пример показан исключительно с визуальной части, и да, визуальную часть действительно чуть проще менять чем даже простой бекендерский круд. И когда мы пилили простую фичу из палок и клейкой массы, то потом трансформировать её в условный мерседес требует куда больше времени нежели рассказано в постулатах agile.
@ElenaSpb подскажите, а почему было отдано предпочтение к описанию ошибок через файл в ресурсах? Если это валидация в DTO контроллера, то, как правило, на один метод - один DTO. Можно ведь явно указать руками сообщение
Правильно ли я понимаю, что в таком случае разработчик просто пишет код и ничего более? Получается ему не требуется погружаться в контекст, а нужно просто реализовать написанное в документации?
Я считаю, что системный аналитик не должен проектировать реализацию, потому что его сила не в этом.
Возьмем гипотетическую задачу. Мы хотим автоматически оплачивать налоги по вкладам конце года. И в этой задаче есть большая аналитическая часть: надо понять как считать налоги, куда отправлять, какие коды и поля надо заполнять чтобы налоговая приняла такой платеж.
В вашей ситуации, аналитик должен потратить львиную долю времени на проектирование базы, эндпоинтов и контрактов и, если я правильно понял, еще потратить время на все то, что я описал выше. И это еще должно как то повысить TTM, но абсолютно непонятно как это должно быть сделано.
В моем же случае, аналитик занимается той частью, которую разработчик физически выполнить не может. Ну не может он ходить и собирать информацию о том, какие там поля в формуляре надо заполнять. Но разработчик может почти бесплатно спроектировать БД и API, ведь ему это ничего не стоит. Он все равно будет это делать.
Тогда разработчик это просто перекладыватель фантазий аналитика в код? Не проще ли написать транслятор с аналитического в какой-нибудь верхнеуровневый язык, кроме того этих языков у аналитиков весьма много. Заодно можете соотнести с профстандартом который непонятно как вообще был приплетен к разговору.
Нет такой кореляции. Проектирование эндпоинтов дело 2х минут, если это все равно будет отображаться в условном swagger - тащить дубликат в confluence не имеет смысла.
Я не понимаю, вы про бизнес аналитика или про системного? Очень странно что в кросс-функциональных бизнес командах контекст есть только у одного лица. В гибких методологиях весь упор ставиться что бизнес-ценность доносится командой, а не конкретной ролью.
olap не выгружается в рамках бизнес-процесса, это единожды стандартизированный процесс, кроме того это не мешает отразить такое в требованиях. Мы, все же работаем с OLTP данными, не надо смешивать их в одном контексте. Разработчик может в базе распологать данные так, как его душе требуется и зачастую это связанно с особенностями хранения + реализации.
Моя точка зрения в том, что аналитик - переходное звено в PO или SA. Ни тот, ни другой не заправляет реализацией. Ценность разработчика не в знании очередного фреймворка, а в том, что на своей стороне он корректно реализует бизнес-требования и они будут отвечать требованиям надежность, масштабированию и сопровождению. Если для поддержания масштабирования нам надо складывать данные иначе, чем нафантазировал аналитик - так тому и быть.
Не должен системный аналитик проектировать ни бд, ни эндпоинты. Если в вашей компании это называется анализом - грош цена такому анализу.
Смысл системного анализа корректно составить функциональные требования и выяснить узкие места. Например необходимые интеграции, правила обработки данных. Разработчики уж как-нибудь сами разберутся как им гонять данные и куда их складывать.
Фактически в российском ИТ эта должность повсеместно не нужна. Нет в банках в рядовых командах таких процессов что требуют глубокого анализа. Зачастую это просто должность, которая плодит тонны документации устаревающей быстрее чем она пишется и при этом не помогает пониманию работы системы.
Это исправляется не документированием всего до уровня атомов, а требованием аналитика собирать функциональные требования к функции и контроль чтобы задачи без этого вообще в работу не брались ни в каком виде.
Если валятся сроки реализации, как правило, в этом виновата не разработка и не мифические сжатые сроки. На моей практике оказывалось что бизнес вообще не знает что он хочет, а расхлябанность процессов порождает требования вида «хочу чтобы пользователь мог получить %киллерфича_нейм%». Короче говоря, бизнес понятия не имеет что он хочет, а аналитик не знает или не может вытащить эти данные из него.
Тимлидство в большинстве российских компаниях это особый вид мазохизма когда ты и разраб и аналитик, и между делом за продукт должен болеть между делом в 10 раз подбивая статусы в сливке, ведь менеджмент не может в тикет-систему.
Я вижу что все большее число компаний вместо построения и улучшения процессов уповают на распределенные роли, коллективную ответственность и бесконечные коммуникации в чатах/созвонах без фиксации чего либо в понятных артефактах.
Все это и приводит к тому что у нас все вроде бы что-то делают, но по людям это размазано настолько сильно, что собрать в систему это будет практически невозможно.
Это все конечно хорошо, но до тех пор пока бизнес не захочет "натянуть сову на глобус". С ужасом вспонимаю ситуации когда нужно было поменять что-либо в середине data transform, очень напоминало word когда изменение границы таблицы ломало весь документ.
Было бы классно почитать какие реальные профиты дает Pega для бизнеса как в денежном (полагаю ФОТ сильно режется из-за понижения требуемой квалификации), так и в скорости выкатки фич в условиях кровавого энтерпрайза. И о необходимости сертификации PEGA
Agile выглядит красиво лишь в постах и мечтах. На практике же гибкие методологии вносят неопределенность. Банально все начинается с архитектуры, сегодня бизнесу нужно сделать быстро. Мы закладываем систему с учетом того чтобы сделать быстро (за делать долго бизнес не хочет платить), затем, оказывается, бизнесу все-таки надо сложно. А платить временем снова никто не хочет мотивируя тем что "ну вы же сделали уже этот кусок, переиспользуйте его".
Я понимаю, проблема описываемая мной это сферическая проблема в вакууме и решается она хорошим архитектором, но именно эта проблема показывает что без тз получается хз. И что мы даже при гибких методологиях должны закладывать избыточность системы какой бы простой она не была.
Даже в статье приводится пример:
И этот пример показан исключительно с визуальной части, и да, визуальную часть действительно чуть проще менять чем даже простой бекендерский круд. И когда мы пилили простую фичу из палок и клейкой массы, то потом трансформировать её в условный мерседес требует куда больше времени нежели рассказано в постулатах agile.
@ElenaSpb подскажите, а почему было отдано предпочтение к описанию ошибок через файл в ресурсах? Если это валидация в DTO контроллера, то, как правило, на один метод - один DTO. Можно ведь явно указать руками сообщение