Страница 40 из 66
В последнее время подобные доски с заданиями были усовершенствованы. Теперь они делятся на колонки, каждая из которых имеет определенное название. Задачи пишутся на карточках, которые располагаются вертикально в соответствующей колонке. Иногда (как в случае с колонкой «В плане» на доске Алекса) порядок карточек отражает очередность выполнения задач. Так в целом выглядит система, которой пользуются Алекс, Девеш и Брайан Джонсон.
Подобный подход к организации работы зародился в сфере разработки программного обеспечения, которая в последние два десятилетия все больше внедряет так называемые гибкие техники управления в своей деятельности. Основные идеи, лежащие в основе этого подхода, впервые были сформулированы в манифесте, составленном в 2001 году группой из 17 программистов и руководителей проектов. Текст манифеста начинается с оптимистичной фразы: мы ищем лучшие способы разработки программной продукции. Затем простым языком излагаются 12 принципов. Один из них гласит: «Наш приоритет — оправдать ожидания клиентов, заблаговременно и непрерывно снабжая его полезным программным обеспечением». Вот еще один принцип: «Необходима простота, и искусство добиться этого заключается в том, чтобы максимально увеличить количество работы, которую делать не нужно»[136].
Чтобы понять суть гибкой техники управления, вы должны осознать, чему она пришла на смену. Процесс разработки программного обеспечения шел в соответствии с перегруженным информацией сложным планом, который искренне пытался заранее предусмотреть тот объем работы, который необходимо будет сделать, чтобы написать большую часть программного кода. Идея заключалась в том, что если у вас есть такой план, обычно пестрящий разноцветными любовно вставленными полосками диаграмм Ганта, то вы сможете точно определить, сколько программистов вам понадобится на каждом из этапов, и огласите заказчику точные сроки выполнения работ. В теории такой подход казался хорошим, но на практике подобные планы никогда не совпадали с реальностью, за исключением, может быть, самых простых проектов. Создавать программное обеспечение — это не автомобили собирать. Сложно точно оценить, сколько по времени займет тот или иной этап и какие проблемы могут возникнуть. Кроме того, стало ясно, что заказчики сами не всегда заранее представляют, что именно им нужно. Так что по ходу работы в проект вносились изменения, и график сдачи работ сдвигался.
Сторонники гибкого управления считают, что нужно разбивать процесс разработки программного обеспечения на небольшие этапы и выдавать готовый продукт заказчику по мере готовности. Как только будет получена обратная связь от пользователей, ее сразу можно использовать для дальнейшей доработки. В результате возникает основанный на обратной связи цикл, позволяющий совершенствовать продукт, а не пытаться сразу создать и выпустить на рынок нечто идеальное. Поскольку все больше программных продуктов базируются на интернет-технологиях и процесс получения обратной связи и внесения обновлений стал проще, разные методы гибкого управления стали очень популярны среди разработчиков.
Ключевое значение имеет слово «разные». Концепция гибких техник управления сама по себе не является организационной системой. Она очерчивает общий подход, который реализуется благодаря различным и многочисленным специализированным системам. В настоящее время наиболее популярны Scrum и Kanban, и если вы хоть немного знакомы с миром разработки программного обеспечения, то вы по меньшей мере слышали о них. Если описать в двух словах, то Scrum разбивает работу на короткие отрезки — спринты. Команда, работающая над проектом, полностью посвящает свои усилия тому, чтобы завершить работу над определенной версией продукта, прежде чем переключаться на следующую задачу. Kanban, напротив, делает акцент на непрерывной работе с помощью фиксированных этапов. Цель такого подхода — минимизировать объем незавершенных работ на любом этапе, чтобы не возникало задержек.
Давайте вернемся к доскам. Если глубже погрузиться в изучение этих двух подходов, вы заметите нечто общее между Scrum и Kanban. Они оба используют доски задач, где карточки с написанными задачами располагаются вертикально в колонках, каждая из которых представляет собой этап разработки программного обеспечения. Например, в системе Scrum часто есть колонка под названием «Незавершенные задачи». Туда помещаются те вопросы, которые сочтены важными, но пока не решены. Есть также колонка, куда помещаются задачи, над которыми в данное время трудится команда программистов, участвующих в спринте, колонка для завершенных продуктов, проходящих тестирование, а также колонка для готовых программ, которые уже протестированы и готовы к запуску на рынок.
Неудивительно, что обе системы в итоге используют одинаковые способы организации работы. Ключевая идея, которая лежит в основе гибких техник управления, заключается в том, что люди обычно весьма сильны в планировании. Вам не нужны сложные стратегии по управлению проектами, чтобы определить, что нужно делать дальше. Обычно достаточно устроить встречу информированных инженеров и обсудить, чем имеет смысл заняться. Но есть существенная оговорка: мы можем планировать эффективно, только если владеем всей необходимой информацией: над какими задачами уже работают, что необходимо сделать, на каких этапах возникли трудности и так далее. Оказалось, что карточки на доске — на удивление эффективный способ передать эту информацию.
Такое свойство досок позволяет применять их не только в сфере программного обеспечения. Именно поэтому мы всё чаще встречаем их в прогрессивных организациях, которые стремятся систематизировать рабочие процессы и сотрудники которых занимаются интеллектуальным трудом. Так что советую вам обратить внимание на такое решение, когда задумаетесь о разработке рабочего процесса для своей компании. Чтобы помочь вам в решении этой проблемы, я собрал несколько наиболее удачных примеров. Они покажут, как извлечь максимум пользы из информационной доски в сфере наукоемкого труда.
СОВЕТ № 1: КАРТОЧКИ ДОЛЖНЫ БЫТЬ ИНФОРМАТИВНЫМИ, А ИНФОРМАЦИЯ НА НИХ — ЧЕТКОЙ
Метод основан на том, что в определенных колонках размещаются карточки. Обычно на них пишутся конкретные рабочие задачи. Важно, чтобы они были четко описаны: информация на каждой из карточек не должна допускать двойственного толкования.
Еще один ключевой момент такого подхода заключается в том, что необходима четкая система распределения задач между сотрудниками. У цифровых систем вроде Flow есть встроенная функция — в результате вы видите маленькие фотографии сотрудников рядом с каждой содержащей задание карточкой. Но даже если такой функции в системе нет, можно просто добавить нужную информацию в заголовок карточки. В каких-то случаях может подразумеваться, что определенный сотрудник занимается задачами, размещенными в конкретной колонке. Например, кто-то из небольшой команды разработчиков может отвечать за задания, помещенные в колонку «Тестирование». Когда карточка перемещается в колонку, подразумевающую начало активной работы над задачей, важно, чтобы не возникало вопросов, кто именно должен этим заниматься.
И наконец, необходимо легко находить всю информацию, связанную с конкретной карточкой. Если вы пользуетесь цифровыми инструментами вроде Flow или Trello, можете прикрепить необходимые файлы или длинные текстовые описания к каждой карточке. Это очень удобно, потому что вся нужная для выполнения работы информация оказывается в одном месте. Когда я изучал доски Trello, которыми пользовался в работе Девеш, меня кое-что поразило. Среди карточек на досках была, например, одна с заданием составить аналитический отчет для клиента. К ней были прикреплены файлы, содержащие всю необходимую информацию, и комментарии относительно того, как оформить отчет. Тому, кто будет заниматься этой работой, не придется фильтровать сообщения в переполненном почтовом ящике или рыться в архивах мессенджера. Когда придет время составлять отчет, вся нужная информация будет собрана в одном месте.
136
Kent Beck et al., “Manifesto for Agile Software Development,” 2001, agilemanifesto.org.