Современные бизнес-процессы становятся всё более интегрированными друг с другом - разработка, изготовление и финансовый учёт работают вместе на одну цель - увеличить ценность бизнеса и снизить затраты потребителя. За последние 40 лет автоматизация позволила бизнес-процессам выстроиться в непрерывную всеобъемлющую цепочку по созданию добавочной стоимости за счет интеграции в неё специализированных инструментов и практик. Клиенты хотят предоставить информацию о себе и своём заказе один раз. После этого предполагается, что ваша служба поддержки должна знать всё о клиенте и его продукте, а маркетинг от вас ожидается адресный и персональный.

Все идеи кажутся превосходными до тех пор, пока их не столкнуть с действительностью.

Понятие Управления по целям, впервые введенное и популяризированное Питером Ф. Друкером, считалось вполне удачным, за исключением того факта, что данная концепция абсолютно не учитывала возможность элементарного злоупотребления менеджерами этим подходом ради получения большего количества бонусов и премий.

Идея Акционерной стоимости, которую поддержал победитель Нобелевской премии Мильтон Фридман, казалась идеальной в своей теоретической части и совершенной для рациональных умов, при условии игнорирования того, что экономические решения крайне редко бывают рациональны.

Сбалансированная система показателей, разработанная Р. Капланом и Д. Нортоном, стала очень удобным инструментом для менеджеров. Но большинство руководителей полагают, что они управляют своей компанией как машиной, вместо того, чтобы ехать на ней, как на лошади, в то время как электронные информационные панели - не самые лучшие наездники.

Список провальных управленческих идей можно продолжать до бесконечности...

• I-17532 Не могу запланировать пожелание в спринт
• I-17685 В журнале изменение не видно отвественного
• I-17694 Для релизов отображаются даты 1.1.1970
• I-17695 При создании вехи доступно поле для ввода пожелания, оно не работает
• I-17707 Аттач-картинка на попап окне свойств карточки доски задач скачивается вместо открытия
• I-17710 Под IE и FireFox при работе с формами система отдает ответ на странице кодами
• I-17711 При попытке загрузить пользователей из LDAP ничего не происходит
• I-17724 Фильтр по типу требования не работает если одновременно указать некоторый тип и "без типа"
• I-17726 Не изменяется название типа требования в списке разделов, сгруппированных по типам
• I-17758 Cоздал нового пользователя. Ни в какую группу его не включал. Отключил все модули для "...
• I-17759 Не удается скрыть закладку Загрузка ресурсов для группы пользователей

Я заметила, что последние лет пять варианты использования применяются для выявления требований в бизнес-анализе все реже и реже. Тем не менее, некоторые организации продолжают пользоваться ими, поэтому специально для них мы написали одну главу в книге "Визуальные модели для требований к программному обеспечению". Забегая вперед, можете скачать наш шаблон варианта использования, настроить его под себя и пользоваться им снова и снова.

За последние 2-3 месяца к нам несколько раз приходили клиенты с просьбой добавить на Kanban доску возможность быстрого изменения ограничения на максимальное количество задач в столбце (WIP limit).

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

На первый взгляд - да, с точки зрения основ юзабилити, идти в настройки проекта за 5-10 кликов для того, чтобы изменить ограничение - это неправильно. Но.

С точки зрения основ самого подхода к разработке, Kanban, это выглядит гораздо более правильным, объясню почему.

Для чего вообще используется ограничение на количество незавершенной работы, WIP?

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

Такое ожидание - одна из основных потерь, с которыми борятся Lean и Kanban. Как можно уменьшить ожидание? Сделать короче очередь задач. Как сделать короче очередь? Ввести ограничение на размер этой очереди и научиться соблюдать это ограничение, например, фокусируясь на доведении каждой задачи до конца перед тем, как взять следующую.

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

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

Разрабатывая Devprom, мы стараемся заложить некоторые основы методологий и подходов, поддерживаемых нашим инструментом. Это выражается различными способами, в частности, мы не даем быстрой ссылки на изменение лимитов прямо с доски задач. И мы верим, что хотя бы части команд это поможет не спрятать проблему в секундном порыве, а лишний раз задуматься, в чем ее причина и как можно эту причину устранить.

Согласны?