Карт-бланш
Опытного Менеджера разработки пригласили в компанию для консалтинга и помощи в выстраивании процессов в разработке. Спустя две недели Менеджер сообщил Операционному директору, что помимо организационных провалов в управлении он видит технические и архитектурные проблемы разработки. Так как у Менеджера разработки нет технического бэкграунда, он предлагает привлечь в команду технического специалиста со стороны для проведения аудита. Операционный директор приглашает своего хорошего друга в качестве Техлида, у которого есть нужные знания и опыт, работа в нескольких компания в качестве CTO(Chief Technology Officer). После первого знакомства Менеджер понимает и сообщает Операционному директору, что Техлид имеет опыт не только в технических вопросах, но может закрыть и проблемы, связанные с процессами разработки. Операционный директор в целом согласен, но предлагает дождаться технического аудита и дальше принять решение по зонам ответственности. Техлид начинает аудит, видит значимые архитектурные проблемы и привлекает для их решения Стороннего разработчика, которому доверяет. Через две недели неделиТехлид начинает директивно ставить задачи Менеджеру разработки, как своему подчиненному, писать регламенты взаимодействия со смежными отделами, ни с кем не согласовывая. Он считает, что нужно работать так и никак иначе, потому что он всегда так работает и его устраивают процессы, выстроенные именно так. Подстраиваться ни под кого не хочет, его время стоит дорого, и он как «талантливый хирург спасает пациента и все вокруг должны ему ассистировать и не мешать».Тем временем к Менеджеру приходит Внутренний опытный разработчик, обеспокоенный тем, что команда не до конца понимает, что происходит: внедряемые изменения слишком радикальны и тяжеловесны для их небольшой компании, ему больше подходит подход к изменениям Менеджера разработки.
Владелец компании также обеспокоен тем, что происходит в компании. Он привлекал новые кадры для стабилизации процессов, а тут такая «буря». Боится, что команда разбежится, да и клиенты тоже, из-за нововведений срок решения задач увеличился, и клиенты уже начинают роптать.
Позиции до переговоров:
Сторона А) Менеджер разработки и Внутренний опытный разработчик - считают, что нововведения, которые хочет внедрить Техлид, слишком агрессивные и тяжеловесные для их небольшой компании, не признают Техлида в роли СТО, подчиняться не готовы, пока не будут официально приняты решения и оговорены новые зоны ответственности.
Сторона Б) Техлид и Сторонний разработчик видят, что проблем много: и технических, и процессных. Чтобы команда эффективно начала работать, нужно быстро внедрять решения, которые уже сто раз были проверены. Считают, что Владелец компании и Операционный директор дали им карт-бланш. Не понимают сопротивления Менеджера и Внутреннего разработчика. Как можно менять процесс, если сам не готов меняться.
Сторона В) Операционный директор и Владелец компании - хотят сохранить команду и клиентов, при этом видят, что пора менять подходы и к процессам, и к техническим решениям, потому что текущий темп разработки задач их не устраивает. В планах увеличение клиентской базы: к концу года Х2, через 5 лет Х10. Решение, кто именно будет отвечать за внедрение, не принято, готовы рассмотреть любые варианты.