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

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

Из жизни проктологов!

   О чем раздел
   Это как...
   Из дневника юного натуралиста
   Что делать
   К чему это все

О чем раздел  ^

Каждый, кто пожелает оглядеться вокруг с удвоенным вниманием, может обнаружить на каждом шагу множество начинаний: больших и маленьких, успешных и не очень, правильных и нет. Существует много определений, которыми можно наделить целенаправленную деятельность. Сегодня мы поговорим об одном из них...
Давайте спросим себя: что значит ЧЕРЕЗ ЗАД? Это достаточно частое определение способа выполнения работ, которое мы встречаем сплошь и рядом. Несмотря на скандальность термина и кажущуюся тривиальность определения, я хочу внимательно рассмотреть как способ, так и причины, приводящие к его применению. На мой взгляд, за затертой фразой стоит достаточно глубокое и фундаментальное явление, являющееся на сегодняшний день фундаментальной проблемой для профессионального ИТ сообщества.

Это как...  ^

Что такое "через зад"? Источник моего определения в проведении параллели между жизнедеятельностью какого-нибудь организма и процессом целенаправленной профессиональной деятельности.
В случае деятельности организма, он получает материальные и нематериальные входы через рот, глаза, уши и другие органы чувств, избавляется от продуктов жизнедеятельности через органы системы пищеварения. Цель же его деятельности и истинные результаты лежат вне процесса преобразования входов в выходы, кроме этого большая часть процесса и промежуточных результатов скрыта от глаз. В случае сложной профессиональной деятельности происходит то же самое: какой-то результат получается в ходе рабочего процесса, появляется множество артефактов, на первый взгляд, мало связанных с результатом. Практика показывает, что со стороны плохо видны как истинные цели, так и большая часть процесса достижения, зато хорошо видны побочные продукты.
Так вот, попытка построения рабочего процесса только на основе знаний о промежуточных результатах или сосредоточение исключительно на последнем результате, минуя сам процесс, и приводит к работе, построенной "через зад".
В качестве примера можно привести диалог из серии "мельчают наши слоны", состоявшийся здесь (в подфоруме "работа" UML2.RU). Коротко, вопрос, заданный автором топика звучал так: "почему соискатели на должность аналитика, не знают теорию?". В середине топика был приведен экспериментальный мониторинг вакансий, в котором было показано, что работодатели в меньшей степени требуют от соискателей знаний системного анализа или теории управления требованиями, но требуют знания конкретных инструментов моделирования (UML, ARIS и т.д.). Опыт показывает, что в большинстве случаев это и есть через зад, так как на собеседовании часто выясняется, что возможности этих инструментов в данной фирме не используются и на 10 процентов, а истинным двигателем процесса является здравый смысл и знание предметной области.
В качестве другого примера можно привести ситуацию, когда не очень большой фирме требуется автоматизация. Кого брать на работу? Конечно же программиста. Что от него требовать? Конечно же владения инструментами программирования. Через некоторое время фирма нанимает студента или вчерашнего выпускника, который за 3-4 копейки зарплаты разрабатывает небольшую систему автоматизации. Все бы хорошо, но практически всегда это заканчивается тем, что специалист, подучившись, уходит, и оставляет фирме кривую студенческую поделку, нуждающуюся в развитии и сопровождении. Кого ищет фирма? Опять программиста и очень сильно удивляется, что для поддержки и развития того, что сделал за пару лет наш талантливый юноша, требуется целая команда из руководителя, аналитика, системного администратора и пары программистов. В чем здесь заключался "через зад"? Фирма руководствовалась простой логикой: что нам нужно, нам нужна программа; кто делает программы, программы делает программист; значит, берем программиста. Никто не думал (по тому, что не знал), что писанию программы предшествует постановка задачи, а постановке задачи предшествует постановка цели. программист, которого наняли для написания программы тоже не знал (так обычно бывает), что ему предстоит работать за троих: аналитика, программиста и администратора, а иногда и за много кого еще. В результате мы получаем то, что получаем...

Из дневника юного натуралиста  ^

Случаев работы, поставленной в фирме или подразделении через зад, не перечесть. Такое встречается сплошь и рядом. Основным признаком является то, что получение результата полностью находится в руках одного человека. Если речь идет о разработке ПО, то такой человек-оркестр обычно и заведует сбором требований, и пишет код и документацию (если она нужна), и занимается внедрением и поддержкой пользователей, и делает много других вещей. При этом, если требуется расширить круг решаемых проблем, то берется такой же человек-оркестр для закрытия параллельного направления. Начальство, привыкшее к такому стилю работы, обычно сопротивляется разделению труда с выделением ролей, так как им не до конца понятно, что полезного будут делать люди, производящие промежуточные результаты (например, техническое задание или сценарии тестирования).
Доводы начальства именно так и звучат: "что будут делать эти люди, я не понимаю." И такая ситуация наблюдается повсеместно. Эти доводы я слышал и от начальника отдела, занимающегося внедрением софта и от директора небольшого машиностроительного производства, когда он спрашивал, почему в производстве на 10 монтажников есть еще 10 человек (занимающихся снабжением, технологической подготовкой и организацией производства), что полезного они приносят?
На рынке труда наблюдается та же самая картина. В ответ на вопрос, кто такой аналитик, люди отвечают для себя: это тот, кто знает UML и ARIS, не понимая, что если ты не можешь систематизировать информацию в текстово-табличном виде, то никакие нотации и системы моделирования тебе ничем не помогут. В ответ на вопрос, кто такой менеджер проекта, люди отвечают для себя - это тот, кто читал PMBOK и имеет сертификат PMP и начинают свой путь с изучения тонны мертвых инструментов и методик (зачастую по кривым переводам), не понимая сути и целей, стоящих перед проектной ролью "менеджер проекта". Кульминацией проктологического подхода в профессиональном самообразовании являются попытки стать профессионалом путем освоения программ, сопутствующих профессиональной деятельности. Как просто: изучил MS Project или Rational Rose и дело в шляпе, все работодатели твои...
Это все было бы смешно и немного наивно, если бы не имело, действительно, глобальных масштабов. Сегодня научиться новым методам управления через программное обеспечение хотят не только люди, но и целые компании. Вот фрагмент типичного диалога, который мог бы состояться на паре сотен софтверных конференций и выставок только в этом году.
- У вашей системы есть типовая настройка?
- Настройка системы выполняется под каждого заказчика индивидуально. Наша практика показывает, что двух одинаковых заказчиков не бывает.
- Да что там разного, эта деятельность везде устроена одинаково.
- Ну у вас есть регламенты, описывающие вашу деятельность?
- Нет.
- Но есть стандарты СМК, ИСО9000?
- Есть.
- Они соответствуют вашей деловой практике?
- не более, чем на 10%.
- То есть вы хотите вместе с нашей системой приобрести управленческий консалтинг, но бесплатно...
- Да, хочу. Ведь для кого-то вы уже ставили эти процессы. Они меня вполне устроят, заложенные в вашу систему.
Так вставить себе новые мозги за три копейки хотят многие фирмы. И не только потому, что им жалко денег. Очень часто для того, чтобы заказать управленческий консалтинг, надо признать, что текущая ситуация не соответствует поставленным задачам. А для этого надо признать изъяны в своем собственном профессионализме, а главное, поставить своему бизнесу адекватные ситуации задачи. Гораздо проще уповать на чудо-инструмент, который в одночасье все расставит по местам, а если внедрение не заладится, то ответственность можно спихнуть на внедренцев.
Это все грустно наблюдать и еще более грустно бывает в этом участвовать. Однако, совсем не хочется оставлять читателя в таком настроении. Поэтому давайте посмотрим, что можно сделать, имея четкое представление о том, что есть "через зад" и что есть не "через зад".

Что делать  ^

Для начала посмотрим, как ДОЛЖЕН быть построен процесс получения результата, и как он может быть построен в реальности.
На рисунке показана жестокая модификация (вплоть до неузнаваемости) широко известного цикла управления: входное воздействие - управляемая система- измерение результата - коррекция воздействия. Рассмотрим компоненты процесса более подробно.
Основной производственный процесс - процесс, на выходе которого получается результат, непосредственно служащий цели. Для разработки коробочного ПО этот процесс может включать производство исходного кода, написание документации, сборку приложения и завертывание его в дистрибутив вместе с документацией.
Процесс планирования - процесс, в результате которого мы получаем более или менее точный образ результата, позволяющий измерить трудоемкость основного производственного процесса. Для нашего примера это процесс производства спецификации требований и все, что этому сопутствует: сбор требований моделирование, проектирование, дающие нам представление о количестве функций, классов, модулей, глав документации в системе и их взаимозависимости.
Процесс обеспечения качества - процесс измерения результата, который дает нам понимание, насколько близко мы приблизились к концу процесса производства или к установленным показателям. Например, процесс тестирования, дающий нам точное понимание, сколько функций реализовано должным образом и сколько нет.
Процесс снабжения - процесс обеспечения всем необходимым: рабочие места сотрудников, настроенная среда разработки и сборки приложений, развернутая на сервере версионная система, тестовые стенды и все, что необходимо для функционирования других процессов.
Процесс управления заставляет все остальные процессы протекать более или менее слаженно.
Каким бы ни был проект: большим или крохотным, все вышеописанные процессы так или иначе находят в нем свое место. Такой взгляд на деление процесса получения результата может претендовать на объяснение известного менеджерам правила: "спроси у программиста о сроках, умножай на 3 и ставь в план". Все узкие профессионалы сосредоточены на той деятельности, которая для их работы является основным производственным процессом, поэтому такие мелочи, как настройка компилятора для сборки приложения, тестирование, потери времени на выбивание тестового сервера из хозяйственной службы, настройку версионной системы или просто время на размышления, они не учитывают, давая оценку трудоемкости работы. Однако менеджерам не позволена такая роскошь, так как знание полного процесса, находящегося под их управлением - это их работа.
Разница между промышленной и кустарной организацией работ заключается в том, что в первом случае за разные виды процессов (описанных выше) отвечают разные люди, глубоко специализирующиеся каждый в своей области, во втором случае весь цикл находится в руках одного - двух человек. Разница между кустарной и проктологической организацией работы заключается в том, что во втором случае не учитываются (читай, не выделяется ни времени, ни ресурсов) на все процессы, кроме основного производственного. Отсюда зачастую и вытекает постоянный аврал и сомнительное качество (а то и полное отсутствие) результата. И каждый из трех вариантов построения процесса встречается в окружающей нас действительности. По моим наблюдениям, чаще всего жертвуют планированием и обеспечением качества, подвешивая работу в полной неопределенности. А вам так не кажется?

К чему это все  ^

Текст вышел немножко сумбурным, поэтому вдвойне необходимо повторить основные мысли, которые он призван донести до читателя.
Во-первых, большая часть процесса достижения любого результата скрыта от глаз. Для того, чтобы скопировать чужой результат надо начинать с четкого определения и сравнения целей, но ни в коем случае не начинать с той части процесса, которая находится на поверхности и хорошо видна со стороны - с большой вероятностью это всего лишь малая часть, причем не первая во времени и не основная в общем процессе.
Во-вторых, при организации любой деятельности после построения основной производственной цепочки следует обязательно задать себе вопросы о процессах снабжения, планирования и обеспечения качества: как они будут организованы и кто за них будет отвечать.
Во третьих если цепочки от источников основных ресурсов до результата оборваны, мы рискуем не получить никаких результатов: глупо разрабатывать то, к чему не предъявлены требования, глупо нанимать внедренцев, если ты не можешь продать проект внедрения, глупо брать обязательства, если они не обеспечены ресурсами, глупо изучать ARIS, если ты не понимаешь сути и места бизнес-процессов в своей профессиональной деятельности и много чего еще глупо...
И наоборот, результат любой деятельности будет положительным с очень большой вероятностью, если включить голову с самого начала.
А для того, чтобы еще раз убедить тебя, читатель, в том, что банальные выводы в конце этого текста работают, предлагаю небольшое домашнее задание. Найди в своей профессиональной деятельности все 5 процессов, которые здесь обсуждались. Чьими руками и головой они осуществляются? Ближе к какому типу производства (промышленному, кустарному или проктологическому) ты отнесешь свое? Возможно, эти простые упражнения помогут тебе сделать свою ситуацию еще лучше, чем она была до этого...