Привет, Хабр!
Решил свою первую статью на портале сделать легкой, без залезания в дебри и диспуты. Пусть будет своего рода научпоп от менеджмента в ИТ.
Немного предыстории: где-то около года назад мы с коллегами были на загородном выезде для манагеров. В программе было обучение и брейнстормы, в перерывах и вечером - активный движ и застолья.
И вот как-то раз, после дневных учебно-мозгоштурмовых сессий народ разбредался по активностям, а я сел в лобби, достал ноут. Сижу. Подходит коллега:
— Что делаешь? Ботаешь?
— Нет, учусь.
— Что учишь?
— ООП
— А зачем?
Если честно, в тот день я не нашел, что ответить. Если ты лид на ДВХ, который вырос из системного же анализа, то тебе из технических знаний нужен SQL, основы баз данных, дата инженерия. Плюс общее понимание, как работают потоки, фреймворки, оркестраторы, очереди, апишки, но именно что общее понимание, на уровне «это даем на вход, это получаем на выход, отрисовывать это надо так‑то а описывать так». Но главный твой инструмент — это аутлук и зум/дион, трекер и экселька. А тут вдруг — программирование.
Тогда я задумался, а и правда, зачем. То что кодить — это интересно и я буду лучше понимать, что происходит «под капотом приложений» — слабая аргументация на первый взгляд. «А вдруг когда‑нибудь понадобится» — тоже такое себе.
Основной вопрос менеджера — «где деньги, Зин?». Если на что‑то тратится время и силы (а я на тот момент уже не одну сотню часов на учебу потратил), у этого должен быть смысл и таки гешефт. Если планируешь менять вектор развития и становиться разрабом‑ тогда понятно, а если нет — то должен же быть смысл. И вот найти смысл сходу — та еще задачка.
Для чего тебе, манагеру, программировать? Сам что ли код будешь писать? Или ревьюить? Или баги искать? — так на то разрабы есть. Будешь среди них очень дорогим джуном, который вместо того чтобы свои задачи решать, под ногами болтается. Порядков не знает. К лотку культуре ведения гита не приучен, гадит коммитит где попало, дерет пайплайны, пристает к соседским кошкам с глупыми вопросами и всех отвлекает.
Да и вообще из самых общих соображений: если командир вдруг откладывает карты местности, берет винтовку и идет стрелять, то войско теряет командующего и приобретает плохого солдата в пафосном мундире. Хорошо это вряд ли закончится.
Сегодня, год и несколько внедрений спустя, я наконец могу обрисовать прикладную пользу от кодинга для лида. Стоит ли игра свеч — пусть решит читатель.
Итак, первое, и на самом деле главное — это намного лучшее понимание того, что происходит на проектах в техническом плане. Разница по ощущениям такая же, как между «смотреть видео на ютубе про путешествие в другую страну» и «поехать и посмотреть своими глазами». Вроде бы на ютубе и не наврали ни о чем, и много интересного рассказали, но вот ты приезжаешь — и получаешь свой персональный неповторимый субъективный опыт, который получить по‑другому просто нет никакой возможности.
Второе, как следствие первого: у тебя появляется позиция и аргументы в руках, ты начинаешь лучше и раньше отлавливать возможные проблемы, а также понимаешь разницу между постановкой и реализацией.
Я имею ввиду что то что описал аналитик — это, конечно, все еще технический документ. Но когда этот документ приходит к разрабу — логика документа начинает преобразовываться таким образом, чтобы код соответствовал принятым техническим паттернам, а сама реализация происходит на имеющихся инструментах, библиотеках, классах и т. п. В итоге логика изначальной постановки, конечно же, реализуется, но не дословно соответствует исходнику.
Что это значит на практике? А то, что со временем эти недословные совпадения будут копиться, сложность системы будет расти, а вместе с тем сложность ее поддержки и развития.
Если лид понимает эти ограничения — то может повлиять на поход к работе аналитиков, добиться лучшего мэтча с разрабами в части реализации и заказчиками в части ожиданий, аргументированно отстоять перед заказчиком правки в решении, благодаря которым впоследствии можно будет сэкономить время, силы, нервные клетки.
Почему здесь недостаточно только лида разработки? А потому, что он не общается (или мало общается) с заказчиком, не лезет в бизнес. Не его задача обеспечить этот метч и чтобы все были довольны, а ваша. Если подумать, этого хотят все: заказчику нужен тот, кто знает, что делает, и кому можно доверять, аналитик хочет делать постановки так, чтобы не ночевать у компа после релиза. Разраб, хотя ночную жизнь и уважает, но овертаймы и авралы — вряд ли. Вот только так получается, что не всегда есть тот медиатор, кто всех подружит.
Третье. Несмотря на то, что вы освоили ЯП, гит, пару библиотек и т. п., по сути — вы все еще джун. Потому что надо еще набрать литров выпитого кофе, строчек написанного кода, тупых ошибок, вылетов по памяти и прочего счастья. НО! Разрабы вас почему‑то уважают, охотно помогают, дают какие‑то задачки порешать, статейки почитать, лайфхаками делятся и т. п.
Почему?
Я так думаю, потому, что им теперь с вами намного проще. Трудно бывает объяснить суть проблемы тому, кого можно заменить попугаем, умеющим спрашивать «Скоро будет готово?». А вам — можно, вы — поймете.
Четвертое. Вы начинаете понимать разработчика. Нет, ну правда. Неужели аналитику блин сложно прогнать SQL скрипт перед тем, как отдавать постановку, и просто убедиться что он работает? Почему я должен за этого аналитика отслеживать приведения к дататипам и длинам полей? Почему я должен чекать дубли за него? Агрххххх, ярость, абырвалг...ой, что это я, я ж сам лид аналитиков. Пойду им поставлю за правило делать проверки 1,2,3, теперь это будет наш стандарт работы в команде. Да, раньше не требовал, а теперь подумал что таки стоит.
Пятое. Вы слетаете с катушек увлекаетесь своей новой властью над умными машинками и начинаете автоматизировать все подряд. И знаете что? Это работает восхитительно!
Потому что теперь вы можете, например, потребовать от аналитиков аккуратно заполнить единственную(!) эксельку, на которую натравите написанный вами генератор постановок, который нашлепает вам за секунду 150 готовых доков в формате markdown, в которых будет околонулевая доля ошибок, т.к. умные машинки не страдают человеческим фактором, не устают, не путают поля и типы, не забывают запятые. Если изменились требования — правим исходник, запускаем скрипт, и снова все быстро, чисто и красиво. На последнем проекте у меня реально была проблема простоя аналитиков из‑за этого. Рутины стало не хватать, как бы странно это не звучало.
Другой пример — написать скрипт, который подцепится к системе‑источнику, получит скажем хеши объектов, агрегированные показатели или что вы там себе напридумываете в QA сценариях, сверит их с системой приемником, и либо явно подтвердит что объект ок, либо выдаст ключи записей с косяками. Мы эту штуку показали заказчику и техническая приемка слоя ods у нас в какой‑то момент стала сводиться к прогону скрипта. Надо говорить, насколько приемка обычно сложная и долгая штука?
Для добивочки третий пример: руководство оплатило вам вместо привычной jira чуду‑юду трекер‑систему известного бренда. Вкусы разработчиков этого бренда весьма специфичны и получить требуемую картинку (пользуясь которой можно реально управлять проектом) имеющимися инструментами просто нельзя. До сих пор PM/PO тратил каждую неделю по полдня чтобы собрать план релизов. Но вот приходишь ты, не мышонок, не лягушка, а неведома зверушка то ли менеджер, то ли волшебник, дергаешь по API объекты трекера, собираешь из них отчет, ставишь сборку витрины с отчетом на регламент, менеджеру вручаешь эксельку, в которую по ODBC тянется витрина. Теперь он имеет свой отчет в любимом excel, обновляет его по кнопке и счастлив до невозможности.
Завершая рассказ
А почему не поручить все описанное просто разработчику? Зачем самому учиться‑то? Хороший вопрос. Следующий вопрос. Да потому, что как‑то не думаешь об этом всем пока не избалуешься возможностью делать что хочешь своими руками. Потому и нет в ИТ проектах массовых автоматизаций рутины, что сам об этом не думаешь, а отрывать от основного проекта и выделять на эту работу ресурс аналитика/разработчика который бы продумал эти сценарии — как‑то не комильфо, да и не каждому хватит на это понимания и кругозора (решаете‑то вы свои проблемы в первую очередь). Вот и получается что делаем мы заказчикам автоматизации, а сами живем без автоматизаций. Сапожники без сапог, ей‑Богу.
Резюмируя: стоит ли овчинка выделки? Скажу честно, пласт знаний огромен. Чем больше узнаешь, тем больше хочется и тем больше кажется что не знаешь вообще ничего. Времени и сил уйдет много. Не верьте тем, кто обещает быстрый результат.
Исключение только одно пожалуй: однозначно рекомендую тем кто работает с табличными данными, освоить Pandas и базовый питон (на уровне циклов и if‑else условий, функций, списков, словарей), сможете делать немножко волшебства с файлами и табличками уже через пару месяцев.
Стоит ли идти в длительное обучение — пожалуй, нет универсального ответа. Выгода ощутима. Лично я — планирую продолжать, хотя бы просто потому, что это оказалось увлекательно и дает очень интересные возможности. С другой стороны, для управленца это точно не критически незаменимый скилл. Жили без него и работали, верно?
Так что, дорогой читатель, решай сам. И меня поздравляй с почином, первая статья на Хабре как‑никак =)
