Image via Shutterstock.Этой статьей я продолжу цикл статей «Карьера в ИТ»на ДОУ.
Думаю, все согласятся, что человек не может быть хорош во всем одновременно. Соответственно, в зависимости от того, кем он хочет стать, он может быть либо «узким и глубоким» экспертом в какой то определенной теме либо «мелким и широким» — то, что называют «мастер на все руки».
При декомпозиции термина «Delivery Manager» мы получаем Delivery и Manager. Если с менеджером всё более-менее понятно (это человек, ставящий задачи, контролирующий их выполнение и обеспечивающий согласованность поставленных задач со стратегией компании) то вот с Delivery не совсем ясно.
Одни подразумевают под Delivery производственный процесс целиком, другие — лишь его часть.
В зависимости от того, что подразумевается под термином Delivery, получаются две версии Delivery Manager’а (в реальности их гораздо больше, но эти две являются «полюсами», между которыми находится множество).
Версия № 1: «Узкий и глубокий»
В этой версии под Delivery имеется ввиду часть производственного процесса, состоящая из оценки, планирования, разработки, тестирования и доставки.
Роль в проекте
При таком подходе от узкого и глубокого специалиста ожидают, что он очень хорош в построении того, что называется Continuous Delivery. Управление проектом — командная игра, и DM первого типа берет на себя ответственность за своевременное качественное прохождение всех фаз итерации разработки, начиная от оценки и планирования и заканчивая поставкой.
Если говорить терминами модели RACI, он — и ответственный, и исполняющий (Accountable/Responsible). Т.е. в большинстве случаев он не делегирует контроль над оценкой и планированием, а лично занимается ими вместе с командой.
Что касается стратегии, Delivery Manager играет две роли:
— Consulted — с ним консультируются касательно возможности и реалестичности изменений в стратегии в части Delivery
— Informed — Account/Project/Programme/Product Manager держат Delivery Manager’а в курсе стратегии и изменений в ней.
На уровне проекта DM’у должны быть даны полномочия на свое усмотрение использовать «и кнут, и пряник» с единственной целью — обеспечить поставку разрабатываемой функциональности заказчику в обещанный срок, в обещанном размере и с оговоренным качеством.
Навыки и умения
Для успешной работы Delivery Manager первого типа должен обладать следующими навыками:
— хороший опыт и понимание процесса разработки, ролей, их взаимодействия;
— умение разрешать человеческие конфликты;
— умение быстро принимать решения;
— умение брать на себя ответственность;
— понимание концепции win-win и желание работать по ней;
— отличные коммуникационные навыки и навык аргументации;
— обладать навыками наставничества и менторинга.
DM первого типа должен обладать определенным уровнем «паранойи» и быть склонным к микроменеджменту. Уметь, сохраняя в памяти картину целиком, сосредотачиваться на работе над конкретным ее кусочком. Добиваться результата за счет способности «доделать, закатав рукава».
Типичный пример — люди, обладающие достаточными навыками, чтобы сделать работу других, и которым «больше всех надо». Т.к. это скорее жизненная позиция, чем компетенция — встретить ее можно у людей разных профессий и разных ролей. Преимущество — опять же, у программистов и тестировщиков-автоматизаторов, т.к. они (теоретически, а довольно часто — и практически) обладают довольно обширным набором компетенций, позволяющих «доделывать до конца».
Карьерный путь
Delivery Manager первого типа занимается тактическими задачами, принимая участие в разработке и имплементации стратегии. Таким специалистом проще всего стать программисту или тестировщику-автоматизатору, прошедшему карьеру: Специалист → Tech Lead → Team Lead → Project Manager (optional).
На такой позиции он будет отвечать за результат поставки заказчику ранее оговоренного функционала с требуемым качеством и в условленный срок. Должен обладать значительными полномочиями для достижения результата и быть способным обеспечить результат своими руками.
По мере карьерного роста DM первого типа превращается в очень толкового менеджера проекта (или программы) либо Account Manager’а.
Delivery Manager первого типа нужен компаниям, в которых распределение полномочий и задач между ролями предполагает наличие роли, сочетающей в себе навыки менеджера и способности технического специалиста.
Версия № 2: «Мелкий и широкий»
В этой версии под Delivery подразумевается весь процесс разработки, от первого обсуждения идеи с заказчиком до выпивки в конце, включая получение благодарностей/тумаков в зависимости от того, как всё прошло.
Роль в проекте
При таком подходе роль Delivery Managerа сводится к интеграции и тому, что по-английски называется governance и orchestration процесса создания решения.
В таком случае Delivery Manager должен обладать 20% знаний и умений каждой из ролей (Dev, QA, Architect, PM, CM etc.), которые дадут ему следующие 80%:
— возможность адекватно оценивать потребность в том или ином специалисте, компенсирующем «мелкость» DMа в конкретной области (например, нанимает PMа, чтобы выстроить процессы в проекте, QM для создания тест-стратегии и т.д.)
— возможность проверять информацию, получаемую от «узких и глубоких» (чтобы не навешали лапши о том, что всё хорошо)
— возможность понимать получаемую информацию и корректно доносить ее до участников процесса.
Основной фокус «мелкого и широкого» Delivery Manager’а — поставка качественного решения, максимально учитывающего потребности заказчика.
Delivery Manager второго типа очень похож на предпринимателя, знающего в общих чертах о том, что такое юриспруденция, бухгалтерский учет, налоговая отчетность, внешнеэкономическая деятельность, производство и т.д. но не разбирающийся в каждой из этих областей досконально.
Навыки и умения
Насколько хорошо он должен разбираться? Достаточно, чтобы понять, какого именно специалиста пригласить и какими навыками приглашаемый специалист должен обладать. Иными словами, это роль, собирающая пазл из других ролей.
Приведу следующий пример, иллюстрирующий потребность в Delivery Manager второго типа:
Компания С приходит к аутсорсинг-вендору V с предложением реализовать проект длительностью в три года. В компании С есть правило: менять менеджера проекта каждый год, чтобы избежать ситуации «незаменимый человек».
Сейчас подобного рода проект чаще всего выполнялся бы по контракту «Time and Materials» где V предоставил бы менеджера проекта и команду со своей стороны, а менеджер на стороне С осуществлял бы постановку задач. Т.к. почти везде менеджер получает годовой бонус в зависимости от выполненных за год задач, менеджеру С будет выгоднее запланировато то, что можно сделать за год его управления проектом и получить за это бонус. На второй год приходит новый менеджер С, пытающийся сделать то же самое. Та же ситуация повторяется и на третий год.
Вероятность успешного завершения подобного проекта —
В реальности Time and Materials эта ситуация для V более менее приемлема, т.к. деньги платятся не за результат, а за время и ресурсы. Но стоит V согласиться работать над подобного рода проектом на основе контракта «Fixed Price» — проект обернется катастрофой. Введение роли Delivery Managerа второго типа для V служит элементом снижения рисков т.к. появляется человек, присутсвующий на проекте с самого начала и заинтересованный в его успешном окончании через 3 года.
Выше я привел лишь одну из причин. На самом деле их гораздо больше. Приведенный сценарий довольно типичен для украинского аутсорсинга. И учитывая тенденции последних лет — при отсутсвии изменений в подходах к работе связанные с ним проблемы будут лишь усугубляться.
Итак, если первый тип у нас — и Accountable, и Responsible, то у второго типа из тактических действий остается A, а из стратегических — и A и R.
Delivery Manager второго типа делает следующее:
— Принимает участие на первых встречах с заказчиком, выработке предложения, заключении контракта
— Принимает участие в выборе методологии работы и ее имплементации
— Принимает участие в подборе ключевых людей, построении процессов
— Служит «Single Point of Contact» для стейкхолдеров проекта
— Выступает гарантом соблюдения договоренностей
и т.д.
Если в проектах с первым типом Delivery Managerа ответственным за весь проект является Account Manager/Programme Manager/Project Manager, а Delivery Manager отвечает лишь за своевременную поставку (не вникает в экономическую целесообразность и т.д.) то в случае второго типа главным на проекте является именно он.
Если вкратце, то цель Delivery Managerа второго типа — пообещать и сделать.
Он должен обладать выраженной компетенцией «ладить с людьми» т.к. он «доделывает до конца, закатывая рукава других людей». Этому типу Delivery Managerа требуется более высокий уровень развития лидерства т.к. от него требуется мотивировать и вдохновлять людей «довести дело до конца» несмотря на трудности, разочарования и отсутствие мотивации.
Карьерный путь
Delivery Manager второго типа занимается стратегическими задачами, помогая подчиненным транслировать (декомпозировать) стратегию в тактические планы и следя за их выполнением. Таким менеджером проще всего стать специалисту с техническим прошлым, прошедшему следующий карьерный путь: Специалист → Tech Lead → Team Lead → Project Manager / Delivery Manager (первого типа) / Programme Manager / Account Manager.
На такой позиции он будет отвечать за общий результат взаимодействия с заказчиком (начало, выполнение и завершение проекта целиком). Должен обладать всеми полномочиями, требуемыми для достижения долгосрочного результата (возможно, иногда даже уходом в минус по деньгам в краткосрочной перспективе с целью получения выгоды в долгосрочной). Обеспечивает результат, работая руками других людей. Должен быть способным этих других людей нанимать/увольнять, вдохновлять и мотивировать. Типичный пример — Project/Programme/Account Manager с хорошим «техническим прошлым», обладающий жизненной позицией Delivery Managerа второго типа.
Как стать Delivery Manager’ом
Технический background
Прежде всего, Delivery Manager’у необходим технический background. Зачем? Ответ на этот вопрос очень прост. Delivery Manager’у первого типа прошлое программиста либо QA необходимо, чтобы оценивать и улучшать эффективность процессов и работы сотрудников. Не имея «темного прошлого», такой менеджер вынужден будет постоянно обращаться за советами/консультациями/информацией к посторонним, что сведет на нет все преимущества данной роли в проекте.
Delivery Manager второго типа отвечает за выполнение договоренностей, поэтому ему крайне важно понимать, как именно эти договоренности могут быть выполнены. Не на уровне «ну вот мы наймем 100 программистов, и они нам напишут», а на уровне архитектурных концептов, процессов, артефактов.
Иными словами, техническое прошлое Delivery Managerу второго типа нужно, чтобы не пообещать «родить ребенка девятью женщинами за месяц».
Так что самым «затратным» (с точки зрения времени и ресурсов) в карьере Delivery Managerа является развитие технических компетенций (понимание архитектуры на уровне концептов, знание технологий, знание подходов и методологий разработки и т.д.). Именно поэтому Delivery Managerом проще всего стать программисту либо тестировщику-автоматизатору т.к. роль Delivery Managerа является гармоничным продолжением их карьерного пути (они смогут переиспользовать максимум приобретенных ранее знаний и умений).
Управленческий опыт
Следующими по важности для обоих типов Delivery Managerов являются менеджерские компетенции, включающие в себя умение работать с людьми, оценку и планирование комплексных задач, правильное делегирование и контроль и т.д.
Знания в этих областях приобрести относительно легко. Сложнее овладеть некоторым уровнем умения, т.к. это возможно только при практическом использовании полученных знаний.
Для Delivery Managerа требуется опыт Team Lead или Project Manager. При этом и для первой, и для второй позиций требуется проект, где ответственность за результат несет исполнитель. Иными словами, в качестве опыта не подходят проекты, где Team Lead или Project Manager может сказать «ну, не получилось» — и за это его компания не понесет как минимум серьезных репутационных или финансовых потерь.
Для обоих типов Delivery Managerа крайне критично брать на себя ПОЛНУЮ ответственность и достигать результата, иногда даже игнорируя цену, которую за этот результат придется заплатить.
Soft Skills
Следующими в очереди идут социальные компетенции. Обоим типам Delivery Managerа очень важно иметь 4 базовые компетенции, «прокачанные» до уровня «Advanced»:
— Умение говорить — сюда можно включить «внятно и складно излагать свои мысли», «отсутсвие слов-паразитов», «правильно структурировать и доностить информацию в зависимости от аудитории» (иными словами, с топ-менеджментом общаемся словами из категории RAG (Red/Amber/Green), а с программистами — словами из категории «написали столько-то строк кода/пофиксили столько-то багов/закрыли столько-то айтемов, и т.д.)
— Умение слушать — «активное слушание» (пытаться понять, почему собеседник говорит именно это и именно так. Что именно он пытается сказать и зачем).
— Умение читать — навык скорочтения важен для качественной обработки письменных коммуникаций, быстрого получения информации из различных источников (сайты, книги и т.д.)
— Умение писать — оба типа Delivery Managerа ежедневно пишут email’ы самым разнообразным аудиториям, доводя до исполнителей стоящие перед ними задачи: менеджменту — о состоянии дел, стейкхолдерам — о планах на будущее. Перечисленное выше объединяет умение кратко и грамотно излагать в письменном виде суть вашего послания.
Еще упомяну эмоциональный интеллект — данная компетенция в 21 веке важна для любого, кто хочет хоть как-то быть конкурентоспособным на рынке труда.
Достаточный уровень развития данных компетенций достигается работой с разными заказчиками на разных проектах. У (экс-) программиста и тестировщика-автоматизатора есть преимущество, т.к. спектр обсуждаемых вопросов у них шире, и как результат — уровень владения компетенциями выше. Представителям других профессий/ролей для развития вышеупомянутых компетенций придется потрудиться гораздо больше.