Ваше программное обеспечение для управления проектами не может вам помочь
Менеджеры рабочих мест, такие как Asana и Trello, обещают организационные утопии. Но они раскрывают ограничения, которые восходят к заводским полам 1900-х годов.
#управлениепроектами #программноеобеспечение #работа #продуктивность #менеджмент #проекты #сотрудничество #эффективность #инструменты #пользователи
КОГДА Я РАБОТАЛ копирайтером в компании, занимающейся игрушками для собак и технологиями, мы использовали Airtable и Basecamp для организации нашей рабочей деятельности. В следующей работе маркетологи заставили нас изучить Asana ("то же самое, что и Airtable, но намного лучше"), но команда продукта продвигала свою работу и спринты через Jira. Меня уволили до того, как мне пришлось изучать Jira, и на следующей работе они клялись в Airtable, которую, уф, я уже знал. Но, по-видимому, все еще терялись эффективности, и виной этому был Airtable. Уходя с этой работы, я слышал, как кто-то упоминал, что новая программа, Trello, собирается заменить Airtable и "изменить все" для нас. Через несколько лет я вернулся как контрактник, и ничего не изменилось. Компания отказалась от Trello и сейчас была во власти чего-то под названием Monday.com. Оно тоже обещало большие перемены.
Если вы работаете как "индивидуальный участник" - инженер, копирайтер, дизайнер, аналитик данных, маркетолог - в современной белоколларной рабочей силе, вы, вероятно, столкнулись с одним из этих предприятий по управлению проектами (PM software). Ваше внедрение будет включать приглашение к сотрудничеству от таких компаний, как Smartsheet, Notion, Udemy, ClickUp, Projectworks, Wrike и Height. Список кажется бесконечным, но по-прежнему продолжает расти. Более ста проприетарных приложений и планировщиков в настоящее время борются за бизнес компаний, все обещая повышенную производительность, безупречные рабочие процессы и непревзойденную гибкость. И если, как и я, вы несколько лет перебирались между несколькими работами и проектными командами, вам пришлось смириться с тем, что недоразумения и путаница являются естественными в любой большой рабочей силе. Но во все более цифровом, все более удаленном возрасте работы вы все еще можете представить, что "убийственное приложение" действительно выиграет. И тем не менее, ни одна из этих служб PM-программ не делает работу работать. Ключ к этим недостаткам заключается в истории самой рабочей эффективности - начиная с оригинальных деловых консультантов.
Поиск решения для повышения эффективности
До второй промышленной революции практически не существовало такого понятия, как производительность. (Само слово в основном не существовало до 1900 года.) По мере того, как фабрики становились все более сложными и число заработных плат становилось все больше, целью капитала стало обеспечение эффективности его рабочей силы. Если связь вашего раздражения на рабочем месте слишком большим количеством уведомлений от Trello вызывает у вас головокружение, вы не одиноки. Но идея того, чтобы убедиться, что вы работаете эффективно, стара, как идея быть наемным работником.
И вот в 1900-х годах появилось то, что мы знаем как управление проектами. Согласно книге Фредерика Тейлора "Принципы научного управления", цель управления рабочими "должна быть обеспечение максимального благополучия для работодателя в сочетании с максимальным благополучием для каждого сотрудника". В то же время, когда Тейлор, механический инженер, поднялся с фабричного пола, чтобы стать одним из первых деловых консультантов Америки, другой инженер, Генри Гантт, популяризировал и систематизировал основы диаграммы Гантта, простой столбчатой диаграммы, которая превращает график работы проекта в набор линий на оси x и y, где время движется слева направо. Также называемые методом "водопада", диаграммы Гантта создают визуальную метафору задач и их зависимостей и условностей, чтобы вы могли видеть каждую отдельную задачу в терминах того, когда она должна начаться и когда она должна быть завершена, относительно всего проекта и задач, предшествующих ей.
Вы графический дизайнер, ждущий поступления фотографий и текстов перед тем, как создать баннерную рекламу? Во многих наших современных приложениях для управления проектами вы можете видеть эти предварительные условия, как на современных диаграммах Гантта, предлагаемых Monday.com, Wrike, Microsoft Project и Click Up. У Asana также есть шаблоны диаграммы Гантта.
Тейлор и Гантт пытались разобраться, как управлять работой фабричного механика, работа которого, подобно Люси в шоколадной фабрике, обычно включает в себя одну повторяющуюся задачу. Но рост числа информационных работников означает больше универсалистов, консультантов, аналитиков и менеджеров - и больше иерархии. На строительном проекте, например, пока установлен арматурный каркас, бетонная бригада может заливать фундамент. Аналогично, рабочему на фабрике не нужно видеть диаграмму Гантта, чтобы изготовить свою часть изделия, ему достаточно знать, что делать. Он не обязан участвовать в создании диаграммы. Он не обязан взаимодействовать с диаграммой. На величественном проекте по строительству плотины Гувера (его строительство было организовано с использованием диаграммы Гантта), рабочим, заливающим бетон, не нужно было самостоятельно управлять этой задачей, проверяя ее в соответствии с диаграммой Гантта. Во времена до информационной работы задачи рабочих (отдельных исполнителей) не требовали самоуправления; они были подчинены.
С другой стороны, информационную работу гораздо проще управлять с использованием методов, разработанных Ганттом. В информационных рабочих силах есть бесконечное количество векторов обратной связи, дебатов, утверждения заинтересованных сторон и редактирования, не говоря уже о бесконечных точках контакта. (Если вы чувствуете, что ваше рабочее место переполнено менеджерами, вы не одиноки.) Программное обеспечение, имитирующее устаревший способ установки проектных домино, является источником нашего рабочего места и началом решений, которые просто создают больше работы.
Критические пути к дорожным картам бесконечных возможностей
Вы знали, что Манхэттенский проект также является частью славной истории управления проектами? Все более сложные проблемы требуют все более элегантных решений, и невозможно за несколько лет перейти от идеи к атомной бомбе без эффективно организованных параллельных рабочих путей. Наблюдения, сделанные некоторыми инженерами во время Манхэттенского проекта, привели к созданию в конце 1950-х годов метода критического пути - алгоритмической модели, создающей мини-карту (немного похожую на дерево принятия решений) всех элементов процесса разработки или проекта. Каждому узлу и пути присваиваются временные значения, и компьютер находит самый быстрый (или самый дешевый) способ достижения конечной цели с выполнением всех необходимых задач. Критический путь объединяется с методом PERT ВМС США, аналогичной системой, разработанной одновременно, и управление проектами перешло в компьютерный век. В то же время система "канбан" (японское слово, означающее "табличка") была разработана в Toyota для повышения эффективности линейного производства. Ручная система карточек и знаков, канбан также стала популярной.
В момент, когда разработка программного обеспечения стала более легитимной областью для управления (в 1980-х годах), у нас уже был "закон" Фреда Брукса, который гласит, что добавление людей в отставшие программные проекты только замедляет их. Истина, лежащая в основе этой идеи, - то, что "ввод" сложных задач занимает больше времени, чем экономит его - является одним из нескольких факторов, которые заставляют программистов работать в рамках и разрабатывать "скрамы" - более гибкий способ общения во время проектов с открытым концом, таких как программирование. Скрамы, возможно, более революционны, чем критический путь, канбан или любой из их предшественников, потому что они представляют собой формат, который соответствует функциональности небольших команд с краткосрочными целями. Скрамы помогают программистам быстро выполнять работу, а затем делать то же самое в следующем проекте.
Вы можете посмотреть на диаграмму критического пути и подумать: Эй, это очень похоже на дорожную карту продукта (то есть некоторое полезное сочетание каскадной части диаграммы Гантта и макета зависимого пути критического пути). Или вы можете рассмотреть доску канбан и подумать: Хорошо, я могу привыкнуть к этому. Но заметьте, что Asana рекламирует свою грамотность в канбане, критическом пути, скрамах, а также в новом термине - гибком управлении. Программное обеспечение для управления проектами представляет себя как Фредерик Тэйлор в конце 1800-х годов, путешествующий из места в место и уверяющий владельцев фабрик в том, что его система может быть применена одинаково к столярным и промышленным прачечным. Разница в том, что у Тэйлора было универсальное решение для всех, а программное обеспечение для управления проектами продает себя как «всезнайка» во всех системах и мастер во всех отношениях.
Помимо завышенных обещаний, модель программного обеспечения для управления проектами также требует от программ выполнять то же, что и Тейлор, но с постоянным доходом. Современная бизнес-модель в сфере технологий основана на ожидаемом повторяющемся доходе, поэтому эти программы должны использовать команды по продажам технологий и модели программного обеспечения как услуги для закрепления постоянных клиентов и поддержания стабильного дохода. Компании могут обещать решение проблем с рабочим процессом, но на самом деле они продают сервис.
Wrike была основана в 2006 году, Asana в 2008 году, Trello в 2011 году, а Monday.com и Airtable в 2012 году. В гонке за маркетинговыми позициями каждая из них заполнила интернет своими собственными сайтами (у Asana есть своя фальшивая газета), оплаченными ложными отзывами, продвигаемыми ответами на Quora и заявлениями о том, что только у них есть подходящее программное обеспечение для организации всего вашего трудового потенциала. Чтобы хотя бы частично выполнить это обещание, программное обеспечение должно быть полезным для различных размеров, стилей и типов рабочих команд.
Wrike может создавать диаграммы Ганта или небольшие таблицы. Asana может создавать дорожные карты, диаграммы "водопад" и доски Канбан. Но что на самом деле делают эти программы? В видеоигровом движке моделируется мир - гравитация притягивает предметы к земле, снаряды ведут себя определенным образом, ваш персонаж может держать определенное количество предметов, прежде чем ему придется что-то выбросить. Программное обеспечение для управления проектами обещает надежные системы для решения сложных проблем, но его решения обычно представляют собой поверхностный пользовательский интерфейс, накладываемый на связанные базы данных. Эти программы часто не "работают" для команд, потому что они либо слишком сложны для простых задач, либо недостаточно надежны для сложных, и потому что связанные базы данных не являются универсальным решением для решения всех проблем, связанных с рабочим процессом.
Проблема пользовательского опыта
Поскольку цель поставщиков программного обеспечения как услуги состоит в продаже и сохранении подписок, эти компании должны постоянно добавлять отдельные функции, чтобы удовлетворять любой возникающий случай использования. Но когда ваше программное обеспечение построено на основе мышления базы данных, новые функции часто приводят только к усложнению. Добавление мышления о связанных базах данных к задаче вроде "мне нужно отредактировать фотографию собачьей игрушки" создает лишние сложности, если программное обеспечение действительно неудобное для пользователя и не имитирует программы, с которыми пользователи знакомы.
В течение длительного времени многие из этих программ (например, Asana) не имели кнопки отмены. Компетентный, но не супер-технически подкованный ретушер мог перейти к "карточке" в Asana и случайно удалить задачу или ее историю, неосознанно испортив все.
Проблема заключается в том, что обычный пользователь имеет всеобщую возможность добавлять, удалять и удалять задачи, и это выбор, который кто-то в Asana сделал (или не сделал). Конечно, вам не следует удалять файлы на вашей работе, но программное обеспечение, построенное на записях базы данных, делает это сложным для человека, мозг которого настроен на современный пользовательский опыт (UX).
Программы, такие как программное обеспечение для управления проектами, созданное на основе мышления программиста, показывают огромный разрыв между тем, как работают компьютеры, и пониманием обычного человека о том, как они работают. В середине 90-х годов вы могли справедливо ожидать, что человек с ПК будет понимать файловые деревья или базы данных, потому что UX еще не достиг уровня безупречности, который мы видим в сегодняшних телефонах и приложениях. Gmail сейчас такой хороший, что Zoomer, приходящий на работу, может даже не уметь мыслить в терминах файловых деревьев или связанных баз данных, и, вероятно, не сможет устранить странное маленькое заикание в своем программном обеспечении для управления проектами. Если мы рассмотрим добавление корзины для восстановления или кнопки отмены к тому, что по сути является базой данных, мы увидим, как разрыв между знаниями пользователей и разработчиков растет, как, скажем, UX Gmail продолжает мастерски сокрывать фактическую работу компьютера.
Кнопка отмены в конце концов появилась, но она поставляется с 20-секундным окном, как в Gmail. Не достаточно быстро? Жаль. Скорее всего, эта функция просто сохраняет ваши действия в локальной памяти и организует их на интерфейсе таким образом, что время между вашими действиями и получением их сервером программы - это время, которое у вас есть для отмены. С точки зрения сервера, вы не отменяете, а просто не делаете.
Причина, почему существует так много таких компаний, и все же нет одного убийцы-приложения, заключается в том, что несложно привлечь капитал и создать новое программное обеспечение поверх базы данных. Jira ставит Java-приложение для веба между вами, пользователем, и базой данных. И способ доступа и манипулирования базой данных оформлен как фактическая, надежная система управления рабочим процессом, упомянутые диаграммы потока и доски канбан. Но большинство из нас не знает, как навигироваться в базах данных. Если что-то идет не так, мы не начинаем думать, как программисты.
Мы также не все менеджеры и не все думаем в терминах деревьев решений. Идея, что управление - это навык, который превосходит отдельные дисциплины, является частью презентации ПО для управления проектами - люди, продающие эти услуги, утверждают, что если их программное обеспечение работает для их разработчиков, оно должно быть хорошо для всех. Постоянное использование продукта, который они создают, также называемое dogfooding, является поводом гордости для компаний, таких как Asana, но для этого обозревателя это менее звучащая рекомендация, чем они могут себе представить.
Конец раздела
Информационная работа все больше требует от сотрудников управления более сложными задачами, но нам не следует самостоятельно управлять своей продуктивностью в несовершенных системах, созданных на основе мышления программистов, чтобы просто выполнять свою работу.
Поскольку нет одного способа организации проектов и рабочих нагрузок, ни одно программное обеспечение не может быть всем для современных работников. Возможно, вам понравится одна из этих программ, и это замечательно! Но преимущества программного обеспечения, такого как Jira, раскрываются настоящим программистам. Более маленькое, специфическое программное обеспечение, например Clio для юристов, скорее всего, решит проблемы конкретных видов работы, чем то, что заставляет работников просматривать SEO-оптимизированные статьи-списки в поисках набора функций, которые можно было бы адаптировать для их команды.
Огромная часть вашей работы сегодня может заключаться просто в разрешении и перенастройке естественной энтропии в вашем офисе, но неправильно переданные сроки будут оставаться таковыми, будь они записаны на карточке, отправлены по электронной почте или прикреплены к "задаче" в Asana. Если вы помещаете что-то на цифровую канбан-доску без достаточной информации, оно не становится более полезным, чем было до создания задачи. Программное обеспечение для управления персоналом перекладывает работу по управлению проектами на бесчисленное количество мини-проектов, каждый из которых полезен только насколько умелы и полезны отдельные пользователи. И мы не можем ожидать, что каждый пользователь будет и создателем, и самоуправляющимся, особенно с недостаточно совершенными инструментами на рынке. Когда мы ставим на одну линию Trello, Asana, Wrike, Airtable и безграничные клонов одного и того же пропущенного в управлении проектами, их различия имеют меньшее значение, чем их конечные результаты, чтобы перефразировать известную фразу из романа "Анна Каренина" — каждое приложение для управления проектами обещает одно и то же счастье, но каждое создает несчастных пользователей по-своему.