Как стать автором
Обновить

Комментарии 34

Мы сделали для бизнеса простой инструмент (таблица в Excel), в которой он мог визуально планировать. Менеджеры дрались между собой, спорили, чья задача важнее, а потом уже приходили к нам и отдавали задачи в разработку.

Так как у нас уже были ограничения, то бизнес относился внимательнее к выбору задач, выбирал наиболее важные, а не заваливал нас всякой ерундой, которая им приходила в голову. И ещё один большой плюс: они отбирали задачи сами без нашего участия, не отвлекая разработчиков на совещания, те спокойно работали и не тратили время на встречи.


Вот это та самая ключевая мера, которая может решить большую часть проблем в любой разработке. Хвала вашему менеджменту, который осилил приоритеты. Не смог бы — все эти метрики, налаживание процессов, вовлеченность, оценка — все коту под хвост. Я видел массу примеров, когда даже слабые тех команды с хиленькими процессами при хорошем проектном менеджменте, который умел фокусироваться на приоритетах, показывали крутой результат, а крутые команды из топовых спецов шли на дно, когда менеджмент не мог элементарно определиться, что же продукту важнее.
Из всех методологий, с которыми я сталкивался, работал только Kanban. А четкие приоритеты задач и достаточное количество ресурсов позволяло решать задачи.
Если ресурсов нет, то никакие изменения процессов не вытащат завал и не уменьшат технологический долг.

Все верно.
"Порядок", бьёт "класс".


Условный бизнес "принял" ограничения и случилась "ещё одна оглушительная победа гибких методологий", продолжил бы заваливать нелепостями с приоритетом major и critical — получили бы как всегда.

Вот мне вообще кажется, что все остальное в этой каше — топор. Менеджеры начали заниматься расстановкой приоритетов, а прогерам предоставляли симпатичную, очищенную от политики и споров картину происходящего.

Не только. Второй ключевой момент — метрики. Начали снимать метрики процессов -> смогли оценивать эффективность -> смогли эти процессы менеджить. Кашу метриками не испортишь.
Конечно, без расстановки приоритетов показаниями метрик бы просто подтирались каждую итерацию.
Спасибо за TL;DR

Подскажите, сколько времени ушло на внедрение этих фич.

У меня на это ушло чуть меньше двух лет. Набивали шишки, экспериментировали и т.д. Сейчас, мне кажется, сделал бы за год или чуть больше (в тех же условиях). Совсем быстро не получится, это утопия.
Мы начали рассуждать: если бэкендеры выполнили свою задачу и передали фронтендерам, то те сразу к ней приступят?

Хм, а что мешало дефинировать интерфейсы и позволить обеим командам работать параллельно?

Проблема не в том, чтобы работать параллельно, а в том, чтобы найти самое узкое место системы. И простой нашего узкого места равен простою всей системы. То есть мы должны эффективно распределять задачи. Например, бекенд может 10, а фронт 5. Если мы завалим всех работой, то на фронтендеров вывалится столько задач, сколько они не смогут отработать. А если мы эти задачи будем копить, то может получиться так, что эти фичи за время ожидания потеряют актуальность. Хотя можно было бы за это время и код отрефакторить, и баги пофиксить.
Проблема не в том, чтобы работать параллельно, а в том, чтобы найти самое узкое место системы.

Ну вообще-то проблема может быть и в том и в другом. Если конкретно у вас бэкэнд вдруг почему то "застрял", то и фронтэнд сидит без работы и ждёт пока бэкэнд доделает. Потом работа у фронтэнда появилась, но уже он может "застрять". А если работаешь параллельно, то такое "застревание" однозначно даёт меньший импакт.


Более того если у вас команды работают параллельно, то их на мой взгляд проще скалировать. Хотя это уже дело вкуса.

бизнес относился внимательнее к выбору задач, выбирал наиболее важные, а не заваливал нас всякой ерундой

бизнес всегда считает свои решения обдуманными, приоритетными и важными, так что просить порядка у тех, кто ломает процессы неразумно.
а кто такой этот «бизнес»? это продукт-оунер? продакт менеджер?

без продакт-овнера опасно развивать продукт, т.к. «бизнесу» всегда нужны фичи еще вчера, и требования могут меняться.
также без архитектора, может быстро накопиться тех долг и новые фичи будут занимать больше времени на отладку и тест, порой геометрически.

мысль: надо обязательно иметь технически подкованного продакт-овнера, и готовить план по развитию продукта на пару лет. Чтобы вся команда знала и была в курсе на какой стадии сейчас и где должны быть в след 3 мес/6 мес/год.

т.е. планировать больше сверху-вниз, а не лишь бы задеплоить в прод как можно больше фичей как бизнес требует (а-ля хуяк-хуяк и в продакшен)
В компании, в которой я это делал, было так. Бизнесом я называю разные юнит единицы: основатель, отдел продаж, отдел логистики, отдел по работе с партнерами и т.д. Не было роли выделенного архитектора, были техлиды направлений. Были аналитики, которые занимались описанием фич, также они занимались и выясняли, что можно сделать для пользователя. Даже мне приходилось выполнять роль продукт-оунера. Отдельной роли продукт оунера не было.
Это одна из ключевых проблем: отсутствие единого ПО. Он нужен как раз для того, что бы все конфликты «бизнеса» превратились в конфликты в его голове и он смог их однозначно решить, расставить приоритеты и выдать roadmap развития продукта.

А без ПО excel-файл будет работать только до тех пор, пока бизнес может и хочет решать конфликты на своей стороне, а это ситуация точно не стабильная.
Как мне кажется многие ваши беды это то, что команда без продукта и кросс-функциональной команды. Конечно интересно, как вы решили проблемы.
Скажите, а чем именно Вы пользуетесь в качестве канбан-доски?
Сначала использовали Trello, потом пробовали Kaiten (https://ru.kaiten.io/)
Можете в двух словах их сравнить? На чём в итоге остановились? Почему решили сменить Trello? Я для себя пытаюсь выбрать доску, не знаю на какие элементы обратить внимание в первую очередь.
Смотрите, в Trello у вас есть доска, но вы не можете разделить, колонки, например, на do и done, также нет возможности поставить WIP-limits. По горизонтали тоже поделить не получится. Кроме того, в Trello нельзя добавлять удобные правила, которые срабатывают, когда вы перетаскиваете карточку из одной колонки в другую. Также там нет инструментов, чтобы строить спектральную и накопительную диаграммы. В Kaiten это все есть.
Понял, спасибо! Гляну на всё это :)
Очень наглядно, все разложено по полочкам
Святой Хаббард!
Я в своей компании использую Trello. Тоже сначала был хаос. Начали переносить все задачи в Trello ставить сроки (конечно с запасом), ответственных. В итоге закончели разработку магазина за 3 месяца.
Мне лично как руководителю не хватало в Trello возможности создать диаграмму Ганта. Для визуализации прогресса по проекту в целом. И держать отчет перед руководством с наличием такой диаграммы намного легче. Так как можно визуализировать все этапы процесса и прогресс по каждому из них. Особенно полезно когда проекты долгосрочные белее чем пол года например.

А вы нашли инструмент для построения Ганта? Поделитесь, пожалуйста :) потому что тоже очень его не хватает

Взять задачи и пытаться увидеть процессы.
Мы сделали для бизнеса простой инструмент (таблица в Excel), в которой он мог визуально планировать. Менеджеры дрались между собой, спорили, чья задача важнее, а потом уже приходили к нам и отдавали задачи в разработку.

Т.е. вместо того, чтобы каждый раз объяснять «разработчики сейчас полностью загружены, прямо сейчас мы за новую задачу взяться не можем» — вы создали визуальный инструмент, который, по-сути, говорил руководству тоже самое. Только без вашего участия.

Потрясающий ход!
Вы не представляете насколько руководство не может понять что значит полностью загружены. Даже если списком задачи в работе писать они тоже не понимают. Но когда рисуешь таблицу по часово и закрашиваешь в ней клеточки. О чудо. Доходит сразу.
Больше задач взять нельзя, так как есть WIP-limit, инженеры должны ждать, когда им помогут её решить. Есть шанс остаться без задач.

А что, собственно, должен делать инженер в такой ситуации?
Они могут фиксить баги, делать рефакторинг, улучшать и т.д. Все то, что я писал в пункте «Мотивация и вовлечённость команд».
Как-то все равно непонятно. Получается что когда кончаются задачи, инженер может взять еще задач (фиксить баги, делать рефакторинг, улучшать и т.д.). Но взять то ему их нельзя, т.к. «есть WIP-limit». Какой-то замкнутый круг. Или имеется в виду, что багофикс, рефакторинг и прочее это отдельный скоуп, который в WIP-limit не учитывается?
У нас есть WIP-лимиты, но никто на них не смотрит. Задач гораздо больше, чем в лимитах, вся доска красная. Ну и ладно, вроде ничего страшного не происходит.
Звучит как «пришло время пересмотреть WIP-лимиты»
Скорее, звучит как «у нас нет WIP лимитов».
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.