Пузырьки компетенций

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

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

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

Это очень упрощено. На самом деле в проекте может быть несколько фаз, каждая из которых будет требовать циклов обследования/разработки/внедрения или еще какого-то сочетания этапов.

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

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

Итак, что же у меня получилось?

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

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

«Хорошие» проекты

«Плохие» проекты

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

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

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

Мы обдумывали такие пути решения

Расширять область компетенций каждого участника. 

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

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

Находить и/или воспитывать людей, обладающих смежными компетенциями в равной мере (достаточной для ведения проекта). 

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

Организовать полную передачу информации при пересечении границ компетенций

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


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

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

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

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