Я рассмотрел общее устройство стартапа в предыдущей заметке. В этой же я хочу подробно остановиться на одном из вариантов устройства полного IT Отдела. Почему одном из? Так как в реальности он может сильно отличаться от стартапа к стартапу и от компании к компании, ведь задачи у бизнеса разные и где-то может быть критично наличие в штате Системных Администраторов ( System Administrator ), которые помогают сотрудникам с техникой ( Help Desk ), а где-то они могут отсутствовать вовсе или быть на аутсорсе. В некоторых компаниях можно встретить должность Архитектора Программного Обеспечения ( Software Architect ), а где-то, и это чаще, его функции на себя берут Технический Директор ( CTO ), Главный Инженер ( VP of Engineering ) и Руководитель Разработки ( Development Lead ). Более того, рассматриваемый вариант это явно не то как будет выглядеть IT Отдел ( IT Division ) в начале стартапа. Это скорее вариант к которому можно стремиться, но не обязательно достигать, ведь конечная конфигурация IT Отдела ( IT Division ) зависит от очень большого количества факторов уникальных для каждого стартапа.
На мой взгляд, в IT Отделе ( IT Division ), так же как и во всей компании, отношения должны строить по принципу: подчинённый моего подчинённого не мой подчинённый. То есть Технический Директор ( CTO ) или Руководитель Разработки ( Development Lead ) не должны ставить задачи разработчикам, если в отделе ещё есть звенья между ними. Руководитель Разработки ( Development Lead ) должен поставить задачу Руководителю Команды ( Team Lead ), описав задачу на уровне достаточном для чёткого, но ещё не детального понимания её принимающей стороной, а Руководителю Команды ( Team Lead ), если отсутствует Технический Руководитель Группы ( Tech Lead ), должен сам распределить её внутри своей команды, исходя из загруженности каждого члена команды, опыта в сфере задачи у них, сроков и других факторов. При передаче задачи на слой ниже Руководитель Команды ( Team Lead ) должен дополнить её до того состояния, чтобы она стала понятна принимающей стороне, а возможно даже разбить её на несколько подзадач, но опять-таки задача не должна быть описана до последней детали, если только она не передаётся Младшему Разработчику ( Junior Developer ), так как с одной стороны всегда полезно выслушать альтернативное мнение о реализации, ведь в конечном итоге любая инженерная задача — это компромисс и не факт, что был выбран наиболее подходящий в данных условиях, — всегда лучше выслушать мнение тех, кто будет заниматься непосредственно реализацией и только потом принимать окончательное решение. С другой стороны, дьявол кроется в деталях и раскрыть все подводные камни на этапе планирования зачастую невозможно, более того, бывает и так, что после нескольких дней реализации приходится возвращаться к обсуждению другого пути решения задачи, так как разработчик уткнулся в маленькую и совершенно не очевидную деталь, которая либо делает невозможным или очень дорогим выполнение выбранного ранее способа решения задачи, либо сразу создаёт технический долг, так как задача решается с применением «костыля». Если в процессе дополнения описания задачи всплывают какие-либо вопросы, которые можно решить по разному, то тому, кто детализирует задачу, предстоит сделать выбор: либо выбрать одно из решений самостоятельно, либо обратиться за советом в принятии решения к тому, от кого он получил эту задачу. В конечном итоге, контроль и ответственность распределяются тоже по описанному выше принципу. Если Руководитель Команды ( Team Lead ) получил задачу от Руководителя Разработки ( Development Lead ), то в случае некорректной работы задачи ответственным для Руководителя Разработки ( Development Lead ) является только Руководитель Команды ( Team Lead ) и никогда разработчики, которые её реализовывали. Точно так же в случае неверной реализации технической составляющей бизнес-стратегии ответственным перед Генеральным Директором ( CEO ) может и должен быть только Технический Директор ( CTO ), но никогда кто-либо из его команды. Я называю это Принципом Инкапсуляции. Он не означает жёсткой иерархии и отсутствие контактов между разными слоями, отнюдь, я считаю, что коммуникация между всеми членами команды очень важна. Этот принцип устанавливает правило единственного ответственного и правило делегирования принятия нижнеуровнего решения.
Перед тем как перейти к рассмотрению ролей в IT Отделе ( IT Division ) предлагаю остановиться ещё на одной очень частой и серьёзной проблеме, которая, если её игнорировать, может привести к драматичным последствиям. Очень часто технические специалисты склонны к героизму и пытаются решить возникшие проблемы в одиночку, что приводит к сильным переработкам, усталости и потери продуктивности. Чтобы этого избежать нужно о возникших трудностях как можно раньше уведомить непосредственного руководителя. При здоровой атмосфере внутри отдела нет ничего страшного или постыдного в том, чтобы говорить о проблемах как можно раньше. Проблемы и неудачи настигают каждого человека и каждую команду — это нормально. Справляться с возникшими ситуациями всегда проще и эффективнее не в одиночку, а командой. Зачастую при приближение срока сдачи проекта можно изменить рамки задачи ( scope ) или выбрать какое-то компромиссное решение. Можно договориться о делегировании части работы другим командам, если появляется отчётливое виденье, что ваша команда не успевает её сделать в отведённое время. Продуктивная коммуникация и желание как можно быстрее достичь поставленных целей у каждого члена команды — вот ключевые факторы успеха проекта.
Теперь предлагаю рассмотреть как может строиться отдел внутри. Я начну рассматривать роли в порядке приближенном к тому, как специалист может их начать исполнять в соответствии с ростом своих профессиональных и социальных навыков ( Hard and Soft Skills ). Начнём с Команды Разработки ( Development Team ) , затем рассмотрим Команду Тестирования ( QA Team ), Команду Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Team ), а затем перейдём к Главному инженеру ( VP of Engineering ) и Техническому директору ( CTO ).
Команды Разработки ( Development Team )
Младший Разработчик ( Junior Developer )
Итак, Младший Разработчик ( Junior Developer ). Это специалист, который перешёл от стадии простой заинтересованности разработкой и выполнения всего по мануалам ( руководствам ) к стадии самостоятельного написания небольших программ или несложных частей больший программных систем. При этом нужно отметить, что большинство процессов и действий, которые он совершает, для него остаётся магией.
Знаний, особенно структурированных знаний, мало, но жажда их получить должна быть очень большая.
Разработчик ( Middle Developer )
Разработчик ( Middle Developer ) начинает понимать что такое архитектура ПО, шаблоны проектирования ( design patterns ), каркасы ( frameworks ) и применять полученные знания и навыки на практике. Магия начинает отступать и появляются структурированные знания.
Старший Разработчик ( Senior Developer )
Старший Разработчик ( Senior Developer ) уже хорошо знает много технологий, несколько frameworks, понимает их архитектуру, скорее всего знает несколько Языков Программирования и может создавать приложения на хорошем уровне. Начинает делиться знаниями с предыдущими уровнями.
При этом наставничество ( менторство ) очень важно для человека на данной позиции, так как именно с неё обычно начинается путь в направлении менеджеров. Именно здесь человек должен научиться слушать и слышать других, ясно формулировать свои мысли и доносить их до других, терпению, когда у его подопечного что-то не получается, умению хвалить, когда его подопечный превосходит его ожидания, особенно если он решит выбрать дальнейший путь в менеджеры.
Магии в том, что он делает, для этого специалиста почти не осталось и здесь возникает очень важный момент для него как личности — не стать «звездой», с которой будет сложно работать другим участникам команды.
Технический Руководитель Группы ( Tech Lead )
Технический Руководитель Группы ( Tech Lead ). Во многих стартапах эта роль отсутствует, так как команды одной технической стороны ( Backend, Frontend, Mobile, etc ) состоят менее чем из 5 разработчиков. Но если в команде одной технической стороны более 7 разработчиков, то целесообразно задуматься над введением этой роли.
Примерно с этой позиции в области разработки программного обеспечения начинаются нечёткие формулировки в описании обязанностей ролей и они начинают варьироваться от компании к компании. Я попробую изложить своё видение этой и последующих ролей, опираясь на свой опыт и литературу со статьями, что я изучил по данной теме.
Технический Руководитель Группы ( Tech Lead ) не обязательно должен быть лучший разработчик в группе, так как эта позиция не подразумевает большее время для работы с кодом, а наоборот подразумевает наличие менеджерских обязанностей с которыми человек должен хотеть и уметь справляться: быть первым среди равных в принятие технических решений в группе и быть ответственным за них, быть представителем интересов группы перед вышестоящими слоями, быть тем, кто помогает эффективно распределить поставленные задачи между членами своей группы, а так же выполнять некоторые базовые функции менеджера — удостовериться что задачи поняты правильно, следить за ходом их выполнения, определять вероятное направления развития каждого из членов группы, проводить еженедельные встречи с членами группы для обсуждения технических аспектов предстоящих задач и сбора обратной связи.
Как уже отмечалось, Технический Руководитель Группы ( Tech Lead ) должен думать о результативности всей группы, а также о том, чтобы результаты работы всей команды, а не только его группы, были полезны для всего стартапа. Он должен иметь свободу в принятии решений в интересах группы, а также практиковаться во взаимодействие с другими отделами компании.
Именно эта позиция открывает плавный и логичный переход к позиции Руководитель Команды ( Team Lead ).
Руководитель Команды ( Team Lead )
Руководитель Команды ( Team Lead ) отвечает за организацию и результаты работы своей команды, но при этом он всё ещё занимается написание кода, хоть уже и значительно меньше, чем разработчики, а также занимается инспекцией кода ( Code Review ), чтобы оставаться в курсе происходящих в системах изменений. Одной из основных обязанностей Руководителя Команды ( Team Lead ) является забота о развитии членов его команды, причём не только прикладных технических навыков ( hard skills ), но и социальных навыков взаимодействия ( soft skills ). Он должен плотно взаимодействовать с Руководителем разработки ( Development Lead ) для планирования проектов, определения приоритетов, содержания задач, а также по не менее важным вопросам развития членов команды. Он должен доводить до сведения своей команды чего именно от них ожидают, а также делиться собственными оценками относительно их работы. В его же обязанности входит определение технического долга, анализ его по параметрам «цена / качество» и согласование с вышестоящими слоями приоритета и сроков для устранения технического долга.
Команда обычно состоит из групп разработчиков с разных технических сторон ( Backend, Frontend, Mobile, etc. ). Она может существовать на постоянной основе, а может собираться под проект или задачу. Сам же Руководитель Команды ( Team Lead ) обычно вырастает из Full-stack или Backend разработчика. Причём это не обязательно должен быть самый лучший разработчик, так как для позиции Руководителя Команды ( Team Lead ) значительно важнее умение организовывать и управлять процессом, поддерживать членов своей команды в процессе работы и следить за тем, чтобы создаваемый результат соответствовал ожидаемому.
Руководитель Команды ( Team Lead ) в дополнение к руководству своей командой должен ещё принимать участие в продуктовых планированиях. Он должен делиться с менеджерами из Продуктового Отдела ( Product Division ) своим видение по объёмам работ, срокам и рискам, относительно планируемых задач.
Руководитель Команды ( Team Lead ) обычно первым замечает, что какая-то из технических сторон становится узким местом и должен донести эту информацию до вышестоящего слоя, чтобы можно было либо перераспределение специалистов между командами, либо спланировать найм новых специалистов, либо изменения в организационном процессе разработки.
На этой позиции человеку предстоит научиться ценить как своё время, так и время коллег, балансируя между количеством и временем совещаний с их продуктивностью. Придётся научиться отказываться от участия в совещаниях. Особенно, если они не собираются ради мнения или принятия решения Руководителем Команды ( Team Lead ). Ведь очень трудно сосредоточиться на создание кода, если каждый час отвлекают.
Так как Руководитель Команды ( Team Lead ) это роль, в которой человек может принимать много автономных решений, в том числе и по тому как организовывать рабочие процессы у себя в команде, то существует опасность, что человек может стать «царём организационного процесса». Это когда человек уверен, что существует один единственный организационный процесс и при правильной эксплуатации он поможет решить все проблемы команды. Он «точно знает» как эффективно организовать работу команды, как нужно организовывать инспекцию кода ( Code Review ), как организовать процесс релиза готового продукта и т.д. Обычно такие люди очень организованны, любят детали и почти всегда следуют правилам без отклонений. Во всех проблемах они склонны винить отклонения от процессов, вместо того чтобы признать, что гибкость необходима, а неожиданные изменения неизбежны. Они часто сосредоточивают внимание на легко измеримых параметрах, например, количестве отработанных часов, при этом упуская из вида массу других нюансов. При этом они совершенно не слышат идей и советов ни от членов своей команды, ни других коллег.
Есть ещё вариант как руководитель может стать «царём». Он может начать искать «идеальные методики» для решения всех вопросов планирования, концентрации внимания, правильной организации времени и определения приоритетов. А затем усиленно навязывать эти методики команде как идеальное решение всех проблем. Но на самом деле эти методики намного более запутанные и возникают из сложных межличностных взаимодействий в коллективе.
Хоть Руководитель Команды ( Team Lead ) это и первая позиция на которой человек может оказаться «царём организационного процесса», но к сожалению не последняя — на всех вышестоящих позициях человек тоже может оказаться «царём организационного процесса».
Антипод «царя» — это человек, который проповедует и придерживается принципов Agile Manifesto — квинтэссенции здоровых моделей управления:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Руководителя Разработки ( Development Lead )
Руководитель Разработки ( Development Lead ) обычно отвечает за спектр систем определённого направления, которые создаются и развиваются сразу несколькими командами разработки во главе со своими Руководителями Команды ( Team Lead ). Если в компании уже разрабатывается много несвязанных или слабо связанных систем, то у каждого из спектра направлений может быть свой руководитель разработки ( Development Lead ).
Руководитель Разработки ( Development Lead ) совместно с Главном Инженером ( VP of Engineering ), Руководителем Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Lead ) и Техническом Директором ( CTO ) разрабатывают архитектуру программных систем, запросы на которые поступают из Продуктового Отдела ( Product Division ) и которые уже одобрены к разработке Техническом Директором ( CTO ) в соответствии с технической стратегией, и в конечном итоге согласовывают выработанное решение с Техническом Директором ( CTO ).
Роль Руководитель Разработки ( Development Lead ) подразумевает наличие бизнес-мышления, чтобы помимо поступающий задач из Продуктового Отдела ( Product Division ) он мог определять системы, которые нуждаются в изменениях и уже стали или могут скоро стать бутылочным горлышком для бизнес-процессов, а также какие новые системы необходимы или могут быть полезны для функционирования и развития бизнеса.
Руководитель Разработки ( Development Lead ) несёт ответственность перед вышестоящими слоями за утверждённые и согласованные проекты, а также за риски, которые могут возникнуть во время разработки и эксплуатации систем: за все поступающие и согласованные задачи, которые нужно выполнить за оговорённое время и в надлежащем качестве, за все инциденты и проблемы во время эксплуатации.
Если команды в компании собираются под проект, то совместно с Руководителями Команды ( Team Lead ) он собирает оптимальную команду для реализации поступившего проекта.
Из чисто инженерных задач у этой роли обычно остаётся время в лучшем случае только на инспекцию кода ( Code Review ).
Помимо задач связанных с развитием продукта, одной из основных задач Руководитель Разработки ( Development Lead ) является организация процесса обучения и развития знаний и умений у всех сотрудников его команд. Это касается как профессиональных знаний и умений, так и социальных навыков ( Hard and Soft Skills ) .
Команда Обеспечения и Контроля Качества ( QA Team )
Чаще всего ребят из этой команды для краткости называют «тестировщики», однако внутри этой команды тоже есть свои роли.
Самым важным качеством, которым должен обладать человек в Команде Обеспечения и Контроля Качества ( QA Team ) — способность придумать неочевидное использование функционала системы. И это значительно сложнее, чем может показаться на первый взгляд.
Младший Специалист Ручного Контроля Качества ( Junior QC Manual Specialist )
Я считаю, что именно через эту роль людям не из IT сферы проще всего перейти на работу в IT. Основа этой простоты в весьма спокойном погружение в IT технологии и предметную область тестируемой системы.
Основные задачи для человека в данной роли: учиться и выполнять инструкции приходящие от вышестоящих слоёв в Команде Обеспечения и Контроля Качества ( QA Team ) и/или от инженеров из Команды Разработки ( Development Team ).
Если человеку в этой роли досталось тестирование функционала пользовательского интерфейса, то его основными инструментами будут мышка, клавиатура и тест-кейсы, написанные либо старшими коллегами из его команды, либо им самим.
Если же человеку этой роли досталось тестирование API, то без изучения основ клиент-серверного взаимодействия и специальных программ ему не обойтись. Однако чаще люди в данной роли всё-таки занимаются тестированием функционала пользовательского интерфейса.
По большей части всё что происходит и всё что делает человек в данной роли для него является магией, которую ещё только предстоит превратить в полезные умения, путём изучения профессиональной литературы и систематизации знаний в процессе оттачивания навыков.
Специалист Ручного Контроля Качества ( QC Manual Specialist )
К этой роли человек уже достаточно освоился в профессии, изучил теорию тестирования программного обеспечения, использовал некоторые теоретические знания на практике и готов к своему дальнейшему развитию в мире IT.
Данный специалист должен легко уметь составлять тест-кейсы, тест-планы, понимать какие виды тестирования существуют и для чего они нужны.
Часть магии связанная с тестированием благодаря систематизированным знаниям отступает, однако магия связанная с технология всё ещё очень сильна и туманна.
Старший Специалист Ручного Контроля Качества ( Senior QC Manual Specialist )
По сути это Tech Lead для Специалистов Ручного Контроля Качества ( QC Manual Specialists ). У человека в этой роли обычно есть несколько подопечных, поэтому помимо прямых задач, связанных с тестированием, в его задачи входит делиться знаниями и направлять Младших Специалистов Ручного Контроля Качества ( Junior QC Manual Specialists ), то есть быть наставником, а так же просматривать тест-кейсы, составленные членами своей группы, проверять на актуальность тест-кейсы и тест-планы, организовывать и проводить регрессионное тестирование.
Ручное тестирование для данного специалиста уже полностью перестало быть магией, однако магия связанная с технологиями всё ещё сильна и чтобы с начать с ней справляться человеку нужно начать совершать переход от ручного тестированию к автоматизированному, а для этого придётся освоить язык программирования и новые инструменты.
Инженер Автоматизированного Контроля Качества ( QC Automation Engineer )
Это весьма логичное и ожидаемое развитие специалиста по ручному контролю качества. Когда постоянно выполняешь очень похожие цепочки действий, то мысль о том, чтобы переложить их на компьютер появляется сама-собой. Однако для этого нужны не только знания в сфере тестирования, но и начальные знания в сфере программирования и более глубокие знания логики предметной области проверяемой системы. И это основные сложности, с которыми сталкиваются люди при попытке перейти от ручного к автоматизированному тестированию.
В задачи этого специалиста входит покрытие API или функционала интерфейса пользователя автотестами, а так же поддержание их в актуальном состоянии.
Магии в тестировании давно нет, технологическая магия под давлением знаний в разработке начинает отступать. Если человек продолжит и дальше углублять и систематизировать свои знания в разработке, то он без труда сможет занять роль Разработчика ( Middle Developer ).
Старший Инженер Автоматизированного Контроля Качества ( Senior QC Automation Engineer )
По сути он может быть Team Lead у QC Automation Engineers и QC Manual Specialist.
В его задачи входит следить за актуализацией автоматизированных тестов, а так же организовывать и проводить автоматизированные регрессионные и нагрузочные тестирования.
Технологической магии для этого человека осталось мало, по сути это уже уверенный Разработчик ( Middle Developer ).
Руководитель Команды Обеспечения Качества ( QA Lead )
В задачи этой роли входит организация работы всей команды обеспечения и контроля качества, взаимодействие с Командой Разработки ( Development Team ), правильное и органичное встраивание тестирования в процесс выпуска программного обеспечения, наставничество для QC Manual Specialist и QC Automation Engineer всех слоёв.
Если другими словами описать автоматизированное тестирование, то получится написание программ для проверки программ. Это уже работа разработчиков, но весьма специфичных, так как в основном они работают не с другими отделами, а с программным обеспечением, написанным их коллегами, и их задача удостовериться, что бизнес функции работают как ожидается, а так же попытаться сломать систему, ведь если это не сделают они, то рано или поздно сделает пользователь нечаянно или злонамеренно.
Именно поэтому для избежания конфликта интересов Команда Разработки ( Development Team ) и Команда Тестирования ( QA Team ) должны быть разъединены и должны иметь своих независимых руководителей. Бывает так, что в компании ещё нет отдельной роли QA Lead, в этом случае её должен исполнять вышестоящий слой над руководителями отделов, то есть Главный Инженер ( VP of Engineering ) или Технический Директор ( CTO ).
Команда Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Team )
Написать программный код — это полдела. Как удостовериться, что код работает корректно согласно бизнес-требованиям, новый код не ломает существующий в production функционал, код готов выдержать нагрузку, которую ему предстоит обрабатывать в production окружении? Можно, конечно, сразу выложить на production сервера и… в случае чего услышать от разработчика классическую шутку: «А у меня всё работает!» И правда, код может отлично работать на его компьютере, проходить unit-тесты, но в production окружении вести себя не так, как ожидалось.
Может есть другой вариант?
Конечно есть! И он называется CI/CD[/CD] ( Continuous Integration / Continuous Delivery [/ Continuous Deploy] ). Это абсолютно инженерные «игрушки», но они очень важны для бизнеса. В двух словах Continuous Integration позволяет непрерывно добавлять к существующему коду новый функционал с формальными автоматизированными проверками, Continuous Delivery позволяет поставлять кодовую базу со всеми зависимостями на тестовые ( stage ) сервера для окончательного тестирования получившегося продукта Командой тестирования ( QA Team ) в автоматическом и/или ручном режиме, Continuous Deploy обычно включают в Continuous Delivery, однако, поставка готового к работе кода на все сервера во всех Центрах (Хранения и) Обработки Данных ( Ц(Х)ОД | Data Center / DC ) на мой взгляд отдельная инженерная задача.
Именно за этот важный участок Жизненного Цикла ( Life Circle ) Программного Обеспечения ( ПО | Software ) и отвечает Команда Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Team ).
Системный Администратор ( System Administrator )
По сути эти специалисты не входят непосредственно в Команду Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Team ), так как работают не с кодом, создаваемым Командой Разработки ( Development Team ), а помогает сотрудникам из других отделов с пользовательскими программами и техникой ( Help Desk ). Однако, я отнёс этих специалистов именно к Команде Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Team ), так как они, как и Инженеры Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Engineers ) тоже отвечают за инфраструктуру, только не серверную, а офисную.
Инженер Развёртывания и Эксплуатации Программного Обеспечения ( DevOps Engineer )
Этот инженер отвечает непосредственно за функционирование, мониторинг и безопасность всей серверной инфраструктуры, а также системы и скрипты для корректной поставки кода на stage и production сервера ( CI/CD ).
Эти специалисты должны очень хорошо знать серверное администрирование, уметь разрабатывать скрипты, разбираться в предметной области систем, создаваемых Командой Разработки ( Development Team ).
Руководитель Развёртывания Программного Обеспечения ( DevOps Lead )
Этот инженер помимо ответственности за функционирование, мониторинг и безопасность всей серверной инфраструктуры также отвечает за вопросы эффективности использования и масштабирования серверной инфраструктуры. Он обязательно принимает участие в обсуждениях, связанных с архитектурой разрабатываемых систем.
Главный Инженер ( VP of Engineering )
Главный Инженер ( VP of Engineering ) — эта роль является высшей точкой развития специалиста, стартовавшего с инженерной роли и не побоявшегося брать на себя всё возрастающую ответственности за свои решения как руководителя всё более и более высокого уровня. Это последняя точка, когда ещё происходит погружение в технические аспекты и код, хотя это делается значительно реже, чем в предыдущих слоях. Количество руководящих функций у этой роли уже настолько велико, что человеку, выполняющего эту роль, очень важно иметь богатый опыт в управлении людьми, проектами, командами и подразделениями, для хорошего выполнения обязанностей, возлагаемых на эту роль.
Главный Инженер ( VP of Engineering ) отвечает за реализацию проектов и задач, повседневную работу команд, создание хорошей рабочей атмосферы, он должен хорошо знать все процессы и детали. В функции этой роли входит помощь в постановке перед командами целей в достижении конкретных результатов для бизнес-интересов компании. Для этого Главный Инженер ( VP of Engineering ) должен работать в тесном контакте с Продуктовым Отделом ( Product Division ). Он должен следить, чтобы планы по выпуску новых проектов и продуктов были реалистичными и чтобы бизнес-цели компании могли трансформироваться в технологические достижения. Главный Инженер ( VP of Engineering ) должен уметь одновременно следить за несколькими проектами в нескольких продуктах и обеспечивать их нормальное развитие. Он должен быть способен вникнуть в детали проекта и заставить их заработать вплоть до самого нижнего уровня.
Главный Инженер ( VP of Engineering ) больше занят реализацией идей, тогда как Технический Директор ( CIO / CTO ) концентрируется на большой стратегии и общем состоянии технического развития компании.
Главный Инженер ( VP of Engineering ) может быть ответственным за вопросы найма новых сотрудников, утверждённых в технологической стратегии, проводить собеседования с кандидатами и принимать решение о найме.
С одной стороны, Главный Инженер ( VP of Engineering ) должен быть наставником для технических руководителей в IT Отдела ( IT Division ). Он должен распознавать способных сотрудников и помогать им развиваться в качестве будущих руководителей более высокого слоя. С другой стороны, он должен прикладывать не меньше усилий для того, чтобы помочь развиваться сотрудникам в инженерных ролях.
Оставьте комментарий