В небольших IT-компаниях часто возникает патовая ситуация: во главе разработки стоит главный архитектор, человек, который стоял у истоков компании, сам проектировал систему. Развил ее до некоего целостного состояния и завоевал позицию абсолютного технического лидера. Теперь по негласным правилам все изменения и согласования проходят только через него.
Как решить проблему сосредоточения экспертизы на одном человеке? И как выстроить работу по расширению коллективного управления и систематизации развития продукта.
Под небольшими IT-компаниями подразумеваются стартапы, переросшие в бизнес с моно-продуктом или аутсорсинговые фирмы, живущие за счет оказания услуг другим компаниям. Численность сотрудников обычно — 30-50 человек.
Основной акцент в контексте статьи — что во главе разработки флагманского продукта стоит один человек, так называемый Главный Архитектор.
«Есть два мнения — мое и неправильное»
Проходит какое-то время, и становится заметно, что внедрение любых нововведений занимает необоснованно много времени. Все согласования — только через Главного Архитектора, так как только он знает, что и как правильно сделать. Причем, очень часто саботирует новшества как не имеющие пользы для Системы, даже если есть тысяча аргументов «за». Ему — не нравится, ему не хочется, настроение с утра плохое или просто он не понимает, зачем это нужно. Чаще всего — относится к Системе как к любимому детищу, на которое кто-то посмел посягнуть…
А клиенты устают ждать и уходят
Потому что для решения даже простейших задач вроде «поставить заглушку» или отключить на время некую функциональность требуется громадное количество времени. В бизнесе, когда на счету бывает каждая минута, такие проволочки приводят к потере денег и репутации. Поэтому заказчики прощаются.
И им неинтересно, что Главный Архитектор хочет сделать «все по уму» или «как надо». Они хотят оперативно. Не можете — до свидания, было приятно познакомиться.
Как менеджеру команды найти подход к архитектору-ретрограду
Как и к любому другому человеку, ведь несмотря на все регалии, «верховный админ» — тоже человек. Его опытные коллеги или те, кто начинал работать вместе с ним, знают тайные кнопки, на которые можно аккуратно нажать — и будет получено нужное согласие на внедрение изменений в систему.
Но как быть тому самому «неопытному», новому менеджеру или тимлиду? В особенности, если на эту должность поставили кого-то из молодых разработчиков (классовых врагов «ретрограда») — именно потому, что именно «салага зеленый» лучше понимает текущие запросы клиентов, может разговаривать с ними на одном языке и легко делать выручку, за счет которой, собственно, и существует компания.
Теперь еще объяснить все это умудренному опытом «старожилу», который возмущен творящимся иерархическим беспределом: вчера это был молодой падаван, а сегодня — он будет руководить самим Главным?
В обеих ситуациях (когда приходит новый менеджер «со стороны» или когда назначают кого-то из разработчиков) подход к решению ситуации одинаковый.
Разберем пример. Появилась информация, что главный конкурент через месяц выпускает новую версию приложения с супер-востребованной функциональностью — подключением смарт-часов. Менеджеры компании уже не раз пытались пропихнуть эту идею, но Главный Архитектор был непреклонен — такая функциональность не нужна и трудно реализуема.
Всем понятно, что дальше — только уходить с рынка. Или что — Архитектора увольнять? (Хорошо, если можно это сделать физически, и лучше — без последствий. Чаще всего — невозможно).
В чем здесь проблемы?
1) Качество системы с точки зрения Главного Архитектора превыше всего. Все, что делается «по уму» — делается несоразмерно долго, иначе оно обесценивается. Как следствие, пункт 2.
2) Система «застряла» в развитии и не удовлетворяет современным требованиям.
3) Клиенты уходят к конкурентам.
4) Все знания по Системе сконцентрированы у одного человека. И если с ним что-то случится, то компания рискует на длительное время остаться без поддержки. Необходимо будет потратить время на найм нового разработчика и введение его в курс дела.
Как сделать Главного Архитектора лояльным сторонником нововведений
Не пытаться передавить его авторитетом. Если он хочет быть главным, то он и должен сам предложить реализацию новых функций.
Анализируем ситуацию глазами Главного, как он ее видит: «Опять эти менеджеры чего-то новомодного напридумывали. Раз сами придумали, пускай сами и делают. А у меня еще три проекта кроме этого, времени нет ерундой заниматься».
Теперь задаем себе вопрос: разве он так себя вел раньше? Скорее всего, нет. Потому что выйти на рынок компания смогла благодаря своевременному внесению изменений в разумные сроки.
С какого момента начался саботаж? Какое событие могло изменить поведение Главного?
Анализируем варианты:
- сменилась команда — пришли молодые разработчики, которые хотят внедрить новые технологии, а на качество не смотрят — и это бесит перфекциониста-архитектора;
- сменилось руководство — прежний менеджер понимал, как Система работает и предлагал адекватные комментарии.
- появилось больше клиентов и соответственно больше проектов, которые не успевают довести до ума (и снова бесят перфекциониста-разработчика).
По каким причинам Главный Архитектор саботирует менеджера?
Например, поставлена нечеткая цель, разработчик не понимает задачу и как следствие — пытается отстраниться от ее выполнения, чтобы не потерять свой авторитет или не показаться недостаточно современным.
Возможно, не умеет. Но такая вероятность — практически нулевая. Скорее всего, все он умеет, поэтому и стал Главным.
Физически не может. Допускается. Главный Архитектор занят другими задачами, которые не видит менеджер. Поэтому внедрение изменений занимает много времени.
Просто не хочет. Возможно. Потому что внесение изменений нарушит целостность системы, породит новые баги — и как следствие, добавит массу работы.
Еще один вариант — Главный просто «выгорел». Да, он опытный и компетентный специалист, но он все еще человек. Да, он ходит на работу, потому что умеет ее делать, потому что хорошо платят, но он морально устал и у него нет никакого интереса заниматься развитием Системы.
Анализируем реальные цели и желания Архитектора-человека
Не компании, не команды, не менеджера или клиента. Чего Главный Архитектор хочет от работы и от жизни?
- авторитета;
- признания;
- развития;
- денег;
- карьеры.
Что из этого будет важно и актуально для Главного? Что покажет ему соответствие задачи личным целям и желаниям?
Как ставить задачу, исходя из желаний архитектора-человека: вовлечение личных целей
Разговор можно начать со слов: «Смотри, у нас есть запрос на интеграцию со смарт-часами. Конкуренты выпустят апдейт через месяц. Как нам сделать такую же и тоже за месяц?»
Именно такая формулировка показывает, что запрос не проталкивается через силу, а привлекает к решению Главного Архитектора. Его мнение, его опыт. Здесь акцент делается на авторитет и признание. Заодно проясняется «нечеткая цель». Если интеграция нужна действительно через месяц, стоит обговорить этапы работы.
Следующий этап — вопрос: «Что будет, если мы займемся этим вопросом?» И в качестве ответа получаем обоснованные аргументы на случай «не может» или «не успеет». Здесь могут всплыть реальные, не учтенные менеджером нюансы: например, задачи и проекты, которые находятся в текущей работе. Главное — дать человеку время высказаться, взвесить свои возможности.
Когда он закончит, можно задать очень простой, но очень мощный вопрос: «А что еще?». И здесь прекрасно раскрываются причины из списка «не хочет» и даже из списка «не умеет». Потому что его авторитет и признание уже благополучно подтверждены. Бояться больше нечего.
Нужно ли решать вопрос диверсификации знаний?
Сосредоточение экспертизы и навыков в руках (и голове) одного человека — это всегда определенный риск, как для продукта, так и для компании в целом. Ответ закономерный и логичный: диверсифицировать нужно. Причем, в контексте вышеприведенного кейса следует отделить нюансы технической реализации от бизнес-требований.
Как диверсифицировать знания
Для решения проблемы концентрации всех знаний и разработок на одном человеке применяется ступенчатое внедрение. Менеджер привлекает (или назначает из команды) нового человека, так как сосредоточение всей экспертизы в одних руках — это неизбежный риск для организации.
Чтобы не встретить еще одну волну саботажа, «упаковывается» внедрение нового человека в тот же самый авторитет и признание.
Главному Архитектору, который уже успел сообщить о своей загруженности, дают в помощь человека, который возьмет на себя мелкие рутинные задачи. На которые у «старожила» нет времени, но выполнить их надо. Главная апелляция здесь: «твоя знания и навыки нужны на новых проектах, поэтому для рутины мы подключим к работе над Системой нового разработчика, но некоторое время ты будешь ревьюить его код».
Таким образом передача поддержки и управления произойдет не сразу, а постепенно.
Конкретную проблему решили, а как теперь быть с вопросов владения знаниями на системном уровне? Здесь приходят на помощь инженерные практики и гибкие методологии.
Парное программирование, ретроспектива (даже если в компании не внедрен Scrum, это вполне себе самостоятельная практика), код ревью, воркшопы. Все эти события объединяет одно — они коллективные. Совместное обсуждение технических вопросов и нюансов их реализации прокачивает общий уровень команды.
Причем, это правило справедливо не только для сферы IT – оно универсально. Например, в конце 19 и начале 20 веков в России набирали обороты литературные сообщества. И многие участники отмечали, что за год коллективных обсуждений их произведений они получали столько опыта, сколько не смогли бы получить в одиночку за пять лет.
А что делать с требованиями бизнеса?
В случае, который мы разбираем как пример, финальное одобрение стояло за Главным Архитектором, что опять же рискованно. На этапе становления это вполне целесообразно, однако если компания — это уже не стартап, а стабильный бизнес, то ей нужен другой подход.
Для принятия устойчивых решений, то есть тех, которые одобряют реализацию той или иной функциональности, необходимо привлекать владельца продукта (он же product owner), если таковой имеется, либо же эту функцию выполняет CEO (chief executive officer).
Главный признак такого человека в бизнесе — он находится на передовой и видит тренды индустрии, потребности пользователей и может принять важнейшее решение: делать или не делать ту или иную функциональность.
То есть глобально продуктовый вектор определяет владелец продукта.
Если в компании внедрены OKR (Objectives and Key Results), то в какой-то мере в формировании продукта будут участвовать все. Владелец сам решает, как он может посодействовать целям компании, а команда в свою очередь эти цели тоже видит и может подсказать что-то непосредственно руководству.
В итоге участие Главного Архитектора и тим лидов становится рекомендательным: какие пожелания сделать можно, но сложно или дорого. Что здесь можно срезать углы, потому что вложений будет много, а продуктового выхлопа — минимум.
Таким образом происходит расширение экспертизы в коллективную сферу, решение технических вопросов остается за командой, а определение того, как должен развиваться продукт — за владельцем.
Резюме
Золотое правило — решаем проблему человека, а не клиента или компании. Главный Архитектор — тоже личность, со своими желаниями и целями. Если увязать его потребности с рабочими задачами — отдача и эффективность будут больше.
При решении проблем — выясняем, по каким причинам эти проблемы возникают, и устраняем именно причины, а не следствия.
