Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2010-08-02 03:55    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

Шуруп в ботинке

Простой пример
Кодекс профессионала
Берегите лоб (как ничего не забыть и все успеть)
Смотреть - не значит видеть
Почему не получается?
Работа - это...
Здесь должна была быть методология

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

Простой пример  ^

Допустим, вы мужчина и весите 85 кг, или женщина и весите 49 кг. Можно больше или меньше - это ничего не изменит. Допустим вы пробегаете 400 метров за минуту и 6 (или 22) секунды (3й юношеский разряд у мужчин/женщин). Но даже, если за 2 минуты - это тоже хорошо.

А теперь внимание, вопрос: как изменится результат, если добавить 10 граммов к вашему весу?

Очевидно, многие скажут, что никак и будут правы - ваши кроссовки весят 300-400 граммов. А 10 грамм жидкости вы уж точно потеряете с потом во время разминки и забега.

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

К чему это я? А к тому, что как всем нам хорошо известно:

Дьявол кроется в мелочах.

Нам всем знакома риторика, что самолеты стоимостью миллионы долларов часто падают из-за отказа копеечных элементов конструкции - болтов, заклепок или контактных разъемов. Все знают стишок про гвоздь и подкову (см. здесь). Все знают понятие "Эффект бабочки". О чем-то подобном писал даже Лао Цзы.

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

Кодекс профессионала  ^

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

Мелочей не существует.

Все, что мы считаем мелочью, просто, нам не знакомо. Каждая мельчайшая деталь в работе, (не)учтенная сегодня, завтра поможет, помешает или (что реже) не повлияет на работу. Для профессионала допустимо только такое отношение к мелочам - оно заставляет думать о связи завтрашнего результата, с сегодняшней работой и, в итоге, заставляет непрерывно развиваться.

Возвращаясь к метафоре шурупа в ботинке, можно сказать, что этот шуруп в этом месте не мешает только тому, кто сидит, задрав ноги на стол, никогда не бегал 400 метров и в будущем не собирается.

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

Берегите лоб (как ничего не забыть и все успеть)  ^

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

О чем здесь речь? Естественно - если со всеми мелочами работать в лоб, то есть большой риск под ними утонуть. Мелочи - они на то и мелочи, чтобы их было слишком много. И тут встают сразу две проблемы:
1. как ничего не забыть?
2. и как все успеть?

В общем все просто: записывать и приоретизировать.

Контрольный список - это один из самых простых инструментов работы. При этом он настолько эффективен, что возникает удивление, когда становится ясно, что некоторые коллеги не умеют и не хотят его применять.

Когда работа хорошо структурирована, для управления ей применяются многие опорные списки, матрицы, схемы и другие каркасные документы. Но сначала достаточно одного списка: "Открытые вопросы (+ответы на них)" - все вырастает из него.

Но самое главное: при любой работе мы должны понимать, что полностью сделанная работа означает знание всех деталей.

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

Конструкционные стали - очень неподатливый материал. Для обычных болтовых соединений достаточно несовпадения координат отверстий на соединяемых деталях на 1/20-1/10 диаметра, чтобы болт не встал на свое место. По этому в машиностроении с большим подозрением относятся к идее отдавать подобные конструктивные решения рабочим.

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

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

При этом часто мы забываем, что между "это возможно" и "это реализовано" лежит ответ на вопрос: "сколько стоит?". Это и есть та мелочь, которая делит нас всех на два лагеря:
- первых раздражает утверждение "это не проблема" в ответ на установку любого вопроса (так как это не дает нам подойти к детализации решений и довести дело до конца),
- вторых раздражает занудство с задаванием множества несущественных (на их взгляд) вопросов - тогда становится ясно, что "они свою работу делать за вас не будут" (c).

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

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

А сейчас вернемся к вопросу, как все успеть.

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

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

Вот почему меня раздражают слова о том, что "эта мелочь - не проблема" одновременно с тем что команда не может объяснить, как она (не)влияет на ключевые параметры проекта. Это означает, что мы двигаемся вперед с закрытыми глазами (и гордимся этим).

Единственно приемлемый ответ, когда мы не знаем, что ответить - это записать вопрос и спланировать получение ответа на него.

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

Смотреть - не значит видеть  ^

И тут нам есть, что обсудить...

Доктор в человеке вместо рук, ног, туловища и головы видит 206 костей, 41 вид внешних образований и 11 систем, содержащих в сумме сотни органов.

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

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

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

Так где же взять список вопросов для проекта по созданию некой вещи? Очевидно, необходимо посмотреть, как она устроена, зачем нужна и кому, представить себе целевое состояние и, опираясь на текущее состояние, принять план перехода.

Следовательно первые вопросы уже определены:
- Какие проблемы решаем?
- Почему мы решаем проблемы именно с помощью данной вещи, а не другими путями?
- Кто, какую пользу будет получать от создаваемой вещи и как это произойдет?
- Как будет проявляться получение пользы в непосредственном контакте с вещью?

Далее идут более специфичные вопросы:
- из каких частей должна состоять наша создаваемая вещь, чтобы принести должную пользу?
- Как эти части должны быть взаимосвязаны и как они должны взаимодействовать?
- Что нужно обеспечить снаружи, чтобы вещь начала приносить пользу?

Построив целевое состояние, мы должны обратить внимание на то, что есть у нас сейчас и продумать план перехода:
- какая компонентная база есть для построения вещи?
- какие рабочие операции нам доступны для разработки/доработки компонентов и соединения их в целое?
- что сейчас находится на месте нашей вещи?
- какие шаги необходимы для "расчистки" территории, создания всех частей, соединения их в целое и запуска необходимых нам взаимодействий?

Кроме вопросов, непосредственно ведущих нас к результату есть еще и вопросы о том, как мы будем двигаться:
- кто нужен для получения результата?
- как будет устроено управление?
- как будет устроена коммуникация и координация?
- как будет устроено снабжение и администрирование?
- как будет устроена и как будет поддерживаться техническая инфраструктура?
- что еще мы должны обсудить?

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

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

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

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

Почему не получается?  ^

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

Почему, все же, с мелочами столько проблем? Тут есть несколько причин.

Лень и отсутствие желания развиваться, которые мы иногда встречаем у коллег. Дело в том, что рассуждать о том, как "космические корабли бороздят просторы большого театра" (c) или создавать решения "для сферического коня в вакууме" (c) гораздо проще и менее ответственно, чем "каждый болт (из пяти тысяч) поставить в свое отверстие и закрутить с заданным усилием". Детали пугают новичков и отдушиной для некоторых из них иногда становятся проекты по освоению бюджета или околомаркетинговые теории от консалтинга, которые из года в год клеят новые ярлыки на давно известные принципы, продавая бизнесу "лекарство для похудения" или программы "12 шагов к успеху".

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

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

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

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

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

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

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

Разное видение целей и горизонтов планирования, пожалуй, одна из проблем, котрые имеют объективные неустранимые причины. Может случиться так, что вещи, создающие проблемы проекту могут быть выгодны департаменту и некоторым участникам проекта; а выгода департамента может быть проблемой соседнего департамента. В итоге формальные цели проекта часто остаются на бумаге, при том, что в жизни каждый сам за себя.

Решение вопроса в балансировке интересов и целей всех заинтересованных сторон, или полном исключении политической составляющей, что само по себе возможно не всегда.

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

Работа - это...  ^

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

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

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

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

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

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

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

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

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

В итоге можно видеть, что путь к развитию и возможность получить желаемое все же существует, но он лежит вне зоны комфорта...

Здесь должна была быть методология  ^

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

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

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