Чтобы понять суть гибкой техники управления, вы должны осознать, чему она пришла на смену. Процесс разработки программного обеспечения шел в соответствии с перегруженным информацией сложным планом, который искренне пытался заранее предусмотреть тот объем работы, который необходимо будет сделать, чтобы написать большую часть программного кода. Идея заключалась в том, что если у вас есть такой план, обычно пестрящий разноцветными любовно вставленными полосками диаграмм Ганта, то вы сможете точно определить, сколько программистов вам понадобится на каждом из этапов, и огласите заказчику точные сроки выполнения работ. В теории такой подход казался хорошим, но на практике подобные планы никогда не совпадали с реальностью, за исключением, может быть, самых простых проектов. Создавать программное обеспечение — это не автомобили собирать. Сложно точно оценить, сколько по времени займет тот или иной этап и какие проблемы могут возникнуть. Кроме того, стало ясно, что заказчики сами не всегда заранее представляют, что именно им нужно. Так что по ходу работы в проект вносились изменения, и график сдачи работ сдвигался.
Сторонники гибкого управления считают, что нужно разбивать процесс разработки программного обеспечения на небольшие этапы и выдавать готовый продукт заказчику по мере готовности. Как только будет получена обратная связь от пользователей, ее сразу можно использовать для дальнейшей доработки. В результате возникает основанный на обратной связи цикл, позволяющий совершенствовать продукт, а не пытаться сразу создать и выпустить на рынок нечто идеальное. Поскольку все больше программных продуктов базируются на интернет-технологиях и процесс получения обратной связи и внесения обновлений стал проще, разные методы гибкого управления стали очень популярны среди разработчиков.
Ключевое значение имеет слово «разные». Концепция гибких техник управления сама по себе не является организационной системой. Она очерчивает общий подход, который реализуется благодаря различным и многочисленным специализированным системам. В настоящее время наиболее популярны Scrum и Kanban, и если вы хоть немного знакомы с миром разработки программного обеспечения, то вы по меньшей мере слышали о них. Если описать в двух словах, то Scrum разбивает работу на короткие отрезки — спринты. Команда, работающая над проектом, полностью посвящает свои усилия тому, чтобы завершить работу над определенной версией продукта, прежде чем переключаться на следующую задачу. Kanban, напротив, делает акцент на непрерывной работе с помощью фиксированных этапов. Цель такого подхода — минимизировать объем незавершенных работ на любом этапе, чтобы не возникало задержек.
Давайте вернемся к доскам. Если глубже погрузиться в изучение этих двух подходов, вы заметите нечто общее между Scrum и Kanban. Они оба используют доски задач, где карточки с написанными задачами располагаются вертикально в колонках, каждая из которых представляет собой этап разработки программного обеспечения. Например, в системе Scrum часто есть колонка под названием «Незавершенные задачи». Туда помещаются те вопросы, которые сочтены важными, но пока не решены. Есть также колонка, куда помещаются задачи, над которыми в данное время трудится команда программистов, участвующих в спринте, колонка для завершенных продуктов, проходящих тестирование, а также колонка для готовых программ, которые уже протестированы и готовы к запуску на рынок.
Неудивительно, что обе системы в итоге используют одинаковые способы организации работы. Ключевая идея, которая лежит в основе гибких техник управления, заключается в том, что люди обычно весьма сильны в планировании. Вам не нужны сложные стратегии по управлению проектами, чтобы определить, что нужно делать дальше. Обычно достаточно устроить встречу информированных инженеров и обсудить, чем имеет смысл заняться. Но есть существенная оговорка: мы можем планировать эффективно, только если владеем всей необходимой информацией: над какими задачами уже работают, что необходимо сделать, на каких этапах возникли трудности и так далее. Оказалось, что карточки на доске — на удивление эффективный способ передать эту информацию.
Такое свойство досок позволяет применять их не только в сфере программного обеспечения. Именно поэтому мы всё чаще встречаем их в прогрессивных организациях, которые стремятся систематизировать рабочие процессы и сотрудники которых занимаются интеллектуальным трудом. Так что советую вам обратить внимание на такое решение, когда задумаетесь о разработке рабочего процесса для своей компании. Чтобы помочь вам в решении этой проблемы, я собрал несколько наиболее удачных примеров. Они покажут, как извлечь максимум пользы из информационной доски в сфере наукоемкого труда.
СОВЕТ № 1: КАРТОЧКИ ДОЛЖНЫ БЫТЬ ИНФОРМАТИВНЫМИ, А ИНФОРМАЦИЯ НА НИХ — ЧЕТКОЙ
Метод основан на том, что в определенных колонках размещаются карточки. Обычно на них пишутся конкретные рабочие задачи. Важно, чтобы они были четко описаны: информация на каждой из карточек не должна допускать двойственного толкования.
Еще один ключевой момент такого подхода заключается в том, что необходима четкая система распределения задач между сотрудниками. У цифровых систем вроде Flow есть встроенная функция — в результате вы видите маленькие фотографии сотрудников рядом с каждой содержащей задание карточкой. Но даже если такой функции в системе нет, можно просто добавить нужную информацию в заголовок карточки. В каких-то случаях может подразумеваться, что определенный сотрудник занимается задачами, размещенными в конкретной колонке. Например, кто-то из небольшой команды разработчиков может отвечать за задания, помещенные в колонку «Тестирование». Когда карточка перемещается в колонку, подразумевающую начало активной работы над задачей, важно, чтобы не возникало вопросов, кто именно должен этим заниматься.
И наконец, необходимо легко находить всю информацию, связанную с конкретной карточкой. Если вы пользуетесь цифровыми инструментами вроде Flow или Trello, можете прикрепить необходимые файлы или длинные текстовые описания к каждой карточке. Это очень удобно, потому что вся нужная для выполнения работы информация оказывается в одном месте. Когда я изучал доски Trello, которыми пользовался в работе Девеш, меня кое-что поразило. Среди карточек на досках была, например, одна с заданием составить аналитический отчет для клиента. К ней были прикреплены файлы, содержащие всю необходимую информацию, и комментарии относительно того, как оформить отчет. Тому, кто будет заниматься этой работой, не придется фильтровать сообщения в переполненном почтовом ящике или рыться в архивах мессенджера. Когда придет время составлять отчет, вся нужная информация будет собрана в одном месте.
Если вы используете настоящую доску, вы не можете прикрепить к ней файлы или длинные описания. Но решением станет какой-нибудь сервис, например Dropbox. Вы создадите отдельную папку для информации на доске, а в ней — другие папки с данными по каждой колонке. Вы сможете хранить сведения, относящиеся к карточке в какой-то конкретной колонке, в соответствующей папке. И когда придет время, эту информацию можно будет легко найти.
СОВЕТ № 2: ЕСЛИ ВЫ СОМНЕВАЕТЕСЬ, НАЧНИТЕ С ШАБЛОНА, КОТОРЫЙ ПРЕДЛАГАЕТ СИСТЕМА KANBAN ПО УМОЛЧАНИЮ
Сложилась определенная практика оформления досок с задачами для тех, кто работает над созданием программного обеспечения. Но тем, кто трудится в другой сфере, может быть сложно понять, как лучше структурировать информацию. Если вы в затруднении, начните с шаблона, который предлагает система Kanban по умолчанию. В нем всего три колонки: «Нужно сделать», «В процессе» и «Сделано». Позже вы сможете доработать этот шаблон по мере необходимости.
Например, на доске Девеша была колонка для задач в разработке и колонка для информации по запуску рекламных кампаний. Такие видоизменения стандартного шаблона Kanban в случае маркетинговой компании уместны, потому что разработкой и запуском занимаются две разные команды сотрудников. На досках Flow, которые использовали в компании Optimize Enterprises, напротив, был упрощенный вариант всего с одной колонкой, куда вносились данные обо всех задачах по проекту, над которыми в настоящее время шла работа.
В шаблоне, который система Kanban предлагает по умолчанию, есть еще одна полезная функция: отдельная колонка для информационных записок и данных по исследованиям, имеющим отношение к проекту. С технической точки зрения это нарушение правила о том, что каждая карточка должна содержать задание. Но с практической точки зрения удобно размещать информацию там, где она может оказаться полезной. Например, в маркетинговой компании Девеша эта колонка использовалась для комментариев о поступивших от клиентов звонках.
СОВЕТ № 3: РЕГУЛЯРНО ПРОВОДИТЕ ВСТРЕЧИ ДЛЯ АНАЛИЗА СИТУАЦИИ
Как мы уже говорили, ключевой фактор успеха при производстве интеллектуального продукта — эффективная система, позволяющая решить, кто чем занимается. Если мы говорим о досках задач, ее роль выполняют прикрепленные карточки с именами сотрудников. Но как принимаются подобные решения? Фундаментальная идея, которая лежит в основе гибких техник управления, заключается в том, что лучший способ проанализировать ситуацию, чтобы обновить информацию на доске, — проводить непродолжительные встречи. Сторонники гибкого управления не поддерживают тот вариант, когда подобные решения принимаются в ходе асинхронного общения посредством электронной переписки или мессенджеров. Когда вы начнете использовать доску задач для структурирования процесса производства интеллектуального продукта, вам придется подчиниться этому правилу.
Стандартный формат таких встреч предусматривает, что сотрудник кратко рассказывает о том, над чем трудится, что ему требуется от коллег, чтобы продолжить работу, и как он справился с заданиями, которые должен был выполнить вчера. Именно во время таких