Канбан Метод. T memarketologmanager
 Скачать 4.05 Mb.
|
|
переговоры, исследования и т.п.? С какой скоростью она прибывает (сколько единиц в день, в неделю, в месяц)? Она появляется регулярно (скажем, на заранее спланированных совещаниях) или случайным образом (скажем, когда клиенты звонят в службу поддержки)? Работа поступает в виде больших партий или единичных, но крупных заказов? Как насчет предсказуемых сезонных вариаций? Каковы ваши ключевые критерии успеха? Насколько они согласуются с клиентскими впечатлениями? Те две команды, с которыми я когда-то работал, могли бы ответить на эти вопросы так: 1. «Какой-то регулярной картины прибытия работы нет. Более крупные проекты начинаются по согласованию с командой менеджеров. Более мелкие задачи появляются в результате частных бесед или поступления писем в почтовый ящик команды. Наша цель — разрешать каждую возникшую проблему, касающуюся поддержки продукта, за 24 часа (и нам это очень хорошо удается). Ожидания в отношении разработки очень разнятся в зависимости от масштабов проекта и нужд клиента». 2. «Новой работой управляют на региональном уровне, обычно через регулярные совещания, которые проводят региональные менеджеры или бизнес-аналитики высшего звена. Масштабная работа отслеживается с помощью двух дистанционных глобальных конференций, которые проводятся дважды в неделю (по одной для каждого из двух главных направлений нашего бизнеса). В них участвует и команда менеджеров, и наши бизнес-партнеры. График работы формируется согласно планируемым релизам. Иногда какая-то часть работы перетекает на следующий релиз, но этому всегда предшествуют предупреждения и обсуждения». Складывается ли все это воедино? Сделав то, о чем говорилось в этой и предыдущей главах, вы получите неплохое представление о следующем: что производится, насколько крупными блоками и насколько часто; что запрашивают клиенты, как, когда и почему; сколько работы требует переход от второго пункта к первому и сколько времени она занимает; чем не удовлетворены те, кто находится за пределами производственного процесса; чем недовольны и разочарованы те, кто находится внутри. О чем все это говорит вам лично? Создалось ли в вашей организации коллективное представление о том, что необходимо изменить? Или есть какие-то вещи, которые пока не вписываются в общую картину? А если так, что с ними делать? Не беспокойтесь, если остаются какие-то немногочисленные неоднозначности, разногласия, пробелы в знаниях. Все станет намного яснее, когда вы завершите семинары и анализ и начнете визуализировать реальную работу. Важно то, что вы создали для этого нужные предпосылки. Глава 20 Смоделируйте производственный процесс В этой главе показаны три подхода к моделированию производственного процесса, которые поможет развивать наша канбан-система: 1. Выстраивание общей схемы. 2. Разбивка сверху вниз. 3. Организация снизу вверх. Важно помнить: мы стремимся создать работающую канбан- систему, а не статичную модель. Поэтому лучше не слишком зацикливаться на плодах этого упражнения: они быстро утратят ценность, как только система начнет эволюционировать. Для простоты предположим, что производственный процесс у вас всего один. Если их больше, можете заниматься каждым по очереди или же использовать один как основу для описания прочих. Выстраивание общей схемы Мы не станем рекомендовать вам какую-то определенную систему записи. Сами решайте, что использовать — классический «бизнес-процесс», картирование потока стоимости, принятые у вас в организации значки или же нечто совершенно неформальное. Выберите тот способ, который не породит ненужное сопротивление у ваших коллег и не заставит уделить этой стадии больше времени, чем нужно. Вы можете опустить все подробности, которые не оказывают реального воздействия на решения людей насчет того, над чем и как работать. Это соображение особенно касается функциональных разграничений и ролей. Должно ли их существование мешать сотрудникам делать правильный выбор? В идеальном мире не должно. Ни наши схемы, ни канбан-системы, которые в итоге сформируются, не должны укреплять такие границы и такое распределение ролей. На рис. 20.1 показана (система записи нарочито неформальная) первая стадия истории XIT (см. «синюю книгу», главу 4 «От худшего к лучшему за пять кварталов»). Если вы знакомы с этой историей, то и без нас знаете, что эта диаграмма показывает, как произошел разрыв между разработчиками и тестировщиками из-за постоянного оценивания новых задач и регулярной смены приоритетов в огромном портфеле работ, которые необходимо выполнить. С тех пор прошло 10 лет, и я склонен использовать более линейное представление для того путешествия, которое совершают рабочие задачи. При этом меня уже не так заботят функциональные роли. По-моему, рис. 20.2 вполне отвечает моим целям и адекватно изображает процесс. Может быть, вас интересует, что происходит после того, как пользователь примет продукт? Хороший вопрос! Разбивка сверху вниз Звучит внушительно. На самом-то деле вам придется лишь написать очень приблизительный ответ с помощью двух подсказок, а потом немного уточнить формулировку. Все просто: 1. Выявите свои точки вовлечения (обычно их одна-две): например, те моменты, когда вы соглашаетесь приступить к созданию или обслуживанию продукта, а затем договариваетесь о его поставке или об иной форме завершения работы. 2. Разбейте на категории те состояния или виды деятельности, которые существуют до этих точек, между этими точками, после этих точек. В примере с XIT это могут быть «Портфель заказов», «Разработка» и «Внедрение». 3. Используя столько уровней, сколько необходимо, разбейте эти категории так, чтобы они отражали повседневную реальность вашей работы. Например: Работы, которые необходимо выполнить: получено; оценка; приоритизировано. Разработка: создание продукта; тестирование. Внедрение: принятие пользователем; выпуск на рынок. Сделано. 4. Есть стадии, когда задачи ждут дальнейшей работы над ними в промежутках между активными стадиями и совершенствованием. Такое часто встречается при передаче работы от одного сотрудника к другому. В нашем примере категории «Полученные» и «Приоритизированные» описывают состояния ожидания. Весьма вероятно, что ожидание возникнет также между созданием и тестированием продукта, если эти операции проводят разные люди. Отдельно сформулированные состояния «Создание продукта завершено» или «Продукт готов к тестированию» покажут, что задача обычно ожидает дальнейшей работы до или после такой передачи другому сотруднику. В высшей степени неформальный вариант такого подхода: начните с самой примитивной схемы «Что надо сделать», «Что делается», «Что сделано» (возможно, какая-то подобная схема уже у вас в ходу). Затем спросите: Есть ли разница в том, «что надо сделать»? Как организовывать процесс — по виду деятельности или по приоритетности? Что происходит на стадии «делается»? Есть ли разница в «сделанном»? Как мы определяем, что работа «действительно сделана»? Организация снизу вверх Вместо того, чтобы вдаваться в различия между видами деятельности и состояниями рабочих задач, я их все включил в универсальное понятие «категория». Коварный шаг, не спорю. Но я сознательно так поступил. Имейте в виду: наша цель — найти эффективный способ организации рабочих задач. Именно эта цель и лежит в основе третьей стратегии, которую мы сейчас обсудим. Может, лучше не моделировать производственный процесс, а просто организовать те рабочие задачи, которые у нас имеются в реальности? Такой подход может оказаться действенным, но для этого нужно, чтобы у нас имелось достаточное число рабочих задач, представляющих достаточно разнообразные состояния. Вы могли бы проделать это, используя уже существующую систему отслеживания производственных процессов. Но куда нагляднее (не говоря уж о пользе для социальных взаимодействий) взять стикеры, которые вы подготовили в предыдущей главе, и расположить их горизонтальными рядами по степени завершенности работы. При этом учитывается не то время, которого они требуют для завершения работы, а то состояние, в котором сейчас находится работа (или, что почти одно и то же, тот вид деятельности, который больше всего отвечает за продвижение данной задачи вперед). Тут могут помочь такие вопросы: Что нужно этой рабочей задаче? Что понадобится этой рабочей задаче, чтобы она больше походила на другую? Что понадобится этой рабочей задаче, чтобы ее можно было считать полностью выполненной? Как этот рабочий элемент сюда попал? Теперь осталось лишь дать названия группам рабочих задач, находящихся в схожих состояниях по степени завершенности, а затем группировать или объединять эти категории, пока вы не получите работоспособную конфигурацию. А заодно эта методика может помочь выявить некоторые любопытные проблемы: Вопрос: что нужно сделать для выполнения этой задачи? Ответ: нужно исправить баг, прежде чем можно будет продолжать тестирование. Или: нужно, чтобы ее вернула нам команда Х. В главе 22 мы еще вернемся к этим примерам. Очень важно обращать особое внимание на то, как мы визуализируем переделку и зависимости — два главных источника задержек и разочарований. Промежуточные итоги Прежде чем мы двинемся дальше, назову несколько хороших способов проверить и улучшить то, что у вас уже есть: Быстро объедините разные подходы, чтобы подтвердить действенность своей модели. Например: Выстройте схему на основе своей модели типа «сверху вниз» или «снизу вверх». Убедитесь, что на вашей схеме или в модели «сверху вниз» представлены реальные рабочие задачи. Затем используйте вопросы типа «Что нужно для выполнения этой задачи?». Подумайте, полезно ли будет сгруппировать или разбить какие-то категории. Проверьте, чтобы стадии ожидания были представлены адекватно. Удостоверьтесь, что вы знаете расположение своих точек вовлечения. Подумайте, где могут возникать факторы неудовлетворенности и разочарованности, обсуждавшиеся в главе 18. Определите типы приобретаемых знаний, связанных с каждым активным состоянием. Старайтесь не обращать особого внимания на функциональную организацию. Представьте вашу модель другим. Никакие стадии этого процесса не должны занимать много времени. Помните: речь идет лишь о приблизительной, предварительной схеме! Глава 21 Определите классы обслуживания В главе 2 кратко обсуждаются классы обслуживания и указывается, что эти категории связаны с клиентскими ожиданиями и производственным графиком. Чтобы напомнить, о чем шла речь, дадим краткие описания четырех категорий, которые встречаются настолько часто, что им даже присвоили названия: Срочные: рабочие задачи настолько срочные, что приходится откладывать выполнение других работ и немедленно переключаться на них. Привязанные к дате (с фиксированной датой): рабочие задачи, невыполнение которых к конкретной дате приводит к наложению существенного штрафа, несопоставимого с любой выгодой от ранней поставки. Такие риски срыва графика тщательно контролируются. Стандартные: срочные рабочие задачи, выполняемые в соответствии с порядком, согласованным с заказчиками, или в последовательности, соответствующей системной политике. В зависимости от ситуации правила выполнения могут быть такими простыми, как: первым пришел — первым обслужен (FIFO), базироваться на такой экономической модели, как стоимость задержки (глава 15), или просто на личном выборе. Нематериальные: улучшение системы, расширение возможностей, эксперименты в области технологий или на рынке, инвестиции в человеческие ресурсы — работа, результаты которой проявляются в среднесрочной или долгосрочной перспективах, но непосредственный бизнес- эффект трудно оценить количественно. Для разработчика систем классы обслуживания связаны с принятием разнообразия (а не с отрицанием его и не с попытками заорганизовать) так, чтобы при этом можно было улучшить предсказуемость. Но классы обслуживания важны не только для тех, кто находится внутри системы. Это зримая часть того, что система предлагает клиентам. Это средство гармонизации клиентских ожиданий и возможностей системы. На самом деле эти стандартные классы — лишь отправной пункт. Главное, выявить качественные различия, которые: 1. Можно заранее легко установить, причем однозначно; 2. Требуют различных подходов, графиков и/или управления риском внутри компании; 3. Влияют на разумные ожидания тех, кто находится за пределами компании. Понятия классов обслуживания и типов рабочих задач (то самое «что», о котором шла речь в главе 19) явно пересекаются. Различие между ними становится интересным, когда мы вводим еще и элемент выбора. Например: Что это — работа по «техподдержке» (с формализованными ожиданиями клиента, предполагающего, что мы обслужим его определенным образом) или же «небольшой ремонт» (работа, встающая в очередь переменной длины, возможно, подлежащая приоритизации)? Когда нужно это сделать — «к пятнице» (и управлять риском как в случае привязки к дате) или же «как можно быстрее» (скажем, по принципу «первым пришел — первым обслужен»)? Как можно ответить на этот вопрос, не зная тех потребностей, которые таятся за просьбой? В таких случаях иногда разумно проводить исследования и переговоры, но зачастую мы доверяем выбор самим клиентам. Обнаруживайте и проверяйте Рассматривайте типы рабочих задач по очереди. Всякий раз задавайте вопросы: Относимся ли мы ко всем рабочим задачам так, словно они одинаково срочные? Если нет, то как идентифицируются более срочные? Связан ли с ними какой-то особый язык? Указывают ли данные о прошлых результатах на то, что целое состоит из нескольких подмножеств? Если так, то насколько надежно мы можем выявить эти подмножества с помощью легко распознаваемых факторов? Какой выбор мы предлагаем клиенту? До какой степени взаимозаменяемы типы рабочих задач? Существуют ли соглашения об уровне обслуживания? Эффективны ли они? Если ответы на эти вопросы показывают, что действительно могут существовать несколько классов обслуживания, удостоверьтесь, что подобное разбиение окажется полезным с практической точки зрения: Как присутствие этих классов скажется на поведении тех, кто находится внутри компании? Какую корпоративную политику необходимо применять? Каким будет результат такого применения? Как может измениться поведение клиентов, если вы предложите им различные классы обслуживания? Какую пользу они от этого получат? Для дополнительной проверки рассмотрите текущую нагрузку: К каким рабочим задачам сейчас относятся по-особому? Какие компоненты заслуживали бы особого отношения? Примеры Нижеследующие примеры типичны для широкого спектра ситуаций, с которыми можно столкнуться даже при разовом внедрении: Запросы на техподдержку (клиентское ожидание — получить услугу не позже чем через 24 часа после обращения). Апгрейд внешних интерфейсов: релиз в определенные даты (из соображений общего ритма бизнеса); воспринимается как срочный рабочий элемент (чтобы не упускать ни единой возможности с точки зрения бизнеса); рассматривается как нематериальный рабочий элемент (ради поддержания здоровья сиcтемы). Серьезные технологические апгрейды (например, апгрейд версии базы данных или языковой платформы): тихо существуют где-то на заднем плане как серия нематериальных рабочих задач. Релизы выпускаются по мере готовности. Нет никакой зависимости от дедлайна; воспринимаются как масштабные проекты в «позднейший ответственный момент» (при этом неизбежно отодвигаются все прочие проекты). Запросы, которые можно выявить заранее как требующие одобрения со стороны службы безопасности, отдела по контролю рисков или еще какой-то группы, обладающей правом вето. На пути к здоровой комбинации работ Это должно быть очевидным: невозможно планировать так, чтобы все занятые на 100% работой с фиксированной датой могли отвлекаться на срочные рабочие задачи и при этом обеспечивали предсказуемость. Даже без отвлечений 100%-ная загрузка задачами с жестким дедлайном — это залог не эффективности, а крайней непредсказуемости и задержек, не говоря уже о стрессах для людей. Системам требуется некоторая слабина, если вы хотите, чтобы они адекватно поглощали изменения, а не бесцельно накапливали их. И людям тоже нужно давать передышку. Возможно, вы задаетесь вопросом, какой уровень такого использования времени может считаться «безопасным» (или «гуманным») — 90%? 80%? На мой взгляд, здесь мы подходим к проблеме не с того конца. Из моего опыта менеджерской работы и из опросов клиентов, которые проводили я и Дэвид, следует, что рабочие задачи с фиксированной датой не должны занимать в большинстве организаций более 20%. Зачастую эта доля оказывается значительно меньше. Выделив, скажем, 10–20% времени на нематериальную работу и вполне реалистичную долю на срочную и другую незапланированную работу, следует отдать самую большую долю времени стандартным задачам, которые обладают высокой ценностью. Нужно ориентироваться именно на такое распределение нагрузки, если вы хотите максимизировать поток стоимости в своем бизнесе. По счастью, предсказуемость при этом тоже достижима благодаря присутствию в производственных системах рабочих задач, которые можно спокойно отложить, когда возникнет необходимость сделать работу с жестко установленным сроком. Классы обслуживания — как и другие методы категоризации — позволяют принимать общие решения о приоритетности независимо от решений по поводу конкретных задач, которые могут вызвать ненужные споры. Явно заявляя об этом, вы создаете возможность гармонизировать их с общекорпоративными приоритетами и с потребностями клиентов. Пока существует краткосрочная гибкость этих категорий, вы можете добиваться и того и другого. Проводя семинары, вы можете задавать следующие вопросы, помогающие создавать правильную комбинацию работ и обсуждать конструкцию системы: Какая доля работ в нашем портфеле должна быть привязана к дате? Даем ли мы обязательства, касающиеся конкретных дат, без особой надобности? И если так, нельзя ли сократить долю таких обязательств? Учитываем ли мы, составляя график работ, реальные возможности, доступные в данный момент? Способны ли мы адекватно отреагировать, если сроки оказываются под угрозой? Какие производственные возможности нужно резервировать на случай срочной и другой |