Soloviov.ru / Веб для бизнеса

Сергей Соловьев о применении веб-технологий с пользой для бизнеса

Опубликовано: 13.02.2011, 18:08

Изобретен еще один “велосипед” для управления проектами

"Велосипеды"

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

Ну, во-первых, потому что новые сервис мне рекомендовал Сергей Сухов, который тоже разбирается в предмете. Я решил, что, наверное, что-то в этом есть, если Сергей считает, что штука интересная. Этой мотивации хватило на 28 минут ролика. На 28-й минуте я услышал кое-что интересное. А на 38-й минуте я даже начал думать, что ребятам удалось сделать хотя бы один шаг в правильном направлении.

Почему каждый раз получается “велосипед”?

Я скептически отношусь к новым инструментам, которые возникают на рынке и выбирают в качестве миссии “произвести революцию в области collaboration and project management tools”. Новые команды со знанием дела рассуждают о том, какие проблемы возникают у команд в проектно-ориентированных организациях, говорят о том, что пора перестать мыслить старыми шаблонами и разработать инструмент, исходя из имеющихся на сегодняшний день возможностей.

Помните, так уже было? “What would the email look like if it was invented today?” Инерция победила. И побеждает каждый раз, потому что приходится мириться с привычками пользователей и просто с природой человека. На выходе получается сервис, который выглядит sexy и позволяет по-новому менять приоритеты у задач (например, перетаскиванием их в списке), но никак не решает фундаментальные проблемы. Последним таким инструментом был Rule.fm, который на деле оказался просто “одним из”.

На этом фоне более выигрышно смотрятся решения, которые фокусируются на абсолютном минимуме и позволяют организовать все детали за пределами инструмента, т.е. используя человеческий фактор (таков Basecamp, например). Такой подход — лучшее, что я встречал, на сегодняшний день. Но и он требует согласованности членов команды, а ведь все создатели сервисов совместной работы как раз хотят построить модель настолько естественную, чтобы не требовалось вообще ни о чем договариваться.

Зрим в корень

Презентация, которую я смотрел сегодня, была подготовлена разработчиками сервиса Asana, который пока находится в закрытом тестировании. Создатели сервиса верят, что они сумеют удивить весь мир, если посмотрят на проблему шире, чем обычно. Это воодушевляет, тем более, что более широкий подход действительно верен: они думают не только о совместной работе над проектами, но о совместной деятельности группы людей вокруг чего угодно. “Если мы работаем в группе, такая деятельность требует координации”, говорят они. Это верно, но мы же здесь противопоставляем себя природе человека, помните? Что же именно сдерживает внедрение подобных инструментов?

Я вижу фундаментальные причины в следующем:

  • Люди хотят заниматься продуктивной деятельностью.
    Если система отнимает хотя бы 10% времени на то, чтобы пользователь правильно настроил проект или выдал задачу, все это воспринимается как “лишняя работа, которую менеджмент нам навязывает”. Классический пример — учет работчего времени (timesheets).
  • Люди хотят, чтобы инструмент был настолько же быстр, насколько быстр их мозг.
    Я и сам регулярно расстраиваюсь, когда вижу, что даже в 21-м веке компьютеры все равно во много раз медленнее меня. Я не о вычислениях говорю, а о банальном наборе текста в условиях мультизадачности. На таком фоне любая дополнительная работа с интерфейсом мешает.
  • Люди хотят, чтобы система была достаточно умной, чтобы бесшовно интегрировалась в их деятельность.
    Никто не любит заниматься перенесением информации из одной системы в другую, просто из-за того, что эти системы друг друга не понимают.
  • Люди хотят, чтобы новые инструменты не создавали новых правил, которым надо обучаться.
    Все усилия по тегированию задач особым образом, чтобы можно было эффективно их потом фильтровать, раздражают или, в лучшем случае, снова воспринимаются, как дополнительная, хоть и необходимая работа.

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

Так поможет ли нам еще один “велосипед”?

Большинство из перечисленных проблем не решаются инструментами, которые я видел.

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

Как ни крути, но у каждого проекта все равно есть мета-данные из как миниму 10 атрибутов, которые необходимо ввести в систему, чтобы проводить сравнительный анализ. Данные до сих пор вводятся вручную, потому что компьютеры еще только начинают научаться понимать человеческую речь в определенных контекстах.

Ну, и так далее.

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

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

Спорно, но хотя бы объясняет, зачем нужно было снова “велосипед” изобретать. Просто они решили приделать к “велосипеду” “турбонаддув” :)

Ну, и наконец на 38-й минуте ребята рассказали о том, как они планируют помогать внедрению инструмента. Одна из основных сложностей при внедрении — сделать так, чтобы люди начали использовать систему. Ведь ни у кого нет времени учиться. Кроме того (и это даже более важно), деятельность любой группы никогда не ограничивается самой группой. Всегда есть люди, которые находятся вне и участвуют в процессе лишь ограниченно. Для компании веб-разработчика это — клиенты и субподрядчики, например. Кто работал в этой среде, тот знает, как сильно рассеивает внимание тот факт, что часть информации находится во внутренней системе, а другая часть — в email’ах. И переносить информацию из писем в задачи — это просто мучение.

Решение Asana — отправять уведомления по email и обрабатывать ответы на них, чтобы добавлять содержание в систему автоматически. Но это само по себе не ново. Тот же Qsoft это уже сделал на практике в своем qTrack. Asana придвинулась еще чуть-чуть дальше и позволила добавлять followers из-за пределов системы для чего угодно. Человек, не являющися пользователем Asana, может быть “подписан” на обновления по конкретной задаче и таким образом участвовать в обсуждении. Без регистрации и без необходимости изучать новый интерфейс. Если со временем он привыкнет и заинтересуется, он может зарегистрироваться полноценно и сразу  увидит в едином интерфейсе все, что происходило там до сих пор. Вот это — очень неплохой финт ушами, у которого есть будущее.

Резюме

В целом, статья, разумеется, не об Asana, не думаю, что и им удастся совершить революцию в области инструментов совместной работы. И все их идеи — они тоже не новые и в разных комбинациях уже опробованы не одной командой.

Статья — это просто рассуждения о том, что между людьми, которым сложно следовать алгоритмам, и машинами, которые только это и делают, все еще — очень большая пропасть. Стремиться построить мостик над ней нужно, но также нужно понимать, что больше шансов имеют те подходы, которые учитывают эту особенность. А пока — ждем, когда количество перейдет в качество.

Notes

  1. soloviovru posted this