Comments 14
Я вчитался в статью и вот что я вижу.
1. У вас была старая команда, которая сделала проект как можно быстрее, но из-за этого накопила тех. долга, на который бизнес не хотел выделять времени.
2. Из-за тех.долга в команде большая токсичность плюс бизнес влезает в ИТ процессы, видимо чтобы ускорить работу.
3. Из-за тех.долга ваш проект напоминает ведро с гайками, поэтому релиз каждый раз долго готовится
Что вы сделали
1. Решили перейти на другой стэк, вместо выполнения бэклога. Бизнес вложил деньги в методику соседнего проекта
2. Ретро решили проводить только в карайних случаях. Хотя пишете что ретро проводите раз в месяц, что нормально, если спринт 2 недели
3. Разогнали старую команду и наняли новую
4. Централизовали роль архитектора
5. Отказались от спринтов и заменили их на некие due-даты (кстати что это?)
Интересно откуда вы пригласили архитектора (из старой команды, из соседнего проекта или со стороны).
Получил ли руководитель соседнего проекта повышение и куда пошёл руководитель старого легаси проекта.
И как вам удаётся контроллировать бизнес? Так как если появится менеджер от бизнеса, скажет впаять вот эту кнопку в релиз или какую-то таблицу в бд, что вы будете делать? :)
1. У вас была старая команда, которая сделала проект как можно быстрее, но из-за этого накопила тех. долга, на который бизнес не хотел выделять времени.
2. Из-за тех.долга в команде большая токсичность плюс бизнес влезает в ИТ процессы, видимо чтобы ускорить работу.
3. Из-за тех.долга ваш проект напоминает ведро с гайками, поэтому релиз каждый раз долго готовится
Что вы сделали
1. Решили перейти на другой стэк, вместо выполнения бэклога. Бизнес вложил деньги в методику соседнего проекта
2. Ретро решили проводить только в карайних случаях. Хотя пишете что ретро проводите раз в месяц, что нормально, если спринт 2 недели
3. Разогнали старую команду и наняли новую
4. Централизовали роль архитектора
5. Отказались от спринтов и заменили их на некие due-даты (кстати что это?)
Интересно откуда вы пригласили архитектора (из старой команды, из соседнего проекта или со стороны).
Получил ли руководитель соседнего проекта повышение и куда пошёл руководитель старого легаси проекта.
И как вам удаётся контроллировать бизнес? Так как если появится менеджер от бизнеса, скажет впаять вот эту кнопку в релиз или какую-то таблицу в бд, что вы будете делать? :)
Привет, спасибо за комментарий (:
Немного поправлю касательно того, что мы сделали. Бэклог мы реализовывали на новом стеке, со стороны бизнеса все выглядело как поставка новой ценности, а не рефакторинг.
Инвестировали в новый процесс, так как продукты прошли этап стартапа, начали появляться требования о гибком наследовании логики между приложениями, стабильности контура и всяких таких вот штуках. На старом стеке это сделать было нельзя.
Due-дата — это дата, к которому мы ожидаем задачу на проде.
Архитектора взяли с рынка, новый тимлид повышение получил, старый тимлид тяготел к инфраструктурным задачам, заглядывая глубоко внутрь техники. Это круто, но для продуктовой команды, которая пытается нащупать клиентов и идеальный продукт, к сожалению, не подходит. Сейчас он пилит приложения для автоматического тестирования бизнес-процессов.
Менеджеры — это команда кредитования, с общими целями. Все в контексте задач друг друга, и понимают ценность фичей. Поэтому при новых задачах получается эффективно договориться. Фасилитацией занимаюсь я.
Пару слов о том, как мы набираем задачи — планируем верхнеуровневыми мазками фичи на квартал, дальше по мере освобождения бэклога договариваемся, что пойдет в разработку следующим.
Немного поправлю касательно того, что мы сделали. Бэклог мы реализовывали на новом стеке, со стороны бизнеса все выглядело как поставка новой ценности, а не рефакторинг.
Инвестировали в новый процесс, так как продукты прошли этап стартапа, начали появляться требования о гибком наследовании логики между приложениями, стабильности контура и всяких таких вот штуках. На старом стеке это сделать было нельзя.
Due-дата — это дата, к которому мы ожидаем задачу на проде.
Архитектора взяли с рынка, новый тимлид повышение получил, старый тимлид тяготел к инфраструктурным задачам, заглядывая глубоко внутрь техники. Это круто, но для продуктовой команды, которая пытается нащупать клиентов и идеальный продукт, к сожалению, не подходит. Сейчас он пилит приложения для автоматического тестирования бизнес-процессов.
Менеджеры — это команда кредитования, с общими целями. Все в контексте задач друг друга, и понимают ценность фичей. Поэтому при новых задачах получается эффективно договориться. Фасилитацией занимаюсь я.
Пару слов о том, как мы набираем задачи — планируем верхнеуровневыми мазками фичи на квартал, дальше по мере освобождения бэклога договариваемся, что пойдет в разработку следующим.
Чтобы без проблем начать делать в 2 раза больше сегодня, нужно было позавчера начать делать по крайней мере в 2 раза меньше.
Из названия статьи почему-то ожидал, что речь пойдет о хитром методе к зашкаливающей продуктивности, а не о том, как она сначала упала сильно, а потом восстанавливалась.
Из названия статьи почему-то ожидал, что речь пойдет о хитром методе к зашкаливающей продуктивности, а не о том, как она сначала упала сильно, а потом восстанавливалась.
Непонятно, какой бизнес анализировал бизнес-аналитик в этом кейсе
Привет, Денис!
В Тинькофф Бизнес мы строим экосистему для юридических лиц.
Конкретно наша команда занимается кредитными и гарантийными продуктами.
Цель кредита — дать клиенту денег, исходя из его потребностей — например для закрытия кассовых разрывов подходит овердрафт. Для того что бы закупить больше товара для последующей продажи — оборотный кредит. Выдаем кредиты на инвестиционные цели.
Банковская гарантия — это продукт для клиентов, которые участвуют в государственных закупках. Гарантия значит, что банк готов поручиться за то, что клиент выполнит требования контракта перед госкомпанией.
Наша цель — сделать процессы комфортными для клиента. Это достигается разными продуктовыми механиками — например, научиться получать бухгалтерские отчетности через личный кабинет, или проверять заявку клиента на большУю сумму андеррайтером. Выявление этой потребности требует от бизнес-аналитика глубокого изучения рынка и клиента.
В Тинькофф Бизнес мы строим экосистему для юридических лиц.
Конкретно наша команда занимается кредитными и гарантийными продуктами.
Цель кредита — дать клиенту денег, исходя из его потребностей — например для закрытия кассовых разрывов подходит овердрафт. Для того что бы закупить больше товара для последующей продажи — оборотный кредит. Выдаем кредиты на инвестиционные цели.
Банковская гарантия — это продукт для клиентов, которые участвуют в государственных закупках. Гарантия значит, что банк готов поручиться за то, что клиент выполнит требования контракта перед госкомпанией.
Наша цель — сделать процессы комфортными для клиента. Это достигается разными продуктовыми механиками — например, научиться получать бухгалтерские отчетности через личный кабинет, или проверять заявку клиента на большУю сумму андеррайтером. Выявление этой потребности требует от бизнес-аналитика глубокого изучения рынка и клиента.
Извините, тут я писал ответ на вопрос выше, но случайно начал писать не в ответах, а новый комментарий :(
Поэтому я поменял текст и приложил мем, что бы в этом комментарии была польза
Поэтому я поменял текст и приложил мем, что бы в этом комментарии была польза
Как вы работаете с due-датами? Можно подробнее? Вижу в этом подходе много подводных камней.
Нам было страшно на них переходить — дата не сторь, накладывает обязательства.
Если есть due от заказчика, то работаем с ним. Такое бывает, когда есть внешние ограничения, не зависящие от команды. Например когда мы блокируем другую систему, или есть срок от аудиторов. В таком случае все понятно — ставим эту дату.
Если такого нет, то команда смотрит задачу, и после архитектуры прикидываем, когда получится ее сделать. После этого договариваемся с заказчиком, что будем в ней делать, почему считаем, что решение должно быть таким, и почему такой срок. На этом этапе нет споров, так как воспиталось доверие между командой и заказчиками.
Отпуска — закладываем в due, около 10% накидываем на непредвиденные ситуации. По мере разработки большой задачи (от нескольких недель которая) встречаемся и синхронизируемся успеваем ли к due.
Если есть due от заказчика, то работаем с ним. Такое бывает, когда есть внешние ограничения, не зависящие от команды. Например когда мы блокируем другую систему, или есть срок от аудиторов. В таком случае все понятно — ставим эту дату.
Если такого нет, то команда смотрит задачу, и после архитектуры прикидываем, когда получится ее сделать. После этого договариваемся с заказчиком, что будем в ней делать, почему считаем, что решение должно быть таким, и почему такой срок. На этом этапе нет споров, так как воспиталось доверие между командой и заказчиками.
Отпуска — закладываем в due, около 10% накидываем на непредвиденные ситуации. По мере разработки большой задачи (от нескольких недель которая) встречаемся и синхронизируемся успеваем ли к due.
С этим-то как раз все понятно. Непонятно другое.
Для того, чтобы поставить due-дату, нужно задачу декомпозировать, оценить время исполнения всех подзадач, вычислить общее время выполнения, заложить всякие митинги и походы в туалет, а после этого нужно еще распланировать другие конкурентные задачи. Просто потому, что они могут конфликтовать по срокам. А могут быть незапланированные задачи поддержки и т.д.
Сдается мне, что это вы, как менеджер, просто сняли с себя некую головную боль и переложили ее на разрабов.
И куча подводных камней тут выглядят следующим образом.
1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы. Скорее всего дорогой лид с зарплатой около 200, на котором и так висит контроль за полчищем джунов. Т.е. лид просто перестал заниматься разработкой и стал менеджером.
2. Если раньше они не вписывались в сроки одной задачи, то просто переносили ее на следующий спринт, а за срыв сроков отдувались менеджеры, то сейчас разрабы просто тупо сидят на переработках. Т.е. упала внеплановая задача или из-за ошибки оценки сроков, и они просто сидят на работе несколько дополнительных часов. И хорошо, если это время покрывается финансово. Чаще всего бесплатно сидят.
Вот и хочется узнать как это происходит на самом деле. А то для меня выглядит такой подход очень рисковым, от которого может и команда разбежаться.
По вопросу донесения до команды бизнесового контекста выполняемой ими задачи — полностью поддерживаю. По поводу due-даты хочу пояснений.
Для того, чтобы поставить due-дату, нужно задачу декомпозировать, оценить время исполнения всех подзадач, вычислить общее время выполнения, заложить всякие митинги и походы в туалет, а после этого нужно еще распланировать другие конкурентные задачи. Просто потому, что они могут конфликтовать по срокам. А могут быть незапланированные задачи поддержки и т.д.
Сдается мне, что это вы, как менеджер, просто сняли с себя некую головную боль и переложили ее на разрабов.
И куча подводных камней тут выглядят следующим образом.
1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы. Скорее всего дорогой лид с зарплатой около 200, на котором и так висит контроль за полчищем джунов. Т.е. лид просто перестал заниматься разработкой и стал менеджером.
2. Если раньше они не вписывались в сроки одной задачи, то просто переносили ее на следующий спринт, а за срыв сроков отдувались менеджеры, то сейчас разрабы просто тупо сидят на переработках. Т.е. упала внеплановая задача или из-за ошибки оценки сроков, и они просто сидят на работе несколько дополнительных часов. И хорошо, если это время покрывается финансово. Чаще всего бесплатно сидят.
Вот и хочется узнать как это происходит на самом деле. А то для меня выглядит такой подход очень рисковым, от которого может и команда разбежаться.
По вопросу донесения до команды бизнесового контекста выполняемой ими задачи — полностью поддерживаю. По поводу due-даты хочу пояснений.
Понял, сейчас постараюсь раскрыть.
Некорректно называть мою роль менеджер команды — я один из заказчиков, который за всю жизнь написал пару сотен строк кода на питоне. Планировать сроки за команду и провести правильную декомпозицию по трем нашим приложениям, самостоятельно я не смогу. По-науке правильно назвать мою роль «владелец продукта».
Да, количество работы, что бы оценить задачу и сказать когда она будет готова, безусловно стало больше. Раньше мы быстро определяли стори (которые как-то в голове заказчиков мапились в дни). На на этапе разработки, когда разраб придумывал решение, выяснялось что все сложнее — какая то функциональность не изучена на дискавери, для какой-то не хватает технических возможностей системы. А дни уже в головах продукт-менеджеров. Спринтов у нас не было, так как канбан, и он не гарантирует, что задача будет на проде хотя бы когда-нибудь.
Собственно, мы вынесли этап придумывания решения в начало жизни задачи, после которого становиться понятно что в задаче надо кодить, и лучше получается ее оценить.
Насколько я знаю у нас на переработках никто не сидит, а что бы более детально раскрыть как происходит оценка, сейчас позову коллег. Для меня это черный ящик, в который кладешь задачи и получаешь дату.
Некорректно называть мою роль менеджер команды — я один из заказчиков, который за всю жизнь написал пару сотен строк кода на питоне. Планировать сроки за команду и провести правильную декомпозицию по трем нашим приложениям, самостоятельно я не смогу. По-науке правильно назвать мою роль «владелец продукта».
Да, количество работы, что бы оценить задачу и сказать когда она будет готова, безусловно стало больше. Раньше мы быстро определяли стори (которые как-то в голове заказчиков мапились в дни). На на этапе разработки, когда разраб придумывал решение, выяснялось что все сложнее — какая то функциональность не изучена на дискавери, для какой-то не хватает технических возможностей системы. А дни уже в головах продукт-менеджеров. Спринтов у нас не было, так как канбан, и он не гарантирует, что задача будет на проде хотя бы когда-нибудь.
Собственно, мы вынесли этап придумывания решения в начало жизни задачи, после которого становиться понятно что в задаче надо кодить, и лучше получается ее оценить.
Насколько я знаю у нас на переработках никто не сидит, а что бы более детально раскрыть как происходит оценка, сейчас позову коллег. Для меня это черный ящик, в который кладешь задачи и получаешь дату.
сейчас позову коллег
Спасибо. Действительно было бы интересно посмотреть на это новшество с другой стороны.
Новшества никакого нет на самом деле :)
Важно заметить, что у нас есть команды которые замечательно живут со сторипоинтами (чтобы не думали, что мы повсеместно мигрируем с них на due date).
На самом деле нет, нагрузка не увеличилась. У разработчиков и до этого были мнения и оценки по трудозатратности задач, но их просто не учитывали. Теперь флоу идет централизованно в следующем виде:
1. Заказчик приходит с задачей к лиду
2. Лид просит кого-нибудь из разработчиков провести архитектуру задачи. Если нужно, то собирает брейншторминг с командой.
3. На основе оценок от разработчиков лид прикидывает сроки, учитывая при этом рабочие дни, отпуска, техдолг и т.д.
Ну и самое важное, что нужно было сказать в начале: due date — это не не твердое обещание, это дедлайн в который мы стремимся уложиться. За исключением дедлайнов по задачам где сроки обусловлены законами и т.д.
Джун у нас в команде всего один, так что тут нет проблем :) Разработкой я вполне успевал заниматься, не было с этим проблем.
Переработок наоборот стало меньше (на мой взгляд), за счет того, что мнение разработчиков стали учитывать при оценке сроков. Сроки были раньше и есть сейчас, они никуда не исчезли. Появилось только сопротивление от команды разработки, которое двигает оценку к более приближенному к реальности значению.
Итого: более точные сроки появились из-за бОльшей вовлеченности команды в эту задачу и из-за бОльшей ответственности со стороны команды.
Важно заметить, что у нас есть команды которые замечательно живут со сторипоинтами (чтобы не думали, что мы повсеместно мигрируем с них на due date).
1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы.
На самом деле нет, нагрузка не увеличилась. У разработчиков и до этого были мнения и оценки по трудозатратности задач, но их просто не учитывали. Теперь флоу идет централизованно в следующем виде:
1. Заказчик приходит с задачей к лиду
2. Лид просит кого-нибудь из разработчиков провести архитектуру задачи. Если нужно, то собирает брейншторминг с командой.
3. На основе оценок от разработчиков лид прикидывает сроки, учитывая при этом рабочие дни, отпуска, техдолг и т.д.
Ну и самое важное, что нужно было сказать в начале: due date — это не не твердое обещание, это дедлайн в который мы стремимся уложиться. За исключением дедлайнов по задачам где сроки обусловлены законами и т.д.
Скорее всего дорогой лид с зарплатой около 200, на котором и так висит контроль за полчищем джунов. Т.е. лид просто перестал заниматься разработкой и стал менеджером.
Джун у нас в команде всего один, так что тут нет проблем :) Разработкой я вполне успевал заниматься, не было с этим проблем.
2. Если раньше они не вписывались в сроки одной задачи, то просто переносили ее на следующий спринт, а за срыв сроков отдувались менеджеры, то сейчас разрабы просто тупо сидят на переработках. Т.е. упала внеплановая задача или из-за ошибки оценки сроков, и они просто сидят на работе несколько дополнительных часов. И хорошо, если это время покрывается финансово. Чаще всего бесплатно сидят.
Переработок наоборот стало меньше (на мой взгляд), за счет того, что мнение разработчиков стали учитывать при оценке сроков. Сроки были раньше и есть сейчас, они никуда не исчезли. Появилось только сопротивление от команды разработки, которое двигает оценку к более приближенному к реальности значению.
Итого: более точные сроки появились из-за бОльшей вовлеченности команды в эту задачу и из-за бОльшей ответственности со стороны команды.
Sign up to leave a comment.
Как делать в два раза больше и получать от этого удовольствие