Ключевой навык успешной карьеры в ИТ или 8 заблуждений на проектах
Привет! Если по вашим венам уже во всю течет оливье, но полноценно работать работку пока не тянет, или просто хочется легкого полезного чтива с котиками, то данная статья с блеском подходит под это описание. В ней я постараюсь на реальных примерах рассказать об одном навыке, который считаю ключевым для работы в ИТ, и которому уделяется не так много внимания, как он того заслуживает. Технари любят устраивать холивары — про архитектуры, паттерны, языки программирования, но все это иногда совершенно не то.
Этот главный навык пригодится всем в индустрии — программистам, лидам, продуктологам, тестерам, менеджменту и всем остальным.
Имя ему этому навыку — здравый смысл.
Да, вот так просто, но на самом деле все совсем не просто, и я сейчас это объясню.
Как сделать сразу хорошо
Давайте сразу с места в карьер: за 16 лет в индустрии я повидал изнутри несколько сотен самых разных проектов и команд — успешных и не очень, больших и маленьких, с кучей интеграций и самыми разными архитектурами и подходами. И все эти проекты объединяло одно — что у них вообще ничего общего между собой не было.
К сожалению, люди очень сильно верят в различные стереотипы, и в ИТ часто случается большой стереотип о том, что есть один проверенный способ чтобы все сделать сразу как надо.
Коуч-кот, который точно знает как все сделать как надо
Но есть большая проблема в том, что как надо у каждого свое и единого рецепта здесь просто нет. И вот это целеполагание, причем на микро и макро уровнях, вместе с умением задавать правильные вопросы правильным людям — и есть самый важный навык. Потому что умение остановиться, оценить обстановку и несколько раз задать себе и другим вопрос «зачем?» — оно зачастую сильно видоизменяет наш план, которого мы будем придерживаться.
Я для себя называю это «технический менеджмент», то есть это такой человек, способный одинаково хорошо говорить на разных языках — дизайнерском, программистстком, маркетинговом, бизнесовом и так далее. Зачастую люди любят свой круг общения, но не понимают нюансов и специфики работы своих соседних коллег (я бы даже, с вашего позволения, сказал бы что часто все друг друга взаимно считают глупыми пи%орасами) и без «переводчика» одно и то же может трактоваться СИЛЬНО по разному разными людьми.
«Опять они там че-то придумали, а нам упарываться» — знакомо? Умение понимать чужую специфику, слушать людей и подниматься до самой сути проблемы, предлагать разные решения и находить баланс интересов — все это очень сильно помогает находить общий язык с людьми и избегать карьерных проблем.
Спецы в ИТ, как правило, фанатики точных наук, поэтому любая поставленная задача сразу воспринимается как есть, хотя на самом деле она такой может совершенно не быть, просто ее поставили как смогли. Вот как смогли так и поставили.
Если составить облаго тегов из первичных вопросов со здравым смыслом, то получится что-то такое: для кого мы это делаем? Должно работать быстро или точно? Какая цена ошибки? Зачем? Кто заказчик фичи? Кто пользователь? Какая нагрузка? Какие трудозатраты? Какой профит? Почему именно так?
Таких вопросов можно назадавать много, но давайте уже перейдем к примерам из заблуждений.
1 — Идея, над которой придется упороться
Сотрудник со сложной задачей
Самое большое количество конфликтов возникает, когда люди говорят совсем на разных уровнях понимания и когда задача проходит через сломанный телефон других сотрудников. Допустим, кто-то большой спустил через других сотрудников задачу Х, дальше возможно много вариантов.
Под X подразумевалось именно X и надо делать строго так
Под Х подразумевалось именно Х, но в процессе кем-то трансформировалось в Y, где Y может быть как проще, так и сложнее
X это лишь примерное обозначение, решение за вами
Х обозначение, решением за вами, но кто-то хитрый по пути перефразировал до Y, который очень сложный
…
Вариантов может быть множество, но если к вам пришла задача сделать что-то большое (или критическое), что может затронуть ядро технологии или потребует больших переделок, здравый смысл — ровно то, с чего нужно начинать. Возможно, задача изначально звучала не так, масштабы бедствия преувеличены, срочность завышена, а вместо недели работы сгодится разовый компромисс за час.
Всегда важно здраво оценивать истинные потребности и сроки задач, которые к вам приходят. А иногда приходится подняться на несколько уровней »зачем», потому что только там вскрывается истинная проблема, а дальше сформулировали как смогли, исказив весь смысл.
Большинство людей все же готовы слушать, если вы готовы спокойно и аргументированно с ними говорить. Не все и не всегда, конечно, но прежде чем упарываться — попробовать стоит.
2 — Нужно сделать срочно
Кот-сотрудник, которому надо сделать срочно
«Срочно» — это очень емкое слово, в которое в корпоративном мире могут влезать самые разные интервалы. Для кого-то срочно это час, для другого — несколько дней, поэтому если к вам пришли со срочной задачей — стоит узнать что именно подразумевается под срочностью и кем именно.
Мой самый любимый случай — менеджером был обозначен срок в виде «бросай все, надо делать», но позвонив вместе напрямую заказчику выяснилось что их конференция через месяц, а первый результат нужен будет лишь через три недели.
3 — Мы должны работать под высочайшей нагрузкой
Кот-сотрудник, который проектирует сложную систему
Менеджмент — зачастую очень амбициозен, а программисты — очень увлеченные, поэтому всем вместе делать большие сложные проекты гораздо интереснее, чем простые. Программистам часто от менеджмента спускаются мифические ожидания о миллионах пользователей и миллиардах выручки уже вот-вот, поэтому нужно сразу заложить очень серьезную архитектуру под серьезную нагрузку. А через полгода бюджет на разработку проекта сгорает без единого живого пользователя.
Сколько хороших архитектур и программисточасов в проектах сгорело на том, что готовились к нагрузке, которой никогда не случилось? Здесь важно понять, что если за вами большая компания, готовая бесконечно вливать деньги — без проблем, но если такую архитектуру с кучей апстримов с гео-балансировщиками и шардированием пытается делать голозадый стартап (у которого такая архитектура это не самоцель), то здесь может быть что-то не так в здравом смысле и постановке задач.
4 — Здесь надо все сжечь и переписать
Кот-сжигатель кода на проекте
С такой классной идеей как правило, на проект приходят новые сотрудники. Видя несовершенный код, с кучей костылей внутри, окрыленный сотрудник предлагает это все сжечь и переписать сразу по нормальному. В идеале — переписать сразу на другом языке, потому что в этом сезоне особо популярен dast/brainfuck/perl. К сожалению, такие порывы без должной страховки и опыта практически гарантировано приводят к большим проблемам, потому что сначала все красиво и хорошо, а потом начинаются жизненные «срочно добавьте», «закостыльте для презы», всплывают забытые исключения и все опять по новой.
Переписывать и облагораживать код нужно, но большие куски/модули переписывать нужно очень осторожно, взвешенно и с умом, потому что зачастую несовершенный работающий код написан чьей-то «кровью» и выглядит так убого не то чтобы просто так.
Живой случай в соседней команде: человек пришел, сказал что надо переделывать, под его харизмой переписывать на новом языке начали, а сотрудник ушел через 4 месяца, бросив все, directed by Robert B. Weide.
5 — Неумение/нежелание разобраться в чужом коде
Кот, которому нужно забить гвоздь бензопилой
Разбираться в чужом коде нового проекта (особенно без документации и помощи от другого сотрудника) — очень муторная штука. Это то, что прям совсем не любят, поэтому зачастую мелкие проблемы решаются авианосной группой.
Например, вместо того, чтобы попытаться все же докопаться до решения и его исправить (например, в текущем скрипте/фреймворке), в проект втаскивается новый фреймворк/библиотека и все переделывается на нем. Причем, трудозатраты могут быть такими же и выше, но лишь бы не копаться, а творить! Все это ок, если это личный проект, но когда на проекте несколько людей или разработка на заказ, то стоит лишний раз об этом подумать.
Новое — часто приносит новые проблемы. Это не плохо, просто всегда нужно понимать стоит ли оно того, если можно все решить текущими средствами.
6 — Локализация проблемы при медленной работе
Быстрая и медленная часть проекта
Когда что-то медленно работает, зачастую командой сразу выдвигается рабочая версия почему — ну там же жирный запрос, или много соединений, или кривой модуль — все ж очевидно, давайте его переделаем.
Когда что-то медленно работает — бросаться переделывать без точного диагноза нельзя, нужно углубляться в раскладку ЧТО именно с каким таймингом работает внутри и, набрав некоторые данные, уже делать выводы. Потому что жирный запрос может оказаться большим на вид, но быстроработающим, кривонаписанный модуль может работать идеально, а проблема быть там, куда без микроскопа просто так не залезешь.
7 — Покрыть весь проект тестами / документацией
Проектная документация
Тесты — штука важная и хорошая, но маниакально тестировать все на свете нет смысла. Точнее, смысл у каждого свой. Для задач с высокой ценой ошибки, критичного функционала и всего, что касается живых денег — да, многоступенчатые тесты обязательны, но покрывать тестами каждую функцию в лендинге — излишне. Тесты требуют своей актуализации, поэтому здесь всегда важен баланс.
Все то же самое справедливо и для документации — открытое апи должно быть хорошо задокументировано, но текстовая (не автоматическая) дока для каждой функции в проекте, где код часто переписывается — о целесообразности такого лишний раз стоит подумать.
8 — Технология для всех и каждого
Кот для всех
Так как область моей текущей работы — ML и AI, то я часто сталкиваюсь с тем, что от них есть ожидание, что технология решит ВСЕ проблемы во ВСЕХ случаях. Например, прицепив к камере «систему распознавания» можно решить вообще все, что могут решать системы такого класса.
Простой датчик движения и система обнаружения девиантного повидения в кафе — совершенно разные (во всем) системы, первой достаточно просто смены картинки, вторая должна глубоко погрузиться в анализ происходящего. Поэтому нужно сразу понимать под какие задачи и для кого на каком оборудовании мы что-то собираемся делать. Если софт будет работать на не самой мощной черно-белой камере в реальном времени, то это требует совершенно другого подхода, поэтому и подходить к задаче нужно соответствующе.
Выводы про здравый смысл
Конечно же, примеры очень условны и их список можно продлять до бесконечности, но перечислить все возможные стыки интересов с проблемами не было самоцелью. Хотелось на примерах показать, что человеческое взаимодействие на сложных проектах в ИТ — всегда сложное и с кучей сломанных телефонов, поэтому здравый смысл во всех рабочих вопросов жизненно необходим.
Увы, на проектах редко бывает технический менеджмент, способный понимать все нюансы происходящего и правильно раскладывать задачи от всех частей бизнеса. Нам часто неправильно ставят задачи и ставят неправильные задачи по самым разным причинам и с этим просто нужно жить. В идеале — жить хорошо, счастливо и без новомодных выгораний.
Всегда нужно уточнять зачем мы собираемся что-то делать именно так и что мы хотим получить, потому что часто это приводит к более точному пониманию задачи на всех уровнях, а часто и к ее полному переформатированию с последующим снижением стоимости, уменьшением сроков и сохранению нервов всех участников обсуждения.
Дзен кот
Хочу пожелать всем продуктивного года, поменьше офисных баталий и больше интересных задач, которые действительно делают мир чуточку лучше.
Спасибо!
