Комментарии 19
А это уже противоречит классическому проекту, у которого обязательно есть финальная дата — дедлайн. У нас дедлайна не быбыло.в
Вот зачем такое говорят? Как нет дедлайна? Он всегда есть. Приходит новое законодательство и сразу-же сроки. Внедряется новая функция вместо старой, надо знать, когда коммукацию к клиентам делать, изменяется внешний вид интерфейса, нужна реклама - когда её делать итд. Что это за вокруг да около, но мы без дедлайна будем работать.
Принеси то, не знаю что. Тогда, не знаю когда...
С одной стороны согласен.
С другой - бывает всякое. Бывают проекты, где нет явной даты, условно "сделать в квартале", а задача размером с недельку-две. Как будет сделана задача - так и будет рассылка на клиентов, будет реклама и остальное. А ещё скрам подразумевает, что вы можете сделать только основную часть фичи в какой то дедлайн, а красоту навести попозже. Водопад классический такие вещи делает со скрипом.
Да, если это новый закон, у которого есть конкретные сроки - дедлайн очевиден, надо взять и сделать. Но нынче все активно что-то пилят, всяческие А\Б тестирования проводят, выкатывают новые продукты и прочее. Тут схема работы и сроки всё равно достаточно гибкие =)
Вот зачем такое говорят?
Чтобы обозначить важное свойство бизнес цели, которое может определить выбор методологии разработки.
Как нет дедлайна?
А что хотим? Нам нужно сделать что-то в срок или сделать что-то полезное?
Я не имею ничего против дедлайнов если они адекватные. Адекватными они могут быть если известен скоуп работ, который я могу оценить. Что делать если известна только цель и условия достижения цели постоянно меняются (т.е. задачи тоже меняются)? Остается либо применить проектный подход надеясь что опытные люди выберут правильный путь и дадут экспертную оценку задачам обозначив тем самым дедлайн, либо пойти в Scrum и каждый спринт поставлять бизнесу что-то полезное (попутно получая колбэк), что постепенно приблизит нас к целе (или к пониманию что цели нужно менять) - мы выбрали второе.
Приходит новое законодательство и сразу-же сроки.
Для разных задач - разные команды. Мы же не отказались от водопада полностью. В банке, помимо Scrum-команд, есть и другие ресурсы, которые могут делать доработки по требованиям регуляторов. Т.е. скорее всего сделаем в водопаде.
Принеси то, не знаю что. Тогда, не знаю когда…
Я бы сказал: “Сделай кое что и покажи через две недели”.
Я бы сказал: “Сделай кое что и покажи через две недели”.
Как вы замеряете качество работы отдельных работников, если дедлайн не проецируется вниз. Демократические голосования я знаю, когда все, даже те, кто не в теме — голосуют за прдложеный вес одного use case. Оно не работает, а делает перекос в сторону «холостых пробегов». Лежит в сущности человека — меньше работать, а больше иметь.
Мне вот интерессно, как это у вас. Спасибо. Минус я вам не ставил. Кому-то другому ваш ответ не пришелся по душе.
Как вы замеряете качество работы отдельных работников, если дедлайн не проецируется вниз.
Я не понимаю почему вы свзываете метрики качества и дедлайн. Дедлайн может повлиять на качество (его можно сознательно понизить ради скорости), но я не вижу связи способов оценки качества и дедлайна.
Мне вот интерессно, как это у вас.
Если говорить про качество кода (можно ведь оценивать не только код - в команде не только прогаммисты), то это ревью кода + статический анализ кода. Причем мерж риквесты принимают люди не из команды (нельзя мержить свои же изменения) - это я к тому что разработчик, которому прилетел мерж риквест скорее всего не вкурсе есть ли дедлайн по задаче в рамках которой этот код написан.
Но на уровне подходов исключать дедлайн, как сущность — во-первых не правильно, а во-вторых — от левого, он всё равно там присутствует.
Почему неправильно ? В скрам-гайде даже слова "deadline" нет (https://scrumguides.org/scrum-guide.html).
Вот и именно, а если вы свои команды выстраиваете по agile, и сущность дедлайна в нём не прописана, как вы будете делать изменения в системе если придут сроки извне - не вами выставляемые, а рынком, регулятором или правительством? Об этом разговор, а не о том, как какие-то рюшечки перекрасить и при этом никому не обещать, когда вы будете с этим готовы.
Если нужно собрать команду для решения задач с дедлайном, то я бы не рекомендовал создавать для этого Scrum-команду. Например, когда мы присоединяли к себе другой банк, создавался проект "слияние с банком ХХХ", под этот проект собирали проектную команду с дедлайном, количество людей в которой было достаточно чтобы успеть к этому дедлайну.
Статью читал очень скептически:
В онлайн из оффлайна не идут просто потому, что хочется иметь возможность по ходу задать кучу вопросов и уточнений, нет доверия к автоматическим системам
делая упрощённую начальную анкету, вы не только увеличиваете эффективность, но и теряете часть людей, которые привыкли заполнять анкету целиком, чтобы понимать, что будет дальше. А так есть эффект "кота в мешке", как, например, у сайтов, нас которых "прайс лист только по запросу, оставьте свой телефон".
Но зашёл на сайт, и прям восхитилсявосхитился формой, особенно вводом даты рождения: это очень удобно, круто, что вы заботитесь о таких мелочах!
В онлайн из оффлайна не идут просто потому, что хочется иметь возможность по ходу задать кучу вопросов и уточнений, нет доверия к автоматическим системам
Онлайн не мешает оффлайну. Мы не отменяли офисный вариант подачи заявки - мы просто его оптимизировали.
делая упрощённую начальную анкету, вы не только увеличиваете эффективность, но и теряете часть людей, которые привыкли заполнять анкету целиком, чтобы понимать, что будет дальше. А так есть эффект "кота в мешке", как, например, у сайтов, нас которых "прайс лист только по запросу, оставьте свой телефон"
Во время разработки "короткой анкеты" мы проводили исследования клиентского опыта, которые показали, что люди хотят простую анкету. А после релиза этой доработки количество поданых заявок (и что важно, полностю заполненых) сильно выросло. Неговоря уже о том, что стало меньше негатива от клиентов получивших отказ по заявке, ведь они не тратили на нее много времени.
Scrum, да и в целом любая Agile методология очень слабо отвечает на вопрос "когда будет завершен проект целиком". Scrum - хорошо планирует короткие итерации, а в "долгую" лучше использовать комбинированные методологии, в которых движение между вехами описывается каскадно (мы создаем новый продукт) или спирально (мы непрерывного его улучшаем).
Внутри вехи ставится цель описанная по SMART с четкими дедлайнами и набором качественных и колличественных характеристик итогового продукта.
То, чо уже давно существуещее называют своим именем — в этом нет ничего плохого. Плохое в этом то, что всегда такая итеративная методика существовала бок о бок с другими. Но сегодня всё это сметается и остаётся только одна, которая нигде не может удовлтворить все требования. И допускает или способствует сильному перекосу. Во всём.
Я провел несколько ипотечных сделок, и мне есть с чем сравнить. Например, личное присутствие в банке на сделке:
ВТБ - 1 час.
Банк Транспортный (давно, сейчас закрыт) - 1 час.
ПСБ - 3 часа.
Сделка в ПСБ была самая беспорядочная. Начиная от того, что посылали туда где закрыто (а подойдите в окно №... на этаже №...) заканчивая тем, что за 12 часов до сделке я узнал, что электронной регистрации не будет. И нужно было срочно искать запись свободную в МФЦ для подачи документов... Если бы это было известно за 2 недели, то все прошло бы проще.
Основная беда всех банков - это наплевательское отношение к документам. Документы подаются за 2-3 недели до сделки, а проверять их начинают за 2 дня. И в эти 2 дня начинается адок, когда - тут нужно переделать, это не подходит, а где справка №.... от ....? А плевать, что справки нет в перечне документов, которые запросили. Вы нам ее предоставте. А самое смешное, что на сделке о данной справке и не вспомнили.
Вообщем, очень рекомендую самостоятельно взять в "своем" банке ипотеку (кредит) и т.д. и пройти все круги ада.
Кста, с ведением электронных сделок ситуация начинает исправляться, т.к. документы начинают проверять по этапам =)))
Спасибо за отзыв, обязательно доведу его до нашего ипотечного бизнеса. От себя хочу добавит: да, проблемы на сделках действительно бывают и мы о них знаем (кстати, у меня уже вторая ипотека в ПСБ), но в этом году сильно процесс улучшили, а в следующем году планируем сделать электронную регистрацию закладной.
Несмотря на то, что онлайн-оформление кредита проще и удобнее, чем поход в офис банка, процент выдачи таких кредитов был низкий.
Точнее, мы знали, что онлайн-версия заявки повторяла один в один офисный вариант, заполняемый сотрудником на месте, и не учитывала современные тенденции и опыт современных пользователей.
Давайте я, как клиент банка, расскажу в чём проблема.
Если человек пришёл в банк, то он точно хочет кредит, юзеру может быть просто интересно.
Не хватает ответов на вопросы, которые задаются сотруднику банка(по крайней мере когда брал у вас кредит я этого не видел). А именно, что со страховкой, а можно будет платёж перенести, мне 2ндфд щас заказать или пока рано, и прочее и прочее. Вам бы провести масштабный опрос операторов на эту тему, что спрашивают клиенты. Э
Если человек пришёл в банк, то он точно хочет кредит, юзеру может быть просто интересно.
Наш банк будет рад если клиент придет в офис - менеджеры ему все подробно расскажут. Эту опцию мы не отменяем. Но есть и менее трудный путь даже если клиент не хочет использовать сайт/приложение - позвонить в колл-центр.
Вам бы провести масштабный опрос операторов на эту тему, что спрашивают клиенты.
Наши бизнес-аналитики периодически проводят такие исследования.
Сад из обломков монолита: как ПСБ перешел на Scrum