Должен ли менеджер проекта быть технарем?

На сегодняшний день существует бесконечное число дискуссий о том должен ли менеджер проектов уметь программировать и должно ли у него быть прошлое программиста или инженера по тестированию.

В этой статье я расскажу почему менеджеру проекта желательно иметь технический опыт и какие преимущества он ему дает. Разумеется это даст подсказки, тем кто хочет стать менеджерами проектов без технического опыта, какой материал им необходимо усвоить чтобы более менее на равных тягаться со своими более технически подкованными коллегами.

[sendpulse-form id=”278″]

Для работы над продуктом, особенно в IT, знания технологий так или иначе необходимы. Для менеджера не должны быть новыми слова «бэкенд», «верстка», «база данных», “баг”, “фича” и т.п. Чтобы отлавливать баги или видеть точки роста в продукте, нужно не просто постоянно им пользоваться, но и понимать, как он устроен.

Если менеджер при воспроизведении проблемы открыл браузерную консоль, увидел в ней сетевые ошибки и пришел к разработчику с данными из трейсов этих ошибок, или сам заглянул в данные и увидел, что бэкенд отдал некорректный json, ситуация сразу начинает выглядеть как подкрепленная доказательствами проблема, а не жалоба пользователя.

Похожая ситуация и с умением программировать. Как такие формулироваки менеджера проектов воспринимаются командой?

• Привет, я думаю, что надо запилить офигенную фичу A (B,C,D,…), хочу проверить, насколько она будет востребована. Просчитай, мне, пожалуйста, какова доля таких-то сценариев в использовании нашего продукта?
• Привет, у меня периодически криво отрисовывается страница, если пользователи тоже это видят, это просто позор. Проверь, что происходит?
• Привет, у меня тут в АБ эксперименте статистически значимо меняется метрика, давай поймем, почему?
• Привет, я тут пишу пост о нашем новом внедрении, проверь, пожалуйста, правильно ли я описал детали реализации.
• …

В данном случае менеджер воспринимается командой, как постоянный генератор дополнительной и частично бесполезной для них работы.

И здесь умение программировать может помочь менеджеру более эффективно организовывать работу команды.

Умея программировать, можно быстро проверять свои же гипотезы, не полагаясь на чужие вычисления и не отвлекая людей заказами этих вычислений. Можно самостоятельно посчитать, сколько пользователей видели фичу Х, или собрать какую-то статистику для презентации. Программисты не любят переключать контексты, и хороший менеджер не должен дергать программиста по пустякам.

Вот моя формула, по которой у нас рассчитывается время, которое разработчик потратит на внеочередную задачу для менеджера (для задач, которые нужны только менеджеру проекта или представителю заказчика, которые никак не скажутся на результате и нужны только им, например, какие-то показатели для презентаций/докладов и т.п.):

(TSC2 + TfNT) + (TSC2 + TfNT)*0.3,

где: TSC – время на переключение контекста, TfNT – время на выполнение новой задачи.TSC умножается на 2, поскольку программисту требуется время чтобы переключиться на новую задачу, а затем вновь переключиться на старую. Также добавляется 30% погрешность, для компенсации рисков. Для каждого проекта есть свой показатель, если результат вычисления больше показателя, тогда задача не берется в работу, или оговариваются условия при которых ее все-таки должен взять программист, с согласованием возможного переноса сроков по этой задаче.

Менеджер, который может «быстренько прикинуть» сам, не будет дергать свою команду, снижая ее производительность. Разумеется то, что называется продуктовым видением, должно быть подкреплено качественными и количественными исследованиями. И менеджер должен уметь проводить большую часть этих исследований самостоятельно.

Умение программировать также помогает валидировать расчеты, которые приносят аналитики. Если, например, менеджер попросил посчитать долю запросов с каким-то сложным набором действий на них, и аналитик приносит расчет, в котором просто общее количество запросов не сходится с собственным расчетом менеджера, у него есть повод усомниться в правильности расчетов и аргументированно попросить перепроверить.

Даже самое базовое умение программировать иногда очень помогает говорить с разработчиками на одном языке. Это как минимум добавляет менеджеру «кармы» среди разработчиков, ведь как он может ставить им задачи, если вообще не понимает, чем они занимаются? Если разработчик говорит, что нужно взять неделю на рефакторинг, а менеджер не понимает, зачем это нужно, и торопит его с фичами, и в результате у разработчика образуется огромный технический долг, от этого может пострадать весь проект.

Это также помогает при планировании, потому что позволяет понимать трудоемкость задачи, и если разработчики говорят, что тут разработки на три дня, а менеджер понимает, что он бы за день сделал, то можно попросить переоценку сроков не боясь оспаривать озвученные разработкой варианты.

В любой специальности ценятся крутые самодостаточные специалисты. При прочих равных программиста с развитыми soft skills будут предпочитать программисту-интроверту. Тоже самое касается и менеджера, умеющего программировать или с техническим бэкграундом. В технологических компаниях он будет цениться выше, чем просто хороший менеджер.

С чего начать?

Многие рабочие файлы, скрипты и некоторые данные лежат на серверах с консольным доступом по ssh, поэтому нужно дружить с командной строкой для работы с ними. Интерфейс взаимодействия через командную строку есть и в unix-подобных системах (Linux, MacOS), и в Windows.

Если вы раньше не работали в командной строке, то начать знакомство можно с прочтения, например, статьи «Основы линукс: Введение в bash».

Приведенные ссылки лишь примеры для общего представления о том, как:

• перемещаться по файловому дереву
• создавать, копировать и удалять файлы
• редактировать файлы при помощи Vim или nano
• с помощью ssh и scp обмениваться любым файлом с ноутбука на сервер и обратно.

Зачастую файлы с данными имеют очень большой размер и для работы с ними не получится использовать, например, привычный Excel. Поэтому стоит познакомиться с командами для работы с текстовыми файлами:

• Команды обработки текста
• Useful Unix commands for data science.

Будет полезно, если в итоге у вас сложится представление о следующих командах: cat, sort, uniq, wc, head, tail, awk, sed, grep, join.

Полезно хорошо знать команду grep с использованием регулярных выражений:

• Регулярные выражения для новичков
• Использование grep и регулярных выражений для поиска текстовых шаблонов в linux.

Более мощным и гибким инструментом для работы с данными является Python. Для того чтобы овладеть им, подойдет любой онлайн курс, можно начать с codecademy.

Хочется уточнить, что умение программировать для менеджера – это не десятки прочитанных книг по питону или С++, не тысячи строк кода отправленного коммитами (хотя от такого менеджера скорее всего никто не откажется!). Во многих компаниях имеются уже готовые инструменты, где на sql-like языке, или вообще drag-and-drop’ом полей в красивом интерфейсе можно сконфигурировать запрос за данными и получить отчет в нужном виде. И в этом случае «программирование» – это умение разбираться в структуре данных, критическое отношение к получаемой информации и желание докопаться до самых-самых глубин продукта самому.

Однако, чем более сложным проектом надо руководить, тем больше технических знаний может пригодиться. Менеджеру может потребоваться оценить предложенную разработчиками архитектуру проекта, следить за наличием тестов для всех компонент, предложить, что нужно рефакторить. Хорошие менеджеры могут до бесконечности развивать технические знания и погружаться в устройство своего продукта.

Такие менеджеры называются джедаями и каждый менеджер проекта должен стремиться стать таковым..

Правила менеджера-джедая

Продукт нужно знать на уровне кода

Точнее, архитектуры, но не кодить его. Знание продукта от и до — первоочередной навык любого менеджера (проекта, продукта, по продажам, по маркетингу). Если вы не понимаете, как и для чего его можно использовать, не видите взаимосвязи модулей и сущностей, не осознаете, на что повлияет изменение той или иной функциональности, вы никогда не сможете сделать успешный проект. Понимание функционирования и принципов работы помогает менеджеру быть требовательным и опытным, но не сумасбродным внутренним заказчиком. Увы, пиарщики и маркетологи за редким исключением этого не понимают, так что вся надежда на нас, менеджеров проектов.

Принцип прост: не предлагайте новые фичи только ради того, чтобы было; не списывайте у конкурента не глядя; не идите на поводу у безумных изменений клиента. Если вы знаете архитектуру продукта, вы никогда не скажете программисту: «Ну что тебе, трудно простенькую формочку прикрутить, заказчик говорит, дело двух часов». Просто потому что вы прекрасно понимаете, в каких местах вылезут изменения и насколько большая работа разработчиков и тестировщиков понадобится. Клянусь, легче отговорить от формочки заказчика. А если это вылезло еще посреди спринта, то можно воспользоваться приведенной выше формулой, как дополнительным аргументом.

Каждый делает свою работу

Делайте свою работу менеджера проекта, а программисты и инженеры сделают свою. Умение анализировать код, трафик, пользоваться отладчиком в браузере — прекрасные навыки для аналитической работы. Но на время общения с программистами оставляйте их при себе. Дело в том, что разработчики в любом случае проверят информацию и снимут свои дампы, заберут и проанализируют логи. И сделают это гораздо профессиональнее менеджера, который разобрался с информацией между делом.

Менеджер с навыками программирования (точнее проектирования и разработки ПО) — подарок и джедай. Но нужно помнить, что в команде есть более подготовленные люди, для которых эта работа является основной в отличие от вас. Не всегда работа с большими файлами в консоли vim необходима для постановки задачи программисту. Он может справиться быстрее с исследованием и потратит меньше времени.

При написании ТЗ переводите с языка заказчика на технический для постановки задачи.

Это очень важный скилл. Научитесь встать на сторону заказчика, проанализировать его требования, собрать их и оформить их во внятное техническое задание, которое можно будет согласовать, подписать и приступить к работе выдав понятные задачи программистам. Это тот блок деятельности менеджера, где он должен проявить свое понимание разработки и знание продукта. Описания должны соответствовать сущностям архитектуры. Требования — не выходить за грани исполнимой реальности. Цены и сроки — коррелировать с мощностью команды разработки с учетом загруженности всех ресурсов.

Учитесь общаться с заказчиком.

Чаще всего заказчики далеки от сферы разработки ПО и проектирования, им совершенно непонятно, почему нельзя добавить «крошечное окошко» или «небольшую фичу, недорого и недолго же» (ну, например, типа такого: привязать к системе считыватель номеров автомобиля на проходной, прописав логику распознавания марки по шильдику и распознования гос. номера). Менеджер — это буфер между желаниями заказчика и возможностями программиста, который умеет отсекать ненужные фантазии из требований. Хороший менеджер тщательно изучит бизнес заказчика, рассмотрит все требования и сумеет выделить те, которые действительно нужны, обосновать выбор и убедить клиента, что он сам так думает.

Планируйте внутри команды.

План работы команды с горизонтом на месяц и больше — главная шпаргалка менеджера. Ни одно решение не должно приниматься без анализа загруженности ресурсов. И только на первый взгляд кажется, что загрузку легко спрогнозировать. В тех же внедрениях CRM или любого другого ПО несколько человек заняты в нескольких проектах одновременно, и таких проектов бывает и на год вперёд. Важно не только расставить приоритеты, но и сделать это с учётом экономической целесообразности, критичности задачи, величины проекта. Ах да, и с учетом графика отпусков 🙂

Учитесь понимать риски

Хороший менеджер прогнозирует, анализирует и пресекает риск до того, как он стал риском. У менеджера должна быть целая система управления рисками — таблица, где перечислены потенциальные угрозы, маркеры рисков и пути реагирования. И здесь у менеджера возникает еще одна головная боль — на риск может пойти руководитель, не особо интересуясь вашей табличкой. Виновата в итоге всё равно будет команда, но быть готовым к такому раскладу определённо нужно.

Управляйте бюджетом.

Бюджетов у проекта несколько: первый — это затраты на его реализацию, второй — затраты заказчика на покупку, третий — реальные затраты на реализацию. Если не управлять бюджетом, третий превратится в монстра, который сожрёт всю коммерческую выгоду. Поэтому менеджер должен точно знать точки экономии, заделы роста затрат, которые стоит контролировать, и понимать, как управлять всеми тремя аспектами, чтобы заказчик был доволен и компания оказалась в плюсе. Прогибы на скидку, штрафы за полдня просрочки и неосторожные условия договора — это всё о бюджете, поэтому не забывайте, что это ваша задача.

Умейте критически мыслить.

У менеджера должен быть набор характеристик для каждого проекта: цена, сроки, ресурсы, необходимые инструменты и т.д. При возникновении любого вопроса и любой проблемы стоит взвесить плюсы и минусы, понять степень влияния на всю задачу в целом. Например, если вам предложили использовать в разработке бета-версию новейшего фреймворка, как менеджер проекта вы не должны броситься читать все мануалы, но должны поразмыслить: насколько версия сырая, какая поддержка будет, сколько багов и т.д. Хотя это скорее к тимлиду, но больно уж ситуация распространенная и неплохо если вы в ней разберетесь.

Чтобы сформировать критическое мышление, необходимо собрать для себя инструменты и подходы, которые позволят логически и системно анализировать изменение каждого фактора. Тогда и решения будут взвешенные, а не «WOW, погнали!»

Учитесь координировать команду по ситуации, а не по agile.

Ваша компания может работать по agile, внедрять scrum и геймификацию, придерживаться канбан, но всё это рассыпается от первого же неадекватного, а ещё лучше государственного заказчика, который покупает много, дорого и начинает диктовать свои условия. На конкурентном рынке глупо отказываться от денег в угоду методологиям. Хороший менеджер должен уметь сочетать любимую методологию с необходимостью применить водопадную модель на ровном месте, при этом обеспечив скоординированность команды и всунув внутрь любимую методологию.

И вот тут менеджер должен уметь четко формулировать, владеть средствами коммуникации и совместной работы, быть готовым забрать файл с сервера и разобраться в схеме проекта — для молниеносной, четкой и однозначной коммуникации в рамках излюбленного скрам-митинга или канбан стенд-апа.

Учитесь мотивировать.

Можно встретить тезис о том, что сильная и умная команда отлично самомотивируется и самоорганизуется. Но, это не так. Всегда есть кто-то, кто:

• мотивирует на постоянной основе и интересуется ходом работы;
• мотивирует по итогам работы и общается с руководством (не всегда понимающим и не всегда программистом);
• мотивирует в кризисной ситуации, сохраняя команду и устойчивость проекта.

Вместо заключения

Менеджер проекта — это мотор, который должен приводить в движение всю систему, обеспечивать согласованность всех элементов и максимально высокий КПД. Он не должен быть сторуким Шивой или двуликим Янусом, не должен быть образованцем, — он должен быть грамотным человеком, знающим, кто, когда, в какие сроки и за какие деньги решит часть проблемы. Если менеджер хочет выучить UNIX или научиться программированию — это похвально и поможет работе, поможет осознанию технических нюансов. Но это не должно делать из менеджера человека-оркестр. Такое положение дел только рассеет профессионализм, поскольку разбираться лучше в одном, но круто, чем во всём на троечку. Среднее арифметическое всё равно будет троечкой. В общем, дорогие менеджеры, не будьте той дурной головой, которая ногам покоя не даёт — думайте головой и всё закрутится как надо.