Управление проектами сотрудников

В этой статье речь пойдет о проектах сотрудников. Касается это в большей степени компаний которые занимаются более-менее интеллектуальной работой: исследования, разбоработка, проектирование и прочий НИОКР.

Приходит сотрудник с какой-то идеей, может быть даже оформленной в виде служебной записки. Начальство говорит конечно, давай, пробуй, делай. 

И какой-нибудь еще сотрудник приходит к что-то предлагает и ему говорят, давай, делай! 

И так их приходит некоторое количество. 

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

И какая там была идея, от какого сотрудника, что он предлагал? Кто уж вспомнит...

Это одна из частых проблем когда речь заходит про инновации снизу. 

Какой же должен быть правильный Алгоритм / Процедура. 

Шаг 1. Фиксация

На самом деле решение для этой проблемы достаточно простое, оно заключается в фиксации. 

Фиксация, она может быть двух видов:

1. Сначала одобрение потом ресурс

Данное решение подходит большинству компаний и сотрудников

2. Сначала ресурс потом одобрение

Данное решение подходит для лучших сотрудников и при условии что это не сломает работу. Чаще всего применяется в сфере НИОКР. 

В первом случае мы (самый простой и ресурсный вариант) заводим табличку (да для этого можно использовать хитрый софт, но подойдет и табличка). Куда сотрудники могут заносить свои проекты.

Здесь у нас может быть несколько целей: 

1. Мы фиксируем проблему;

Что само по себе ценно. Мы узнаем где в нашей системе есть не оптимальность. 

2. Мы фиксируем решение; Думаю польза очевидно и не нуждается в дополнительном пояснении.

3. Мы фиксируем кейс/прецедент;

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

Городить тут что-то сверх сложно на первых порах не надо, достаточно:

1. Проблема, которую решает сотрудник.
2. Что предлагается в качестве решения
3. Что надо сотруднику для реализации теста/прототипа
4. Дата

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

По поводу того как побуждать и сподвигать людей на это вы можете узнать из статьи или видео Управление знаниями, почему не получается?

Шаг 2. Оценка

Далее предложения надо оценить. Самое трудное просто делать это! 

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

Здесь важно что даже если идея фигня необходима обратная связь сотруднику. И не в течение года или десятилетия, а в идеале недели. 

Ответ должен быть как-то обоснован. Просто нет/отклонено это не обоснование. 

Обоснование указывает:

1. Почему это не сработает (желательно с указание на существующий прецедент, рыночную ситуацию, тренды в области и пр.).
2. Каких данных не хватает. Возможно сотрудник недостаточно глубоко изучил проблему или решение.
3. Если нужны большие сливания бабла (хоть это и случается не часто), почему компания не может потратить бабки сейчас и сможет ли потом.
4. Или если просто в компании завал/аврал и иная ситуация когда надо сфокусироваться на чем-то одном, указание на то когда можно будет этим заняться. То есть что на проект не забили, а просто поставили на паузу.

Из опыта автора просто сформулировать Проблему, Решение и Что для этого ему надо, могут очень сильно не все сотрудники. 

Про то как научить/обучить людей делать кейсы вы можете прочесть в отдельной статье. 

А переживать по поводу того что Вас ими завалят не стоит. Судя по мировому опыту это происходит крайне редко. 

Шаг 3. Ресурсы

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

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

Иногда для реализации прототипа сотруднику нужны дополнительные люди. 

Здесь могут быть несколько вариантов: 

1. Сотрудник сам набирает людей заинтересованных, а вы только согласовываете.
2. Люди откликаются на предложение. Это можно реализовать в том же простой табличке и рассылке по мыло или в месенджере.
3. Люди выделяются принудительно. Если проект перспективный. Например в японской компании Canon есть проекты "золотых значков" которые считаются особо перспективными и соответственно могут набирать себе те ресурсы которые им необходимы принудительно (пример вы можете найти в базе знаний).

Если сотрудники опытные/лучшие в некоторых корпорациях применяются несколько иную схему.

Да в таблицу все еще заносится информация, что сотрудник начал проект. 

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

Шаг 4. Сроки и критерии 

Народная мудрость – После того как проект начался, главное его закончить. Иначе в компании копятся проекты зомби которые когда-то, кто-то начала, но так и не закончил. 

То есть должен быть срок показа какого-то результата согласованный с сотрудником. 

Например, через месяц сотрудник отчитывается о состоянии проекта.

Далее мы принимаем решение продолжать проект или закрывать его. 

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

Хотя из любого проекта мы должны извлечь урок = превратить его в кейс. Что-то полезное что может пригодится нам в будущем. С этой целью в конце проекта проводится что-то вроде "разбора полетов" или ретроспективы. 

Про них у меня так же есть отдельные статьи.

Шаг 5. История

Что бы проект был полезным помимо "разбора полетов" у проекта должна быть сохраненная история. Про это так же есть отдельная статья. 

Шаг 6. Повторное использование

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

Для этого вы просто даете доступ к истории похожих проектов каждый сотруднику.

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

Но более детально об этом я так же расскажу в отдельной статье.