Как работать с разработчиками "первой волны"
Думаю что многие сталкивались с таким положением дел. У руля стоит команда разработчиков, которая начинала проект уже 18 лет назад. Позади уже не первая версия продукта, коллектив небольшой, но спаянный. Спаянный, потому что друг друга знают, делают правда все по-старинке. И никого к себе в разработку не пускают.
Системы и отлаженных бизнес процессов нет. Но ведь раньше не было это необходимо.
И вот порождаются уже новые продукты - а сейчас особенно - так как технологии шагнули вперед очень далеко. Но продукты ох как похожие на то, что делалось в начале 2000-х.
Молодые РП ругаются и отказываются работать, и продукт продолжает печально хромать к своему логическому завершению по Адизесу.
Можно ли исправить такой проект? Ведь не проект же так себя ведет. Это люди. И они, когда застряли в своем времени, застряли прочно. Что тут можно сделать? И нужно ли?
И что доложно на самом деле быть? Как должна работать команда по настоящему замотивированная на проект?
1. Начнем по порядку. Сделать кое-что можно. Во-первых, часть таких команд иногда все-таки еще поддается порывам сделать хорошо," тряхнуть стариной" - и тогда необходимо ввести в проект молодых - и просто начать работать по новому.
Если же все-таки таких вариантов нет, то мне кажется и тут выход есть достаточно гуманный. Но он нуждается в полном одобрении вышестоящими лидерами организации, так как без их поддержки идея рассыпется как карточный домик.
Перестроить процесс по типу Бирюзовых организаций - Фредерика Лалу «Открывая организации будущего». Этот вариант скорее всего существенно почистит ряды сидельцев на проекте - но оставшиеся люди будут иметь удивительный шанс поработать с командой, в которой есть "синергетический эффект" - совместная работа будет на только эффективной, но и вдохновляющей.
Ну и третий вариант - это просто создать проект заново. Такие случаи тоже бывают. Ничто не стоит на месте.
2. Как же стоит работать над проектом.? В принципе все уже описано выше - если проект построен по Бирюзовым принципам - то каждый, кто участвует в проекте, получает и опыт и радость от совместной работы над проектом. И проект растет и развивается в положительную сторону. Когда есть радость от работы, и работа спорится.
И именно в этих условиях очень часто становится видно, что на первом месте в проектах должен стоять не личный эгоизм и корысть, а синергия и сотрудничество. Которые порождают отличные творческие решения.
ЕСТЬ ЛИ В МОЕЙ ЖИЗНИ ТАКИЕ ПРИМЕРЫ? Да - безусловно. Иначе я бы не рискнула даже об этом заикнуться на страницах блога. Проект M2Ms система диагностики - которая разрабатывалась как обособленный продукт в компании CSBI - был изначально построен по этим принципам. Работа получилось простая и красивая. Команда работала с удовольствием. И в нее всегда просились "соседи". Опыт показал - что это не только эффективно. По отзывам всех участников - с точки зрения креатива и базисных отношений - это было одно из лучших решений и мест для работы, не взирая на то, что в остальных отделах, построенных по другим принципам не все было так радужно. За что и спасибо руководителям дирекции, которые таки дали создать проект не вмешиваясь в структуру.
Что же касается старых сотрудников огромных проектов. Иногда, как мне кажется, для этих людей было бы огромным благом оказаться уволенными - так как это даст им еще один шанс посмотреть со стороны не только на процесс разработки, но и на себя самих. А также снова "прокачать" свои навыки.
В дополнение могу сказать, что решение для "старичков" есть. Оно в большей степени используется в крупных корпорациях, которые умею и должны себя "страховать" от подобных инцидентов.
Так вот решается вопрос при наличии ресурсов и жестких правил достаточно просто:
1. Ключевые позиции получают опцион и на них хоть как то но можно влиять.
2. Ключевые позиции четко документируют все что они делают - так построен бизнес процесс
3. В компании есть СБ, которая следит за тем чтобы не было утечек данных и за тем, куда смотрят сотрудники, подписывается NDA
4. Ключевые компетенции дублируются!!!!!!!
Да - продукт может получиться немного хуже, нежели с привлечением одного единственного гения. Но и внакладе компания не останется, так как ничто не будет утрачено, если даже ключевой сотрудник уволен по каким-то причинам или сам ушел.
На самом деле из своего опыта уже скажу, было всякое - увольняли, уходили люди группой, потому что поманили чем то сладким. Удержать тоже никого не возможно. Надо быть готовым к этим ситуациям. А это пункты 1-4.
Мы часто боимся, жалеем и не хотим увольнять, потому что это и страшно, и неприятно. Но это в любом случае может произойти. Человек может умереть/заболеть/уехать ключевой. Поэтому лучше всего так организовать бизнес-процесс - чтобы пункты 1-4 соблюдались. Тогда потери можно свести к минимуму.