Реальность цифрового мира: проекты делает некомпетентная команда

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

Итак, все мы сталкивались или слышали о ситуациях, в которых IT-компания, которая взялась сделать проект, выставила команду из одних новичков или слабо компетентных сотрудников. Впрочем, это бывает не только в IT, так происходит в рекламе, в маркетинге, в разных других областях. Ощущения заказчика при этом напоминают то, что думал Вовка из замечательного мультика «Вовка в тридевятом царстве» глядя как делают его задание.

Часто думают, что это просто бизнес- модель подрядчика, что он зарабатывает деньги именно продажей новичков под видом компетентных специалистов. Однако, возникает вопрос – почему рынок не урегулирует эту ситуацию, почему заказчики не уходят к другим, компетентным подрядчиком?

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

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

Ситуация острая в IT уже 10 лет и обостряется с каждым годом. Казалось бы, рынок подготовки персонала должен реагировать и исправить ее. Собственно, в этом и была мораль уже упоминавшегося мультика про Вовку – учиться надо.

Однако, этого не происходит. Почему? Потому что технологии развиваются так быстро, что классический цикл подготовки специалистов через обучение за ними не успевает. Он медленный: 3-5 лет становления курса первопроходцами в какой-то области. Потом еще 5-10 лет они пишут учебники и методики, и сократить этот срок не получается. И только после этого можно массово тиражировать обучение. При нынешнем темпе развития технологии этот срок надо сократить даже не в два- три раза, а гораздо больше, проходить его за год-два. Это нереально. Поэтому учиться специалисты будут, выполняя ваши проекты.

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

То есть ситуация некомпетеных команд носит кумулятивный характер, она проявляется не только в области технологического фронтира, а во всей IT-отрасли. А поскольку цифровые технологии сейчас распространяются из IT во все отрасли, то дефицитный рынок персонала и некомпетеность команд будет повсеместной. И так будет теперь всегда, ну или лет 30-50 до стабилизации нового технологического уклада.

Собственно, эти изменения предсказывал Питер Друкер своих книгах по менеджменту с 80-х годов прошлого века посвящая им отдельные главы о новых вызовах менеджмента в бизнесе, основанном на знаниях. А в начале 21 века он написал об этих вызовах отдельную книгу «Менеджмент. Вызовы XXI века». Он предсказывал, что рынок труда превратиться из профицитного в дефицитный. И что деньгами проблему найма компетентного сотрудника решить будет невозможно. Что мы и наблюдаем сейчас в IT, где денег просто должно быть достаточно, а дальше выбор места работы идет по другим критериям. А я разбирал эти вызовы в статье «Цифровой мир: от физического труда — к умственному».

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

Хотя, конечно, бывает, что специалисты в предметной области, например квалифицированные разработчики, решают научиться руководить и приходит в команду руководителем проекта. А заодно приносят свои компетенции как разработчика и помогают джуниорам научиться разрабатывать. Но именно заодно, а не как основную деятельность, потому что они же пришли, не для этого, а чтобы научиться руководить проектом, и учатся этому, руководя как получается. Бывает наоборот, опытный менеджер решил пойти в новые сферы деятельности и осваивает на вашем проекте новую предметную область. И тогда он в команде занимает позицию аналитика или другую позицию по работе с предметной области. Менеджерские навыки у него не исчезают, и он может помочь в организации проекта. Но только помочь, у него основной фокус будет иным.

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

Оказывается, для этого уже давно есть методы. Первые из них появились, естественно, в IT как раз тогда, когда было осознанно, что регламенты и правила не работают, а ключевым фактором успеха является человеческий фактор. Об этом есть классическая книга Тома ДеМарко «Peopleware» (1987), которая в русском переводе так и называется «Человеческий фактор».

И как ответ на эту ситуацию появился Agile. Он взлетел именно поэтому, что появился во время прихода персоналок. Персоналки ведь пришли не домой, они сделали компьютеры доступными для мелких и средних компаний. И потребовалось массово автоматизировать бизнес, возник дефицит разработчиков. Их не было, выпуск институтов не увеличился. И именно Scrum и Agile обеспечили решение этой проблемы, позволив успешно делать проекты некомпетентной командой. Это был один из ключевых факторов их успеха и широкого распространения. В России, кстати, мы это не очень ощутили, потому что именно тогда, в период появления персоналок, развалилась оборонка и много квалифицированных инженеров ушли в айтишники, они демпфировали этот кризис. А на Западе этого не было.

IT проходил периоды востребованности новых технологий несколько раз. С развитием интернета всем компаниям потребовались сайты, потом – интернет магазины, сейчас всем нужны мобильные приложения и web-сайты, эффективно работающие со смартфонов. И заметим, что передовиками выступают вовсе не крупные корпорации, которые по старинке делают ставку на компетентность. А молодые мобильные компании, которые ищут тех кто готов расти и осваивать новое. И это – хорошо известно, это практически очевидно, и неявно предполагается в контексте обсуждений и дискуссий. Не слишком хороший, отстойный сайт крупной корпорации считался в порядке вещей, в отличие от сайтов небольших компаний, для которых ожидания гораздо выше. Корпорации сейчас уже, в основном, исправились, но это произошло на 5-7 лет позже. Я читал кучу комментариев про покупку билетов на сайте РЖД в стиле «надо же, у них не такой отстой, как я ожидал, и даже достаточно удобно» – это то есть от корпораций не ожидают сервиса по умолчанию. Аналогично, неудобный мобильный банк у крупного банка тоже никого не удивляет, стандартами удобства выступают совсем другие игроки.

И IT смог через все это пройти именно благодаря Agile-подходам к выполнению проектов. Да, Agile тоже не дает гарантии успеха. Статистика лишь говорит, что доля успешных проектов по Agile выше чем проектов выполняемых в рамках классического менеджмента, но в абсолютных цифрах она достаточно низкая. Ссылки на разные отчеты я приводил в статье про кейсы Agile-трансформации, не буду повторяться. Однако, в Agile нем сильно дешевле накладные расходы на управление. А встроенные механизмы обратной связи и корректировка движения позволяют идти в нужном направлении и достигать результата.

Но Agile – не единственный метод, которые позволяет делать проекты некомпетентными командами. Есть еще дизайн-мышление, Design Thinking. Собственно, идея-то очевидная: когда ты не знаешь, как достичь результата, значит, тебе надо это придумать. Ну и давайте соберем методы мышления, которые позволяют эффективно коллективно порождать идеи и создавать результат, добавим к ним эффективную фасилитацию – и у нас обязательно получится. Кстати, эта идея иллюстрирована в прекрасном фильме «Карнавальная ночь» – успех там достигается за счет совместного креатива. И я всегда привожу пример этого фильма, когда мне надо дать хороший образ команды, самостоятельно организующей свою работу и решающей нестандартные задачи, особенно людям старшего поколения. Вот так оно выглядит.

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

Сейчас ставят на компетенции, которые позволяют быстро осваивать новые предметные области. Тут много разных направлений. На мой взгляд, наиболее перспективно то, что делает Анатолий Левенчук и его Школа системного менеджмента. Это рациональное мышление, системное мышление, его прикладные приложениями в менеджменте, инженерии, лидерстве и других областях, с углублением на базовые уровни управления вниманием и волей, а также выходом в методы убедительную коммуникацию.

Итак, как же делать проекты в современном мире? Главное – принять то, что их с большой вероятностью будет делать некомпетентная команда. И не применять в новых условиях то, что в них не работает. Если компетентная команда вам недоступна, то все методы, в которых ее наличие является непременным условием успеха надо выбросить.

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

На этом я завершаю статью. Она была написана по мотивам моего выпуска в подкасте «Менеджмент цифрового мира» на ТОП-менеджмент FM http://tmfm.site. B если вы предпочитаете слушать, а не читать, то это можно делать там. Подкаст идет на 12 разных площадках, на сайте есть ссылки - выбирайте ту, которая вам нравится.