Одо, ИТ и все, все, все

(запись сделана под впечатлением от 2 главы ОДО2021 и работы в ИТ-отрасли)

Ролевое поведение это неотъемлемая часть человека как интеллектуального существа. Мы входим в роли и выходим из них чаще всего даже не замечая, что этот процесс происходит. Разнообразие ролей говорит о том, насколько интеллектуален человек - при этом это не стоит путать с эрудированностью (навыком запоминать факты из различных областей деятельности). Мы уважаем людей, которые с одинаковой трепетностью к деталям и знанием дела строят дом и лечат других людей, управляют командами и показывают навыки в спорте. Однако что же показывает степень интеллектуальности человека - глубина проработки отдельной практики или возможность быстро учить новые. И то, и другое - глубокий навык, который позволяет зарабатывать деньги, а переключение позволяет охватить вниманием больше объектов и не застояться.

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

Можно ли решить эти проблемы - возможно следующие шаги помогут в этом деле:

  1. Так как роль не завязана на конкретного человека, то её исполнение должно быть возможно другим человеком - для этого нужно максимально формализовывать и выводить наружу свои знания и опыт (документы, программы, скрипты, чек-листы и прочее). Если человек не делает этого - он часто защищает себя через механизм "job security". Такой подход приводит к застаиванию, боязни увольнения - не нужно бояться увольнения, особенно если вы знаете, в какую сторону можно развивать интеллект и что всегда есть "stepping stones".
  2. Учиться коммуникации, знать роли - так проще узнать у других, чего они хотят и что нужно вам. Причем коммуникация бывает не только с исполнителями ролей, но и документами (ведь их кто-то тоже написал).
  3. Перестать рассматривать работу как только источник дохода или среды для обучения - все-таки бизнес нанимает вас решать свои задачи и проблемы и вам нужно понимать, что за задачи вы решаете.
  4. В курсе ОдО часто упоминается, что нужно руководстоваться SoTA в видах деятельности - это правильно, но в ИТ это правило превратилось в карго-культ: разработчики тянут всё "новое" (на поверку часто оказывается, что это новое - забытое старое) в проекты, чтобы пополнить резюме. В результате мы видим огромные кучи кода, которые справляются с задачей обучения автора, но не делают хорошо пользователям программ (вспомните навскидку сколько раз в день вы встречаесь с ошибками в ПО, зависшими страницами, потерями данных - боюсь, что в мире скоро не останется людей, которые не встречают ошибки каждый день).

#сиОдО

Игорь, отличный пост!

Долго думал над SoTA в ИТ, в частности, в программировании, и понял, что не могу найти способа достоверно определить SoTA-методику. Каждый “топит” за свой подход, аргументация вроде бы со всех сторон разумная. А если принять, что для каждого проекта SoTA будет своей, - это все равно не меняет сути вопроса - как ее гарантированно определить? Что Вы думаете по этому поводу, как Вы бы стали искать SoTA в ИТ?

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

Жизненно! И по моим впечатлениям — основная пробуксовка, основные сложности в IT-проектах из-за не налаженной коммуникации (как с исполнителями ролей, так и с документами, да). И ведь люди-то в основном все умные, слушают друг друга на ежедневных митингах; но не всегда друг друга понимают…