Анатолий Юдов @misato
Пользователь
Информация
- В рейтинге
- Не участвует
- Откуда
- Helsinki, Southern Finland, Финляндия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Fullstack Developer, Scrum Master
Lead
От 7 000 €
PHP
OOP
Git
Agile
Business process management
Project management
JavaScript
MySQL
Web development
План по часам в целом выдерживается. Не вижу ничего сверхъестественного в том, что человек способен оценить время, необходимое на работу, тем более что сложные блоки раскладываются на более простые, которые уже и оцениваются. Исследовательские задачи в которых вообще ничего непонятно можно искусственно ограничивать оценкой (т.е., время в таком случае важнее результата). Это даёт управляемость процесса, нет такого, что все люди вдруг заняты, и некому сделать что-то срочное.
В то же время эта система защищает разработчиков от перегруза, когда всем всё надо сделать срочно. Есть план — в нём и разбирайтесь, кому из вас нужнее. Это хорошо влияет на качество.
Естественно, в этой схеме предусмотрены действия, что делать если человек ошибся с оценкой и как максимально безболезненно осуществлять перепланировку.
В целом я не пытаюсь доказать, что такая система однозначно лучше канбана. Она просто лучше в определённых условиях, когда есть много проектов, много задач, требуется быстрое реагирование и соблюдение каких-то локальных сроков.
По поводу «висят на доске» — видимо мы друг друга не поняли. Я имел в виду, что даже если вы ставите задачу в бэклог с высоким приоритетом, до неё может не дойти дело, поскольку исполнители уже заняты задачами «в процессе», которые там двигаются в тестирование и обратно. Вот эта неопределённость и мешает.
Почему планирование по дням помогает решить проблемы с дележом ресурсов? Потому что при таком подходе проще отследить, кто именно загрузил отдел работой в прошлом, в настоящее время, и в будущем. Это наглядно видно по календарю, а значит с этим можно работать. Менеджеры могут буквально до часов делить ресурсы отдела на следующую неделю и это легко контролируется.
В канбане это гораздо сложнее устроить. Если тебе нужно, чтобы задача была во что бы то ни стало сделана к конкретному дню, тебе нужно постоянно играть с приоритетами, повышая их, по мере приближения дедлайна. И это всё равно не гарантирует выполнения в срок (потому что всё, что уже висит на доске, может затянуться).
Плюс ко всему, когда в компании несколько инициаторов задач и несколько бэклогов, а отдел разработки один, тогда ещё появится и проблема дележа приоритетов (или ресурсов).
В компании, куда я пришёл заниматься организацией деятельности, использовалось нечто, что они называли канбаном. У них были карточки с ограничением количества в работе и прочие вещи. А компании нужна была прозрачность и понимание того, в какой день какая задача будет готова. Всю эту систему мы заменили на планирование по дням, потому что, как мне кажется, система подобная канбану такого дать не может, у неё другие преимущества.
Вы мне пытаетесь доказать, что в канбане можно гарантировать исполнение какой-то задачи в конкретный день. Я и спрашиваю вас, как? Статистические значения здесь не годятся, потому что сроки бывают жёсткими.
То есть, если, например, в приведённой схеме «Сбор требований <--> Анализ и проектирование <--> Разработка <--> Тестирование <--> Развертывание» этап тестирования перегружен, то аналитик не может взять себе новых задач и будет сидеть без дела?
В командах, разрабатывающих ПО, практика канбана чаще сводится к тому, что это, дескать, очень наглядно: в любой момент видно, как много задач мы сделали, и как много ещё предстоит сделать. Хотя очевидно, что если команда использует хоть что-то похожее на учёт задач, то всё то же самое достигается одним простейшим отчётом.
Лично я, пока участвовал в организации работы отдела разработки, предпринял для повышения предсказуемости следующее — предложил избавиться от канбана и внедрить старое-доброе планирование работы по дням недели, что впоследствии очень хорошо сказалось как на предсказуемости результатов, так и на производительности труда, и на прозрачности всего процесса в целом.
«серебренная» => серебряная
Скажу от себя, что Канбан плохо подходит для клиентской поддержки. Казалось бы, он даёт инструмент для быстрого реагирования, но зато полностью отбирает возможность получить какую-либо определённость в сроке исполнения задачи, потому что любая работа может быть сдвинута на неопределённый срок другими задачами.
Да и в целом, я бы не стал называть Канбан методологией. Это скорее удобная практика, которую можно применять в подходящих случаях.
Я бы никогда не стал в лоб спрашивать, какой бюджет — они и сами могут не знать (они и задачу-то свою могут не знать, мало ли что в ТЗ понаписали). Со своей стороны я всегда стараюсь максимально кратко и доходчиво объяснить, почему трудно оценивать уникальные решения. Раз уж ТЗ прилагается — всегда можно назвать и вилку цены, но объяснить, по каким причинам названа вилка, за счёт чего цена может снизиться или вырасти (если мы делаем этот блок сложно, то дороже, если вот этот проще, ну и так далее).
Главное больше спрашивать о задаче, узнать о бизнесе клиента, постараться лучше уловить, какой именно уровень бюджета он ожидает, какой уровень проработанности решения он ожидает. В общем, это практика продаж, здесь готового решения нет.
Иногда он очень важен, иногда жёстко зафиксирован, поэтому и озвучивается раньше прочих требований. Довольно часто бывает и наоборот, конечный бюджет не так важен, как другие требования.