Опыт в сфере коммерческой разработки. Из них 8+ лет – на руководящих позициях.
Общий размер команд разработки, которыми доводилось управлять. Включали в себя разработчиков, тестировщиков, бизнес-аналитиков, технических писателей.
И 650K+ уникальных посетителей. Работал преимущественно с высоконагруженными проектами в сфере e-commerce.
Эти компании уже смогли воспользоваться моим опытом и экспертизой.
Являюсь сторонником подхода, согласно которому каждый специалист в команде, включая руководителя, должен обладать глубокой экспертизой в одной области, и более поверхностными знаниями в нескольких смежных областях. Оптимальная организационная структура, на мой взгляд – когда есть выделенные центры экспертизы (департаменты/отделы/группы) по направлениям, возглавляемые лучшим экспертом по этому направлению, а сотрудники этих отделов уже делятся на продуктовые/проектные команды по принципу матричного подчинения.
Глубоко ценю и на интуитивном уровне понимаю пользу от подходов гибкой разработки. Всегда стараюсь применять их там, где это возможно. Наибольший успех с выстраиванием прозрачной, эффективной и прогнозируемой разработки пока удавалось добиваться благодаря внедрению гибкого фреймворка Scrum.
Стремлюсь всегда интегрировать ИТ, бизнес и руководство, чтобы все были довольны и никто не уходил обиженным. 🙂 Я считаю, что совместная работа в компании это никогда не игра с нулевой суммой, в которой есть победители и проигравшие. Если есть какая-то, любая, боль у заказчика, у члена команды или у моего руководителя – с этой болью нужно работать, чтобы её вылечить и все могли работать комфортно и эффективно. Если для решения проблемы одного подразделения требуется помощь со стороны другого – необходимо совместно выработать и внедрить взаимовыгодный компромисс (win-win).
Первое, что предстоит каждому новому сотруднику, включая меня – это онбординг. А лучший способ обеспечить эффективный и короткий онбординг – наличие исчерпывающей документации по сфере ответственности сотрудника (рабочие процессы, архитектура и функционал систем, структура команды и смежных отделов). Документация помогает не только онбордить новых сотрудников, но также систематизировать знания и повышать bus factor для текущих сотрудников.
Как у нового сотрудника с широкой сферой ответственности, у меня будет уникальная возможность оценить текущее состояние документации и сразу же дополнить её недостающими в ней данными, которые я неизбежно получу в процессе онбординга.
Как новый сотрудник, я не буду иметь глубокого понимания имеющихся в текущих процессах и системах проблем. Чтобы эти проблемы выявить и решить, мне потребуется пообщаться со всеми интересантами в моей сфере ответственности – мой руководитель, мои члены команды, наши бизнес-заказчики.
По итогам этих обсуждений, я собираю список имеющихся проблем, которые мешают максимально комфортной и эффективной работе, чтобы затем их решить.
Для того, чтобы оценивать насколько эффективно работаю я и моя команда, необходим набор объективных метрик, на основе которых можно будет делать об этом выводы.
Помимо внедрения стандартного набора метрик (Time To Market, Аптайм систем, % багов, SLA решения инцидентов), я также обращаю внимание на ранее собранную обратную связь от интересантов, чтобы понять какие именно метрики сейчас проседают и следить за динамикой их улучшения.
Теперь, когда у меня есть понимание содержания моей сферы ответственности и всех имеющихся в ней проблем, остаётся приоритезировать решения этих проблем в виде стратегического плана и постепенно их внедрять. Важно, чтобы эти решения были одобрены как командой, так и затрагиваемыми интересантами – в таком случае не возникнет сопротивления внедряемым изменениям.
Далее остаётся отслеживать улучшения метрик по итогам внедрения изменений, при необходимости корректируя их на основе итогов ретроспектив и личного общения с интересантами.
На протяжении многих лет работы, я открыл для себя ряд лучших практик, которые планирую продвигать на будущих местах работы (если не обнаружу там ещё более хорошие 🙂 ).
Хотя хранение кода ИТ систем в системах версионирования (Git, BitBucket) может показаться очевидным, но, в действительности, я ещё иногда встречаю в компаниях системы, код которых существует только на сервере, на котором они развёрнуты. В системе версионирования должен храниться код абсолютно всех ИТ систем – даже тех, которые не значительны для бизнеса или являются legacy.
Для эффективной работы с инцидентами важно, чтобы информация о результатах работы ИТ систем логировалась (и не в файлы, а в специализированные системы – Graylog, ELK, Loki), а все происходящие сбои – алертились (в частности через Sentry). Критичные алерты должны сразу форвардиться в корпоративный чат команды, чтобы была возможность на них максимально оперативно реагировать.
Бэкапы должны регулярно (не реже 1 раза в сутки) создаваться для каждой продуктивной ИТ системы, включая вспомогательные (например таск-трекер и система контроля версий). Также необходимо периодически (раз в несколько месяцев) проводить отработку восстановления ИТ систем из бэкапов, чтобы, если это когда-нибудь придётся срочно делать в результате сбоя, этот процесс и его механики были заранее подготовлены и отработаны.
Если в продуктивной системе произошёл критичный сбой, в результате которого деградировала её работа, то мало этой сбой устранить – необходимо принять меры для того, чтобы он больше не повторился. Для достижения этого, тот специалист, который работал над устранением сбоя, составляет постмортем, в котором, среди прочего, расписывает какие меры будут приняты для предотвращения подобных сбоев в будущем.
Само по себе, отслеживание индивидуальных ключевых показателей является важным, но привязка достижения их определённых значений к сумме зарплаты, которую сотрудник ожидает получать ежемесячно, для квалифицированных мотивированных сотрудников действует скорее как лишний фактор стресса, чем как дополнительная мотивация. С другой стороны, амбициозные планы OKR, достижение которых приводит к премированию поверх ежемесячно ожидаемой зарплаты, может являться дополнительным фактором мотивации.
Одна из важных составляющих мотивации членов команды – прозрачные и понятные им перспективы роста. Как профессионального, так и финансового. Наиболее эффективным решением этой задачи является внедрение релевантных для проекта грейдов, на которые могут претендовать члены команды, а также требуемые для каждого грейда компетенции и ожидаемая зарплатная вилка. Также важно составлять для каждого сотрудника индивидуальный план развития, чтобы помочь ему улучшить свои слабые стороны и достичь желаемого грейда и зарплаты. Наличие понятных принципов оценки и развития компетенций, а также материальное вознаграждение этого роста, значительно мотивирует сотрудников развиваться внутри текущей компании, а не искать развития в других компаниях.
Из тех инструментов, которые сейчас доступны на рынке, Jira и Confluence пока остаются лидерами в сфере таск-трекинга и составления документации, особенно если использовать их плагины. Хотя изначальная настройка этих систем сложна – у меня есть богатый опыт с их установкой, настройкой и администрированием, включая подключение любых плагинов.
Для обеспечения централизованного управления доступом к конфиденциальной информации, желательно всё общение осуществлять в отдельном приложении корпоративного чата, которое либо интегрировано с Active Directory, либо использует авторизацию по корпоративному e-mail. В таком случае, при закрытии доступа учётной записи в AD при увольнении, у сотрудника сразу закроется доступ ко всей конфиденциальной информации, и не придётся вручную ходить удалять его из всех чатов. Интеграция с AD позволяет также централизованно подгружать в корпоративный чат информацию о ФИО, фотографии, должности и структурном подразделении сотрудников, не вынуждая их вводить эту информацию вручную.
Здесь можно посмотреть примеры создаваемых мной артефактов.
