Для чего IT-пиэму нужно уметь программировать

Введение

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

На стартовой встрече на моей первой руководящей работе гендир и техдир завели дискуссию, должен ли конструктор ракет сходить в атаку с десантниками. В целом, пришли к выводу, что в этом случае КБ лишится конструктора, а десантники приобретут бесполезного солдата. Но на деле, на один день в поля меня всё же отправили ;-)

Личная практика.

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

Так всё же, зачем?

Лучшее понимание происходящего

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

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

Аргументированная личная позиция

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

Далее. Вы начинаете понимать, как разработчики преобразуют написанные аналитиком требования в техническое решение. Это позволяет рецензировать требования намного качественнее и глубже. Кроме того, к вам приходит понимание того, что реализация повторяет постановку совсем не дословно.

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

Разрабы будут вас уважать

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

Например, я на последней работе попросил лида фронтенда о помощи. Кое-что поправить в стилях в этом блоге. Он разгрыз мою задачу, я прошу скинуть полный кусок кода. Он говорит, зачем, просто поправь строчку в css темы. Я отвечаю, чувак, если так сделать, при следующем обновлении вордпресс-темы, наши правки затрутся. Нужно переписать всю конструкцию через внешний css. Он хранится в БД, никогда не перезаписывается и всегда грузится последним. И чувак прям проникся. Менеджер смог его научить технической штуке. Круть.

Личная практика.

Если вы свой, вам будут нормально объяснять суть проблем. Общаться с попугаем «ребята, какой статус?» разрабы не любят.

Вы научитесь понимать, когда вас обманывают со сроками

Разработчикам свойственно мухлевать со сроками. Обязательно найдётся умник, который будет завышать оценку задачи, овертаймить один день, а потом четыре дня пинать балду. С одной стороны, задача делается, какая вам разница. С другой, вы могли бы задействовать этого разраба более эффективно.

Поработав какое-то время с командой и поделав типовые задачи, вы более-менее научитесь оценивать эти типовые задачи даже без технических навыков. Но скиллы программирования позволят оценивать¹ качество оценки (лол) и на нетиповых тасках.

Вы сможете в автоматизацию

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

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

Выводы

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

Так надо записываться на курсы? Скорее, нет. Но если вы работаете с табличными данными (а это 99 % пиэмов), советую освоить Pandas² и базовый Python³. После некоторой прокачки, сможете делать всякое с табличками и файлами, это уже будет иметь большой эффект.

В общем, будьте технически грамотной индюшкой, это даёт много плюшек.

---

1. Я вас только заклинаю, не скатывайтесь в: «Да что там делать, я бы за час закодил», унижать коллег не нужно. ↩︎
2. Pandas — программная библиотека на языке Python для обработки и анализа данных. Работа pandas с данными строится поверх библиотеки NumPy, являющейся инструментом более низкого уровня. Предоставляет специальные структуры данных и операции для манипулирования числовыми таблицами и временны́ми рядами. Название библиотеки происходит от эконометрического термина «панельные данные», используемого для описания многомерных структурированных наборов информации. pandas распространяется под новой лицензией BSD. ↩︎
3. На уровне циклов и if‑else условий, функций, списков, словарей. Осваивается за 36 часов при базовых технических скиллах. ↩︎