Человек из IT

Привет! Меня зовут Александр (@glorfindeil), и я DM в ЕПАМ. DM, если кратко - это "технический менеджер", "следующая форма тимлида". Про ЕПАМ, надеюсь, все знают:) Работаю в IT уже больше 11 лет и на этой неделе буду приоткрывать вам свой профессиональный мир.

Ребята, у меня последний день в коллективном тви. Я решил так и не делать больше тематических тредов. Неделя получилась скомканная, но все равно хочу поблагодарить всех поучавствовавших. Если остались вопросы или горячие топики - пишите в личный тви @glorfindeil , отвечу там

Ребят, в тяжелое время надо искать какой-то позитив. Расскажите, как ваш работодатель помогает коллегам с Украины?

Друзья, не имею морального права делать вид, что ничего не происходит, и спокойно писать про IT. От себя лично - не поддерживаю агрессию в любом ее проявлении. Желаю всем чистого неба.

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

Четвертое - не все могут перестроиться с "потоковой" деятельности, где ты сфокусирован на одной задаче на деятельность с постоянными прерываниями, коей по сути и является менеджмент. Привет всем, у кого 8 митингов по 30 минут подряд на совершенно разные темы ✋

Менеджер с безнадежно протухшей технической базой это ГОРАЗДО хуже, чем менеджер без какой-либо. Я слыхал истории про вебовские проекты на C++, которые начинались потому что директор предприятия заказчика 20 лет назад "прогал на плюсах и все было круто, надежный язык".

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

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

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

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

Понимание деталей технического производства может позволить действовать менее шаблонно при построении процессов в команде. Ты можешь примерно прикинуть при каких задачах нужны или не нужны те или иные процессы или метрики. Нужен ли вам CI? А CD? А команда авто-тестеров?

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

Кроме того, понимание "подкапотья" может позволить сразу же предупреждать заказчика с сумасшедшими идеями об их невыполнимости, не бегая к команде. Слышал историю про контракт на перенос 100% десктопного приложения на веб, включая функции открытия новых окон с разделением экрана

Третий важный аспект - это работа с эстимейтами. Опыт разработчика, или близкий к нему позволит примерно ощущать, когда разраб явно недо-оценил или пере-оценил задачу. Соответственно тут уменьшается риск сесть в лужу (притом в обе стороны).

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

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

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

Это позволяет генерировать более креативные решения, смотреть на проблемы шире и пропускать явления через призму своего опыта. То есть инфа, полученная от тех-эксперта нас не блочит. Мы можем копнуть глубже и слегка раскрутить клубок.

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

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