О некомпетентности в ІТ, или Как сеньора Сеню хинкали погубили
Я Руслан Дмитракович, разработчик ПО и предприниматель. За моей спиной множество программных проектов в различных областях. В настоящее время занимаю должность программного архитектора. Уделяю особое внимание нетехническим аспектам разработки ПО.
Индустрия ІТ очень разнообразна, существует немало сегментов, требующих обширных знаний. И чем больше знает специалист, тем больше у него поводов сомневаться в самом себе. Ведь он понимает, как много того, что еще можно узнать. Как говорил Сократ: «Я знаю, что ничего не знаю». И эта статья именно для тех, кто постоянно учится, но все же сомневается в себе.
Хочу рассказать несколько реальных историй... Ну или почти реальных, если я где-то и добавил художественного вымысла, то совсем немного. Но, как говориться, считайте все совпадения с реальными персонажами случайностью.
«Смерть Сократа», Жак Луи Давид
Сеньоры, которые все знают
Недавно общался с группой программистов примерно одной квалификации и опыта. В ходе беседы задавались два стандартных вопроса:
- Как вы оцениваете свою квалификацию?
- Как вы учитесь и чего планируете достичь?
Группа разделилась на Senior и Middle. И ответы на второй вопрос четко коррелировали с ответом на первый.
Middle-разработчики рассказали, какие книги читают, что изучают и какого прогресса хотят достичь. Senior на второй вопрос отвечали расплывчато, а уточнения по поводу литературы вызывали затруднения.
Уровень знаний оставлял желать лучшего, но наши герои не стремились что-то изучать. «Совпадение? Не думаю». Довольно логично, если ты уже достиг наивысшего уровня мастерства, то зачем еще учиться?
«Я — король!»
А вот история про архитектора. Если сеньор может не учиться, то архитектор и подавно. У меня есть знакомый, занимавший эту должность. На вопрос о том, читал ли он что-то по обсуждаемой теме, не стеснялся ответить, что на чтение у него нет времени, потому что это мешает личной жизни. И отсутствие знаний не мешало ему с уверенностью высказывать свое мнение.
Себя он считал профессионалом с большой буквы и с большим опытом (потому как человек уже не молодой). На обсуждениях технических вопросов частенько звучало: «Делаем так, потому что я архитектор», и резонные замечания не принимались. Такое происходило не в момент решения критических проблем, когда кто-то должен быстро взять на себя ответственность. Нет, это были вполне обычные, регулярные собрания для обсуждения технических вопросов. Аргументы и желание понять точку зрения оппонента в споре заменялось директивным указанием.
В этот момент в комнате явно не хватало Тайвина Ланнистера, чтобы сказать: «Обычно „Я — король“ заявляют те, кто королем не являются».
Детали реализации архитектора не интересовали, и то, что было сделано, не проверялось на соответствие принятым решениям. Нередко программная система и архитектурная картинка отличались. Однако финансовые ресурсы компании позволяли сглаживать дополнительным «железом» или людьми все недочеты.
К сожалению, возраст и должность часто вводят в заблуждение. Опыт ценен тем, что это практическая часть обучения. Но если человек на протяжении многих лет решает одни и те же задачи и постоянно наступает на одни и те же грабли? Можно ли считать, что он обладает большим опытом?
Должность и квалификация должны соответствовать друг другу. А что если человек попал на должность случайно или по знакомству? Или человек, решающий вопрос о принятии на работу, сам не является профессионалом?
Думаю, что в первую очередь нужно обращать внимание не на годы в индустрии и позицию, а именно на знания и список решенных задач.
Эффект хинкали
Вот еще одна история, про Сеню, человека с «опытом». Уже немолодого программиста приняли в аутсорсинговую фирму на должность Senior-разработчика. Нужно понимать специфику организации, выставляющей заказчику счет за отработанные специалистом часы. Фактически наибольшую прибыль фирме дают наименее квалифицированные персонажи. Заказчик оплачивает час работы полноценного специалиста, а работнику платят согласно его реальной квалификации. И если качество работы серьёзно не проседает, то можно немного и «разбадяжить» квалифицированных специалистов.
Сеня занимался исправлением багов. Во-первых, такую деятельность не всегда можно точно оценить по времени, во-вторых, программист имеет дело с готовым решением и сам мало что пишет. Зачастую бывало, что проблема находилась и исправлялась, но через некоторое время появлялась уже другая.
Дело в том, что в ходе исправления Сеня одно чинил, а другое ломал. Помню, как, решая проблему, которая возникла в модуле B, зависящем от модуля А, он изменил А. Потом появилась ошибка в модуле С. Во время поисков выяснилось, что так как С зависит от А, то новая проблема возникла после данного изменения. Система была написана не идеально, и, внося правки, нужно было отслеживать, на что именно они влияют.
Однако наш герой сильно в подробности не вникал. И если фирме он приносил деньги, то коллегам — головную боль. Приходилось тщательно подбирать ему задачи — с минимальным риском что-то поломать.
Разговоры с руководством о том, что Сеня, мягко говоря, не дотягивает, результата не давали.
«Если вас ударят в глаз, вы вначале вскрикнете. Раз ударят, два ударят, а потом привыкнете». Вот так и коллеги привыкли, что надо мириться с обстоятельствами в лице Сени.
Однако на очередном тимбилдинге произошел казус, который сломал Сене карьеру. Команда пошла в грузинский ресторан, и несколько человек, в том числе и наш герой, заказали хинкали. То ли обслуживал Junior-официант, то ли кто-то чего-то недопонял. В результате все хинкали были насыпаны в одну миску, и счастливчиком, которому эту миску принесли, оказался Сеня. Не заметив несоответствия между ТЗ и тем, что ему досталось, Сеня с аппетитом уминал одно хинкали за другим. Коллеги же, не получившие свой заказ, начали роптать.
Баг системы обслуживания всплыл, но Сеня откровенно заявил, что просто не заметил разницы. Это было последней каплей. Как может человек замечать какие-то несоответствия в программном коде, если он не может сосчитать хинкали в собственной тарелке?!
В итоге руководство согласилось отправить Сеню в свободное плавание...
Но, что самое замечательное, наш герой искренне считал себя Senior-разработчиком. И он так же ничему не учился в рамках своей специальности.
Даннинг — Крюгер против самозванца
Об эффекте Даннинга — Крюгера слышали многие, и мои истории именно об этом. Но есть отклонение и в другую сторону — синдром самозванца. В этом случае специалист, наоборот, себя недооценивает. Такое наблюдается у большого количества людей в ІТ-индустрии.
И хотя последнее более конструктивно, потому что подталкивает человека к развитию, но, как и переоценка своих знаний, является неадекватным восприятием себя в контексте окружающей действительности и имеет негативные последствия.
Данная статья в первую очередь для тех, что считает себя «самозванцем», чтобы рассказать о самозванцах настоящих.
Выводы
Если вы не уверены в себе, то больше общайтесь. Попытайтесь узнать, что думают о вас окружающие. Это должны быть разные люди, вполне вероятно, что, попав в общество «профессионалов» из моих историй, вы почувствуете себя не в своей тарелке и будете вести себя как герои научно-популярного фильма «Я и другие».
Если же так случилось, то вспоминайте изречение: «Если вы самый умный человек в комнате, то вы не в той комнате, где должны находиться». Меняйте свое окружение. Участвуйте в конференциях и тусовках. Благо, что для того, чтобы общаться с коллегами, достаточно подключится к дискуссионной группе в мессенджере. Это поможет вам как получить новые знания, так и «откалиброваться» относительно коллег.
Проходите курсы и сертификации. Обучаясь и сдавая экзамены, получите формальное подтверждение своей квалификации.
Кавалерия династии Мин
И еще один неочевидный вывод. По компетенции и адекватности специалистов вы можете судить о руководстве компании. «Скажи мне, кто твой друг, и я скажу, кто ты». В данном случае эта поговорка отлично работает. Ее можно перефразировать так: «Посмотри на персонал компании, и ты поймешь, кем является ее руководитель».
Как следствие, вы сможете прогнозировать перспективу своей карьеры и на раннем этапе принять решение о том, стоит ли продолжать работать или нужно искать «другую комнату».
