Напиши нам программку…

в 7:28, , рубрики: Анализ и проектирование систем, Исследования и прогнозы в IT, Песочница, управление проектами, метки: ,

Здравствуй, читатели.
Идея данной темы для обсуждения пришла ко мне довольно давно, но поводом, толкнувшим к собственно тому, чтобы открыть редактор и написать текст, послужило недавнее собеседование. Но обо всём по порядку.

Введение

В 2009–2011 гг. я вёл проект системы управления знаниями (СУЗ) для одной довольно крупной компании. Собственно, этот проект сам по себе является поводом если не цикла статей, то уж двух-трёх точно. Именно в ходе реализации этого проекта я в полный рост столкнулся с одной огромной проблемой — мифологизации информационных технологий. Самое страшное то, что ей подвержены вроде бы взрослые люди, и даже временами выходцы из этой отрасли.

Проявляется это явление в том, что почему-то весь менеджмент поголовно (за очень редким исключением) считает, что внедрение какого-нибудь современного и волшебного программного обеспечения, в редких случаях — информационных систем, — всё резко изменит, и те же самые люди, занимающиеся той же проблематикой (но почему-то не желающие работать так, как того хочет руководство), начнут работать с отдачей 110%. Вот так-то смешно написано, и вроде как банально, но примеров несть числа. К примеру, СУЗ.

О передаче знаний и главном мифе ИТ

Основной задачей СУЗ является сбор и распространение знаний внутри компании. Есть ещё задача генерации знаний, но её пока рассматривать не будем, с ней, в общем-то, научные работники вроде как обычно справляются. Так вот, для того, чтобы успешно собирать и распространять эти самые знания, требуется в первую очередь, чтобы каждый ключевой работник при возникновении необходимости поделился тем, что наисследовал, придумал, написал, и т.п. То есть — чтобы не было психологического барьера «ты у меня списываешь», «ты будешь получать деньги за мою работу», «я рыл эту яму три дня, ты должен потратить не меньше», и т.п.

Замечу в скобках, что несколько особняком стоит позиция «дай человеку рыбу, и ты его накормишь сегодня» — она скорее относится к вопросу внутреннего обучения. Мы же сейчас говорим про состоявшихся специалистов, которым требуется доступ к знаниям для завершения конкретной работы, или для планирования сроков (в случае менеджеров), или ещё что.

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

  1. большое количество форумов и вообще интернет-ресурсов всевозможных тематик;
  2. привычка делиться своими знаниями;
  3. понимание принципа «если я сегодня помогу ему, то завтра он может помочь мне»;
  4. понимание того, что количество информации при копировании не уменьшается, а увеличивается;
  5. и более того, возможен эффект, что при передаче знаний они самопроизвольно увеличат свою ценность и актуализируются.

То есть «высокоуровневые» айтишники в основной своей массе приучены делиться этими самыми знаниями, иначе бы они не стали тем, кто есть сейчас.

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

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

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

Дальше, я думаю, все дополнить могут. В особо запущенных случаях (предваряя вопросы — да, у нас был именно тот самый вариант) вносятся предложения об организации внутреннего вконтактега, «чтобы люди могли общаться по сети».

Здесь, кстати, надо оговориться, что все эти схемы — создание форумов, проведение летучек, создание вконторок — оправданы в некоторых случаях, когда предприятие для них созрело. Но в нашем-то случае люди не знают, что делает коллега за соседним столом!.. А менеджеры (если таковые предусмотрены в структуре) не владеют информацией о том, какие проекты были проведены на предприятии за последние, скажем, три года (хотя бы по своей области), и какие были натоптаны на них грабли.

То есть, говоря кратко, на ИТ-отдел возлагается задача службы кадровой политики по командообразованию, обмену опытом, налаживанию коммуникаций, и т.п. А они не для того придуманы. Более того, если в ИТ-отделе найдётся разумный человек и попытается решить проблему соответствующими методами (то есть пойдёт учить людей говорить друг с другом), или просто не подпишется под данной задачей, руководство его одёрнет: «ты айтишник? вот и напиши нам программку...»

Напиши нам программку

Я думаю, эти слова слышал каждый специалист в ИТ-области. Зачастую это попытка решить их проблемы за наш счёт, потому что если программа не решит задач, то это программа плохая, а если решит, то «вот как я хорошо придумал!».

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

В моём случае СУЗа (да и в рассмотренном в предыдущем разделе примере гипотетического предприятия) была именно ситуация неверного окружения. То есть людей, разбросанных географически, зачастую не связанные общими проектами, целями — ничем, кроме названия организации — требовалось объединить в одну сеть и сказать: «делись своими знаниями!». Пардон, а зачем? Кому это надо? Сотруднику, у которого загрузка варьируется от 110% до 150%? Руководителю, у которого будут сотрудника отнимать?

Такое могло бы сработать при наличии чётко прописанных регламентов и руководств в стиле, например, Schlumberger — после сдачи проекта провести семинар по обмену извлечёнными уроками проекта. Или при выявлении и успешном решении какой-либо проблемы в срок не более одного дня фиксировать результаты во внутренней базе.

То есть в первую очередь организовать правила обмена знаниями в виде семинаров, летучек и прочего. Что совсем не айтишная задача — это задача отдела кадровой политики. Это методологическая задача, которая зачастую не решена на момент запуска айтишного проекта. Более того, обычно даже не осознаётся необходимость данного проекта, а также невозможность успешного внедрения получившегося продукта в эксплуатацию.

Внимательные товарищи тут могут спросить: а как же работает, например, Stack Overflow — с виду же нет общих регламентов, заставляющих программиста из России запостить вопрос, а программиста из Австралии на него ответить?..
На самом деле такие регламенты есть — тот самый регламент вида «помучайся 20 минут, не получается — спроси у соседа», внедряющийся в командах по всему миру. Именно он заставляет искать ответ в первую очередь у соседа, а потом, вместе — в Google. И именно он потом заставляет открыть страницу с незакрытым вопросом на Stack Overflow, и ответить на него. Просто потому что тут так принято.

Возвращаясь к мифам. Основной и самый главный — программа нам поможет. То есть без разницы что делать, насколько ясен процесс, насколько он хорошо документирован, но если написать программу — всё будет пучком. На самом деле, разумеется, нет. Всегда требуется учитывать не только развитость ИТ-инфраструктуры (и даже не столько!), но и внешние условия.

Внешние условия

На самом деле, я бы долго ещё думал о том, чтобы сюда написать, если бы недавно не сходил на одно собеседование, где было упомянуто о системе «Умный город». Когда я поинтересовался, что же входит в это понятие, мне рассказали много интересного, включая идею об автоматизированном регулировании дорожного потока. То есть о специальном программно-аппаратном комплексе, который централизованно управляет светофорами, формируя потоки автотранспорта, которые впоследствии оперативно пропускаются по маршрутам. Заявлено, что город разгружается на 25%. Ага, в солнечной Австралии.

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

Засим спасибо, хабр, за внимание, а тем, кто дочитал до конца — двойное спасибо.

Автор: norritt

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js