Вчера на Хабре вышла интересная статья о том, должен ли менеджер уметь программировать. Одна из наших менеджеров прошла огонь, воду, программирование, тестирование и проектную работу, поэтому решила написать ответ. По традиции таким сотрудникам мы даём свободный микрофон. Спойлер статьи: менеджер должен соображать, а не изображать. В общем, слово коллеге.
Мнение компании RegionSoft Developer Studio может не совпадать с мнением сотрудника. А может и совпадать. Тексты свободного микрофона мы не исправляем и не согласуем.
Привет! Статья отчасти правильная, и она не просто задела меня и зацепила глаз, а буквально оттопталась по больным мозолям моей менеджерской души. В общем, 10 лет назад, придя работать в ИТ-сферу, я думала точно так же, как автор статьи. Расскажу о вилах, граблях и райских облаках такого подхода.
Путь: менеджер — инженер по тестированию — менеджер
Итак, в 2007 году я пришла работать в крупную телекоммуникационную компанию и мгновенно ощутила серьёзные проблемы в общении с программистами и подразделением АСУ (автоматизированных систем управления). Ребята по нашим ТЗ готовили нам выгрузки данных, которые мы обрабатывали в Excel и Access, а затем использовали для стандартных коммерческих нужд вроде рассылок, разработок нишевых тарифных планов и охоты за недобросовестными продавцами наших симчатых пакетов подключения. Программисты наши технические задания ненавидели — самым безобидным замечанием был вызов к себе и швыряние распечатанными листами со словами «хватит плодить сущности, пиши, что именно тебе надо, а не вот это всё». Мне было обидно, ведь каждое ТЗ я расписывала по-университетски старательно: кто заказчик, для каких целей, какие поля, даты, сроки, согласования и т.д.
Во время очередного обеда с разработчиками ко мне пришло осознание, что всё это оттого, что я никуда не гожусь со своим экономическим образованием и, чтобы научиться общаться с программистами, нужно… стать одним из них. Так я пошла в один корпоративный университет Нижнего Новгорода (привет, НИИТ!), где в течение двух лет на полном серьёзе осваивала: алгоритмы и структуры данных, С, С++, Java (хотелось застрелиться), Python (его полюбила нежно), немножко Assembler (а Java-то ничего) и даже UML-диаграммы и управление ИТ-проектами. У нас был гигантский и глубокий курс UNIX, в ходе которого я научилась работать с консолью, компилировать в gcc, grep-ать, писать регулярные выражения, познакомилась с vim и т.д. То есть стала прямо эталонным образцом из статьи — уже обросший опытом менеджер с навыками администрирования и знанием довольно глубоких основ программирования.
Мои технические задания изменились — они стали едва ли не готовыми скриптами для выборок и… разбесили АСУ-шников ещё больше. Что вышло?
- Появилась уверенность в своей правоте и избранности при том, что программисты были на голову опытнее. Грепающий менеджер, умеющий редактировать файлы в vim и немного секущий в SQL, стал головной болью семи человек.
- Навыки транслировались на совершенно другие системы. Например, моё знание Python никак не ложилось на недознание SQL.
- Я ощутимо выросла над коллегами-менеджерами, отчего возникало недопонимание. Зато отлично складывались отношения со службой безопасности — теперь я знала, что фрод отлавливается не с помощью магии, а с помощью скриптов, снятия, анализа и контроля трафика. Мы реализовывали интересные проекты, и там универсальность была впору.
- Точности расчёта времени и затрат на реализацию очередного проекта не прибавилось, поскольку одно дело всё спроектировать, а другое — реализовать. Пришлось вникать в тестирование и осознать, что UML-диаграммы ничего не решают. Некоторые разработчики о них и знать не знали, но фигачили код с бешеной скоростью и умели управлять своим временем внутри проекта, а другие знали всё, а кодили мало — просто не было навыков. Теоретики.
- Самое главное — понимание кода продуктов и кода, стоящего за услугами, не дало того углублённого знания продукта, которое появляется при непосредственном тесном взаимодействии с разработкой в роли пользователя. Тут дело такое: менеджер — это мостик между разработчиком и конечным пользователем. И, чтобы что-то улучшить, нужно понимать, чего не хватает клиенту и его сотрудникам, а не почему модуль отрабатывает за 0,15 мс, а не за 0,11 мс. Клянусь, пользователь этого не замечает. А вот то, что нет крестика, которым закрывают программу, очень даже замечает (реальный баг одного из релизов личного кабинета абонента).
В общем, я стала понимать, что быть менеджером не благородно и ушла в инженеры по тестированию в компанию-разработчика систем связи и коммутации. То есть что? Правильно — оказалась по другую сторону баррикад и теперь пришёл мой черёд психовать при виде менеджера проекта или, что ещё хуже, маркетолога или продажника. «Блокирующий баг от клиента», «Критикал от клиента», «Запрос на фичу, передаём в разработку» — о боже, эти люди вообще понимали, как мы работаем в поте лица и что нам не до новых фич?! Как можно было присвоить критикал минорному багу? Почему менеджеры проекта так некстати употребляют слова: бэклог, спринт, коммит, багтрекер, почему они путают Багзиллу и Мозиллу Файерфокс, что значит выражение «задевелопь фичу, чтобы я мог провести митинг с аккаунтом», ведь так не говорят? На самом деле, менеджеры всё понимали и даже сочувствовали нашим переработкам, но за их плечами стояло то, о чём пока ни я, ни автор исходной статьи не обмолвились.
За плечами менеджера стоят деньги. И вся программистская работа, работа тестировщика и инженера — это деньги компании, на которые она существует и из которых нам платят зарплату. И если менеджер в рабочее время «накидывает архитектурку» и копается в дампах из Wireshark, чтобы развернуться перед программистом во всей красе, он теряет эти самые деньги.
Правила менеджера-джедая
Как вы уже поняли, из инженеров по тестированию я вернулась в менеджеры, уже перерождённой и осознанной. Увы, я не могу рассказать о тонкостях управления проектами в RegionSoft Developer Studio, поскольку это закрытая разработка и внедрения, рассказ о которых нужно согласовывать с клиентами, но после такой двойной трансформации я с радостью поделюсь правилами, благодаря которым можно стать действительно успешным менеджером.
Продукт нужно знать на уровне кода (точнее, архитектуры), но не кодить его. Знание продукта от и до — первоочередной навык любого менеджера (проекта, продукта, по продажам, по маркетингу). Если вы не понимаете, как и для чего его можно использовать, не видите взаимосвязи модулей и сущностей, не осознаёте, на что повлияет изменение той или иной функциональности, вы никогда не сможете сделать продукт успешным на рынке. Глубокое понимание функционирования и принципов работы помогает менеджеру быть требовательным и опытным, но не сумасбродным внутренним заказчиком. Увы, пиарщики и маркетологи за редким исключением этого не понимают, так что вся надежда на нас.
Принцип прост: не предлагайте новые фичи только ради того, чтобы было; не списывайте у конкурента не глядя; не идите на поводу у безумных изменений клиента. Если вы знаете архитектуру продукта, вы никогда не скажете программисту: «Ну что тебе, трудно простенькую формочку прикрутить, заказчик говорит, дело двух часов». Просто потому что вы прекрасно понимаете, в каких местах вылезут изменения и насколько большая работа разработчиков и тестировщиков понадобится. Клянусь, легче отговорить от формочки заказчика.
Делайте свою работу, программисты и инженеры сделают свою сами. Уметь анализировать код, трафик, пользоваться отладчиком в браузере — прекрасные навыки для аналитической работы. Но на время общения с программистами оставляйте их при себе. Дело в том, что разработчики в любом случае проверят информацию и снимут свои дампы, заберут и проанализируют логи. И сделают это гораздо профессиональнее менеджера, который разобрался с информацией между делом.
Менеджер с навыками программирования (точнее проектирования и разработки ПО) — подарок судьбы. Менеджер, тратящий время на освоение командной строки и vim-a — неэффективная имитация.
Учитесь писать ТЗ и переводить с языка заказчика на язык задачи. Это очень важный скилл. Научитесь встать на сторону заказчика, проанализировать его требования, собрать их и оформить их во внятное техническое задание, которое можно будет согласовать, подписать и приступить к работе. Это опять тот блок деятельности менеджера, где он должен проявить своё понимание разработки и знание продукта. Описания должны соответствовать сущностям архитектуры, требования — не выходить за грани исполнимой реальности, цены и сроки — коррелировать с мощностью команды разработки с учётом всей загруженности. В обратном случае придётся договариваться об отсрочке дедлайна и работать в ущерб компании, а это не та цель, ради которой существует менеджер проекта.
Учитесь общаться с заказчиком. Чаще всего заказчики далеки от сферы разработки ПО и проектирования, им совершенно непонятно, почему нельзя добавить «крошечное окошко» или «небольшую фичу, недорого и недолго же» (ну, например, типа такого: привязать к системе считыватель номеров автомобиля на проходной, прописав логику распознавания марки по шильдику и распознования гос. номера). Менеджер — это буфер между желаниями заказчика и возможностями программиста, который умеет отсекать ненужные фантазии из требований. Хороший менеджер тщательно изучит бизнес заказчика, рассмотрит все требования и сумеет выделить те, которые действительно нужны, обосновать выбор и убедить клиента, что он сам так думает.
Планируйте внутри команды. Вообще план работы команды с горизонтом на месяц и больше — буквально главная шпаргалка менеджера. Ни одно решение не должно приниматься без анализа загруженности ресурсов. И только на первый взгляд кажется, что загрузку легко спрогнозировать. В тех же внедрениях CRM или любого другого ПО несколько человек заняты в нескольких проектах одновременно, и таких проектов бывает что на год вперёд. Важно не только расставить приоритеты, но и сделать это с учётом экономической целесообразности, критичности задачи, величины проекта. Ах да, и с учётом графика отпусков :-)
Учитесь понимать риски, видеть их и управлять ими. Хороший менеджер прогнозирует, анализирует и пресекает риск до того, как он стал риском. У менеджера должна быть целая система управления рисками — таблица, где перечислены потенциальные угрозы, маркеры рисков и пути реагирования. И здесь у менеджера возникает ещё одна головная боль — на риск может пойти руководитель, не особо интересуясь табличкой. Виновата в итоге всё равно будет команда, но быть готовым к такому раскладу определённо нужно.
Управляйте бюджетом. Бюджетов у проекта несколько: первый — это затраты на его реализацию, второй — затраты заказчика на покупку, третий — реальные затраты на реализацию. Если не управлять бюджетом, третий превратится в монстра, который сожрёт всю коммерческую выгоду. Поэтому менеджер должен точно знать точки экономии, заделы роста затрат, которые стоит контролировать, и понимать, как управлять всеми тремя аспектами, чтобы заказчик был доволен и компания оказалась в плюсе. Прогибы на скидку, штрафы за полдня просрочки и неосторожные условия договора — это всё о бюджете, поэтому не забывайте, что это ваша задача.
Умейте критически мыслить. У каждого менеджера должен быть набор характеристик проекта: цена, сроки, ресурсы, необходимые инструменты и т.д. При возникновении любого вопроса и любой проблемы стоит взвесить плюсы и минусы, понять степень влияния на всю задачу в целом. Например, если вам предложили использовать в разработке бета-версию новейшего фреймворка, как менеджер проекта вы не должны броситься читать все мануалы, но должны поразмыслить: насколько версия сырая, какая поддержка будет, сколько багов в любой бете и т.д. Хотя в этом примере речь скорее о тимлиде, но больно уж ситуация распространённая.
Чтобы сформировать критическое , необходимо собрать для себя инструменты и подходы, которые позволят логически и системно анализировать изменение каждого фактора. Тогда и решения будут взвешенные, а не «WOW, погнали!»
Учитесь координировать команду по ситуации, а не по agile. Ваша компания может работать по agile, внедрять scrum и геймификацию, придерживаться канбан, но всё это рассыпается от первого же неадекватного, требовательного, а ещё лучше государственного заказчика, который покупает много, дорого и начинает диктовать свои условия. На конкурентном рынке глупо отказываться от денег в угоду методологиям. Хороший менеджер должен уметь сочетать любимую методологию разработчиков с необходимостью провести мозговой штурм, применить водопадную модель на ровном месте, при этом обеспечив скоординированность команды.
И вот тут менеджер должен уметь чётко формулировать, владеть средствами коммуникации и совместной работы, быть готовым забрать файл с сервера и разобраться в схеме проекта — для целей молниеносной, чёткой и однозначной коммуникации (а не бесплодных 5-часовых совещаний).
Учитесь мотивировать. Можно встретить тезис о том, что сильная и умная команда отлично самомотивируется и самоорганизуется. Нет, это не так. Всегда есть кто-то, кто а) мотивирует на постоянной основе и интересуется ходом работы; б) мотивирует по итогам работы и общается с руководством (не всегда понимающим и не всегда программистом); в) мотивирует в кризисной ситуации, сохраняя команду и устойчивость проекта.
Менеджер проекта — это мотор, который должен приводить в движение всю систему, обеспечивать согласованность всех элементов и максимально высокий КПД. Он не должен быть сторуким Шивой или двуликим Янусом, не должен быть образованцем, — он должен быть грамотным человеком, знающим, кто, когда, в какие сроки и за какие деньги решит часть проблемы. Если менеджер хочет выучить UNIX или научиться программированию — это похвально и поможет работе, поможет осознанию технических нюансов. Но это не должно делать из менеджера человека-оркестр. Такое положение дел только рассеет профессионализм, поскольку разбираться лучше в одном, но круто, чем во всём на троечку. Среднее арифметическое всё равно будет троечкой. В общем, дорогие менеджеры, не будьте той дурной головой, которая ногам покоя не даёт — думайте головой и всё закрутится как надо.
Наш сайт с абсолютно десктопным ПО для бизнеса и нашей флагманской RegionSoft CRM.
Наш Телеграм-канал BizBreeze. Всякое про CRM и бизнес, по уму, без копипаста и на 90% без рекламы. Подписывайтесь, там бывает прикольно.
Автор: Free_Mic_RS
