Новые принципы делового общения

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

Ключевое значение имеет слово «разные». Концепция гибких техник управления сама по себе не является организационной системой. Она очерчивает общий подход, который реализуется благодаря различным и многочисленным специализированным системам. В настоящее время наиболее популярны Scrum и Kanban, и если вы хоть немного знакомы с миром разработки программного обеспечения, то вы по меньшей мере слышали о них. Если описать в двух словах, то Scrum разбивает работу на короткие отрезки — спринты. Команда, работающая над проектом, полностью посвящает свои усилия тому, чтобы завершить работу над определенной версией продукта, прежде чем переключаться на следующую задачу. Kanban, напротив, делает акцент на непрерывной работе с помощью фиксированных этапов. Цель такого подхода — минимизировать объем незавершенных работ на любом этапе, чтобы не возникало задержек.

Давайте вернемся к доскам. Если глубже погрузиться в изучение этих двух подходов, вы заметите нечто общее между Scrum и Kanban. Они оба используют доски задач, где карточки с написанными задачами располагаются вертикально в колонках, каждая из которых представляет собой этап разработки программного обеспечения. Например, в системе Scrum часто есть колонка под названием «Незавершенные задачи». Туда помещаются те вопросы, которые сочтены важными, но пока не решены. Есть также колонка, куда помещаются задачи, над которыми в данное время трудится команда программистов, участвующих в спринте, колонка для завершенных продуктов, проходящих тестирование, а также колонка для готовых программ, которые уже протестированы и готовы к запуску на рынок.

Неудивительно, что обе системы в итоге используют одинаковые способы организации работы. Ключевая идея, которая лежит в основе гибких техник управления, заключается в том, что люди обычно весьма сильны в планировании. Вам не нужны сложные стратегии по управлению проектами, чтобы определить, что нужно делать дальше. Обычно достаточно устроить встречу информированных инженеров и обсудить, чем имеет смысл заняться. Но есть существенная оговорка: мы можем планировать эффективно, только если владеем всей необходимой информацией: над какими задачами уже работают, что необходимо сделать, на каких этапах возникли трудности и так далее. Оказалось, что карточки на доске — на удивление эффективный способ передать эту информацию.

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

СОВЕТ № 1: КАРТОЧКИ ДОЛЖНЫ БЫТЬ ИНФОРМАТИВНЫМИ, А ИНФОРМАЦИЯ НА НИХ — ЧЕТКОЙ

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

Еще один ключевой момент такого подхода заключается в том, что необходима четкая система распределения задач между сотрудниками. У цифровых систем вроде Flow есть встроенная функция — в результате вы видите маленькие фотографии сотрудников рядом с каждой содержащей задание карточкой. Но даже если такой функции в системе нет, можно просто добавить нужную информацию в заголовок карточки. В каких-то случаях может подразумеваться, что определенный сотрудник занимается задачами, размещенными в конкретной колонке. Например, кто-то из небольшой команды разработчиков может отвечать за задания, помещенные в колонку «Тестирование». Когда карточка перемещается в колонку, подразумевающую начало активной работы над задачей, важно, чтобы не возникало вопросов, кто именно должен этим заниматься.