Пузырьки компетенций или почему ваш проект был неудачным?

Некоторое время назад, когда мы решили, что нужно двигаться в сторону больших (по-настоящему больших) проектов, я сел и углубился в анализ истории, которая накопилась за годы работы.


Анализировал успешные/не очень успешные, а так же простые и сложные проекты. Простые и сложные не с точки зрения реализации, а, скорее, с точки зрения их безболезненного прохождения. Бывает так, что проект сложнейший: какая-нибудь безумная разработка, интеграции с малоизвестными системами, у программистов (предполагаю) мозги кипят. При этом проект простой, идет легко и гладко как по маслу.

А бывает и наоборот, проект по сути яйца выеденного не стоит. Бюджет крошечный, задача простая. А проведение его от начала до конца становится непреодолимой задачей.Постепенно сложилась модель, показывающая причины таких неудач. Я ее назвал «пузырьки компетенций».

Проект в самом общем случае можно разложить на следующие большие этапы:

  • Пресейл (этап от лида до сделки)
  • Обследование (это этап бизнес-анализа, консалтинга, сбора требований, описания требований и концепции)
  • Разработка (тут тоже может быть обследование, но оно техническое, с целью написания ТЗ на разработку; продумывание архитектуры, разработка, тестирование, техническая сдача работ)
  • Внедрение (это общение с пользователями, очень много общения: обучение пользователей, настройка обменов, загрузка данных, выверка, помощь при эксплуатации)
  • Поддержка (техническая поддержка внедренного решения)
Это очень упрощено. На самом деле в проекте может быть несколько фаз, каждая из которых будет требовать циклов обследования/разработки/внедрения или еще какого-то сочетания этапов.

С другой стороны, в проекте могут быть не все этапы: например, может быть только консалтинговая часть. Может быть только часть «разработка» (когда мы получаем на входе «требования к разработке», а внедряет, например, генподрядчик или ИТ-служба заказчика), или может быть только внедрение, когда типовой продукт без разработки запускается.

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

ИТАК, ЧТО ЖЕ У МЕНЯ ПОЛУЧИЛОСЬ?

  • Пресейл – отлично делает коммерческий директор. Могу сделать и я.
  • Обследование (бизнесовое) – у меня получается. Может делать и коммерческий директор.
  • Управление разработкой – технический директор от и до.
  • Внедрение и техподдержка – руководитель отдела внедрений и техподдержки, что, в общем, логично.

Спросите, ну и что? А вот что: безусловно успешные проекты у нас – это такие, в которых «пузырёк» только один. Пузырек один – проект идет гладко и хорошо. Все четко, понятно, в сроки и без нервов. Пузырьков несколько – проблемы. Теперь все стало ясно и логично, самые удачные (с точки зрения вложенные нервы/заработанные деньги) и самые ужасные проекты легко уложились в эту модель. Пузырек внутри одной сферы компетенций – проект будет супер. Пузырек охватывает две и более компетенций – можно ожидать осадки с грозами.

«ХОРОШИЕ» ПРОЕКТЫ

«ПЛОХИЕ» ПРОЕКТЫ

Да-да, я знаю, что меня читают клиенты. Может, даже потенциальные.

Не пугайтесь, «плохой проект» иногда клиенту и не заметен, с его точки зрения все идет как надо. Вопрос – какой ценой нам это доставалось. Какие внутренние битвы между отделами происходили, сколько конфликтов приходилось выслушивать/решать, и какова в итоге получалась маржинальность такого проекта.

Были проекты, закрытые «в ноль» или даже с убытком (то есть дешевле было бы его не делать).Как только я осознал проблему, стало ясно, что ее надо срочно решать. Тогда цель «делать большие и сложные проекты» уже была поставлена, так что «пузырьковая задача» стала одной из самых важных.

МЫ ОБДУМЫВАЛИ ТАКИЕ ПУТИ РЕШЕНИЯ

РАСШИРЯТЬ ОБЛАСТЬ КОМПЕТЕНЦИЙ КАЖДОГО УЧАСТНИКА. 

Сложно… У комдира нет желания разбираться в управлении программистами и архитектуре разработки. На самом деле, в том, как внедрить 1С:Бухгалтерию, он тоже не хочет разбираться. Технический директор… скажем так, любит программистов и не очень любит общаться с пользователями.

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

НАХОДИТЬ И/ИЛИ ВОСПИТЫВАТЬ ЛЮДЕЙ, ОБЛАДАЮЩИХ СМЕЖНЫМИ КОМПЕТЕНЦИЯМИ В РАВНОЙ МЕРЕ (ДОСТАТОЧНОЙ ДЛЯ ВЕДЕНИЯ ПРОЕКТА). 

Да что же это за люди такие, универсалы-многостаночники-терминаторы? Которые будут разбираться во всем: продажах, управлении программистами, архитектуре решений на 1С, внедрениях? Конечно такие есть. Я, например:) Только стоят они дорого, их мало, и они не пошли бы ко мне работать, потому что у них свой ИТ-бизнес.

ОРГАНИЗОВАТЬ ПОЛНУЮ ПЕРЕДАЧУ ИНФОРМАЦИИ ПРИ ПЕРЕСЕЧЕНИИ ГРАНИЦ КОМПЕТЕНЦИЙ

+ (возможно) организовать систему курирования проекта тем, кто проводил бизнесовое обследование.

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

Как вы поняли, я пошел именно по этому, третьему, пути. Как мы это сделали, я расскажу в другой раз.

Сейчас все новые проекты ведутся по новому – с авторским надзором и четкой передачей всей информации как «на стыках», так и «изнутри» пузырьков. Результаты радуют, процесс стал прозрачнее, конфликтов внутри коллектива практически нет, каждая заинтересованная сторона в курсе ключевых аспектов проекта в любой момент.

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

Оригинал статьи: https://corada.ru/obsuzhdaem-problemy/interesnoe-i-poleznoe/puzyrki-kompetentsiy/