{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

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

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

Итак, все мы сталкивались или слышали о ситуациях, в которых 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 разных площадках, на сайте есть ссылки - выбирайте ту, которая вам нравится.

0
10 комментариев
Написать комментарий...
Dmitry Podluzny

Мне кажется, что некомпетентность команд, конечно, объективная вещь, но это не такое уж распространенное явление. Большинство задач, которые решают IT специалисты, весьма типовые и повторяются из компании в компанию. В итоге 95% всего что делается будет делаться командами с достаточно степенью компетенции. Остается небольшой процесс инновационных задач и пограничных случае. В случаи иновационных задач сама задача определяет то, что любая команда с ней сталкивающаяся окажется недосточно компетентной вначале. А пограничный случай – это ситуация излишнего оптимизма, когда команда лезет в область, которую не очень знает или недооценивает сложность, ну или бизнес специально выбирает тех, кто готов озвучивать фантастические по скорости планы, которые олждаются из-за некомпетентности команды. 

Ответить
Развернуть ветку
Максим Цепков
Автор

Не, вы не понимаете ситуацию. Инновационных задач вовсе не 5% и даже не 10, их гораздо больше. Есть такая штука - TRL, Technology readiness level придуман NASA чтобы оценивать, насколько новые технологии гарантированно дают результат. Потом это начали использовать широко. И вот Боинг, который контрактует самолеты на стадии конструирования, выяснил, что чтобы контракты выполнялись, в новый самолет можно закладывать технологии с уровнем не ниже 8 из 10. Иначе провал по срокам и деньгам почти гарантирован как при большом НИОКР в новой области. Так вот, если мы по этой шкале посмотрим на технологии, на которых сейчас делают мобильную разработку, то их готовность - 4-5. И это - стабильная ситуация, потому что пока технологии становится более надежными, техника делает следующий шаг вперед, и процесс повторяется. Поэтому инновационных задач в IT-отрасли  - не меньше половины. Ну, пусть треть.

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

Ответить
Развернуть ветку
Дмитрий Смирнов

Тут ещё проблема что часто именно в этих 5% вся суть проекта и заключается. Например, когда делался условный агрегатор авиабилетов вся сложность была именно в качественной агрегации (5% нового) - все интерфейсы, базовые алгоритмы и т.п. (95% старого) важны, но без этих 5% нового проект теряет смысл.

Ответить
Развернуть ветку
Влад Кошечкин

Поэтому в конце на это есть сноска, что если нет доступа к компетентной команде, то выбросить как раз те 5% задач, смириться с этим (ну или заменить задачи и тд)

Ответить
Развернуть ветку
Максим Цепков
Автор

Не 5% там. Я подробнее ответил Дмитрию...

Ответить
Развернуть ветку
Влад Кошечкин

согласен, просто в контексте предыдущего комментария

Ответить
Развернуть ветку
Artem Petrenkov

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

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Artem Petrenkov

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

Ответить
Развернуть ветку
Максим Цепков
Автор

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

В общем, тут Agile-методы тоже помогают. Особенно если рассматривать их из широкой рамки, включая инженерные и специфичные практики - парное программирование, code review, continuous integration, FDD, DDD, TDD и так далее. Техническую некомпетентность они тоже позволяют преодолевать. А еще есть непрямое воздействие. Например,  необходимость оценки задачи перед выполнением. Если к этому относятся всерьез, то ты должен подготовить задачу до оцениваемого состояния. Той командой, которая будет делать. Плюс требование декомпозиции больших задач.

Что касается нагрузки - то заказчик вполне может это требовать - через испытания. Фишка в том, что никакая компетентность команды не гарантирует масштабирование и нагрузку без испытаний. Это просто факт. Правда, стоят денег и времени - а это уже вопрос коммерческих рисков Заказчика. Многие же хотят получить их "бесплатно" через компетентную команду. Так не бывает. Просто компетентные исполнители объяснят это заказчику, покажут как сделать.  Но для этого он должен их нанять, они дороже. И он пойдет на это, только если понимает риски в работе под нагрузкой. Но если он их понимает - то значит и другой путь, через испытания - тоже доступен и надо выбрать.

Ответить
Развернуть ветку
7 комментариев
Раскрывать всегда