Некорректно называть мою роль менеджер команды — я один из заказчиков, который за всю жизнь написал пару сотен строк кода на питоне. Планировать сроки за команду и провести правильную декомпозицию по трем нашим приложениям, самостоятельно я не смогу. По-науке правильно назвать мою роль «владелец продукта».
Да, количество работы, что бы оценить задачу и сказать когда она будет готова, безусловно стало больше. Раньше мы быстро определяли стори (которые как-то в голове заказчиков мапились в дни). На на этапе разработки, когда разраб придумывал решение, выяснялось что все сложнее — какая то функциональность не изучена на дискавери, для какой-то не хватает технических возможностей системы. А дни уже в головах продукт-менеджеров. Спринтов у нас не было, так как канбан, и он не гарантирует, что задача будет на проде хотя бы когда-нибудь.
Собственно, мы вынесли этап придумывания решения в начало жизни задачи, после которого становиться понятно что в задаче надо кодить, и лучше получается ее оценить.
Насколько я знаю у нас на переработках никто не сидит, а что бы более детально раскрыть как происходит оценка, сейчас позову коллег. Для меня это черный ящик, в который кладешь задачи и получаешь дату.
Нам было страшно на них переходить — дата не сторь, накладывает обязательства.
Если есть due от заказчика, то работаем с ним. Такое бывает, когда есть внешние ограничения, не зависящие от команды. Например когда мы блокируем другую систему, или есть срок от аудиторов. В таком случае все понятно — ставим эту дату.
Если такого нет, то команда смотрит задачу, и после архитектуры прикидываем, когда получится ее сделать. После этого договариваемся с заказчиком, что будем в ней делать, почему считаем, что решение должно быть таким, и почему такой срок. На этом этапе нет споров, так как воспиталось доверие между командой и заказчиками.
Отпуска — закладываем в due, около 10% накидываем на непредвиденные ситуации. По мере разработки большой задачи (от нескольких недель которая) встречаемся и синхронизируемся успеваем ли к due.
В Тинькофф Бизнес мы строим экосистему для юридических лиц.
Конкретно наша команда занимается кредитными и гарантийными продуктами.
Цель кредита — дать клиенту денег, исходя из его потребностей — например для закрытия кассовых разрывов подходит овердрафт. Для того что бы закупить больше товара для последующей продажи — оборотный кредит. Выдаем кредиты на инвестиционные цели.
Банковская гарантия — это продукт для клиентов, которые участвуют в государственных закупках. Гарантия значит, что банк готов поручиться за то, что клиент выполнит требования контракта перед госкомпанией.
Наша цель — сделать процессы комфортными для клиента. Это достигается разными продуктовыми механиками — например, научиться получать бухгалтерские отчетности через личный кабинет, или проверять заявку клиента на большУю сумму андеррайтером. Выявление этой потребности требует от бизнес-аналитика глубокого изучения рынка и клиента.
Извините, тут я писал ответ на вопрос выше, но случайно начал писать не в ответах, а новый комментарий :(
Поэтому я поменял текст и приложил мем, что бы в этом комментарии была польза
Это история о том, как мы выправляли наше деливери. Приемы, благодаря которым у нас получилось — универсальны, и наверняка могут быть полезны и сработают не только у нас
Идея о закупке разработчикам пива для достижения пика Балмера тоже была (:
Немного поправлю касательно того, что мы сделали. Бэклог мы реализовывали на новом стеке, со стороны бизнеса все выглядело как поставка новой ценности, а не рефакторинг.
Инвестировали в новый процесс, так как продукты прошли этап стартапа, начали появляться требования о гибком наследовании логики между приложениями, стабильности контура и всяких таких вот штуках. На старом стеке это сделать было нельзя.
Due-дата — это дата, к которому мы ожидаем задачу на проде.
Архитектора взяли с рынка, новый тимлид повышение получил, старый тимлид тяготел к инфраструктурным задачам, заглядывая глубоко внутрь техники. Это круто, но для продуктовой команды, которая пытается нащупать клиентов и идеальный продукт, к сожалению, не подходит. Сейчас он пилит приложения для автоматического тестирования бизнес-процессов.
Менеджеры — это команда кредитования, с общими целями. Все в контексте задач друг друга, и понимают ценность фичей. Поэтому при новых задачах получается эффективно договориться. Фасилитацией занимаюсь я.
Пару слов о том, как мы набираем задачи — планируем верхнеуровневыми мазками фичи на квартал, дальше по мере освобождения бэклога договариваемся, что пойдет в разработку следующим.
Некорректно называть мою роль менеджер команды — я один из заказчиков, который за всю жизнь написал пару сотен строк кода на питоне. Планировать сроки за команду и провести правильную декомпозицию по трем нашим приложениям, самостоятельно я не смогу. По-науке правильно назвать мою роль «владелец продукта».
Да, количество работы, что бы оценить задачу и сказать когда она будет готова, безусловно стало больше. Раньше мы быстро определяли стори (которые как-то в голове заказчиков мапились в дни). На на этапе разработки, когда разраб придумывал решение, выяснялось что все сложнее — какая то функциональность не изучена на дискавери, для какой-то не хватает технических возможностей системы. А дни уже в головах продукт-менеджеров. Спринтов у нас не было, так как канбан, и он не гарантирует, что задача будет на проде хотя бы когда-нибудь.
Собственно, мы вынесли этап придумывания решения в начало жизни задачи, после которого становиться понятно что в задаче надо кодить, и лучше получается ее оценить.
Насколько я знаю у нас на переработках никто не сидит, а что бы более детально раскрыть как происходит оценка, сейчас позову коллег. Для меня это черный ящик, в который кладешь задачи и получаешь дату.
Если есть due от заказчика, то работаем с ним. Такое бывает, когда есть внешние ограничения, не зависящие от команды. Например когда мы блокируем другую систему, или есть срок от аудиторов. В таком случае все понятно — ставим эту дату.
Если такого нет, то команда смотрит задачу, и после архитектуры прикидываем, когда получится ее сделать. После этого договариваемся с заказчиком, что будем в ней делать, почему считаем, что решение должно быть таким, и почему такой срок. На этом этапе нет споров, так как воспиталось доверие между командой и заказчиками.
Отпуска — закладываем в due, около 10% накидываем на непредвиденные ситуации. По мере разработки большой задачи (от нескольких недель которая) встречаемся и синхронизируемся успеваем ли к due.
В Тинькофф Бизнес мы строим экосистему для юридических лиц.
Конкретно наша команда занимается кредитными и гарантийными продуктами.
Цель кредита — дать клиенту денег, исходя из его потребностей — например для закрытия кассовых разрывов подходит овердрафт. Для того что бы закупить больше товара для последующей продажи — оборотный кредит. Выдаем кредиты на инвестиционные цели.
Банковская гарантия — это продукт для клиентов, которые участвуют в государственных закупках. Гарантия значит, что банк готов поручиться за то, что клиент выполнит требования контракта перед госкомпанией.
Наша цель — сделать процессы комфортными для клиента. Это достигается разными продуктовыми механиками — например, научиться получать бухгалтерские отчетности через личный кабинет, или проверять заявку клиента на большУю сумму андеррайтером. Выявление этой потребности требует от бизнес-аналитика глубокого изучения рынка и клиента.
Поэтому я поменял текст и приложил мем, что бы в этом комментарии была польза
Идея о закупке разработчикам пива для достижения пика Балмера тоже была (:
Немного поправлю касательно того, что мы сделали. Бэклог мы реализовывали на новом стеке, со стороны бизнеса все выглядело как поставка новой ценности, а не рефакторинг.
Инвестировали в новый процесс, так как продукты прошли этап стартапа, начали появляться требования о гибком наследовании логики между приложениями, стабильности контура и всяких таких вот штуках. На старом стеке это сделать было нельзя.
Due-дата — это дата, к которому мы ожидаем задачу на проде.
Архитектора взяли с рынка, новый тимлид повышение получил, старый тимлид тяготел к инфраструктурным задачам, заглядывая глубоко внутрь техники. Это круто, но для продуктовой команды, которая пытается нащупать клиентов и идеальный продукт, к сожалению, не подходит. Сейчас он пилит приложения для автоматического тестирования бизнес-процессов.
Менеджеры — это команда кредитования, с общими целями. Все в контексте задач друг друга, и понимают ценность фичей. Поэтому при новых задачах получается эффективно договориться. Фасилитацией занимаюсь я.
Пару слов о том, как мы набираем задачи — планируем верхнеуровневыми мазками фичи на квартал, дальше по мере освобождения бэклога договариваемся, что пойдет в разработку следующим.