Комментарии 34
Мы сделали для бизнеса простой инструмент (таблица в Excel), в которой он мог визуально планировать. Менеджеры дрались между собой, спорили, чья задача важнее, а потом уже приходили к нам и отдавали задачи в разработку.
Так как у нас уже были ограничения, то бизнес относился внимательнее к выбору задач, выбирал наиболее важные, а не заваливал нас всякой ерундой, которая им приходила в голову. И ещё один большой плюс: они отбирали задачи сами без нашего участия, не отвлекая разработчиков на совещания, те спокойно работали и не тратили время на встречи.
Вот это та самая ключевая мера, которая может решить большую часть проблем в любой разработке. Хвала вашему менеджменту, который осилил приоритеты. Не смог бы — все эти метрики, налаживание процессов, вовлеченность, оценка — все коту под хвост. Я видел массу примеров, когда даже слабые тех команды с хиленькими процессами при хорошем проектном менеджменте, который умел фокусироваться на приоритетах, показывали крутой результат, а крутые команды из топовых спецов шли на дно, когда менеджмент не мог элементарно определиться, что же продукту важнее.
Из всех методологий, с которыми я сталкивался, работал только Kanban. А четкие приоритеты задач и достаточное количество ресурсов позволяло решать задачи.
Если ресурсов нет, то никакие изменения процессов не вытащат завал и не уменьшат технологический долг.
Если ресурсов нет, то никакие изменения процессов не вытащат завал и не уменьшат технологический долг.
Все верно.
"Порядок", бьёт "класс".
Условный бизнес "принял" ограничения и случилась "ещё одна оглушительная победа гибких методологий", продолжил бы заваливать нелепостями с приоритетом major и critical — получили бы как всегда.
Вот мне вообще кажется, что все остальное в этой каше — топор. Менеджеры начали заниматься расстановкой приоритетов, а прогерам предоставляли симпатичную, очищенную от политики и споров картину происходящего.
Спасибо за TL;DR
Подскажите, сколько времени ушло на внедрение этих фич.
Мы начали рассуждать: если бэкендеры выполнили свою задачу и передали фронтендерам, то те сразу к ней приступят?
Хм, а что мешало дефинировать интерфейсы и позволить обеим командам работать параллельно?
Проблема не в том, чтобы работать параллельно, а в том, чтобы найти самое узкое место системы. И простой нашего узкого места равен простою всей системы. То есть мы должны эффективно распределять задачи. Например, бекенд может 10, а фронт 5. Если мы завалим всех работой, то на фронтендеров вывалится столько задач, сколько они не смогут отработать. А если мы эти задачи будем копить, то может получиться так, что эти фичи за время ожидания потеряют актуальность. Хотя можно было бы за это время и код отрефакторить, и баги пофиксить.
Проблема не в том, чтобы работать параллельно, а в том, чтобы найти самое узкое место системы.
Ну вообще-то проблема может быть и в том и в другом. Если конкретно у вас бэкэнд вдруг почему то "застрял", то и фронтэнд сидит без работы и ждёт пока бэкэнд доделает. Потом работа у фронтэнда появилась, но уже он может "застрять". А если работаешь параллельно, то такое "застревание" однозначно даёт меньший импакт.
Более того если у вас команды работают параллельно, то их на мой взгляд проще скалировать. Хотя это уже дело вкуса.
бизнес относился внимательнее к выбору задач, выбирал наиболее важные, а не заваливал нас всякой ерундой
бизнес всегда считает свои решения обдуманными, приоритетными и важными, так что просить порядка у тех, кто ломает процессы неразумно.
а кто такой этот «бизнес»? это продукт-оунер? продакт менеджер?
без продакт-овнера опасно развивать продукт, т.к. «бизнесу» всегда нужны фичи еще вчера, и требования могут меняться.
также без архитектора, может быстро накопиться тех долг и новые фичи будут занимать больше времени на отладку и тест, порой геометрически.
мысль: надо обязательно иметь технически подкованного продакт-овнера, и готовить план по развитию продукта на пару лет. Чтобы вся команда знала и была в курсе на какой стадии сейчас и где должны быть в след 3 мес/6 мес/год.
т.е. планировать больше сверху-вниз, а не лишь бы задеплоить в прод как можно больше фичей как бизнес требует (а-ля хуяк-хуяк и в продакшен)
без продакт-овнера опасно развивать продукт, т.к. «бизнесу» всегда нужны фичи еще вчера, и требования могут меняться.
также без архитектора, может быстро накопиться тех долг и новые фичи будут занимать больше времени на отладку и тест, порой геометрически.
мысль: надо обязательно иметь технически подкованного продакт-овнера, и готовить план по развитию продукта на пару лет. Чтобы вся команда знала и была в курсе на какой стадии сейчас и где должны быть в след 3 мес/6 мес/год.
т.е. планировать больше сверху-вниз, а не лишь бы задеплоить в прод как можно больше фичей как бизнес требует (а-ля хуяк-хуяк и в продакшен)
В компании, в которой я это делал, было так. Бизнесом я называю разные юнит единицы: основатель, отдел продаж, отдел логистики, отдел по работе с партнерами и т.д. Не было роли выделенного архитектора, были техлиды направлений. Были аналитики, которые занимались описанием фич, также они занимались и выясняли, что можно сделать для пользователя. Даже мне приходилось выполнять роль продукт-оунера. Отдельной роли продукт оунера не было.
Это одна из ключевых проблем: отсутствие единого ПО. Он нужен как раз для того, что бы все конфликты «бизнеса» превратились в конфликты в его голове и он смог их однозначно решить, расставить приоритеты и выдать roadmap развития продукта.
А без ПО excel-файл будет работать только до тех пор, пока бизнес может и хочет решать конфликты на своей стороне, а это ситуация точно не стабильная.
А без ПО excel-файл будет работать только до тех пор, пока бизнес может и хочет решать конфликты на своей стороне, а это ситуация точно не стабильная.
Как мне кажется многие ваши беды это то, что команда без продукта и кросс-функциональной команды. Конечно интересно, как вы решили проблемы.
Скажите, а чем именно Вы пользуетесь в качестве канбан-доски?
Сначала использовали Trello, потом пробовали Kaiten (https://ru.kaiten.io/)
Можете в двух словах их сравнить? На чём в итоге остановились? Почему решили сменить Trello? Я для себя пытаюсь выбрать доску, не знаю на какие элементы обратить внимание в первую очередь.
Смотрите, в Trello у вас есть доска, но вы не можете разделить, колонки, например, на do и done, также нет возможности поставить WIP-limits. По горизонтали тоже поделить не получится. Кроме того, в Trello нельзя добавлять удобные правила, которые срабатывают, когда вы перетаскиваете карточку из одной колонки в другую. Также там нет инструментов, чтобы строить спектральную и накопительную диаграммы. В Kaiten это все есть.
Очень наглядно, все разложено по полочкам
Святой Хаббард!
Я в своей компании использую Trello. Тоже сначала был хаос. Начали переносить все задачи в Trello ставить сроки (конечно с запасом), ответственных. В итоге закончели разработку магазина за 3 месяца.
Мне лично как руководителю не хватало в Trello возможности создать диаграмму Ганта. Для визуализации прогресса по проекту в целом. И держать отчет перед руководством с наличием такой диаграммы намного легче. Так как можно визуализировать все этапы процесса и прогресс по каждому из них. Особенно полезно когда проекты долгосрочные белее чем пол года например.
Мне лично как руководителю не хватало в Trello возможности создать диаграмму Ганта. Для визуализации прогресса по проекту в целом. И держать отчет перед руководством с наличием такой диаграммы намного легче. Так как можно визуализировать все этапы процесса и прогресс по каждому из них. Особенно полезно когда проекты долгосрочные белее чем пол года например.
Взять задачи и пытаться увидеть процессы.
Мы сделали для бизнеса простой инструмент (таблица в Excel), в которой он мог визуально планировать. Менеджеры дрались между собой, спорили, чья задача важнее, а потом уже приходили к нам и отдавали задачи в разработку.
Т.е. вместо того, чтобы каждый раз объяснять «разработчики сейчас полностью загружены, прямо сейчас мы за новую задачу взяться не можем» — вы создали визуальный инструмент, который, по-сути, говорил руководству тоже самое. Только без вашего участия.
Потрясающий ход!
Больше задач взять нельзя, так как есть WIP-limit, инженеры должны ждать, когда им помогут её решить. Есть шанс остаться без задач.
А что, собственно, должен делать инженер в такой ситуации?
Они могут фиксить баги, делать рефакторинг, улучшать и т.д. Все то, что я писал в пункте «Мотивация и вовлечённость команд».
Как-то все равно непонятно. Получается что когда кончаются задачи, инженер может взять еще задач (фиксить баги, делать рефакторинг, улучшать и т.д.). Но взять то ему их нельзя, т.к. «есть WIP-limit». Какой-то замкнутый круг. Или имеется в виду, что багофикс, рефакторинг и прочее это отдельный скоуп, который в WIP-limit не учитывается?
У нас есть WIP-лимиты, но никто на них не смотрит. Задач гораздо больше, чем в лимитах, вся доска красная. Ну и ладно, вроде ничего страшного не происходит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выстроить процессы и перестать издеваться над командой