Я не рассматриваю ручное редактирование файлов как целевой процесс изменения справочников. Вряд ли стоит экономить на разработке приложения для редактирования справочника, которое позволит вносить данные в соответствии со схемой данных и допустимыми значениями атрибутов - откровенный мусор оно будет отсекать сразу. Здесь продуктовый каталог в виде JSON файла показан в качестве примера.
Автор пытается понять, чем в лучшую сторону девопс-инженер отличается от обычного, нормального админа, не застрявшего в прошлом веке
Возможно тем, что девопс, что называется, проактивен? Т.е. это не тот случай, когда его нужно просить что-то сделать ("сначала создай мне задачу в Jira, и согласуй ее с моим начальником"), а наоборот - он сам предлагает что-то поменять (узнает у разрабов какие сервисы и как мониторить, настроит заббикс, расскажет об этом специалистам поддержки, ...).
Или вы считаете что админы всегда настроены улучшать процессы и технологии даже если их никто не просит об этом?
Если человек пришёл в банк, то он точно хочет кредит, юзеру может быть просто интересно.
Наш банк будет рад если клиент придет в офис - менеджеры ему все подробно расскажут. Эту опцию мы не отменяем. Но есть и менее трудный путь даже если клиент не хочет использовать сайт/приложение - позвонить в колл-центр.
Вам бы провести масштабный опрос операторов на эту тему, что спрашивают клиенты.
Наши бизнес-аналитики периодически проводят такие исследования.
Спасибо за отзыв, обязательно доведу его до нашего ипотечного бизнеса. От себя хочу добавит: да, проблемы на сделках действительно бывают и мы о них знаем (кстати, у меня уже вторая ипотека в ПСБ), но в этом году сильно процесс улучшили, а в следующем году планируем сделать электронную регистрацию закладной.
Если нужно собрать команду для решения задач с дедлайном, то я бы не рекомендовал создавать для этого Scrum-команду. Например, когда мы присоединяли к себе другой банк, создавался проект "слияние с банком ХХХ", под этот проект собирали проектную команду с дедлайном, количество людей в которой было достаточно чтобы успеть к этому дедлайну.
Как вы замеряете качество работы отдельных работников, если дедлайн не проецируется вниз.
Я не понимаю почему вы свзываете метрики качества и дедлайн. Дедлайн может повлиять на качество (его можно сознательно понизить ради скорости), но я не вижу связи способов оценки качества и дедлайна.
Мне вот интерессно, как это у вас.
Если говорить про качество кода (можно ведь оценивать не только код - в команде не только прогаммисты), то это ревью кода + статический анализ кода. Причем мерж риквесты принимают люди не из команды (нельзя мержить свои же изменения) - это я к тому что разработчик, которому прилетел мерж риквест скорее всего не вкурсе есть ли дедлайн по задаче в рамках которой этот код написан.
В онлайн из оффлайна не идут просто потому, что хочется иметь возможность по ходу задать кучу вопросов и уточнений, нет доверия к автоматическим системам
Онлайн не мешает оффлайну. Мы не отменяли офисный вариант подачи заявки - мы просто его оптимизировали.
делая упрощённую начальную анкету, вы не только увеличиваете эффективность, но и теряете часть людей, которые привыкли заполнять анкету целиком, чтобы понимать, что будет дальше. А так есть эффект "кота в мешке", как, например, у сайтов, нас которых "прайс лист только по запросу, оставьте свой телефон"
Во время разработки "короткой анкеты" мы проводили исследования клиентского опыта, которые показали, что люди хотят простую анкету. А после релиза этой доработки количество поданых заявок (и что важно, полностю заполненых) сильно выросло. Неговоря уже о том, что стало меньше негатива от клиентов получивших отказ по заявке, ведь они не тратили на нее много времени.
Чтобы обозначить важное свойство бизнес цели, которое может определить выбор методологии разработки.
Как нет дедлайна?
А что хотим? Нам нужно сделать что-то в срок или сделать что-то полезное?
Я не имею ничего против дедлайнов если они адекватные. Адекватными они могут быть если известен скоуп работ, который я могу оценить. Что делать если известна только цель и условия достижения цели постоянно меняются (т.е. задачи тоже меняются)? Остается либо применить проектный подход надеясь что опытные люди выберут правильный путь и дадут экспертную оценку задачам обозначив тем самым дедлайн, либо пойти в Scrum и каждый спринт поставлять бизнесу что-то полезное (попутно получая колбэк), что постепенно приблизит нас к целе (или к пониманию что цели нужно менять) - мы выбрали второе.
Приходит новое законодательство и сразу-же сроки.
Для разных задач - разные команды. Мы же не отказались от водопада полностью. В банке, помимо Scrum-команд, есть и другие ресурсы, которые могут делать доработки по требованиям регуляторов. Т.е. скорее всего сделаем в водопаде.
Принеси то, не знаю что. Тогда, не знаю когда…
Я бы сказал: “Сделай кое что и покажи через две недели”.
Я не рассматриваю ручное редактирование файлов как целевой процесс изменения справочников. Вряд ли стоит экономить на разработке приложения для редактирования справочника, которое позволит вносить данные в соответствии со схемой данных и допустимыми значениями атрибутов - откровенный мусор оно будет отсекать сразу. Здесь продуктовый каталог в виде JSON файла показан в качестве примера.
Возможно тем, что девопс, что называется, проактивен? Т.е. это не тот случай, когда его нужно просить что-то сделать ("сначала создай мне задачу в Jira, и согласуй ее с моим начальником"), а наоборот - он сам предлагает что-то поменять (узнает у разрабов какие сервисы и как мониторить, настроит заббикс, расскажет об этом специалистам поддержки, ...).
Или вы считаете что админы всегда настроены улучшать процессы и технологии даже если их никто не просит об этом?
Согласен. Много файлов ≠ сложный код. Разве будет хуже поместить файлы Request и Response в папку посвященную их фиче (вместе с файлом контроллера)?
Неужели лучше скролить файл с несколькими классами?
Наш банк будет рад если клиент придет в офис - менеджеры ему все подробно расскажут. Эту опцию мы не отменяем. Но есть и менее трудный путь даже если клиент не хочет использовать сайт/приложение - позвонить в колл-центр.
Наши бизнес-аналитики периодически проводят такие исследования.
Спасибо за отзыв, обязательно доведу его до нашего ипотечного бизнеса. От себя хочу добавит: да, проблемы на сделках действительно бывают и мы о них знаем (кстати, у меня уже вторая ипотека в ПСБ), но в этом году сильно процесс улучшили, а в следующем году планируем сделать электронную регистрацию закладной.
Спасибо за комментарий. Плюсую.
Если нужно собрать команду для решения задач с дедлайном, то я бы не рекомендовал создавать для этого Scrum-команду. Например, когда мы присоединяли к себе другой банк, создавался проект "слияние с банком ХХХ", под этот проект собирали проектную команду с дедлайном, количество людей в которой было достаточно чтобы успеть к этому дедлайну.
Я не понимаю почему вы свзываете метрики качества и дедлайн. Дедлайн может повлиять на качество (его можно сознательно понизить ради скорости), но я не вижу связи способов оценки качества и дедлайна.
Если говорить про качество кода (можно ведь оценивать не только код - в команде не только прогаммисты), то это ревью кода + статический анализ кода. Причем мерж риквесты принимают люди не из команды (нельзя мержить свои же изменения) - это я к тому что разработчик, которому прилетел мерж риквест скорее всего не вкурсе есть ли дедлайн по задаче в рамках которой этот код написан.
Онлайн не мешает оффлайну. Мы не отменяли офисный вариант подачи заявки - мы просто его оптимизировали.
Во время разработки "короткой анкеты" мы проводили исследования клиентского опыта, которые показали, что люди хотят простую анкету. А после релиза этой доработки количество поданых заявок (и что важно, полностю заполненых) сильно выросло. Неговоря уже о том, что стало меньше негатива от клиентов получивших отказ по заявке, ведь они не тратили на нее много времени.
Почему неправильно ? В скрам-гайде даже слова "deadline" нет (https://scrumguides.org/scrum-guide.html).
Чтобы обозначить важное свойство бизнес цели, которое может определить выбор методологии разработки.
А что хотим? Нам нужно сделать что-то в срок или сделать что-то полезное?
Я не имею ничего против дедлайнов если они адекватные. Адекватными они могут быть если известен скоуп работ, который я могу оценить. Что делать если известна только цель и условия достижения цели постоянно меняются (т.е. задачи тоже меняются)? Остается либо применить проектный подход надеясь что опытные люди выберут правильный путь и дадут экспертную оценку задачам обозначив тем самым дедлайн, либо пойти в Scrum и каждый спринт поставлять бизнесу что-то полезное (попутно получая колбэк), что постепенно приблизит нас к целе (или к пониманию что цели нужно менять) - мы выбрали второе.
Для разных задач - разные команды. Мы же не отказались от водопада полностью. В банке, помимо Scrum-команд, есть и другие ресурсы, которые могут делать доработки по требованиям регуляторов. Т.е. скорее всего сделаем в водопаде.
Я бы сказал: “Сделай кое что и покажи через две недели”.